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."

Comments

Not a bad article.

[Anti-Trend]

This editorial definitely seems to be for marketing purposes, being both hosted by IBM and directly confrontational about Microsoft. Still, interesting enough article; it's always tough to be brief and to the point about such a complicated subject. I especially like the author's point about the liquidity of the Microsoft "standard" API which is so touted as a counterpoint to *nix implementation -- DOS, Win16, OS/2, Win32, WinNT, WinXP, .NET, Vista... versus POSIX. Yeah, he's right, it sounds pretty ridiculous when you put it that way. That being said, the article's pretty light on the details. For those rare individuals interested in reading more than TFA, here's a little more info on UNIX and the POSIX standard.

Re:Not a bad article.

[(Score:1)]

For the history of Unix (timeline), read this one:
http://www.levenez.com/unix/

Re:Not a bad article.

[seebs]

Hosted by IBM just because it's a regular column on standardization. In all the years I've written for IBM, the only edit they've ever made on such grounds is that they changed the word "Belkin" to the name "Company X" in my article about Belkin's packet-hijacking routers. Oh, wait; I think they disliked a couple of comments I made about Verisign once. Mostly, if there's no obvious liability, they don't get involved.

Re:Not a bad article.

[masklinn]

Well, the guy also has a Computer Languages Timeline (with only the 50 most used/interresting languages or so)...

Re:Not a bad article.

[ROOK*CA]

I especially like the author's point about the liquidity of the Microsoft "standard" API which is so touted as a counterpoint to *nix implementation -- DOS, Win16, OS/2, Win32, WinNT, WinXP, .NET, Vista... versus POSIX.

Good point, I think the most distinguishing factor is marketing, Microsoft has been consistantly been able to map out a clear transition from API to API (as well as inserting a dash of FUD when required), even if customers and/or ISVs knew there was going to be transition pain, Microsoft was there to assure them of backward compatibility and/or easy portability (even if some of those "assurances" were a bit "hyped") . It's a bit harder for the *NIX world to communicate this to customers & ISV's since you have vendors competeing in the same space against each other and trying to differentiate their *NIX based offerings from everybody elses.

It's funny but I think a lot of customers & ISVs happily accept vendor lock-in in the case of Microsoft, but are hestitant when it comes to *NIX, even though in reality *NIX generally speaking turns out to be the more flexible (portable) platform. No accounting for taste I guess :).

Re:Not a bad article.

[drsmithy]

I especially like the author's point about the liquidity of the Microsoft "standard" API which is so touted as a counterpoint to *nix implementation -- DOS, Win16, OS/2, Win32, WinNT, WinXP, .NET, Vista... versus POSIX. Yeah, he's right, it sounds pretty ridiculous when you put it that way.

Particularly since the "Win32, WinNT, WinXP" part of it are all the same thing, so the real progression is:

DOS, Win16, OS/2, Win32, .NET.

Re:Not a bad article.

[drsmithy]

Good point, [...]

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.

Re:Not a bad article.

[peragrin]

Um what are you smoking?

16-bit windows and dos apps only work if they are non-trivial. I can't upgrade our work computers out of windows 95 and windows 98 because we depend on non-trivial software that doesn't run on the NT line. So MSFT is just as bad as everyone else. Try running some of the early versions of word in XP or win2k3 it doesn't work, and the modern versions can't read the older formats. been there. tried that, considered it lost.

Most linux problems aren't binaries but library and their various and multitude of locations.

Re:Not a bad article.

[jbplou]

DOS, Win16, OS/2, Win32, WinNT, WinXP, .NET, Vista

Kind of not true also. One of the main drives behind .NET is that develping in .NET allows applications to move between different Window O/Ss as long as you have the .NET runtime. Microsoft wants you to develop for Vista in .NET just like they want you to devleop for Windows Server 2003 and XP in .NET.

Also I really don't think Microsoft ever wanted anyone going to OS/2.

Re:Not a bad article.

[sasdrtx]

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.

Re:Not a bad article.

[peragrin]

Yep they violate the fact that it requires a Novell netware server to run, and MSFT kept breaking and changing the networking API so much that Novell couldn't keep up with the ever shifting target.

It's why I give the Samba guys credit. MSFT has purposely broken code in their networking to slow down others from using it outside of windows. Listen to the Samba guys talk about it sometime. Even with XP and win2k3 msft is still at it.

Re:Not a bad article.

[samkass]

The biggest difference between Microsoft's APIs and others, I think, is that at any given time one and only one API is considered the canonical one in which to write all future software. If I want to sit down today and write software to be released in a year or so, Microsoft will tell me what API to write to unequivocally. With "UNIX", although it's getting better, there have been competing APIs for threads, networking, GUIs, configuration, user handling, etc., often co-existing and sharing the "this is the future" status. Even MacOS has Carbon and Cocoa these days, and despite what a lot of former NeXT fans inside and outside Apple wish, does not advocate either API as the canonical one going forward-- and probably, as a matter of market share, doesn't even have the power to do so if they wanted. Even the format of libraries and versions of libc have changed from release to release, while a Windows binary from 10 years ago will probably run unmodified today.

I think this has helped solidify Microsoft's reputation for API stability among their proponents, and hurt the Unixy operating systems.

Re:Not a bad article.

[Hal_Porter]

Except you can easily write a Win32 binary that works on any Win32 os from Windows 95 to Vista.

Hell with a bit of work, you can make it use the features on later OS's too. Each new OS adds a few functions, but you can always add code that uses GetProcAddress and LoadLibrary to use them if they are present or use the old version if they are not. Not that you really need to, most of the new functions are for stupid eye candy anyway.

So it's misleading to describe each of the Win32 based OS's as a new API.

Re:Not a bad article.

[Anonymous Coward]

Also I really don't think Microsoft ever wanted anyone going to OS/2.

All through the 1980s, Microsoft pushed MS OS/2 as the eventual successor to MS-DOS. However, Microsoft never made the mistake of throwing away the MS-DOS user base the way some other companies did (eg Apple threw away its Apple II user base when it created the Mac), and continued to develop MS-DOS to meet customer demands and keep up with the competition (eg by adding the Win16 GUI).

Microsoft NT OS/2, a project started in 1988, continued the Microsoft strategy of keeping all options open, by including a portable kernel capable of running on the popular RISC systems of the day (first MIPS, later Alpha and PowerPC), as well as Intel's new 32-bit version of the x86 (the i386), together with three emulation subsystems: MS OS/2, MS-DOS and POSIX. This made the system potentially compatible with all of the major hardware architectures and software platforms. All three of the subsystems ran on top of the native NT kernel, but the primary one (ie the one in which the core system applications were written) was the OS/2 subsystem, since this was the platform Microsoft had been betting on for the future.

In the early 1990s, Windows 3.x took off in the marketplace, while OS/2 continued to languish. This led Microsoft, which has almost always put market demands ahead of technical superiority (a very sound business strategy), to create another subsytem for NT called Win32, which was a 32-bit version of the Win16 API. Microsoft also decided that, based on the market demand for Win16, Win32 (rather than OS/2) would be the primary subsystem on NT. This would make it easier to port software from Microsoft's market-leading, but technologically inferior, system (MS-DOS/Win16) to its future system (NT).

Microsoft's decision to add Win32 to NT created a huge disagreement with IBM, which wanted to continue pushing OS/2, no matter how successful Win16 became in the market. As a result, IBM and Microsoft split their OS/2 efforts, with IBM taking exclusive control of OS/2 2.x development, and Microsoft removing OS/2 2.x support from the OS/2 subsystem in NT (the OS/2 subsystem was thus restricted to emulating OS/2 1.x). Microsoft also renamed NT OS/2 to Windows NT 3.1.

The OS/2 fiasco caused a fair amount of anger amongst those who had followed Microsoft's advice and invested in developing applications for OS/2, but since the vast majority of developers had ignored Microsoft's advice and developed applications for MS-DOS/Win16 instead, this angry minority didn't have much of an impact on the success of the system (but led a lot of OS/2 aficionados to hate Microsoft, and most of them eventually migrated to Linux).

Re:Not a bad article.

[dryeo]

WordPerfect 8 runs fine under Ubuntu here. Just had to apt-get xlib5 and libc5 IIRC. That is the tarball version. The deb version wanted something like xlib5g which conflicted with too many things so I didn't bother

Re:Not a bad article.

[seebs]

There was a time when Microsoft's official answer to "What API should I use" was "OS/2". This was before they found out that Windows 3.1 was commercially successful enough that they didn't care that they couldn't figure out how to engineer it.

As to .NET, I seem to recall someone complaining about compatibility between versions.

Re:Not a bad article.

[jbplou]

I'll admit .NET as it is supposed to work and the way it truly does is somewhat disparate at best. Many of the functions rely on under level COM objects so on some O/S's they don't work, for example some things don't exist in 98 so they fail. The core features work on all and I suspect that you could port something that works in .NET on Win 2000/XP to Vista without error as long as it is completely based on .NET and does not create any objects directly from COM. Like Java is supposed to be run anywhere, but anybody who has had to support some third party Java based program like Remedy finds there are all sorts of little requirements that make it fail.

Re:Not a bad article.

[corvair2k1]

Are you talking 50 languages, or different versions?

I see:

1. Fortran
2. Forth
3. Logo
4. JOSS
5. Telecomp
6. MUMPS
7. Prolog
8. B-O
9. Flowmatic
10. COBOL
11. PL/I
12. Pascal
13. Modula
14. CPL
15. BCPL
16. B
17. C
18. Jovial
19. Coral
20. Simula
21. IAL
22. Algol
23. Gogol
24. Smalltalk
25. BASIC
26. sh
27. Lisp
28. Scheme
29. ML
30. Snobol

...Within the first screen. I didn't count different versions of the same language (e.g. Fortran I, Fortran II), but I did count close relatives (e.g., Lisp, ML, Scheme). Still, obviously more than fifty.

Who has too much time on their hands NOW?!?

Re:Not a bad article.

[masklinn]

I'm not talkiing or counting, i'm quoting:

There is only 50 languages listed in my chart, if you don't find "your" language, see The Language List of Bill Kinnersley (he has listed more than 2500 languages).

Re:Not a bad article.

[marcosdumay]

Wine and DOSEmu happen to emulate* 16bit windows quite well. Maybe those applications turn out to work better on Linux nowadays...

I have a lot of old games that I must run on Linux now, because Windows won't run them anymore.

*Wine is not an emulator, but you got the point.

Re:Not a bad article.

[BrokenHalo]

It sounds very much as if you didn't Read The Fine Article. The author makes the point that code from 20 years ago will still compile and run today. In fact, many of the utilities distributed by default with Linux/BSD/OS X *WERE* written 20 years ago.

Re:Not a bad article.

[Brandybuck]

It's funny but I think a lot of customers & ISVs happily accept vendor lock-in in the case of Microsoft, but are hestitant when it comes to *NIX, even though in reality *NIX generally speaking turns out to be the more flexible (portable) platform.

My company is on its third year of porting a huge Unix codebase to Windows, and it looks like we'll have at least two more before the product is ready. We switched because the embedded RT Unix we were using was getting long in the tooth. But we COULD have ported to different embedded Unix in six months.

Re:Not a bad article.

[NumerusSpy]

Ah, no, faggot.

I bet you would never dream of saying that to someones face. The fact you did it on /. as an AC is a testament to the strength of your character.

it's ok

[rayde]

i don't take any reports of UNIX's death as fact without a Netcraft confirmation.

Re:it's ok

[narkotix]

....no but apparently some whacko reckons aix aint made by ibm and its all part of the big plan...u know the krill files

The IBM Unix variant, AIX, is rumored to have been developed by space aliens

Re:it's ok

[NitsujTPU]

Have they said anything about Slashdot dying?

There are 11 whole posts (so far) on a story where geeks get to stroke their egos by showing their ignorance and calling everything in sight a version of Unix.

Heck, I didn't even see anybody post a *BSD is Dying troll.

Re:it's ok

[aussie_a]

Heck, I didn't even see anybody post a *BSD is Dying troll.

That's because it is already dead.

Re:it's ok

[NitsujTPU]

Yeah, but it lives on through OS X and all of the its bastard children, or something.

Re:it's ok

[tigga]

Heck, I didn't even see anybody post a *BSD is Dying troll.

That's because it is already dead.

Really? Troll is dead already?
Good! It was annoying because of it's boring stupidity...

Re:it's ok

[H0p313ss]

That's because it is already dead.

No... it's just sleeping...

Sleeping? It's pining for the fijords!

Re:it's ok

[sharkey]

It also sucks eggs, through a very thin straw.

Or so I've heard.

Single Unix Standard, Version 3

[Gopal.V]

As a programmer, that's what I really consider as Unix - sus v3.

I code for this API and the sources end up being source compatible. But then there are library paths and stuff, which is why even something as homogenous as Linux is forced to create LSB standard. The API standard OTOH, is crystal clear - look at the API tables in terms of availability. And yeah, my project is called Portable.net, so I've put in my time writing portable code for various platforms (even BeOS and SkyOS). Wish the threading models worked the same, that's all :)

There is just *nix ... just *nix and VMS - everything else is somewhere in between.

Re:Single Unix Standard, Version 3

[Anonymous Coward]

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.

Re:Single Unix Standard, Version 3

[MichaelSmith]

just *nix and VMS - everything else is somewhere in between.

MSDOS is between *nix and VMS?

Re:Single Unix Standard, Version 3

[menkhaura]

Don't stretch it.

Re:Single Unix Standard, Version 3

[Anonymous Coward]

Well, that's certainly a negative way to put it, but what if anything could they do any better? It's not like it would be particularly practical or reasonable for unix vendors at this stage of unix history to break backwards compatibility for the sake of future compatibility.

So, the unix vendors do the next best thing: they make whatever changes they can to bring their platforms to uniformity without breaking backwards compatibility, and they maintain a common standards document that documents the cross-platform compatible functionality. When they inevitably make mistakes in the documentation process, they remove specifications that they cannot implement complatibly in all unix systems.

The most important point here is the intent of the unix vendors: They are working towards compatibility wherever they can, and they are striving for accurate documentation of the compatible functionality. There's nothing to disparage in their actions, even if they make the occasional mistake -- at least they are improving all the time.

Even linux developers are known to deviate from the SUS occasionally, but they too do strive to implement the standard wherever possible. Yes, the Single Unix Specification is incomplete and flawed, but it's the best thing we've got.

Re:Single Unix Standard, Version 3

[rubycodez]

ah, so MS-DOS is between CP/M and Windows

Re:Single Unix Standard, Version 3

[Octorian]

Yeah, you'd have to stretch things to make those comparisons. VMS may have some syntactic similarities to DOS, but not as many as you'd think. Let's take a complete file path, for example:
UNIX: /files/stuff/foo.txt
DOS: C:\FILES\STUFF\FOO.TXT
VMS: SYS$SYSDEVICE:[FILES.STUFF]FOO.TXT;1

Though DOS and VMS both use "DIR", while UNIX uses "ls". However, both DOS and UNIX use "cd", where VMS uses "SET DEFAULT". DOS and UNIX also use "mkdir", where VMS uses "CREATE/DIRECTORY". Though UNIX uses "-foo" for command switches, where both DOS and VMS would use "/FOO", but VMS doesn't require a space between the command and the switches.

Re:Single Unix Standard, Version 3

[TheRaven64]

...but VMS doesn't require a space between the command and the switches.

Neither did DOS, since the '/' character wasn't allowed to appear in file names. It's something that, growing up with DOS, I still haven't quite got used to with UNIX and still find myself typing 'cd..' (which I've now set up as an alias) or 'ls-lah' and getting an error.

Re:Single Unix Standard, Version 3

[Quantam]

Even linux developers are known to deviate from the SUS occasionally, but they too do strive to implement the standard wherever possible.

Don't, just don't go there.

First Sale Doctrine

[David Hume]

FTFA:

A single programmer who wants a copy of the POSIX specification would have to pay US$974 for it. That gets a one-year subscription; you are not licensed to continue referring to the standard thereafter.

What about the first sale doctrine? Do they really contend that you cannot "refer" to the standard after one year? Do they do a mind wipe? Or is just that your subscription for updates lapses after one year?

Re:First Sale Doctrine

[Anonymous Coward]

They'll probably try to stop you from using it by applying the Patriot Act. I think in section 3.14.a.2.2.b it says that a terrorist is someone who uses standards documentation without renewing their license.

Re:First Sale Doctrine

[larry bagina]

You can (legally) get it for free at unix.org and opengroup.org. An individual paying a $974 annual fee for it has more money than brains.

Re:First Sale Doctrine

[TheRaven64]

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.

UNIX ?

[this great guy]

UNIX is not UNIX ! Hmm wait... no sorry I heard that or something close somewhere else.

Re:UNIX ?

[larry bagina]

XINU Is Not Unix.

(It's actually a giant space clam that wants you to give all your money to L Ron Hubbard)

Re:UNIX ?

[koinu]

I have more reliable sources than wikipedia: Linux.
I know why I'm using FreeBSD.

Re:UNIX ?

[sharkey]

You motherfucker. You owe me a new Model M, you bastard.

BTW, vodka through the nose REALLY hurts.

old paradigms

[jonastullus]

isn't unix:

- 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
- ./configure && make && make install

?

well, that's just a few things that come to my (linux/bsd slanted) view of what (a modern) unix is...

Re:old paradigms

[grahamlee]

You've used a couple of Plan 9 and Sprite paradigms, some things which never applied to Unix[*], a load which apply to operating systems in general and an implementation artefact of GNU autoconf. I really hope that's not Unix....

[*]"least privilege" - MACs would predate setuid() if that were the case. For instance

Re:old paradigms

[jgrahn]

isn't unix: [...]? well, that's just a few things that come to my (linux/bsd slanted) view of what (a modern) unix is...

You're not Linux/BSD slanted, as far as I can tell. And even ancient Unices match almost all the items on your list.

Eric Raymond's The Art of Unix Programming sums up the meaning of "Unix" pretty nicely, by the way. And in great detail.

Re:old paradigms

[jonastullus]

yes, the "./configure" bit might have been a bit misplaced. but i was less "defining" unix and more trying to capture what frequent users of unix systems would have in common. and the "./configure" idea factored into it for me, although this might well be a GNU invention.

don't many programs under BSDs do it like that too, BTW?

i don't quite understand your MAC commentary. if i had meant MAC i would've said so.

The principle of least privilege requires that a user be given no more privilege than necessary to perform a job..

and from what i understand about unix systems, this has been an important aspect since they have supported multiple users. even though lacking ACLs and MAC, it's never been very fine-grained or comfortable.

Re:old paradigms

[Anne Thwacks]

You failed to mention:

Heirarchical file system

attach new filesystem anywhere in the old one

networking (UUCP, Ethernet, mail, etc)

User name based login accounts (with 8 char limit :-)

Re:old paradigms

[grahamlee]

To take the specific point of MACs, if UNIX was about giving you the least privilege necessary to get your job done, then the concept of setuid (which gives you *all* the privileges available) would never have existed. Tools like sudo, solaris profiles, SEDarwin/SEBSD and the like have come up to try and plug this privilege leak but fundamentally, Unix has a binary privilege model. You either have none, or you have them all. More generally, I think it's hard to fundamentally sum up Unix (without using one of the technical definitions, such as "something which implements SUS"); when it comes down to it it's a C language API and a set of tools which implement that API, running a multiuser multitasking OS. I think a good description would be "an OS that one person can grok"...

Re:old paradigms

[rolfwind]

isn't unix:

- everything is a file

No. Not everything is a file in Unix (exceptions started piling on as hacks for originially unintended devices, etcetera started piling on), that's why there is Plan9 - where everything is a file - from the original creators of Unix at Bell labs.

http://cm.bell-labs.com/wiki/plan9/plan_9_wiki/

Re:old paradigms

[Cow Herd (Anonymous)]

...the concept of setuid (which gives you *all* the privileges available)...

The setuid bit on an executable file gives you the privileges of the owner of the file. It is mostly used as setuid-root, but doesn't have to be.

setuid(2) is a different matter of course, because you need to have uid 0 for it to work at all.

Re:old paradigms

[Pharmboy]

It is mostly used as setuid-root, but doesn't have to be.

I use setuid all the time, but never as root. In particular, running game servers, I always have crond check to make sure all is well, and restart if needed as a regular user. If there is ever a buffer overflow issue with the game daemon, at least the access would only be as the user, not root.

Re:old paradigms

[swordgeek]

Lots of mostly true and slightly debateable points. However:

#./configure && make && make install

This is a Linuxism that's only recently starting to be backported into Unix.

Correlation, Causation, LSD

[Quirk]

In some cases, existing practice in a field reflects a decision a college student at Berkeley made at 3 AM.

"There were only two things to come out of Berkeley in the 60's, LSD and Unix. I doubt that is a coincidence."

Re:Correlation, Causation, LSD

[zhiwenchong]

Actually the original quote was:

Two things came out of Berkeley in the 60's, BSD and LSD.

Re:Correlation, Causation, LSD

[Brandybuck]

Mod parent down. Not only is this quote incorrect, it is so incorrect I must surmise that zhiwenchong is the new pseudonym for Cliff Clavin.

Re:Correlation, Causation, LSD

[multiplexo]

"There were only two things to come out of Berkeley in the 60's, LSD and Unix. I doubt that is a coincidence.

Actually LSD was discovered by Dr. Albert Hofman in Switzerland in 1943. Dr. Hofman, a rather interesting fellow, recently celebrated his 100th birthday.

great, we slashdotted IBM and Coral Cache :-P

[Hakubi_Washu]

IBM (http://www-128.ibm.com/developerworks/power/libra ry/pa-spec13/?ca=dgr-lnxw01UnixStandard):

Our apologies The IBM developerWorks Web site is currently under maintenance. Please try again later. Thank you.

Coral Cache (http://www.ibm.com.nyud.net:8090/developerworks/p ower/library/pa-spec13/?ca=dgr-lnxw01UnixStandard) :

Error: 500 Internal Server Error Server CoralWebPrx/0.1.16 (See http://coralcdn.org/) at 216.165.109.81:8090

Makes one smile :-)

Re:great, we slashdotted IBM and Coral Cache :-P

[NitsujTPU]

45 posts (and you know most people don't RTFA)... my assumption is that that server was built on one of the original IBM PCs.

Had to be said.

[deblau]

"The nice thing about standards is that there are so many to choose from." -- Andrew S. Tanenbaum, author of Minix.

Re:Had to be said.

[arunkv]

The Unix Hater's Handbook attributes that quote to Grace Murray Hopper. From pp9:

"The wonderful thing about standards is that there are so many of them to choose from"
-- Grace Murray Hopper

The Spirit of UNIX

[murdie]

Probably the oldest standard that people still refer to is AT&T's 1985 System V Interface Definition (SVID).

I routinely use printed Seventh Edition (Bell Labs Research) UNIX manuals, even when writing C for Linux. It also helps one remain blissfully ignorant of the 'cat -v' option and similar excrescences. Also the Tenth Edition UNIX manuals. I have to remember the changes introduced by Standard C and the like, but it's convenient to have the essence of the modern-day manual in printed form. Of course, there are some people out there who delight in using Fifth, Sixth, Seventh etc Editions on PDP-11s etc - see the PDP-11 UNIX Preservation Society, http://minnie.tuhs.org/PUPS/. I wish I had a larger garage! How much would a PDP-11/40 cost me now, anyway?

Peter Salus' book "A Quarter Century of UNIX", Addison-Wesley, 1994 (corrected 1995), ISBN 0-201-547771-5 is a good informal UNIX history.

"Those who do not understand UNIX are condemned to reinvent it -- badly."
                                                  -- Henry Spencer

Re:The Spirit of UNIX

[MichaelSmith]

How much would a PDP-11/40 cost me now, anyway?

I know somebody who probably threw away 20 or so 11/84 and 11/83 systems recently.

I think your answer is "not much" if you know which bin to look in.

Re:The Spirit of UNIX

[MROD]

From my experience, I'd say the first "UNIX standard" was AT&T Version 7, which was the common ancestor. I seem to remember this being used as the base standard at least when it came to basic functionality and API.

Re:The Spirit of UNIX

[Fred_A]

Until your first power bill came in I suppose...

Mirrordot has it

[oglueck]

Mirrordot

Re:Unix is in everything

[Anonymous Coward]

(Unix->VMS->WNT)
Only an american could be so ignorant of history. VMSVMS did indeed lead to NT, but had nothing to do with unix.

Re:Unix is in everything

[zephc]

Indeed, the story of UNIX today is depicted in this documentary.

Re:Unix is in everything

[larry bagina]

VMS is absolutely nothing like Unix.

Re:Unix is in everything

[stx23]

Huh? Unix isn't remotely related to VMS.

Answer

[ceeam]

Unix is not GNU.

Re:Answer

[CCFreak2K]

Wouldn'd that make it Ung instead?

UNIX hater's handbook.

[mumblestheclown]

Unix hater's handbook

it's funny AND true.

/ seriously thinks UNIX like systems need to go the way of VAXen.
// well, actually not so much the systems themselves, but the assinine UNIX mentality of "harder is better" and "more documentation eliminates the need for good design.", which set back Computer Science departments and academia 15 years behind industry.
/// fortunately, one of the unintended side-effects of Linux is that the mentality, at least amongst Linux users, is slowly, ever so slowly, fading away.

Re:UNIX hater's handbook.

[MROD]

// well, actually not so much the systems themselves, but the assinine UNIX mentality of "harder is better" and "more documentation eliminates the need for good design.", which set back Computer Science departments and academia 15 years behind industry.
/// fortunately, one of the unintended side-effects of Linux is that the mentality, at least amongst Linux users, is slowly, ever so slowly, fading away.

Hmm.. yes, in /// you say that Linux programmers are going away from //. They are, they're just not doing the documentation. ;-)

Re:UNIX hater's handbook.

[AlexMax2742]

Hmm.. yes, in /// you say that Linux programmers are going away from //. They are, they're just not doing the documentation. ;-)

Which is why we have BSD.

Re:UNIX hater's handbook.

[10101001 10101001]

Unix hater's handbook

it's funny AND true.

Yes, and not true of GNU in many cases.

/ seriously thinks UNIX like systems need to go the way of VAXen.

To an extent I agree. But the only paradigm I've seen that's a good replacement for UNIX is something like EROS, and I'm still waiting for a working implementation. // well, actually not so much the systems themselves, but the assinine UNIX mentality of "harder is better" and "more documentation eliminates the need for good design."

Actually, the mentality is "simpler [code] is better", often to the point of requiring the user to do some bizzaro things to make things work right. GNU has really worked to fill in these gaps, probably because when reimplementing things they got fed up with problems innate to the old tools. Admittedly, some of the solutions are really just hacks of a sort (--).

, which set back Computer Science departments and academia 15 years behind industry.

I'd say it's the reverse. I'd say UNIX is much like unicellular life. Unicellular life is simple, multiples rapidly, and it functions well at the limited number of tasks it does. Without life like this, there'd simply never have been the means to build more complex, multicellular life. And even with this more complex life, there's still many nitches where unicellular life is still best. UNIX was/is a very good design for the job it's itended to do. But it's clearly not the solution to a lot of complex problems. Oh, and Windows isn't remotely either, as it's stuck in the same paradigm of VMS/UNIX, but with some more complex ACLs slapped on top. /// fortunately, one of the unintended side-effects of Linux is that the mentality, at least amongst Linux users, is slowly, ever so slowly, fading away.

I'd say GNU is responsible more for this. Truthfully, though, it'd be a pretty drastic fork away from anything *nix-like before there will be real progress in this area. The good part, though, is that Linux could provide the means to this new OS's driver needs. Applications, though, would probably be a massive rewrite.

Re:UNIX hater's handbook.

[mumblestheclown]

I think it comes down to this: when a user's input results in some unexpected output or if the user was unable or found it difficult to tell the computer what he wanted to do, the UNIXine (and this applies to GNU stuff, Linux stuff, and BSD stuff equally) response for many years was "the user made an error" or "the user's lack of knowledge is the core of the problem."

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...

Re:UNIX hater's handbook.

[linzeal]

The CLI is only faster if you are using the same tools over and over again. That is my experience anyways. Any time I have to do something new with an OS I would rather just have a damn gui application than learn some new "foobar -dfgw | h.c" crap.

Re:UNIX hater's handbook.

[Anonymous Coward]

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

Re:UNIX hater's handbook.

[BritneySP2]

There is no limit to one's stupidity. How more obvious could this be. Saying that KDE and Unix are essentially the same is like saying that a person and the clothes he/she wears are the same, or flying the plane (as a pilot) and flying on a plane (as a passenger) is the same.

There is no point in even comparing KDE to Unix: it makes no sense to compare the capabilities of, say, Unix shell with--what?--the style of window decorations, the desktop background color of antialiasing of fonts?

In other words, Unix (at least, in my view) is all about automation, that is, making a computer work, while KDE and such are all about people doing work on a computer. KDE users, play your games and leave the OS your eye candy happens to run on top of to the care of others. And remember: your ability to drag 'n drop does not make you a Unix user.

Re:UNIX hater's handbook.

[Anonymous Coward]

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.

Re:UNIX hater's handbook.

[mumblestheclown]

Let's get specific, shall we? The CLI itself is not the problem - it's the way it was implemented. By the early 1990s, it would have been possible - trivial even - to make a context-sensitive CLI standard that, by prompting and hinting to the user at appropriate points, would have helped the user ensure that he was typing in appropriate things. this would have in no way impacted the speed or overall usefulness of the cli, and in fact undoubtedly would have resulted in fewer operator errors and overall efficiecny improvements. You know, something to the efect that as you typed in command-line arguments to gzip, would pop up english language help right there, helping you get it right the first time.

However, this was not done in any meaningful way. In other words, while it would have been SIMPLE to add additional usability with NO loss of functionality or speed, it was not done. Why? IDIOT PHILOSOPHY.

It was not done because UNIX back then (as now) was a combination big dick and competing standards contest fought between people who basically still subscribed to the idea that they were the gatekeepers of information- the intercessory priests to the god of computing. We see an echo of this jackass attitude in one of the responses to my posts - the idea that CLI is for "experts" and KDE is for "newbies." There is, amazingly, no middle ground mentioned because the whole system was explicitly designed by a deranged "elite" so that there would be no middle ground - no hierarchy.

It's not that the CLI is itself an evil invention - it's not. It's the attitude that surrounded its many, universally poor implementations that was evil, and again, the general belief and universal attitude by those pathetically clinging to their status as "UNIX Gurus" that it was the responsibility of the user to climb UP to the system (by learning various hacks, system-specific things, and so forth) rather than changing the system ONE IOTA to, you know, actually make it easier to use. The history of UNIX-like systems, until quite recently, has largely been the opposite - make MORE incompatible, often contradictory systems so that the user is left with even more rudimentarily simple tools to accomplish ever more complex tasks.

Re:UNIX hater's handbook.

[marcosdumay]

It was done to the extent that was possible. The CLI isn't there to let the user write, it is there to automate stuff. When you want to automate stuff, you use lots of rarely used functions that your system would neglet (making the user RTFM anyway) and monitor space is extremly important. Also, you don't want some weard program messing up with the streams.

Re:UNIX hater's handbook.

[jadavis]

to make a context-sensitive CLI standard...

You are ignoring important points. Part of the reason the cli is so successful -- and it is successful -- is that it's not context-sensitive (for the most part).

What that means is that "grep" or another tool doesn't really care what program is passing it information, and it doesn't care what program it's passing information to. It has a well-defined input-output behavior, independent of context.

Your little idea for help might be nice, but it's limited. Some shells do offer little bits of help here or there (tab completion is the obvious example). There's only so much help you can display on the screen before it makes more sense to just use "man".

The thing about a CLI is that there are two major types of interfaces: those that present you with a set of options; and those that allow virtually limitless possibilities.

When people say windows or a mac is "easy", it's because the options are limited. Whatever is in your start menu, that's what you can do. If you want to do more, pop in a CD and hit "install", and now you have one additional option in your menu. Anything other than that and you need to start programming.

In a CLI, there are no predefined options. You do what you want. Which means, you need to know what you want to do, and what tools will help you do it. There are many, many tools, so it doesn't make sense to provide the tools as options.

Unix and unix-like OSes are used for such a wide variety of tasks that the CLI is important to those operating systems. I haven't heard you come up with any real suggestions for a unix-like OS aside from your nifty help feature, which is not exactly earth-shattering.

You also ignore other important usability points. Gedit and Notepad are "easy" because they are intuitive. Click where you want to type, and type. However, intuitive is not always the most effective interface. I personally like emacs because I have trained myself to edit files more quickly than I ever could with Notepad. If you want to compare emacs to VS.NET, one clear advantage of emacs is that it can be used on a wide variety of machines remotely very easily.

Re:UNIX hater's handbook.

[ClosedSource]

"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."

At the time Unix was created there was no such thing as a casual user and GUI's were not practical (The Xerox Alto was still 4 years in the future). So the Unix CLI wasn't designed for experts or casual users; if anything it was designed to be efficient on the slow teletype machines that were commonly in use.

Re:UNIX hater's handbook.

[Anonymous Coward]

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

Re:UNIX hater's handbook.

[mumblestheclown]

Yes, that's right. Don't let anybody challenge your comfortble, if severely outdated notions. Meanwhile, just ignore the fact that the words "usability" and "user-centered-design" were basically nowhere to be seen in virtually any computer science department until quite recently, and even then, it's as an elective "soft" subject basically irrelevant to the "main theme." The preaviling orthodoxy of how programming is "taught", which is "code before design" and that "user-related stuff is for the visual basic programmers at the community college down across town."

You think I'm wrong? Consider something like computer vision people in CS departments who arguably should have nothing to do with this discussion. How would they be affected by this cancer? Why, for the simple reason that they were forced by convention to do their research with tools completely inappropriate to the task - low level programming languages where they had to worry about malloc() instead of actually coding computer vision stuff. NLP people who spent more time worrying about LISP parentheses than actual NLP stuff because writing an actual IDE that didnt suck and/or take a "guru" user to use was taboo and "showed weakness." Always was missing was the general idea that there should be a hierarchy of tools to make life easier or the fact that the whole point of a computer was that you can make tools to automate and/or eliminate hard and/our routine tasks. The entire mentality at MIT/CMU/Harvard (those are the places I knew best in my graduate years) was that in order to show that you had the right mettle, you had to go through the agony of learning some pointless shite in order to do something that a PC user wouldnt have to think twice about.

Re:UNIX hater's handbook.

[master_p]

unfortunately truths like in that document are not being said any more, due to 'political correctness' and the mentality of 'profit drives everything'...so we have ended up with bad O/Ss, bad UIs, bad programming languages, and half of our time is spent fixing problems instead of being creative.

Re:UNIX hater's handbook.

[chthonicdaemon]

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.

Re:UNIX hater's handbook.

[mumblestheclown]

A word processor lets me write what I want. I am not limited to some arbitrary modal things that I can write with it.

However, it has a spellchecker and a grammar checking tool. They are not perfect, but you'd have to be willfully blind not to recognize that those things do catch spelling mistakes and help along the work of even English PhDs. If you want to write in another language, say, portuguese, you install a grammar checker for that. The installation process is simple and well signposted, since installing a portuguese dictionary is not something that is done often.

The installation of a spellchecker in no serious way slows down or detracts from my use of the word processor. All else being equal, a word processor with a spellchecker is better in the sense that it allows tasks to be done either more quickly or more accurately or both than one without. Its an INCREASE in usability.

You can drone all you want about the wonderful qualities of the CLI in the hands of a skilled user. You (and others) can go on endlessly telling me how it's "not SUPPOSED to be easy to use.. it's supposed to be to automate things..". You could, but you'd just evidence more that you just don't get it.

There COULD have been a CLI with enhancements equlivalent to a spellchecker (if you've ever seen, for example, the Visual Basic 6 IDE, which, for all its warts, has an absolutely lovely context-sensitive programming help which is an example along the lines of the sort of thing I'm talking about). The point is that nobody actually went and did one. Was the reason a technical limitation? NO. Was the reason that adding such a thing would have made the underlying item less useful and/or slower? NO. Was the reason that there was no demand for such a thing from users? NO. The reason that such things were not built was 100% completely because of a BAD MEME in the UNIX (and associated CS) commnunity which basically said "I spent the time learning these useless flags and other quirks and now I am a respected guru. I dont want to give up this 'status', and since I have learned this already, there is little to no incentive to make things better. Guruism is knowing useless shit and being a gatekeeper to computing power, NOT being an enabler of allowing OTHER PEOPLE to use computing power."

And this, is the core of the problem.

Re:UNIX hater's handbook.

[mumblestheclown]

Stop it already.

Even if we take your silly examples of powertools and the like, if you went into a shop floor today and compared it with a shop floor of 50 years ago, you will notice one obvious difference:

The tools are fundamentally the same. However, today's tools have been designed to be SAFER and have fewer operator errors. The usability is INCREASED.

I am not suggesting replacing chainsaws with butterknives, or the idea that a chainsaw can ever be COMPLETELY safe. However, the history of UNIX usability in the 1990s was basically "let's build a car with a plate glass windshield instead of a safety glass one, because, even though the glass would be 100% the same from the standpoint of every day usability and essentially the same in terms of cost, only good drivers should be driving this car and good drivers dont crash (and if they do, they weren't good drivers)."

The results were many bloody drivers, many destroyed cars, and, perhaps least noticably but most importantly, the average speed of the cars was much slower than it could have been, as even the 'expert' drivers were compelled to go slower than they could have had they had better tools. Of course, if you complained, you were a n00b.

Re:UNIX hater's handbook.

[xeno-cat]

You are starting to sound like you just want the world to work exactly the way that would be convienient for you. If the world obliged then of course things would work well, for you. I don't expect the world to work only for me. There are good reasons the UNIX CLI is designed the way it is, as people have mentioned here. What I have found is that investing the time to learn the system has made me about 1,000 times more efficient and less error prone than people who relly on the GUI to get things done. This is what proffessinals do, they invest time to learn the powerful tools. If you want easy, stick with your GUI, they come in all flavors.

      Also, your retort to the modern machine shop floor is flawed. I'm not sure how many shop floors you have seen but depending on what you are doing you can not just walk up to, say, an industrial lathe and use the nice GUI to make a lamp stand. Modern machines _are_ safer but they are much more complex than what they replaced. For example, a local wood shop has a robot that can take a block of wood and use a series of about 20 tools to produce almost any shape you have created a template for. But to use it effectively you need to have a lot of specialized knowledge. i.e. _you_ have to learn the context.

      Which is sort of what UNIX is all about, a context to automate other contexts :). There is no reason you could not write a CLI that does everything you are asking for. It would just be rigid and limited. Apple actually did something like this when they had A/UX. It was cool if you were a newbie but pretty useless once you got passed the basics.

      If you want an completely integrated environment that understands context you might really like the new Microsoft .NET enabled CLI. But now I'm just being mean.

Kind Regards

Re:UNIX hater's handbook.

[chthonicdaemon]

I get that one can add protective measures that are not 'in the way' and that a tool that encourages or invites accidents or misuse could be redesigned to make it inherently safe. I am an engineer, so I am aware of the idea of designing in safety. As I said, you make a few good points.

I think the problem with your original post is that it muddies the water with statements like 'long manuals are the hallmark of bad design' in the context of computer use. Especially because many of the readers here regularly use language-based tools that are literally impossible to master without a manual, simply because language is not self-documenting, and does not necessarily have to be. I think what you may be missing is that people like the GNU project have put in significant effort to make their tools 'intuitive' to the user, by using similar flags and by presenting a unified abstract view of the machine through files. Perhaps you where trying to say that the 'original' unix attitude encouraged bad design, but that it is changing. Instead it came off as bashing non-graphical/non-self-documenting systems as overly dangerous and complex.

I think usability and power are not totally orthogonal, but there is a nonzero angle between them. We can all agree that some usability improvements cost nothing in power, but we will not agree that a complicated system relying on use of language to supply power can be used optimally without reading the instructions.

PS: I think I agree with almost everything you are saying, so don't think I am being argumentative.

MISQUOTE

[Anonymous Coward]

"There are two major products that came out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson

Thanks

[Hakubi_Washu]

Thank you

Re:It's not what the inventors think

[jgrahn]

The inventors of Unix don't use it any more, isn't that enough for you people.

No. I'll stop using Unix when something more useful to me comes along. That hasn't happened yet, obviously.

Plan 9 could have been useful if Unix was bad enough to make people migrate.

As it is, something that replaces Unix would have to have enormous technical advantages, no social or economical disadvantages -- and a complete Unix compatibility subsystem. I think Pike has written about that effect too, somewhere...

Re:mnennnnn

[Bloke down the pub]

That command is only valid for System V type variants.

Correction

[XanC]

That's ISBN 0-201-54777-5, or 978-0-201-54777-1.

Re:mnennnnn

[ettlz]

kytf jxcjvoixcvj :: POIJP>>IPOhghghgIPO

That command is only valid for System V type variants.

Ah. I see you've been forced to use AIX as well!

ibm slashdotted?

[marafa]

what? what is going on?
Our apologies

The IBM developerWorks Web site is currently under maintenance.
Please try again later.

Thank you.

IBM On demand servers slashdotted?!

[unforkable]

Our apologies

The IBM developerWorks Web site is currently under maintenance.
Please try again later.

Thank you.

!!

Well, maybe they're running Windows on demand!

Re:IBM On demand servers slashdotted?!

[ClamIAm]

Hmm, maybe slashdot could advertise "On Demand" DDoS?

Define it by its limitations

[rolfwind]

Maybe it would be easier to see what Unix is by pointing out the weaknesses, reading "The Unix Hater's Handbook" for instance:

http://web.mit.edu/~simsong/www/ugh.pdf

Which, despite the name is not a mindless bashfest and is interesting.

--Plan9/Inferno and Lisp Machine advocate--

Re:Define it by its limitations

[moranar]

It is a mindless bashfest. Nevertheless, it is interesting. There is some truth in their madness. But they themselves admit that it's over the top and to be taken with a grain of salt. At least the book, I'm not sure about the mailing list/newsgroup.

Re:Define it by its limitations

[rolfwind]

I'll disagree - it's a series of articles by people who worked with Unix (back then) and have other systems to compare it to, I consider many of the articles surpass the atyppical +5 posts here on slashdot^_^

Re:Define it by its limitations

[rolfwind]

Check out chapter 7 titled "The X Windows Disaster: How to make a 50-Mips Workstation run like a 4.77MHz IBM PC"

I especially like the opening quote:

"If the designers of X Windows built cars, there would be no fewer
than five steering wheels hidden about the cockpit, none of which fol-
lowed the same principles--but you'd be able to shift gears with your
car stereo. Useful feature, that."--Marcus J. Ranum, Digital Equipment Corporation

Re:Define it by its limitations

[rolfwind]

Please keep in mind it was written circa 1990, some of it was meant as pure comedy. Though, I think the point of expertness that you bring up dovetails with their complaint about the complexity of the system.

Re:Define it by its limitations

[Xabraxas]

A lot of it isn't even true anymore. It was a great read 15 years ago but today it is an ancient relic.

Surely, if Unix was a stable and standardised API

[C A S S I E L]

...we, erm, wouldn't need Autoconf?

unix

[wwmedia]

unix brings me back to college days

back them doing assignments on windows was more fun than unix command line...

alot of people on our course got put off from ever touching unix and linux thanks to this

Re:Surely, if Unix was a stable and standardised A

[Anonymous Coward]

>...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

Re:Unix is in everything

[eneville]

This is a better documentary of UNIX evolution: http://imdb.com/title/tt0308808/

Last time I checked, UNIX was a trademark

[layer3switch]

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??

Re:Last time I checked, UNIX was a trademark

[Russ Nelson]

If Linux is a kernel, where is Solaris/Linux (in the same misbegotten naming scheme as GNU/Linux)? That makes no sense, of course, since the operating system *is* the kernel plus whatever runs on it. Linux is Linux, GNU is GNU, and Solaris is Solaris. Name/modifier is crap/shit. Just say no to crap/shit.

Re:Last time I checked, UNIX was a trademark

[Frumious Wombat]

You're witnessing the power of Marketing. IBM called their Intel/DOS system a PC, and therefore all of its descendants are as well. Apple Computer, Inc, etc, have appropriated common words, and your average owner forgets to put the (TM) after their name. "Well Bob, I bought one of them (tm) new Apple Computer Inc(tm) PC(tm) Thingies to steal movies with".

They've missed the true meaning of PC, which is "Personal Computer". Once, due to circumstances not entirely beyond my control, I was the sole User/Root on an Origin 2000. Except that it was headless (had to use a real DEC VT220 to access it), it was an absolutely marvelous PC. At the time, the only improvement would have been if it had been an Onyx, with the cinema display.

Re:Last time I checked, UNIX was a trademark

[WebMink]

Linux is Linux, GNU is GNU, and Solaris is Solaris.

In which case, what is Nexenta making? They're using Debian GNU/Linux but with the OpenSolaris kernel - they themselves can't decide between "NexentaOS" and "GNU/OpenSolaris". The result doesn't appear to fit your taxonomy, but still works really well. I think we'll see more and more of these rematches of userland and kernel appearing. Easy assumptions about the superiority of $KERNEL or $USERLAND are way overdue for a challenge.

Re:Last time I checked, UNIX was a trademark

[rshimizu12]

Trademark clarifications UNIX is a trademarked name that is owned by the Open Group. In order for a OS to call itself UNIX it must meet the Unix 03 standard (http://www.unix.org/unix03.html ). Linux does comply with the Unix 98 standard, but I am uncertain about the Unix 03 standard.

Re:Last time I checked, UNIX was a trademark

[Xtifr]

> If Linux is a kernel, where is Solaris/Linux [?]

I don't know, I don't care, I wouldn't be surprised if somoene was working on it, but I wouldn't be particularly interested in the project. I've been using GNU since the mid/late-eighties, and it's the part I really care about. I started with GNU on DOS and OS/2 and XENIX and SunOS, and preferred it because it gave me the highest level of portability I could find at the time. Frankly, I no longer care what kernel I'm using, as long as I'm using a GNU-based system. "Linux" may be the commonest name for the most commonly used GNU-based systems, but I'm not using those systems because they have Linux, I'm using them because they have GNU. Systems that have Linux (the kernel) without GNU I'm not interested in (and yes, they exist). Systems that have GNU without Linux are just fine by me, though.

I'm generally a "rose by any other name" sorta guy, so I don't care what it's called, but I do find it puzzling why you care so very much, and why you object so strenuously to people mentioning the only component I actually care about.

> Linux is Linux, GNU is GNU, and Solaris is Solaris.

The Debian project has GNU/BSD and GNU/Solaris systems in the works. How do those fit into your world-view? Frankly, the fact that they're all GNU is really the only thing that matters to me.

> Name/modifier is crap/shit.

At least you got the order right. "GNU" should be the name, IMO, and "Linux" (or "BSD" or "Solaris") the modifier--if someone cares about names all that much (which I don't). Calling the whole system by the name of just the kernel, when nobody with any sense really cares that much about the kernel, is just silly. But then you do seem to be overly obsessed with labels (or so I judge by your involvement with that most useless of labelling organizations, the OSI) so maybe I should cut you some slack. :p ;)

It's said that people often become what they attack. While I like the GNU project, I would be the last person in the world to deny that RMS can be bat-fuck insane. But it seems to me that people who disagree with him merely because he's bat-fuck insane are in serious danger of becoming bat-fuck insane themselves, and you and ESR seem to me to be well down that road, Russ. And at least RMS and his gang of crazies put out some good, solid code that I use every day. If I were to choose sides on this issue that I don't care about, I'm afraid I'd be inclined to go with those who actually do something a little more useful between rants.

Re:Last time I checked, UNIX was a trademark

[linuxpyro]

Systems that have Linux (the kernel) without GNU I'm not interested in (and yes, they exist).

Just out of curiosity, what is an example of one? I'm not arguing, just wondering.

Re:Last time I checked, UNIX was a trademark

[oudzeeman]

I had a CS professor that had an iMac in his office with a post it note stuck above the screen that said "This is a frigging PC"

Re:Last time I checked, UNIX was a trademark

[Russ Nelson]

I'd be inclined to go with those who actually do something a little more useful between rants.

I'm always embarassed on behalf of people who claim that ESR doesn't write code, or if they acknowledge it's code, they claim it's bad code, or if it's not bad code, it's not useful code, or if it's useful code, it's not useful to enough people, or if it's useful enough people, he takes too long to write it. Clearly no matter what ESR (or apparently me too) do, it's not going to be enough to satisfy some people. So, since you clearly are planning to be dissatisifed, there's no point in attempting to correct you. I'll let you be wrong -- and let you wonder why, and how, and where.

Re:Last time I checked, UNIX was a trademark

[shmapty]

i go poopie

"Processes."

[Ivan Matveitch]

Turning a physical computer into n virtual computers that each execute machine instructions in a separate address space. Throw in a bunch of interprocess communication mechanisms (filesystems, sockets, shared memory, etc) and you get unix. The model is so successful because it is so conceptually unambitious.

Re:"Processes."

[Col. Bloodnok]

I like to think of it as a bunch of computer science theories put into a vat and distilled into a powerful brew, with a strength and flavour that takes a while to get used to, even longer to like, then before you know it you can't live without the stuff.

Slight hangover on some mornings though, when you've had too much.

Timeline also has...

[KwKSilver]

lots of links to other unix stuff.

Repeat after me

[furry_wookie]

Repeat after me...... AIX is not UNIX. :)

Re:Repeat after me

[hellraizr]

... no it's better :)

Re:Say what you want about Windows.

[Ami Ganguli]

Are you sure about that? I confess that I haven't tried running old binaries on new systems (with source code available there doesn't seem to be much need) but I know that the Linus, at least, is dogmatic about making sure that the Linux system call interface is always backwards compatible. You can run binaries that were compiled against Linux < 1 unmodified today.

I'm not as confident that the same is true of userspace, but I bet it's not that different. Where there have been incompatible user-space ABI changes (glibc, gtk) the distributions I've used make the older versions available and useable alongside the newer versions.

still an amazing OS

[yagu]

I've been working with Unix/Solaris/SunOS/Linux/AIX/AUX/BSD/ATT Unix, et. al. now for over twenty years. I mostly love the environment, I'm self-taught, and never have stopped discovering new and cool (and sometimes amazing) things about how Unix works.

I've pretty much always always been able to sit down and immediately be productive in a Unix environment. Things are stored and arranged in a surprisingly consistent way (not always in the same places, but one of a few organizations (/etc vs. /usr/etc)), and for those hard to find arrangements you need only know "find".

Considering how many different Unixes there are it's actually impressive how compatible and consistent they are across the Unix universe. It's only my opinion, but I find adapting and adjusting to the Unixes far easier than the various versions of Windows.

portability wtf

[jilles]

"With rare exceptions, porting hassles between UNIX systems are long forgotten."

Yeah right. We're down to complaining about porting apps between versions of the same distribution of linux and here's a guy claiming that porting hassles between UNIX systems ar long forgotten. Come on, you can't claim that with a straight face even if you are working for Microsoft.

It's not like your 1993 binary of wolfenstein will work out of the box on win XP but the chances of binaries from that era doing something are a lot higher than say running any unix binary from that era on the latest Red Hat/Debian/Whatever. Compiling with the latest GCC almost guarantees running into porting issues, never mind the particular OS you are doing that on. Probably hello world works fine but anything doing something less trivial is likely to not work at all. Generally problems increase as you (necessarily for non trivial stuff) depend on libraries not part of any of the Unix standards. For example, these standards do not cover anything related to graphics or user interfaces so you're fucked if your app is non trivial enough to include a (G)UI.

Re:portability wtf

[TheRaven64]

Last week I installed Erlang/OTP on an IRIX box. The build system didn't work with IRIX make and the code didn't compile with the MIPSPro C compiler. Building GNU make was fairly easy. Building GCC took most of a day; it would configure fine and then fail in the build step with an uninformative error. Eventually I resorted to building it without C++ support. Next, building Erlang was fun. The configure script (well, actually a configure script invoked by a recursive make, which took a while to find) was incorrectly detecting gcc as supporting -pthread (an option which, as far as I know, is only valid on a DEC Alpha compiler), and then failing since GCC doesn't support POSIX threads on IRIX. Once it configured correctly, there was some code at the end of a huge list of OS-dependent #ifdefs that was so obviously wrong it was obvious no one had ever tried compiling it. Commenting it out (it was in a part of the OTP library I am not going to use) finally allowed it to build.

The entire process took the best part of a day. Building non-trivial software on a UNIX that it was not designed for is definitely not easy. Anyone who has written code that uses POSIX threads or AIO will be able to tell you that. I wonder if the author of this article has ever actually tried.

Re:portability wtf

[Anonymous Coward]

yeah. It was next to impossible to get id's quake 1 source to compile on linux. oh, the horror.

i had to type 'make'!! and then, get this, i had to move the quake binary to ~/bin myself!

Re:portability wtf

[daverabbitz]

you mean you didn't install it system wide? CRAZY!

Re:portability wtf

[swordgeek]

You're right. Two interesting facts come up in your post, which are worth commenting on: ...the chances of binaries from that era doing something are a lot higher than say running any unix binary from that era on the latest Red Hat/Debian/Whatever.

and

Compiling with the latest GCC..."

Yep. And thank you Linux, for trashing Unix porting progress and taking us back to 1981.
SunOS binaries from 1993 will almost certainly run on Solaris 10. Same with HP-UX and AIX. On the other hand, Linux binaries from last Tuesday may or may not work on the same machine after patches. Between distros, you're almost completely SOL.

There are TONS of ways to create portable code--everything that doesn't deeply tie into the kernel or device drivers should be portable. X11 was part of that portability, as were many other bits and pieces. The good Unix developers took pride in writing efficient, portable, clean code.

Linux as a complete system and a community (i.e. not just the kernel) has turned its back on backwards compatability, and also on interoperability. Worse, it is developing a base of 'standards' which are absolutely required. Most apps now don't need a C compiler, they need GCC version 'x'. Similar problems exist for make/gmake and bloody troff/groff! That's right, people are writing MAN PAGES which require a specific release and version of GNU tools to read (MPlayer is one example).

The more time I spend with Linux, the more frustrating it is to see a ground-up free OS making all of the same mistakes that MS has made, but without the marketing/financial benefit to justify them.

If only that were true!

[Anonymous Coward]

Clearly you were never forced to program anything to the Win32 API.

There's a common subset of functions available on both 9x and NT flavors of Windows. (With different bugs and sometimes different supported flags, different restrictions on use, etc). Then there's a bunch of functions that only work on NT-based flavors of Windows, not 9x-based. And the opposite is also true. Then XP came along, then Server 2003, each adding a bunch of new stuff to the API that Microsoft (unfortunately) did not go back and also add to the earlier versions of Windows.

There really are at least 3 distinct flavors of the Win32 API, and you have to be careful what functions you use if you want your program to run on all three of them.

For an example, check out the documentation for the CreateWindowEx function.

If you scroll to the bottom, they describe several of the differences in the behaviour of this function on different versions of Windows ranging from 95 to XP.

This situation could have been avoided if Microsoft had had the foresight to separate the Win32 API implementation from the rest of the OS so it could be upgraded independently.

Re:If only that were true!

[Quantam]

Then there's a bunch of functions that only work on NT-based flavors of Windows, not 9x-based. And the opposite is also true. Then XP came along, then Server 2003, each adding a bunch of new stuff to the API that Microsoft (unfortunately) did not go back and also add to the earlier versions of Windows.

I can only think of one feature that's available on Windows 9x but not NT, which isn't part of the Internet Explorer toolkit, and it's a very rarely used feature (although it's just the kind of thing I use). Almost universally, the API on NT is a superset of that available on 9x; though it is true that occasionally some small implementation details different between the two.

Then XP came along, then Server 2003, each adding a bunch of new stuff to the API that Microsoft (unfortunately) did not go back and also add to the earlier versions of Windows.

Correct. The Windows API evolves over time, adding new and often useful features to new versions, often involving new features of the kernel. In nearly all cases these changes are backwards compatible.

There really are at least 3 distinct flavors of the Win32 API, and you have to be careful what functions you use if you want your program to run on all three of them.

Windows 9x, Windows NT, and..? Well, I suppose you could call the ANSI/Unicode versions different, even though the differences between the implementations are usually very clear-cut (i.e. path strings are always handled in certain different ways).

For an example, check out the documentation for the CreateWindowEx function.

If you scroll to the bottom, they describe several of the differences in the behaviour of this function on different versions of Windows ranging from 95 to XP.

That serves as an excellent demonstration of what I've said: the differences are usually minor enough to not be a concern, and that new features are added in a backward compatible way. Take a look: one of those differences refers to a feature that was added in XP (WS_EX_COMPOSITED), another refers to a kernel limitation of 9x, and the third refers to a feature that was added in 2000. Of those, the only "serious" one is the 9x kernel limitation, and even then it's not particularly important.

Re:If only that were true!

[Anonymous Coward]

Clearly you were never forced to program anything to the Win32 API.

Have you ever programmed on Unix/BSD/Linux systems? When writing non-trivial applications, there are substantial differences among them. Why do you think GNU autoconf was created?

Having programmed on both, I can say that Win32 is, and always has been, much more uniform across variants of the system than Unix/BSD/Linux. That doesn't mean it's better, or more consistent on any givem implementation. I generally prefer the Unix/BSD/Linux APIs, and would say they're more consistent on any given implemenration, but the differences among implementations are clearly bigger than the differences among Win32 implementations, especially if graphical APIs are added to the mix. There's also a much wider variety of different Unix/BSD/Linux systems developers have to worry about than is the case with Win32.

Another Amiga mention...

[LoadWB]

heheheh I'm beginning to think that finding a mention of Amiga in articles covering aged, long-standing, or break-through technologies or philosophies, or just places of honor in computing history, is almost like a "Where's Waldo" using web pages as the pictures :)

(Uh, are we a cult yet?)

I vote for syslog

[Russ Nelson]

I vote for syslog as the most drug-induced facility.

Re:I vote for syslog

[samkass]

You've never read a Sendmail.cf file, have you?

Re:I vote for syslog

[Anonymous Coward]

To be fair, he did say "drug induced". Sendmail.cf (Heck, M4 in its entirity) clearly is not drug induced. It is a many tentacled being which slithered forth from the darkest nether regions of hell to lay waste to the minds of humanity. On a good day.

Re:I vote for syslog

[sharkey]

Currently sleeping in R'lyeh, reports indicate.

Re:I vote for syslog

[juliao]

ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn

but don't forget

[plopez]

OLE
COM
COM+
DCOM
There are are probably more, but it seems like MS changes APIs every few years.

Re:but don't forget

[Hal_Porter]

A few minutes Googling would tell that you COM+ and DCOM and back compatible versions of COM with new features, and that OLE is a dead end technology built out of COM.

And you can write Windows applications without knowing much about any of them
.

The only lasting influence of COM is in DirectX based programming, since DirectX is COM based, but the latest DirectX versions hide most of the COMmunism of the API.

Linux vs UNIX

[argoff]

In all fairness, it all came from the same tradition - but when AT&T took back the copyright on their original UNIX implementation - that's when it started to seriously fragment into AIX, HPUX, APUX, DGUX, Solaris, and BSD's. Evolution slowed down drastically and left the UNIX community wide open enough for Microsoft to drive a train thru. To compensate, the UNIX community tried to force thru all these standards initiatives (renember CDE?, Motif), but they always failed to stem the tide.

Then Linux came along, and started to undo the damage that the copyright fragmenting caused to begin with because it was under the GPL, and ever since then it has been the beginning of the end for Microsoft and Linux has taken off in the server space and now it's getting ready to attack the desktop. Moral: free markets are about freedoms and not markets. When you have freedoms the markets will take care of themselves, but when you sacrifice freedoms for markets - you will eventually loose both.

Re:Linux vs UNIX

[wolftone]

Then Linux came along ... and ever since then it has been the beginning of the end for Microsoft I get it now: it's not the *nix family that's dead, it's Microsoft!

'it's the standard that isn't'

[circusboy]

isn't it? that what I was told...

60's??? WTF???

[IvyKing]

Hard to believe that UNIX came out of Berkeley in 1960's since the first tape from Bell Labs arrived in December 1973. I'm guessing the CS department wanted to have a replacement for Kronos that went away when the CDC-6400 'B' machine got shipped off in January 1973.

Or Considering Component Architectures

[Cruxus]

If you consider the evolution of component architectures, the evolution of programming for the Microsoft platforms is a little more complicated. Really, the Microsoft .NET platform is just a replacement for COM and the Win32 API and is inspired by Sun Microsystems' Java platform. COM and ActiveX controls stem from the older OLE (Object Linking and Embedding) and VBX (Visual Basic eXtensions).

Re:Say what you want about Windows.

[larry bagina]

the linux userspace/kernelspace interface is changed a LOT. Sometimes it's minor stuff that only affects a few applictions (like changing the /proc/ file format), but they have completely broken the system call abi, so linux 1.0 compiled binaries will not run on a recent distro.

Re:Say what you want about Windows.

[daverabbitz]

You generally can run old linux programs on current Distros, but you need to install the relevant libc/glibc/uclibc compatibility layer. You can even run many Solaris and BSD binaries on Gnu/Linux with the right compatibility layers.

The thing most windows users don't get is that windows has those compatibility layers there by default, whereas most Distro's don't install them as so few users actually need them.

The Same goes for BSD, FreeBSD 5 can run FreeBSD 1.0 binaries, but you need to install the relevant compatibility packages.

On the other hand, some operating systems do have consistent ABI's, Solaris and MVS (now known as zVM?), But (in the case of Solaris) it's only really an advantage to those few suckers that got stuck with Binary-only software and no upgrade path.

Anyway, don't buy custom software without the source code, you *will* get shafted.

Unix you say?

[MattskEE]

A lady struck up a conversation with me on an airplane.

• Her: "And where are you going?"
• Me: "I'm going to San Francisco to a UNIX convention."
• Her: "Eunuchs convention? I didn't know there were that many of you."

From http://rinkworks.com/stupid/cs_comeagain.shtml

So true

[mkswap-notwar]

One of the best quotes I've ever heard was from a colleague of mine,

"Unix isn't."

So What is UNIX?!

[znx]

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.

Re:Say what you want about Windows.

[toadlife]

[i]"The fact that MS userland is hooked into the registry and alows root level access is the reason that crap binaries are so easy to create."[/i]

For a sentence that neither makes sense, nor contains any accurate information, it sure contains a ton of jargon.

Are you a consultant that specializes in Windows>UNIX migrations?

WinNT API

[TwilightSentry]

If I remember correctly, the early versions of NT had their own seperate API, which MS eventually dumped in favor of Win32...

Re:WinNT API

[drsmithy]

You are probably thinking of NT's internal API, which third party developers are not supposed to use.

the middle ground system

[phossie]

The middle-ground system I can imagine happening sometime soon is this: a balanced user interface standard which specifies a unified set of best practices for both CL and GU interfaces. The GUI is all about rapid and focused information retrieval, while the CL is all about rapid and focused information manipulation. GUI is therefore good for discovery - it's natural for new users and can manifest in varying degrees of sophistication. Every GUI program presents a command-line alternative for every GUI-accessible function (and perhaps more, as CLI is well suited to esoterica). A general terminal client with a customizable GUI discovery mode provides an interface for CLI-only programs.

"Everything is a file"

[ClosedSource]

"everything is a file"

Yes, it's the original "leaky abstraction". We're talking buckets of water here.

Re:Choc-a-lates

[Gleng]

Or...

"UNIX is like a box of chocolates. You pick one that looks nice, and it turns out to be really hard."

Re:It's not what the inventors think

[cerberusss]

The best thing about Plan 9 is that lovely and cute bunny! Oh man, I just LOOOOOOOVE that Glenda bunny!