Explaining The Windows/UNIX Cultural Divide 685
giampy writes "Joel Spolsky writes a review-like article on the last book of Eric S. Raymond (The Art of Unix Programming). His views on the cultural differences among Windows and Unix programmers are well explained. Overall, an interesting read." Also on the topic of Windows, badriram writes "Microsoft is reorganizing the windows team, it seems the are separating the
OS core development. Seems like things heading in the right direction in creating a more secure OS, and making it more business oriented. Read the
article here."
Re:to sum it up... (Score:4, Interesting)
Command line? Hell, how about process? Security? (Score:5, Interesting)
I introduced one of them to Nessus [nessus.org], not because it was a Unix program, but because it is a damn good (the best?) security auditing tool available.
His reaction to a security audit showing our primary app server had multiple potential holes just in the programs that support the app? "Well, we don't use that software much, we only use it to get into the program. All the work is being done using the other programs."
For the record, the system was an HPUX server running an older version of Apache 1.x. The app gateway is through Apache to Weblogic, though the main application program runs on the HP box, not elsewhere.
This is not simply an aversion to Unix or command lines. The lax security extends into all the Windows systems as well. For example; all drives readable/writable on the network by any user.
It's a lack of professionalism, not intellegence -- the guy is plenty smart. Adding a little fear to the mix (we print checks dammit!) doesn't raise his concern too much. I've not raised the possibility that he, personally, might be held to blaim for security issues and I doubt that it would work with him.
My only hope is that slowly, without forcing him, he will see that there is something behind my comments and tips. Maybe a light will go on, and he will decide to take a look.
about cultural divide. (Score:3, Interesting)
And yes, that means I prefer GUI over commandline by far and would never touch commandline. To those who think it's a fault: It might be only a personal preference but trying to debate it is like trying to debate whether apples (fruits, not the computers) taste good. In that sense, Windows offers me greater freedom to do with my computer what I want to.
Microsoft's Will to Change (Score:1, Interesting)
Unlike many other people, I'm not waiting on Microsoft to release a useable operating system before embracing them. I'm never buying Windows again, ever.
Re:windows users are the problem... (Score:5, Interesting)
It's sitting right there in your home office. Behind at least one locked door. Maybe even a couple.
I mean, I have my machine set up to automatically log me in; I turn it on and there it is, ready to go. There's me, my room-mate, and nobody else. I trust my room-mate to stay off my machine; she trusts me to stay off of hers.
Binary libraries (Score:5, Interesting)
Of course, if there was a bug in the library itself rather than the application using it, it would be another matter.
Re:How to tell if you are a linux fanatic. (Score:4, Interesting)
ha ha (Score:5, Interesting)
i think the article shows a bit of a polarised image. okay, i see the point of OS advocates being too tech-oriented, but we also have some [kde.org] efforts [gnome.org] that really try to aim at end users, more or less succesfull. allright, it's not as easy as using MacOSX, but it's quite close in many aspects. and quite usable for the novice, especially in the distributions that try to make it simple (xandros, lindows, etc)
linux on the desktop? very possible. a lot more likely than the writer of this article would like us to believe IMHO
The real reason behind "silence is golden" (Score:5, Interesting)
If I recall correctly, the "silence is golden" maxim in Unix programming arose as an artifact of Unix's origins. When Dennis Ritchie and the rest of the historic team at Bell Labs began work on the earliest editions of Unix and C, they were operating on teletype terminals that ran at 110 baud (kinda humbling in this day and age, ain't it?). 110 baud translates to roughly 13 characters per second, so a program that was too chatty wasted precious bandwidth. If they had something like the cp(1) command operating the way the MS-DOS COPY command did, displaying messages like "14 file(s) copied.", which is 20 characters (plus the newline), it would take about a couple of seconds to display, while displaying nothing would be 20 times faster. It had nothing to do with making programs work better with each other and everything to do with conserving bandwidth. This is also the reason why ed(1) and vi(1) have such eccentric design, preserving a resource that was scarce in the day they were made.
reasons behind attitude (Score:4, Interesting)
i personnally don't care what OS i'm using. at home i'm using my computer for video games and sound engineering, so i have 1 up2date windows box for games, and a mac for sound engineering. Why'd i get a mac? because while i'm in the middle of recording a band session i can't turn to the band and say "sorry guys computer crashed i lost the last 3 hours of your work" if windows was stable enough i would be using that. At work is another story though. i write stupid docs and java code so they put me in front of a windows machine. i personnally don't care. although i worry less about my mac then my windows machine.
My family recently decided to get DSL first thing i did was lock that computer down. i almost went so far as to remove IE with some ie removal tool (XPlite for example) but then i realize this would cause more calls to me then it would solve.
i also find that people want a brand name. i was asked to "buy" my own machine for work and i went to one of the lesser known computer builders and the price difference was several hundred dollars compared to what they wanted me to buy from Dell. Take a guess what's on my desk.
A lot of windows users don't care. if you gave them a mac as their first computer they wouldn't switch because they wouldn't know. the example i use alot is "how many people continue to buy automatic tranny cars over stick shift?" neither one is better or worse just a different interface but sticks are slowly getting phased out.
a lot of people (myself included) need to stop saying "windows is for morons" or "windows is less secure use unix" and start to change our "marketing focus" to something more like "building a more structured and secure tomorrow" like it or not "Where do you want to go today" sold computers, it sold windows and increased his market share. unix needs a "where do you want to go today" why? because no normal computer gives a crap about where the source came from.
BTW side story i was on a project where the dev team used exclusively solaris boxes. i had to write a code review document. with no MS office on my computer i wrote it in the other thing available StarOffice. i got hounded for several months by a stupid Q&A team because they couldn't find evidence that this "StarOffice Product" even existed. like just goto google and type "Staroffice" in the freaking search box.
Again just to reiterate my point. people don't care about which OS they run. they want their computer to be like their cars. "if i got someplace else and sit in a car i should be able to drive it". We need to change the marketing strategy of UNIX.
mod me whatever you like but some of you will think i'm flaming which i'm not. some of you will agree with me. i've said all i wanted to say. thank you for reading
it's a "cultural difference"... (Score:1, Interesting)
Windows programming is overwhelmingly done by people with little experience and skill for people with little experience and skill. Windows programming environments are the programming equivalent of prerecorded music, painting by numbers, or ready-to-serve meals.
And Windows programmers will never advance beyond that stage if they keep doing just Windows programmings: you no more learn programming by using Visual C++ than you learn to play the piano by playing all of Horowitz's collected works on your CD player over and over again.
UNIX is obscure, unforgiving, and takes a long time to master. Just like a musical instrument. You won't hear musicians complain either that a violin or a piano has a user interface that is "too complex"--compared to what their craft is really about, the initial difficulties of the instrument are minor.
But even the appreciation of art takes experience, so it is perhaps not surprising that Spolsky even fails to understand the difference.
Without realizing it... (Score:5, Interesting)
observing that a program that produces no output because it succeeded cannot be distinguished from a program that produced no output because it failed badly
With Windows programs, you just never know. In general, I pick up a *nix program, test it a few times to verify that it does indeed do what it was supposed to do and then I use it. With Windows programs, I just never feel secure. I find myself saving more often, checking output at myultiple times through the process and wasting sooo much time verifying that everything did what it ought to have done because I am never quite sure.
Now this is a profound cultural difference, but I think it has little to do with writing for Aunt Madge or writing for other programmers. I think it has more to do with the culture of quality and craft (*.nix) or the lack thereof (Windows).
Many Windows programs "babble", not to reassure Aunt Martha, but to reassure Windows users who have grown up in a culture of "slap it together, get it out the door and let the user worry about any problems with the way it works". Without some confirmation the user just never knows whether a given program is actually working or has crashed. Many Windows widgets including moving progress bars, constantly moving icons and spinning logos are there just to reassure the user that something is indeed happening and that Windows has not crashed in the meantime.
Windows programmers less ideological? I think not. (Score:3, Interesting)
I've encountered too many Unix programmers who sneer at Windows programming, thinking that Windows is heathen and stupid.
[...]
It's rather rare to find such bigotry among Windows programmers, who are, on the whole, solution-oriented and non-ideological.
does not quite relect my personal experience, and I am mostly working in the Windows world (at the moment). The bigotry can be found everywhere, and I've given up on trying to explain the advantages of one culture to people who are claiming the superiority of the other one.
Let me emphasize what an interesting read the Raymond book [faqs.org] is. Very much recommended. Certain issues are too often considered 'common knowledge', although they're not, and the book explains the Unix culture well to those who are interested in technology, regardless of ideology. After all, a lot of things can be used on Windows, too, although they may not be the usual way to do it.
Documentation??? (Score:3, Interesting)
Some of the best docs I have seen are from Open Source projects. Yes sometimes the docs are incomplete, but at least you have the fall back of being able to LOOK AT THE CODE when it's necessary.
UN*X vs. Windows (Score:1, Interesting)
I think Linux needs more standardization of libs; not a rewrite and dozens of libs doing the same.
Starting a new thread: the Unified Driver Interface is an interesting topic
Wasn't that an Open-Source thingy sponsored by SCO??
Re:Bubbling frustration (Score:5, Interesting)
I believe we need to have "end-user focused" programmers, and I think there are a few sneaking into our world (H Pennington, Miguel de Mono come to mind). They'd be folks who know the "unix way" but focus on the "final" solution: The end app that will be used without piping off to other apps, without having to support connections to 15 other things, whatever. Just what the user needs right then and there.
There's a dearth of those kinds of apps now, but they seem to be arriving more and more.
Haughtyness (Score:4, Interesting)
You know, I had a similar thought when reading this review. Mr. Spolski brings up many of the compare-and-contrast points of unix vs windows programming, and while (in my unix-centric view) most unix points stand on their own, the windows points are rather fluffed up with artificial and (in my unix-centric view) rather unconvincing hand waving. Most of his points seem to boil down to
In the end, Mr, Spolski's review falls into the same category that he would like to pigeon-hole Mr. Raymond's book -- an attempt to be balanced and fair defeated by the author's self-inflicted blinders.
My Conversation with Eric Raymond (Score:5, Interesting)
However, there was this one point during this discussing at the dinner before his speech where me and several of the LUG members were talking with him about linux GUI's and the future of the Linux Desktop. Eric Raymond said something about the whole unix system of creating back ends first and then grafting GUI's on to those later.
My response: "But Eric, most usability experts recommend you design the interface first and then write the code".
His response: "then they're wrong."
My response: "But what if there's something that the backend folks didn't think of when they wrote there code that the GUI really needs? Or what if there's something in the back-end that just doesn't work once you add a GUI?"
His response: "then it needs to be fixed."
My response: "But what if so much code has already been written that no programmer wants to go back and make all the changes necessary to make it really work?"
His response: "then we've got a problem."
It was at this moment I realized two things:
Wanna see Unix on the Desktop? (Score:3, Interesting)
The obvious stuff:
1) Coding for other programmers promotes code reuse. Code reuse promotes productivity.
2) Security is affected by code reuse. It propagates bugs resident in the reused code but avoids bugs that would be introduced should the user have to recode that functionality. The net gain is that, so long as the reused code is in a common library, fixing it once fixes multiple applications. Available source means that more (and fresh) eyes review the common code, improving the possibility of finding the bugs in the first place.
3) Writing for end users, when done well, produces applications with better usability. Naturally it tends to sell better.
4) Writing only for end users tends to produce inflexible applications. The user must use the program exactly as the author intended and no other way, unless the programmer takes the higher road. In the first-to-market commercial business environment, taking the higher road is as hard as pushing a rope.
5) Literate end users is not only a contradiction in terms, it is an unreasonable expectation. Programmers cannot expect end users to learn more than the minimum needed to operate the computer because (1) they see it as a tool to to accomplish their real goal, and (2) The inner workings of the hardware and software do not interest them. Is it reasonable to expect all drivers to understand the inner workings of an automobile, or kitchen users to understand the inner workings of their dishwashers?
6) If Unix is to succeed on the desktop, it must cater to end users.
My conclusions:
1) If we really want Unix to succeed on the desktop, it seems to me like we need cultural fusion. We must pay more attention to end users but without losing the values in the Unix community that produce modular, reusable, secure, reliable code.
2) This fusion alone is necessary but not sufficient, else Apple would have more market share than it does.
3) The cultural fusion discussed so far is in the technical world. But IT vendors' companies rest on three pillars: the technical pillar, the business pillar, and the merchandising/marketing pillar. Every company that hopes to put Unix on the desktop would be well-advised to rethink their business processes, standard contracts, and advertising so as to cater to home end users and to give business end users more visibility and consideration. First on my list of business processes to review would be the help desk metaphor. What a universally negative experience!
What say you, technical literati?
Bottom-up AND Top-down learning together? (Score:2, Interesting)
I am now trying to learn Perl (for work) and most sources, again, teach it bottom-up [This is a $calar. This is an @rray.] I wish they would start with [This is how to get perl use a form to ask for a password, submit the form and check the userid/password in a database, return something, and generate the next page, depending on whatever]. I know I gotta understand the foundation but I also have to generate product. I wish I could find somewhere that the two ways of teaching merge so I can generate good stuff AND, eventually, (gasp! maybe by explaining in short phrases even I can get) understand the underpinnings. It's good to have a goal.
*cragen
Where's the sequel? (Score:3, Interesting)
The world will be a better place when the UNIX partisans understand exactly why the "Those who do not understand UNIX are doomed to revinvent it, badly" quote makes IBM mainframe guys go ballistic. Compare mainframe security to UNIX security sometime for just a hint of what I'm going on about.
Re:about cultural divide. (Score:2, Interesting)
The company had standardized on MS Office and didn't officially support anything else. The technology group was in a different city and used Oracle on the database side, but I did not have access to those resources.
I spent well over a year trying to get things to work with MS Access and whatever else was available to me on my workstation for handling data and information.
Eventually I found an old unused computer, put Linux on it and was then able to accomplish things which before had been either hard or impossible. A mixture of Perl, MySQL and PHP for interfaces made a lot of things possible which were otherwise very difficult.
For large datasets Excel is worthless and Access does not give you the flexibility you might need to do massive changes or comparisons between two data sets. Perl and MySQL were far superior for manipulating large data sets.
If I need to get things done I will use whatever tool is best for the job out of what is available to me. In a lot of cases, that means working on the command line or writing a script. I would be severely limiting my capabilities by restricting myself to fancy GUIs.
Re:can this guy actually code? (Score:5, Interesting)
"They don't like GUIs much, except as lipstick painted cleanly on top of textual programs, and they don't like binary file formats. This is because a textual interface is easier to program against than, say, a GUI interface"
This is so naive as to be laughable. The thing that soooo many windows programmers do not understand is that the "text" based paradigm of the UNIX world is exactly that a paradigm and the metaphysics of that paradigm are so deeply ingrained in the approach to programming that the real benefits are often underestimated. If I write a command line program, I need only understand 4 interfaces stdin, stdout, stderr and argv and only half of them are readable! Within that, we have lines and whitespace as standard concepts, again trivial to grok.
As a programmer it is up to me to present my output in the format understood by the stdin/argv scanner of the program I want to call and the process by which I can discover that format is of varying difficulty based on the complexity and quality of the program I wish to call, but generally pretty simple process nonetheless.
The next generation of interaction between programs (or lets call them objects) requires a huge leap in complexity. It is this next generation paradigm that many windows programmers would claim to use. But for it to work, the self discovery of those input and output formats and some standard nomenclature to allow them to communicate with each other to make the discovery is required. For example, my spreadsheet program may have many different inputs, a clipboard, a file interface, a dynamic data interface etc etc and its outputs might be equally complex, but the critical thing is that it must be able to tell my data capture program that it is a spreadsheet stlye application and that phrase "spreadsheet" style application must make as much sense as a "stdin/stdout" style application makes today. Whilst I agree with this posters point about creating an object, and then using a GUI to call it, the point is somewhat moot since the discovery process means that in the Object focused world there is no capacity for this communication to take place and so the programmer is left with the task of doing all the mapping between objects since a "data capturey" type object doesn't really grok the metaphysics of how to present to a "spreadsheety" type application. Now, don't misunderstand, I am not suggesting that UNIX can do this any better, but the paradigm under which a unix programmer operates understands something about the metaphysics of how applications talk to each other and so the UNIX programmer will think in a reuse/talking to other programs kinda way to a level, even if it is at, overall, a lower level of functional richness, that a windows programmer cannot really hope to emulate.
$0.02
Re:Separation (Score:5, Interesting)
Yeah, it's also called Melissa and several other names [thenakedpc.com].
Why automation is considered more important than security is one thing, but why do people feel the need to defend that wierd choice of values? Do people who grow up on this stuff and never learn software tools (unix) methedologies really think WSH is an interesting technology?
Re:Crossing coming to a Chasm near you ... (Score:3, Interesting)
it raises its profile on emedded devices home users will become more comfortable with the idea of a Linux desktop. Similarly as corporates become comfortable with Linux in their server racks, more and more of them will consider the possibility of deploying Linux desktops, perhaps starting with places like call-centres where they don't need a fully-fledged Windows rollout.
Certainly, the chasm can and should be crossed in a series of steps. This is exactly what Moore recommends. More precisely, he recommends establishing a beachhead by gaining control of a niche market. However, this niche market has to have certain characteristics - most crucially, it has to be part of the mainstream market in the first place i.e. other mainstream buyers must reference, trust and rely upon the recommendations made by buyers in this niche market in their purchasing decisions.
Is the embedded device market or server market a market which desktop users will reference in their purchasing decisions? I don't think so.
I'm probably oversimplifying the approach laid out in "Crossing the Chasm". Again, I highly recommend this book.
Various slashes, a history lesson (Score:3, Interesting)
The slashes go "the wrong way" (hmm, any explicit biases there?) because the switch syntax was copied from CPM, the dominant microcomputer OS at the time. CPM in turn copied it from DEC's PDP operating systems (like RSX-11, TSX-11, RT-11, etc. etc. etc - the VAX/VMS system also inherited this syntax, incidentally, along with DCL (Digital Command Language) which is the direct descendant of CCL (Concise Command Language) and RSX Indirect).
A stupider paradigm is Unix's re-use of the directory separator as the name of the root directory; there are some efficiencies of notation and processing that this provides but it's really profoundly counter-intuitive. It's actually worse than the exposed numeric MFD of VMS (which is also stupid, but at least it forces one to understand the mechanics of the filesystem).
Joel is off base. (Score:4, Interesting)
I have subscribed to Joel's mailing list for several years, and have programmed on both sides of the fence. Joel paints a black and white picture of the differences between Unix and Windows - which I must say, is not true. I have to disagree with Joel's oversimplification because he has made the same mistake that he accuses ESR of making: namely that his own monoculturalism has clouded his view of Unix programming. Anytime someone makes a statement that starts with 'the very fact', you can be sure there is less fact and more conjecture than the writer is willing to admit.
The key error in his analysis is narrowly defining the Unix program as being a command-line 'mostly' affair that doesn't tell 'Aunt Madge' when it succeeds. This is not exactly true; while it is true of strict command line applicatioins (which Aunt Madge will not use anyway) - the GUI interfaces do not follow that formula - and programmers are free (not constrained as he would suggest) to build interfaces that meet whatever needs an end user may have - whatever their skill level.
Just because 99% of the end users are familiar with and resist change from the Microsoft GUI does not mean that it is the best UI - it just means that people did not have much of a choice from the beginning (there were only one GUI for PCs back in the late 80s - Windows; the other major GUI was tied to the Apple Macintosh). While the Windows GUI stagnated over the 1990s, the Linux world exploded and a plethora of user interface ideas have surfaced that are effecting the new Windows interface. Same story (DOS - a rip of CP/M), different day ("yeah, whatever, I just need to make a living here").
He also touches on, but does not explore with a self critical eye, the limitations imposed by not having source code. The dependence of Windows programmers on Microsoft APIs provides too many limitations, and increases the likelyhood of unforseen interactions that cause bugs. He whitewashes these issues by simply focusing on the size of the Windows desktop deployments vs. *nix.
The reality is a *nix developer has all of the options available to him; he is not constricted by artificial barriers; a Windows programmer is at the mercy of Microsoft - who can change APIs at the drop of a hat.
His quote above really hits the nail on the head: the Microsoft monoculture is about money above and beyond any moral considerations. I would much rather be a "slashdot-karma-whore" than a Microsoft-whore. From his writings over the years it is plain that he absorbed the 'money is good no matter how you get it' mentality during his stint at the company.
Re:My Conversation with Eric Raymond (Score:2, Interesting)
For example, I'll generally do a simple screen mockup on a whiteboard (or sometimes static HTML), About 50% of the time the users will say "There should be a button there, and when you press it, [blah blah blah] happens". And it turns out that [blah blah blah] is significant functionality that requires a very different back-end design that I was envisioning.
There's no way you are going to get that sort of business user feedback from a set of class diagrams or commandline switches. It requires some sort of whiteboarding or "prototype".
So, I dunno about a Windows programmer (I do web, mainly), but the POV of the Windows User is the GUI and therefore solutions are conceptualized in terms of GUI elements. Makes you understand why VB is so popular.
from a former windows nut (Score:3, Interesting)
the box was red hat 8.
in the past 9 months i've become much more intimatly familiar with *nix. My router is linux, and i just deployed two new boxes, one of them a dual boot with Win2k (for gaming). Only one of the three nix boxes has a GUI, and that right now is KDE. Granted it's a bit klunky compared to Win2k's, in fact ir reminds me more of Windows 95's desktop. Win2k's file manager/web browser/ftp client combo is nice, just type in a different address, but it has many, many, many bugs and holes.
I toyed with the idea of setting up a nix box for my parents, just mozilla, evo and OO.o. until i found out that they needed Quicken 2003 (Crossover didnt deliver).
In any case, I like nix better for some things, windows for others. Is nix suitable for use by the general population? no. it took me 6 months to shake windows logic, the gneral populus would keel over and die, at the least they'd be screaming mad.
My estimation of ESR has gone up (Score:2, Interesting)
If you design the UI before you write the program, chances are you are writing the wrong program. It is not possible (except in trivial circumstances) to find all your requirements up front. Any attempt to do so will result in oddly behaved programs. By thoroughly understanding your problem domain (using less than finished UIs) you have the best chance of eventually creating a decent UI.
If you get the problem domain wrong when you are creating the back end, you have less cultural baggage to contend with when you change it. Changing UI is difficult, because people get used to what they had. Even if it is arguably wrong, chances are people won't want you to change it. They could care less if you change the back end. Therefore, if the back end is broken, fix it. Easy as pie. If the front end is broken, you're in a world of hurt.
Now for the last point, which indicates that ESR really knows what he's talking about. If you've already written so much shit in your back end that no-one wants to look at it, you may as well go shoot yourself. You are well and truely fucked. Because if you can't change your back end, your program is dead. This is true of all programs. If you are afraid to change it, you can no longer work on it. The solution? Create a culture where change is good.
Don't know why I'm writing this. The story's old enough that no-one will probably look at it. Oh well.....
Re:Separation (Score:3, Interesting)
The idea that there is one true O/S is ludicrous.
I cling to plan9. 256 colours, no multi-media, I can't even play mpegs on it.
It doesn't have a web browser worth using.
It has no RDBMS or a dedicated file browser.
No icons. No buttons.
http://www.proweb.co.uk/~matt/screeny_dec_03.gi
But it suits my computing needs for doing work.
Windows isn't reviled because it is used by common people.
Re:Separation (Score:3, Interesting)
On that score the most secure O/S would be CP/M or MSDOS...
Shaddow passwords are more complex than the original UNIX design,. they are empirically substantially more secure.
Unix is a very complex operating system. There are dozens of different formats for configuration files. A large part of the operating system is written using scripting languages and for some reason these will typically be written in four or five different variants of the same scripting language. There is little or no consistency in the architecture, where there is consistency (everything is a file) it causes strange contortions as an object that is clearly not a file is crammed into the same impoverished data model.
You can bolt on an encrypting file system to Linux, but the crypto layer used as a result will be entirely disjoint with any crypto for messaging, single sign on etc. As a result almost no Linux users have an encrypting file system even installed on their laptop. This has been standard on Windows for some time.
Complexity is certainly to be avoided in security systems. But not at the expense of functionality. If you took an original UNIX machine and stood it up on the net it would be rooted in minutes.
Re:Separation (Score:5, Interesting)
Um, yes that lunacy IS unique to windows. Unix as a practice does not allow email apps to operate as root. A web server running with wheel privilages is considered a design flaw. While it is possible to create an environment where a script could enter a Linux box and infect the system, you would have to have the perfect storm of inept sysadmins running deliberately loose settings, exploiting a bug in the software.
All that comes free with Windows.
The chances of that same script being able to infect a second machine is near zero. The other machine would have to be a near clone of the first.
As far as Unix being locked in time, I would like to point out that we have been using Kerberos and Ldap long before Windows thought it was a good idea. (For your edification, Active Directory is an adulterated implementation of Kerberos and LDAP.) NT and it's ilk are also POSIX complient, meaning they strive to be unix-like.
I should also add that Unix does not have a giant world writable configuration system. Regedit is all I need to access the security files, system configuration settings, even policies. Show me a Windows setup that operates without the GUI, without Visual Basic, and without the registry. Then talk to me about security.
Re:Separation (Score:4, Interesting)
Shadow passwords are more complex than the original UNIX design
Shadow passwords are not a solution, shadow passwords are an ugly hack. Of course the most secure solution is not the simplest. In the this case, shadow passwords were barely enough for stand-alone systems; in a networked environment you need a different kind of distributed authentication framework, and that is what factotum/secstore provide [bell-labs.com] with a relatively low complexity keeping in mind the implicit complexity of the problem domain.
As for problems with how in Unix "everything is a file", the problem is not with the original Unix ideas, but with how some misguided souls(*cough* USL, *cough* BSD, *cough* SUN, *cough* RMS/GNU, *cough* Linux, *cough* GNOME,
Who added most of the networking functionality to Unix? a bunch of clueless undergrads in Berkeley, really, who is surprised about the result(BIND, sendmail, etc..)?
Unix, in it's original and "pure" form, evolved, and most if not all the original problems where *fixed*, and so Plan 9 [bell-labs.com] was born, more than 10 years ago, but the "UNIX community"(read, "bunch of misguided clueless religious fanatics") never even understood what Unix was supposed to be like, and more than 30 years later they keep repeating the same mistakes again and again, but now they don't have enough with their own mistakes, that they need to copy others mistakes too(see GNOME...).
There is nothing wrong with the original Unix ideas; yes, there were some horrible mistakes(*cough* suid,
None of the problems you mention applies to Plan 9(and some of them nor to the last version of Research Unix), and in most cases neither to what Unix was originally.
BTW, Plan 9 doesn't even have the concept of "root" or "Administrator", so it can hardly be rooted, as for buffer overflows, all you need is sane libs to deal with string manipulation, which it's true the original Unix didn't have, but the problem is people that in more than 30 years is incapable of fixing a broken lib design, the original Unix designers fixed the "problem" *long* ago.
Best wishes
uriel
What an idiot (Score:1, Interesting)
No end users for Unix based systems? What an idiot.
First off I have programmed on systems ranging from IBM mainframes through the minis and into the PC"s and unix workstations. Every unix workstation I've seen since about 1985 or so has had end users. Who does Joel think is sitting between the chair and the keyboard anyways.
Most IBM mainframes have end users - at least the tellers in the bank do look like end users to me. All the mini's I ever saw had end users too. So what is this guy flapping his lips about.
As for error messages? M$ stripped the error codes out of the stacks in NT4.0. I saw exactly the same text comming out of OS/2 and on many occations and had to go to my OS/2 machine and call up the error in order to find out what was wrong. NT4.0 was zero help. This is one reason I've abandonded NT.
Not only this - I've found that I could not copy files over the net with NT networked into OS/2. The files failed to arrive 100% of the time with a network copy. FTP did work. NT never provided a single error message. So this fact alone provides proof that Joel does not know what he is talking about.
A test many can try is this. Take a windows 95 machine and an external SCSI hard drive. Do say a dir/s so it will search the disk. While it is doing this, turn off the drive.
You'll find that winders does not provide any message at all that the operation failed. It is very clear that M$ is quite content to put bad data into the end users files or to throw away the data completely rather than deal intelligently with a problem. This is NOT the case with UNIX.
So IMHO Joel has no credibility at all. I think if one checks back to what he did while at microsoft we'll find that integrating the Visual Basic scripting languge into word is one of his accomplishments.
To do something like this is STOOPID from a security standpoint. There is far too much power in the BV system. A word document from a black hat source can ruin your system. Did anyone ask the question why a word processor should be able to run any old code from any old source?
End Users Are Not Morons! (Score:2, Interesting)
There are also other people who, while scoring low on logical intelligence, score extremely high on social intelligence, kinetic intelligence, musical intelligence, etc. These people are just as talented as any UNIX programmer, only in another domain.
Are all these people, regardless of their intelligence in whatever domain, unworthy of being offered a computer experience that is straightforward and consistent? Must the whole world become programmers at a professional level? Because that's the underlying message of a lot of the RTFM crowd.
There's a reason so many creative people gravitate toward the Macintosh, with its (theoretically, at least) "every program works like every other program" paradigm. They simply have other things to do with their lives than read "man" pages on building drivers, thousand-page tomes on UNIX programming, and memorizing 15 different and sometime contradictory GUIs and keyboard command sets.
The next time you are being given an injection by a nurse, enjoying a dance performance, or benefiting from the skills of an office peacemaker, remember that they are also computer users. If that nurse spent all of her time programming the myriad instruments she uses to monitor your health, she probably wouldn't have time to actually ... well, monitor your health -- probably wouldn't even pay attention to all the nonverbal (and non-instrument) cues that tell her how you are doing.
It takes all kinds of people to make a world. We all need each other. Non-programmers need programmers to give us these potentially marvelous tools. Programmers need other programmers to create tools that are useful for programmers. And someone must intervene between the programmer and the "end user" to ensure that these tools are actually useful to a general population. (Hence the Macintosh, as Joel pointed out.) And you, Mr. Programmer Guru, need nurses and dancers and musicians and cooks and, well, friends and family who's skills are in being your friend and your family. It's not a question of which culture is superior. It's more: how can the best of all cultures mesh?
Re:Various slashes, a history lesson (Score:3, Interesting)
Reminds me of the the famous story about the origins of the US railroad gauge:
Re:Various slashes, a history lesson (Score:2, Interesting)
Given that so many things end up with non-relative paths, I find device roots to be rather annoying. A program shouldn't care if "\Program Files\FooBarBaz" is on C: today and D: tomorrow, or that "\Program Files\Foo" is on C: and "\Program Files\Bar" is on D:, or F: for that matter.
Real symlinks would go a long way here, but only as a kludge. They'd allow you to simulate a single-rooted file hierarchy inside of a multi-rooted hierarchy. Fundamentally programs should not care where their physical storage is, only where it is in the namespace. Exposing the physical devices in the namespace requires programs to take note of it, and makes it harder for you to upgrade or change configurations later.
--Joeplus ca change, plus ca meme chose (Score:4, Interesting)
I'm surprised Joel didn't take on some other major differences:
I'd like to lock the Joel and Eric in a room and see what becomes of it...