Slashdot Mirror
The Top UNIX Moments of the Century
jyang writes " Performance Computing has this December article: 'The world might seem to run on UNIX, but it wasn't always so.
Readers opine on the best moments of everyone's favorite OS.'" Well, among all those "end of the century" lists, we finally found a worthwhile one. ;-)
I was surprised not to see K&R C on the list (they mentioned when Ken Thompson's mom met his dad though) although I thought it was pretty complete. The fact that mentioned the change from ^ to | as pipe impressed the hell out of me.
It also makes you think about Richard Stallman's contribution to computing to see that like 5 things on the list are his direct doing.
Is it just me or was the following entry missing:
* Linus Torvalds uploads the linux kernel
I mean really, that's a given!
bakes
--
Ho! Haha! Guard! Turn! Parry! Dodge! Spin! Ha! Thrust!
1. The CLI (command language interpreter) was a separate, user-mode program that could be easily replaced. I was used to DEC operating systems where the CLI was an integral part of the operating system, sort of like the baby alien that attachs to your face in the movie Alien. It couldn't be removed without major surgery on the OS and its tentacles were firmly embedded in the kernel.
2. The shell didn't hardwire the command set like most CLIs of the day. You didn't have to modify the shell to add new commands, just write a new user-mode program. The shell was light on command line policy, leaving most things up to the interpretation of the user program.
Mea navis aericumbens anguillis abundat
Research Unix Edition 7 was released in 1978, and included:
- The Bourne Shell, the first shell that was a programming language in its own right.
- Environment variables (this was an OS enhancement, not just the shell features supporting it).
- UUCP--the Unix/Unix Copy Program. This brought networking, email, and (a bit later) news to the masses. This feature literally changed the world.
- File systems larger than 32MB. Unix was no longer a toy.
- Lint, along with system sources that actually passed it (no more "register *p" for generic pointers everywhere). C was forever improved by this step, since many people learned to program in it from reading kernel sources (just like Linux programmers do today).
- 32V, the port to the VAX--this was the ancestor of 3.x and 4.x BSD. (The 2.x BSD's ran on PDP-11's, and for a time were developed in parallel.)
- And so on...
This was the version that got Unix started at many Universities. It was also the last version of Research Unix to make it out of Bell Labs into general distribution for research and educational use. One can only wonder what we would have seen had AT&T not decided to squeeze money out of it, locking away further Research Editions.I fail to see why this is a top moment in Unix history. If anything, this is a downfall, as as far as I'm concerned, the last thing we need running on unix platforms is Microsoft software.
Netscape's introduction of an integrated mail, news, and browser application
I can't say I'm too much of a fan of this one either, at least not the way it's implemented. While I use Communicator for browsing and Mail under RH6.1, I hate the fact that whenever one function (mail or browser) locks up/crashes, the other does too. I think you could have the two as separate applications that were still tightly integrated.
AT&T SVR4 and the Amiga?! 1991: The release of SystemVR4 was a major stage in the growth of UNIX. But a little-known fact about the start of this industry paradigm shift was that the very first platform to receive the AT&T port of this innovative and powerfully stable pillar of UNIX was the Commodore Amiga3000(UX)!
:)
I can't beleive it - I can't beleive it!
Someone *does* remember this - it's amazing
I still remember the day when all those crappy newspapers called the A3000UX a 'miss of the decade'. Like "Who is going to use UNIX anyway?!". Indeed, it didn't make a lot of success, but Amiga was *always* way ahead of its time.
We've got almost 40 years until the end of time as we know it. (or until 64-bit Unix, whichever comes first.)
:)
:), having different widget sets and window managers available, or having a free compiler and a useful toolset...
However... kudos to BSD for developing Unix to what we have today, and the same to the Linux community, for continuing to develop it, and spread the gospel.
I think I'm continually impressed with how Unix takes a more open and general approach to everything, and makes life easier in the end.
Like how directories and even hardware devices are files, networking transparency is inherent in X (even if it took me a while to figure that out
Truly, if I hadn't found Unix, I would have been doomed to reinvent it. Probably starting with DOS. Ewww....
---
pb Reply rather than vaguely moderate me.
pb Reply or e-mail; don't vaguely moderate.
I just don't understand why everything has to be written in C. Why don't they write a Fortran based OS ? Surely with Fortran's superior mathematical operations it would kill C-written UNIX. Someone should rewrite UNIX in FORTRAN.
Well, of course GNU is Not UNIX, but it's impossible to talk about the history of UNIX without talking about GNU tools. What would UNIX be without them? Well, it would seem to me that the folks whom are good at writing OS stuff would have to write tools for their OS, taking them away from working on their OS. #include "GNU.h" OS people say "Hey, this kicks butt! We can go back to work on our OS now!" OS subsiquantly gets better, but relys on GNU tools for that part of it. Hence GNU and the FSF are integral in the history of UNIX, hence why there's in that list. Q.E.D.
It is not amazingly surprising to see Richard Stallman feature so prominently on this list. Not because he has done so much for UN*X (or so little, for that matter), but because People Know Richard Stallman. They know his name, he has featured prominently in the media in the last couple of years, and projects his name is (still) attached to are doing well.
As to his contribution to UN*X? I have no idea. I'm a newcomer to the wonderful world of SunOS, HP-UX, Solaris, *BSD and linux, I did my first man man in '93, I had my first root in '96, and I feel a lot of the Big Things In UN*X (tm) happened before my time.
I think it is a fundamental thing with these kind of lists that they pretty much always overvalue recent contributions/songs/films/ice-cream flavours, at the expense of older ones. A lot of people only catch on later, and will not remember the first tottering steps, the first breakthroughs, because they simply weren't there yet. They will go for the more recent accomplishments, the things they *did* witness.
So, lists like this are fun, and interesting, but I have my doubts as to their value for actually determining the impact that developments have had, the relative importance of UN*X moments.
Jos "numbers, I want numbers!" D.
I'd say, in general, that most of the work done at UCB contributed more to the success of Unix than anything else. Without UCB, Unix would have probably remained in the dark ages. They gave us networking, vi, csh, and perhaps most importantly, an open source development model, which allowed Unix to become widespread.
PS. Sure, csh syntax may suck, but without it, we'd all be using Bourne shell. csh gave us command histories, brace expansion, and numerous other goodies that we take for granted today. Without csh, other shells (ksh, bash, zsh) would be very different, if they existed at all.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
PCC was another product of Edition 7. The VAX C compiler in 32V (and the first VAX-based BSD's) was constructed using PCC.
Berkeley wasn't alone in adding networking to Unix (there were at least half a dozen different protocol stacks for Unix before TCP/IP saw the light of day). But they were contracted to implement the Big One: TCP/IP. A good thing, too, since the NCP stack (NCP was the ARPANET protocol prior to TCP/IP) for Unix was pretty buggy.
X's predecessor was W (developed, I believe, at Stanford). So C isn't the only product of alphabetic succession (its precursor was B-- Ken Thompson's BCPL derivative). I wonder why the Berlin folks haven't named their project "Y"? (Why not?)
There are just too many to make it a good sample, but the above were darned fine moments.
Cheers,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
Oh, yes. I wasn't trying to put Linux down, I was just trying to explain the difference as best I know it. As far as my personal opinion goes, Linux should be near the top of that list. While Linux is an interesting OS, it hasn't really contributed that much to UNIX directly. Indirectly it has launched innumerable geeks into the UNIX world, steered scores of programmers to write UNIX apps, and most importantly is the first UNIX variant to achieve household name status. While the vast majority of computer users still haven't ever seen Linux, they know the name. What other UNIX variant can you say that about?
There is nothing so pathetic as seeing a beautiful young theory roughed up by a tough gang of facts.
As the AC above noted, C's default assuptions about pointer aliasing make certain classes of programs run like crap. The new restrict keyword is a huge step in the right direction, but it's still a Band-Aid.
Why are sane pointer aliasing conventions important in the language? Well, since effecient code generation is something nearly everyone lusts after, compiler writers spend alot of effort "optimizing" code. Since C doesn't provide much of a mechanism for describing where pointers point, the compiler has to implement alot of guesswork. If it's not sure, it punts and outputs slow code.
The problem is that these optimizations are hard to get right. Notice how GCC 2.95 broke the Linux kernel, unless you compiled with the new alias analysis turned off. It would be better for the language to have saner pointer semantics.
Note that this wasn't so much of a problem in the beginning when pipelines were short and issue-widths were narrow. Nowadays, though, pointer aliasing issues are one of the biggest issues preventing code from going faster. (I know, I hit these issues regularly.) I welcome restrict with open arms.
--Joe--
Program Intellivision!
The lp1 on fire bit wasn't in the docs, was it?
BTW, who remembers the rest of the tunefs joke? (Namely, the bits that were in the actual nroff source for the man page?)
From what I recall, the man page's source said something along the lines of "Remove this, and a Unix daemon will dog your steps until the time_t's wrap around." I unfortunately do not have access to a system with the original quote that I know of offhand. Anyone?
--Joe--
Program Intellivision!
Anyways, here's a few moments that I'd regard as being significant (irrespective of whether they're in anyone else's list or not). They are not in any specific order - date, importance, etc. It's just the order I wrote them in.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Fortran "should" be dead? not by a long shot. No, Fortran (not FORTAN anymore, btw) is not the language to use for everything. Even though Prime did it, it is not a good choice for writing an OS.
But when it comes time to due high level number crunching (or beyond that, merely bashing them into submission), Fortran has no peer--nothing even close.
Yes, you can usually tune c to give similar performance. But by the time you're done tuning, I've already used the Fortran code, and am on to the next project--or the one afterwards.
Fortan does not inlcude large portions of what c contains--which is what allows it to make assumpitons and optimizations that would be disastrous in c. It is also much faster to write (especially with F90 free-format), and easier for an "outsider" to read. (but then, there's no language yet built which is proof against crummy coding)
I hate to think of how much longer the dynamic programming project for my dissertation would have takein in c than Fortran *shudder*.
This is not strictly true. Some of the original System V licensees (Sun and SGI, at least) bought out the license for a large one off payment, when it was still owned by Novell, IIRC. As such, they no longer pay SCO royalties.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
Sure, CDE sucks, but it's not so much that they were unable to come up with anything elegant, but more they were unwilling to do so. It was very much a political thing, with each manufacturer having to be seen to contribute a part of it. HP's contribution was VUE, their Visual User Environment, which later became what we now know as CDE. I hated VUE back then, and I still hate CDE now. As you say, though, being designed by committee didn't help, either...
"The invisible and the non-existent look very much alike." -- Delos B. McKown
I remember TECO with a great deal of fondness. With what other editor could you spend more time on life games, renumbering utilities, and gray-code searches than manipulating text?
:)
There was even a macro VEDIT, for those times you just wanted visual editing with arrow keys and all. It was conveniently distributed without any format characters and provided weeks of fun just figuring out how it worked.
I'm far more productive with Brief/Crisp but I've never had as much fun with an editor since TECO. It could really trash a file from the simplest typos!
Solaris, obviously. The userland apps are generally 32 bit (for space efficiency), but the kernel is 64bit.
:)
HP-UX. Those PA-RISC machines are 64bit, right?
IRIX runs on 64bit MIPS chips.
For that matter, several BSDs are truly Unices, and run on some 64bit platforms. NetBSD runs on all of these, right? FreeBSD runs on several of them, and I think even Open has one or two (verification?).
And of course, everyone's favortie 64bit Unix-alike, Linux, which runs on all of the above
But Mastering Regular Expressions credited Ken Thompson with the original version of grep, circa 1968.
Cheers,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht