UNIX was a terrific workhorse for its time, but eventually the old nag needs to be put out to pasture. David Chisnall argues that it's time to retire UNIX in favor of modern systems with a lot more horsepower. "UNIX has a lot of strengths, but like any other design it's starting to show its age. Some of the points listed in this article apply less to some UNIX-like systems, some apply more."
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2005-11-06
Yes, go and play with MSH and it's superior object-oriented semantics. You probably have no clue how much more powerful making ps list System.Diagnostics.Process objects instead of some crappy text is.
An object-oriented system like MSH could work very nicely. What's great about UNIX shell commands and their reliance on text, however, is that everything understands text. APIs may shift and different tools may be designed to work with different object sets, but text is text, and if it's not quite in the correct format, there are formatting tools to massage it quite easily.
And they will make crappy programs with tons of strcpy()'s, buffer/heap/integer overflows, format string bugs..why not use C# or C++/CLI or any other managed language and forget these classes of bugs which UNIX heritage cursed unto us?
Managed languages are slower to run and use up more resources. I think there are a lot of people with older systems who are thankful their OSes are not running on a VM.
C is a pain in the ass, but I'm not sure object-orientation is the ultimate answer. It's painful, sometimes, to see some programming tasks crammed into an OO model. A good, low-level, "portable assembler" is required for an OS because it has to run on bare metal, with hardware access, and because at the very bottom of the abstraction stack it has to be the most efficient. C is not ideal for this, but it's as good as I've seen.
Member since:2005-07-06
> text is text, and if it's not quite in the correct format, there are formatting tools to massage it quite easily.
Well if you use only ASCII text for English, sure, but I bet that a huge percentage of shell scripts break when the input is in Chinese UTF-32..
With UTF-8, it works probably better, but before saying "text is text", read the Unicode specification, you'll get an headache!
Text is not so simple as you're suggesting.
Member since:C is a pain in the ass, but I'm not sure object-orientation is the ultimate answer.
I'm sure object-orientation is not the ultimate answer.
It's painful, sometimes, to see some programming tasks crammed into an OO model.
I agree 100%. Isn't it nice to have a language that allows such abstractions when it is appropriate, but doesn't force those abstractions when it is not? Isn't C kind of like that in some ways? No, C doesn't force you to use object oriented abstractions. It does force you to use a certian set of abstractions though. Now, don't missunderstand me, it is certianly possible to use other models in C, but the language doesn't make it easy, and some models are almost impossible in C. I belive C actually inhibits our understanding of what is conceptually possible in in OS.
A good, low-level, "portable assembler" is required for an OS because it has to run on bare metal, with hardware access, and because at the very bottom of the abstraction stack it has to be the most efficient.
Really? It is? So, a higher level language cannot be made to "run on bare metal"? Why not? I can't think of any reason why you have to use a "portable assembler" to write an OS.
In fact some people are working on just the thing:
http://tunes.org/
http://unununium.org/
http://common-lisp.net/project/movitz/ (History if full of Lisp Machines)
http://www.cse.ogi.edu/~hallgren/House/
I can hear it now: "But these languages don't perform as well as C" Well, of course, that is true, however, some of these languages come aweful close to C in performance. Really, is it worth giving up saftey and protection for a few extra microseconds of performace? For scientific applications it may be, but not for general computing. Think about it. The buffer overflow is a very well documented and understood problem, and has been for a number of years now. Yet, the buffer overflow is still one of the biggest security problems of modern computing. C, as a programming language, forces you to think about insignificant issues that you shouldn't have to think about.
"Inefficient software isn't gross. What's gross is a language that makes programmers do needless work. Wasting programmer time is the true inefficiency, not wasting machine time. This will become ever more clear as computers get faster." -- Paul Graham (http://www.paulgraham.com/hundred.html)
My whole point is that C, as a language, may be (not is, but may be) hindering our understanding of what an Operating System is and what an Operating System should and can do.
Member since:
one big weakness he finds is Unix's reliance on text streams, largely (as best I could figure out) because they don't support unicode. His proposed solution: switch to binary data! Aside from text being binary data
Of course it is, but ls, sort and other dummy UNIX tools don't understand them unless they are ASCII.
If you want "binary data" go play on Windows, with their atrocious mess of strung together and interlocking COM interfaces. I'd rather have text, in Chinese.
Yes, go and play with MSH and it's superior object-oriented semantics. You probably have no clue how much more powerful making ps list System.Diagnostics.Process objects instead of some crappy text is.
Of course, we have the usual objections to C as being "out of date," and as we all know, C and Unix are one and the same thing. Chisnall really doesn't understand this subject. There are great alternatives available for application programming if you prefer them, but just about every current OS is written in C (for good reason) with no viable competitor in sight.
Almost all public windows user-mode libraries are written in C++ and based on COM, even some parts of kernel are writen in C++ (USER/GDI inside win32k.sys). On Windows and MacOS you can use C++ (at least a large part of it) to write drivers, on Linux and other UNIXen...you can't. Why? Because Linus has astrong objection to it - he thinks C++ is "bloated". Ugh.
Until that changes (and all OS's are rewritten), OS API's will be exposed in C and a lot of people will choose to use C/C++ to program them. I'm sorry if that causes him pain!
And they will make crappy programs with tons of strcpy()'s, buffer/heap/integer overflows, format string bugs..why not use C# or C++/CLI or any other managed language and forget these classes of bugs which UNIX heritage cursed unto us?