Slashdot Mirror
What is UNIX, Anyway?
Lieutenant writes "Technology professionals have loosely used the term "UNIX" since the first person had to explain the difference between the Berkeley and AT&T flavors, so it's not surprising to find as many UNIX standards as there are versions of the operating system. Peter Seebach wades through the wellspring of UNIX standards and sorts them out for you, concluding that the rumors of the death of UNIX are (as usual) greatly exaggerated."
isn't unix:
./configure && make && make install
- everything is a file
- every file is a stream of bytes
- do one thing and one thing well, Keep It Simple Stupid
- human readable/editable config files
- principle of least privilege
- services as daemon processes
- clear separation of kernel and userland (although this one is debatable)
- multi-user environment (despite the name)
- remote access facilities
- console/automation oriented, powerful shells
-
?
well, that's just a few things that come to my (linux/bsd slanted) view of what (a modern) unix is...
VMS is absolutely nothing like Unix.
Do you even lift?
These aren't the 'roids you're looking for.
I code for this API and the sources end up being source compatible.
Oh boy, you haven't deployed any code in the real world, have you?
The total number of conformant implementations of SuSv3 (or even v2) is zero. None. Zip. Zilch. Nada.
Everything, including the linux/glibc, BSD, and proprietary unix-like platforms, differs from the spec in subtle and complicated ways. SuS and POSIX are paper standards, not things that you will encounter in software. They're fodder for managers and marketing; they have little or no engineering value. And the differences are important to the point where you have to modify the source of your program to support other platforms, once the program becomes sufficiently complicated. As a rule, a complex program with no platform-specific hacks is a complex program that has bugs on some platforms which have not been found/fixed yet.
This isn't likely to change in a useful manner. Most of the platforms approximate SuS/POSIX as closely as they can without breaking existing applications. Successive revisions of SuS/POSIX become more vague in order to encompass more of the things that happen in the real world. So a good way to look at these two is to consider them an inefficient and fairly inaccurate attempt at documenting the common features of a set of platforms. If this process was completed perfectly, the resulting document would be so vague and cover so many platform-specific hacks that it would be of limited value. Since the documents get updated much more slowly than the software, they will probably never be completed to a satisfactory level of accuracy.
Which is why we have BSD.
I'm the guy with the unpopular opinion
>...we, erm, wouldn't need Autoconf?
Actually, that is precisely why autoconf can exist.
Because Unix is a stable and standardised
API the differences between various flavors of Unix
are small enough that it's possible to write
an application like autoconf/automake that
can handle the small differences between the
platforms.
As someone who has had to write over 100 packages for
portability I appreciate that the flavors of Unix
are close enough that autoconf/automake can work.
--Johnny
Yup. UNIX isn't an OS. It's a trademark and a standard. And Linux is a kernel, not an OS.
http://www.unix.org/
http://www.kernel.org/
Also Windows aren't OS. It's an opening constructed in a wall or roof that functions to admit light or air.
Lastly Apple is not a company. It's a god damn fruit. Why is that ESPECIALLY MacOS users don't seem to get that Apple Computers are PC!?!? Try to ask a MacOS user this. "Do you have a PC?" I bet, 99% of them will say "No, I don't have PC, but I have a Mac." WTF??
"Don't let fools fool you. They are the clever ones."
Not really.
Firstly, because that list is artificially inflated ("Win32, WinNT, WinXP" are all the same thing - Win32).
Secondly, because the unix side is just as bad, if you compare apples to apples (ie: throw X and associated libs into the mix - how many widget libraries can you name ?).
Thirdly, because binary compatibility on Windows is very well maintained. It's not uncommon for those twenty year old DOS and Win16 binaries to run unmodified on Windows XP or 2003 (and probably Vista). Woe betide most with a twenty year old non-trivial unix app and no source code. Heck, with something like Linux you're lucky if binaries work between one major relase and the next, let alone 10 - 20 years worth of them.
I presume you mean "...apps only work if they are trivial".
I hate Microsoft as much as anyone, but if you have apps that run on Win95, but not NT-based systems, it's because they violate some fundamental rules of Window's APIs. Win95/98 were notoriously lax about enforcing those rules, which was certainly a big factor in the unreliability of Win95/98.
Most people don't even think inside the box.
More useful than the specification itself is Advanced Programming in the UNIX Environment. This is my absolute favourite reference for UNIX programming. Not only does it cover the POSIX spec (and SUS and a few others), it also tells you which bits have been implemented, and with what limits, in Solaris, FreeBSD, Linux and Mac OS X. It's slightly out of date (obviously, since it wasn't published today); for example it says that OS X 10.3 doesn't support most SysV IPC mechanisms which, while true, is not particularly useful since 10.4 does support them. It's a useful base-line though.
I am TheRaven on Soylent News
This attitude was (and to a great degree still is, though somewhat less than before) is the single most cancerous and evil mode of thinking in computer science, and yet it went widely accepted ("unchallenged" would be wrong) in Unix circles and associated hanger-on CS departments for years. The correct attitude should have been "if users are making the same mistakes and being tripped up in the same places over and over again, then clearly the fault lies with the tools themsleves."
Now, I'm sure if I go through the usual examples of this theory, I'll get back the usual result: some unenlightened idiot telling me that EMACS and/or the CLI are faster at the end of the day and therefore better, and that the problem is simply "more training." Thankfully, in 2006, I hope I don't have to explain why this mode of thinking is outdated (well, never right in the first place) nonsense, since most of you have finally woken up to these facts:
- Usability and speed are orthogonal to each other. You do NOT need to give up speed to gain more usability, and vice versa. The trick is something called GOOD DESIGN. Bad design simply trades off one for another. Good design at least imporves on one front without diminishing another.
- A long manual is a hallmark of bad design. Did you need to have a manual to start using, say, a web browser? No. Why should, say, a text editor be any different?
- i) The UNIX philosophy of "make tools small and atomic" is not necessarily bad from a deep technical standpoint, but this doesnt mean the user necesarily has to directly interact with those tools and ii) one doesn't have to be a "Windows for Dummies" esque user to benefit from well built tools. There are lots of real life examples of progress in this, from the steady emergence of (still often highly flawed, but far better than what was before) high-level languages/environments like PhP, Perl, Gnome, KDE, and so forth. There is ABSOLUTELY no reason why I can't be a UNIX guru and haven't the slightest idea what the command-line arguments to 'tar' are off the top of my head.
Bring on the 'yesbuts...' from the dinosaurs and self-annointed high priests...Close, but no Cigar.
You can optimize for anything, but you can't optimize for everything.
If you optimize for pretty, you get art. It's beautiful, but does nothing.
If you optimize for power/flexibility you end up with a programming language. It's powerful and flexible, but a bitch to use.
I'm sure by now you see the point.
The Unix CLI (as well as Emacs and Vi for that matter) was designed to maximize productivity for experts. It was not designed to make things easy for newbies or casual users. As such, it is extremely successful at what it is designed for. It is so successful that after years of trying to eliminate the command line, Microsoft is building a better CLI for its operating systems - experts demand its power.
KDE and Gnome are being designed for newbies. Kate (another editor) is a lot easier to use than emacs - so are KDE and Gnome. All three are less productive than the command line for someone who is experienced in its use.
Another example is blender - a 3d design and animation package. The user interface is complete hell to learn. Every button on the mouse does three or four different things depending on context. The entire package depends on keyboard shortcuts, and it takes weeks to learn enough of the functions to get anything done in a reasonable period of time. Does that make it a bad design? No. Once you learn the interface, its layout allows you to create complex 3D forms very quickly and efficiently. It takes weeks to learn, and the same interface saves you a good deal of time every day.
At the end of the day there's a price for everything. Some prices are paid by having to learn something. Some are paid with your checkbook. Some are paid in time, effort, and work. It's all compromise - pick the prices you're willing to pay. There's simply no need to criticize tools that you're not willing to pay the price to use.
Jacques Richer
I think that the whole discussion can be summed up, just as the article says, with:
"We reject kings, presidents and voting. We believe in rough consensus and running code." -- Dave Clark
So in answer to "What is UNIX?", UNIX is code that runs based on general agreement of the masses. This is why it will not die, even LSB is discussed in the article and rightly so, it falls into the same category. A loosely held standard that defines what the general masses of Linux distributions use.
No hard and fast standard would ever survive in the *nix world, ever system is unique to its purpose.
Nice article, IBM churn them out and every so often a good one turns up.
BOO
I'm not sure about this. It's easier to draw pictures than it is to write, but there are advantages in learning how to write, including things a lot of people have trouble with, like proper spelling, grammar and punctuation.
It's easier to use a web browser than it is to use, say vi, and that's good. At the same time, however, having learnt to use vi, I often long for the ability to navigate a web page in my browser with the same ease and efficiency of navigating a text file in vi. I can't, because my browser's page-navigation capabilities simply aren't as good.
If my browser had a command-line interface like vi, I'd much prefer it, and that wouldn't require the weakening of the graphical interface. At the same time, those using the command-line would have to take more care not to make mistakes; it's simply the nature of a command-line.
It is possible for a command-line interpreter to try and guess what the user means, just as it's possible for GUI software to do this (and a lot of Microsoft software does this by default, much to my annoyance), but the guesses are often wrong, and when they're right, they can perpetuate mistakes. It's rather like people who become so dependent on spell checkers that they never learn to spell properly, or can't do maths because they've always used a calculator.
Some might say that skills like writing, maths and using a command line are obsolete, since we have technological aids that can allow people to achieve the same ends without fully understanding these concepts. However, I'd argue that an understanding of such things is an important part of making the best use of them. A calculator can never fully replace an undestanding of mathematics, spelling and grammar checkers can never fully replace the ability to write and a friendly interface on a computer system can never fully replace an understanding of that system.
This attitude was (and to a great degree still is, though somewhat less than before) is the single most cancerous and evil mode of thinking in computer science.
Your preaching and ultimate judgement of what exactly computer science is goes without discernible warrant. With blunt and frankly inexcusably incorrect use of the term "computer science" like that, you have earned a place on my ignore list. You are a complete fucking idiot.
Posting anonymously so I won't be demerited karma for calling an idiot on what exactly he is.
-kfg
You make a few good points, but seem to have a misplaced faith in designing out problems. Let's take a look at the 'real world', which has been around a lot longer than the computer world, and see whether good design has triumphed to make the world around us work without danger and reliance on human memory or judgement.
Let's look at powertools, cars, airplanes, guns, knives or other things that modern people use. All of them have measures designed to stop people from hurting themselves and require no training to use, as their use is obvious, right? Wrong. If I design a knife that is too blunt to cut flesh, it cannot cut my steak. If I design a car that does not move fast enough to kill me if I am in an accident, the car doesn't move fast enough period. Notice how this is ok, and how we can give kids blunt plastic knives until they have learned how to use them well enough to use 'big tools'.
This pattern is even more pronounced with 'professional tools' like planers, jigs or powerful hydroulics. You need trained operators for those, because they can take of your arm or kill many people at once. The true myth of our time is that computers should be both easy to use and powerful enough to do anything you want. Design can bring you so far, but each level of ease of use you slap onto a device usually makes it that much less powerful. Observe F1 racing cars -- not an 'easy drive', but really good at what they do. Safety measures and 'easy to start' engines are too heavy, so they don't make the cut.
Getting back to the computer, there is no way to stop you from making mistakes. There are a few common mistakes, but there is no reliable way of knowing whether the user really wanted to delete all the files in that directory. I know people who have 'accidentally' deleted files in Windows, clicked on 'yes, I am sure', emptied the recycle bin and then realised they made a mistake. How was the operating system to know to stop the user? Professionals hate people looking over there shoulders, double-guessing their actions. They don't like little dogs asking them to type a file query. They like the power of a stripped down interface that allows them the freedom to do what they want they way they want. If all your needs are filled by GUI tools, there is no reason not to use them, but I prefer to get stuff done my way.
So, in the end, things get down to formalisms and language. And that's the thing about language -- it has rules. You have to learn the rules. You have to use the language often to remain fluent. What you get in return is tha ability to express yourself accurately. And thank goodness that we have a powerful language interface to the OS in things like bash.
Languages aren't inherently fast -- implementations are efficient