Slashdot Mirror
Explaining The Windows/UNIX Cultural Divide
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."
forget the programmers, until general knowledge of computers improve and stuborn idoits don't need to have things like " why do i need a password to run a program on MY OWN computer" explained the state of computer security will not improve.
If you mod me down, I will become more powerful than you can imagine....
The fact that you can't use a *nix machine the way you want isn't a reflection of the Windows/Unix divide - it's a reflection of your personal preferences, experience and background. It's not remotely cultural.
I can't make my Windows machines work in the way I like to (mix of command line and GUI), whereas I can make my iBook and my G4 work wonders because I know OS X / Unix well. That's not cultural either - it's a reflection of the fact that my computing experience has always been some distance from the Windows world.
Just because you don't like something or don't feel comfortable with it doesn't necessarily mean it's a fault with the system as a whole. It can equally easily be a "fault" with your own experience.
"This is why men never share their feelings; because women always remember." -Just Shoot Me.
Interoperation is something Microsoft fundamentally doesn't get.
Instead of interoperating with published standards, they try to interoperate with Microsoft legacy methodologies (e.g., everything must bee visual basic scriptable.) This is a terrible source of security worm-holes. I wish they would reorganize their visual basic scripting fanatics to Antarctica.
I make it a point to return any base64-encoded text/plain email to the Outlook-using idiot who sent it, explaining that Outlook is obscuring their email text, along with a list of reasons to switch to another email client and instructions for doing so.
Although I understand and agree with your basic point, I would ask that you consider the "product" of a computer and how that relates to average "consumers" need for a tool to make their lives easier/more entertained (because that is, after all, the basic reason why average consumers purchase computers).
Consumers want a tool to use, whether it be for games, email, finances, or just internet surfing. Quite frankly they don't want to spend a ton of time learning about how to use it, and many don't care how or why it works just as long as it does work.
The tug-of-war that exists is that computers by their nature are complex and flexible. Consumers by their nature are very insistant on their desires which in include simplicity, flexability, safety, cost, and utility.
Calling them "stubborn idiots" only highlights the divide of understanding between the computer literate that understand and desire ultimate flexibility, and the average consumer that just wants to use their computer, like a toaster or a vcr or a Sony playstation, without a lot of hastle.
Somehow the creators (programmers and hardware vendors) need to accomodate for that, because I assure you that the average consumer won't change.
Although I despise Microsoft's business ethics, I appreciate their dedication to the principle that I mentioned above.
Linux is in a very good position to make headways in this regard as well, but it will take a fundamental understanding by the programmers and harware teams of said principle to make real headways in the desktop market.
Anything less will ultimately limit the adoption of Linux to, for example, server, web, and corporate applications.
"The masses" are what they are, and deriding them for it won't influence them to change, however it will influence them to avoid the product.
Lets find a way to meet them where they are while preserving the fundamentals.
Is the juice worth the sqeeze?
I am not sure why people bother reading Joel Sporsky's weblog -- half of what he writes is tripe, and half is heavily biased by his ego. Someone else quoted Joel's jab at how "the Unix world is so full of self-righteous cultural superiority;" apparently he does not realize that he is an exemplar of the Windows version of the same.
If I wanted to follow his lead and oversimplify the differences between Windows and Unix programmers, I would say that Unix programmers care about code (period) and Windows programmers care about the quick buck. Mr. Sporsky's crass and half-informed self-promotion is an excellent example. (Ever notice how often he plugs his company and software while griping about software development practices?) I have seen the insides and outsides of commercial applications for both Windows and Unix, and the quality under Unix is generally higher than under Windows.
This story will be duped at some distant point in the future.
The latest Slashdot meme.
Good. Great. Bully for you.
I'll give you the benefit of the doubt that you truely limit your comments to your wants and needs. The problem is that the standardization naz^Wadvocates (oops, almost invoked Godwin's Law, sorry about that) always extend their needs as trumping everyone else's needs. This is just as much a crime when it comes from those whining that Linux needs a standard GUI (or whatever) because the unstated subtext is always "the one I am using".
My needs are different from yours -- I find that I cannot use a Windows system the way I want to, and am much more at home on a unix system. I find I cannot use a KDE inteface the way I can use a olvwm interface. With a modular system like unix, I can use the interface I want, even as other users on the same system use a completely different one, and all without causing undue problems between them.
you should read everything on the internet as if it had "but I'm probably talking out of my ass" appended to it.
I just had a Windows programmer/sysadmin type tell me that all he does is play with the program in question until he figures out how it works. He told me that help files are useless. I on the other hand live by the documentation and everything better damn well be documented or I ain't trying it.....not on my production system. I don't mean the easy stuff either. the more touchy something is, the more I want to read befor I attempt it. Man pages can and do suck, but everyone I have come across pointed me in the right direction. Windows likes to hide things even from the programmer. I don't think thats a correct way even if your writing a program focusing on the end user. If something goes wrong, how do you track it down?
The registry would not be as bad as it is if it was better documented. I know I know....if you subscribe to MSDN or some other microsoft money scheme, you can read the documentation. Well, users should have access to that if they so want.
Things like this is why OS/X does well on both fronts. You don't HAVE to look at the commandline ever if your just using it. If you want to write a little script or automate something, the command line is there if you need it. Microsoft on the other hand went so far as to say that Windows ME had no access to the DOS prompt, yet with in a minute of installing it, I had a DOS prompt.
I happen also to disagree with this guy that UNIX programmers typically write a command line program first. Some do, but I have seen others which are useless without a GUI program.
Commandline is valued because you can take different command line programs and pipe it here, append to a file there and have a script or program that does what the original writers of each module never dreamed. There's something to be said for that!
Just one tiny example where the UNIX way ends up being better for users:
The gpsd project is a project that takes the gps data collected by a serial port and makes it availble not just to apps running on the local machine, but also across a network. The advantage is that if you have programs wrote to work with gpsd, you can use MULTIPLE map programs at the same time each showing your current position. You don't have to juggle the serial port between 2-3 programs if you use one map program because of one reason and another map program for another reason. This has not even been dreamt of yet on Windows and the only way to accomplish it on Windows is using 2 GPS's each on their own serial port. To make the data available to any application that want/needs it, you just configure the daemon to look at the serial port your GPS is connected to and then other programs can get the data from the daemon instead of the serial port.
UNIX programmers program to work around limitations in the platform and are able to make the platform do what they want to do. Windows programmers will just say that it's not possible or Microsoft does not support it. UNIX programmers say: Nonsense! You are a programmer right? Then write a program or API that does what you want. Some say that this is a weakness, but I say it's a strength that makes UNIX a tool that actually makes it easy to make it do what you want. Some users don't want or need this kind of power, so they are happy with Windows. The ones that need it turn to Linux or UNIX.
Gorkman
Is this bad enough news? No.
Furthermore, until the same "benevolent dictator" FORCES ALL *nix to employ the use of focus groups, user feedback, and other methods of optimising the UI to suit the needs and wants of the AVERAGE JOE, ALL *nix will continue to suffer a host of maladies from merely looking clunky up to and including full incomprehensibility to the guy we're trying to promote this stuff to.
Apple came a gnat's whisker from pulling this double burden off, but because they run a MORE EXPENSIVE machine that is NOT COMPATABLE with the Great Shoal of Computers, they failed.
Proceed with the downmodding children, I can take the hit.
Is it fascism yet?
Three years ago I had to do something very simple with Microsoft's Crypto API. It has two layers: high and low. The high level functions did some common tasks, though totally non-customizable. So I had to use the low level ones. The documentation was vague. Only if they have published the high level functions source, me and the company I worked for would have saved a month. Or maybe I'm mentally retarded. So here is another example: IFS kit. It costs $1000, and it comes with 0/zero/none/not a single line of documentation about writing network file system drivers! Don't get me wrong - I don't like reading Microsoft code (the MSDN "examples" are just enough!) but if I had the source code of the relevant parts of the IFS kit, I would have finished that stupid task a month ago. Now, we're waiting for some preliminary documentation which is to come after 2 months. And 6 years after the first version of the kit... So, poorly documented open-source libraries may suck, but poorly-or-not-documented-at-all Microsoft libraries sick a lot more!
I agree.
That is not to say however that my home machine doesn't need security, especially as the world becomes more networked.
Password based security is the most nightmarish of security scenarios: a partial success. Successful enough for people to rely upon, successful enough to impede the adoption of better approaches, but not successful enough to provide the security and convenience people need. Some people do OK with them but they're a tiny minoritt. Upgrading humanity is not an option. Indeed I suspect that the majority of computer "experts" would fail if audited according to strict password management standards.
The problem is that passwords are an ugly hack that were adopted when the problem was less severe and the stakes were lower. They're a huge Achilles' heel.
Personally, I think a key like device like an iButton would be much better. It's intrinsically more cryptographically secure than a memorizable password, as well as practically more convenient to manage in a secure manner. In high security apps the key device could be enhanced with biometrics or even password protection, approaches that are insufficient on their own but could thwart casual, opportunistic reuse and buy time for privilege revokation if the hardware key is stolen. The very fact the hardware key must be physically taken away from its users is a huge advantage. Passwords can be "stolen" without their owners knowing.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
There are two ways to solve this - bring the functionality into the same address space as the GUI (so if it hangs, force quitting won't leave the confused backend around), or use a network-style protocol with a defined ping/pong approach, and when the backend fails to ping, kill it.
But text-based interfaces are always fragile. Just look at any of the millions of cdrecord frontends out there. They never quite work properly, because cdrecord-of-the-week always has some new diagnostic message, or error, and the program gets confused.
However, as the snippet from the original article above shows, I don't think my interpretation is entirely (if at all) incorrect. Mr. Sposky seems to me to be saying that the Unix metaphor is "less usable" to "Aunt Minnie" (pretty insulting, BTW: my Aunt Minnie was programming calcuating machines before Mr. Sposky was born, but that's another topic) due to its inherent nature.
I am observing that the Windows metaphor works great for the first 2-3 years, but then the end user runs into a brick wall where he can't do what he wants, doesn't know why, and has no tools or path at his disposal to move forward. I have seldom seen a person who grew up in the Unix (or VMS, or TOPS-20) metaphor hit that same wall and not be able to figure out a way around it. It was primarly my Unix and VMS background that allowed me to figure out how to make Microsoft LAN Manager 1.1 actually work, for example, when the Microsoft technicians were clueless (another long story).
sPh
I don't believe the grandparent post referred to their computer as being attached to a network. It has become a pernicious assumption that all computers are networked these days. I have a non-networked computer, and although it is behind locked doors, I use a password on it just for peace of mind. However, I find the recently common assumption that all computers are networked to be a real pain. Ever tried working on a program where all the documentation is html links? Not easy when you are on an isolated computer. It has become so bad that software boxes have as the computer requirements something like: Pentium 200 Mhz or better, 128MB RAM, at least 1 GB Hard Drive space, etc. but neglect to mention that Internet connectivity is required for use. Not everybody uses their computer as a websurfing device. It is still true that the most secure computer is one which is not attached to a network. You can try to tunnel into the computer I am typing this from, but I dare you to get the data on my other one!
Take cdrecord. cdrecord does the same stuff that the windows cd-rom recording libraries do: write a cd-rom. How do you feed the windows libraries data to write? I don't know. Are they self-documented? Nope. How do you feed cd-record? The most obvious way: give it an image to write via stdin:
cat image.iso | cdrecord
If I didn't know this, cdrecord --help tells me what to do. man cdrecord has a longer explanation with examples. I can get the application, usable by end users, and place it inside my backup scripts. Do this with the windows libraries or Nero or some other burning application. Tell me how long do you have to sift through documentation to do this: Find a way to backup a disk partition to a cdrom using the windows libraries. In any unix, this is something like:
cat /dev/sda1 | cdrecord
Will a end-user have trouble using command line cdrecord? Naturally. But cdrecord is a core application, which shouldn't be used by end users. That's what the Rule of Separation is about. Grab krecord or something like that, and use it.
If at first you don't succeed, skydiving is not for you
Or could you maybe give an example what that should be:
"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?"
I can give you one. The APT library (the backend to Debian's apt tools) uses a built-in download manager to fetch packages and other files. So far so good.
Now, say I'm in the middle of a long download, and I decide I changed my mind about some packages. For instance, I want to install some packages I hadn't thought of or cancel some downloads. There is no way to do this in any interface without cancelling the whole download and setting it up again, and that's because the backend library does not support this functionality. You can access the list of individual download jobs, but there's no way to cross-reference between jobs and the packages to which they refer (aside from decoding URIs to guess what the package is).
I asked the authors about this, and they said (essentially) that they didn't want to go back and make all the changes. This is probably reasonable -- it's a fairly esoteric feature and could be a pain to get working perfectly -- but it is one example of a place where the backend can limit the frontend.
I do find it amusing, though, that the author of the article just implicitly assumes that the reverse is not true: ie, that designing the frontend first will never result in arbitrary limitations for the backend.
Daniel
Hurry up and jump on the individualist bandwagon!
No, seriously? Windows GUIs suck... compared to what?
Compared to X? The same X where every single programmer just _has_ to use a different layout, different shortcuts, different menu structure, and for bonus points his own widgets? And where 90% of the GUIs were never even tested in any other resolution or font size than what the developper had? (Here's a hint: 100 DPI fonts are an X standard for a long time now.) And where every app is configured in a different way? And in some cases (e.g., IceWM), contrary to common sense, the changes you do through the menus aren't even saved, and you have to launch a different application to configure your start menu?
Sorry, from the end user point of view, it's the Unix GUIs that suck big time. They suck like an industrial vacuum cleaner. They suck like an expensive hooker.
They're made by geeks, for geeks. And religiously defended by hordes of flaming trolls, ready to insult everyone who dares doubt their idol's wisdom.
What a non-geek user expects is to learn some skills once, and apply those skills again and again. It doesn't matter if you have some cute unique idea. He just doesn't want to have to learn a whole new set of skills for every single program.
He wants that if in Word CTRL+X is "cut", then in every single program it's still "cut". He wants that if F1 is "Help", then by God, it better be "Help" in all programs. And if one program's scrollbars behave in one particular way, then it better be the same way in all programs.
For you discovering how yet another widget set works might count as fun. For Joe Average, it counts as a waste of his time. He'd rather do something else in that time. Like be done sending that e-mail, grab a beer and watch TV, instead of still being at discovering how it works.
And yes, the Windows developpers know that it pays to care about the paying customer. That means, yes, caring about Joe Average who's using those programs. Thinking how you can help Joe Average do what _he_ wants, instead of making it all an exercise in programming for your own ego.
And until more of the Linux crowd discovers the same thing, I just can't see Linux making it big on the desktop. Sorry.
A polar bear is a cartesian bear after a coordinate transform.
I have extensive experience "programming Windows" and programming "UNIX" [ I live and work "without prejudice"], so I've moved between and am comfortable in both "cultures". Interestingly enough, I find that the cultural divide is much more pronounced now than 20 years ago (20 years ago, did anyone program exclusively for Windows? -- the platform was a joke...). I think that because the Windows SDK is controlled by Microsoft, it's more difficult to do really insightful programming for that platform. So much Unix and Linux stuff is "open", that programmers involved in that culture are exposed to more "inner workings", etc... Where programmers have ONLY used Microsoft's Visual Studio and have ONLY produced end-user, non-programmer apps, their skills I feel are limited. UNIX programmers can certainly produce apps for non-programmers (Open Office, Gimp, KDE etc...), but I think that "Windows Cultured" programmers cannot as easily develop "programmer's tools". I don't think it has as much to do with "culture" as much as "depth and varity of knowledge."
Y'know, people keep saying that this is such a trivial little matter of implementation, but I can't help but observe that 20 years after the Macintosh came out, cut and paste in X windows is still completely fucking broken.
At some point, you have to abandon the excuses and admit that it's not just an implementation problem, it's a broken paradigm.
DEVELOPER: "Here's our GUI! Enjoy!"
USER: "Wow, thanks! This sure is pretty. So, how do I cut and paste?"
DEVELOPER: "Well, that depends on which toolkit the app you're running uses."
USER: "Uh, OK. Thanks." [user turns off computer, goes back to his Windows or OS X machine.]
In the above scenario, the user is right, and the developer is wrong, wrong, wrong, wrong, wrong.
But I haven't seen a lot of people pointing out that esr is also taking it too easy on the Unix culture.
I started reading the draft of esr's "Art" a while back, and was immediately struck that he was repeating the "do one thing and do it well" slogan as if anyone ever really worked that way. Has he ever seen the man page for "tar"? How about "find"? The Unix Way is more like "do one thing sort-of-okay, and then trick it out with options and modifiers and run command files and embedded scripting languages until you can't tell when it's going to fry eggs or flush the toliet."
You might want to balance out esr's idealized view with the half-serious ranting of The Unix-Hater's Handbook (pdf).
I think the chapter on X is one of the better X-windows tutorials around (though unreasonable people may disagree).
"Unix" doesn't have a choice in the matter - it's purely an end user decision.
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.
Or you need a typically inexperienced and ignorant end user running as root for convenience.
Not every unix box is managed by a sysadmin (and the proportion that are is only going to get smaller).
Added to that, with the typical scenario of a single-user desktop machine that spreads these "email viruses", it doesn't *have* to infect the entire machine to have a negative impact and propogate.
The "well at least under a properly configured unix box a virus can only wipe out the user's files" argument is irresponsible and specious when applied to a typical PC configuration.
NT and it's ilk are also POSIX complient, meaning they strive to be unix-like.
No, they implement a POSIX layer for compatibility and to help software migration. If you think NT is striving to be "unix like" you're sadly mistaken.
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.
The registry (in NT) is subject to ACLs. It isn't world writable by arbitrary users any more than /etc is.
Show me a Windows setup that operates without the GUI, without Visual Basic, and without the registry. Then talk to me about security.
But for some reason a unix box with X, perl (or sh) and /etc can be secure ?