Early years

The first computer we had at home when I was growing up was a Macintosh Classic II. I have fond memories of that machine. Its use mostly involved word processing and educational games like Math Blaster and Number Maze.

Then we got a huge PC tower capable of a whopping 33MHz (if you pressed the Turbo button - we never turned off Turbo except to briefly marvel at how slow the 8MHz mode was). We could actually play games that other people played! Granted, they were DOS shareware games, most stopping after a few levels, but we knew those levels well.

At this point, "Windows" was some shiny thing that you ran not by turning on the PC and logging in, but by typing "win" into the DOS prompt. We mostly ran our games from DOS at that time (we got really good at typing cd games, although I didn't quite understand directory structures yet).

The computer lab

Years later, my middle school got a bunch of iMacs for the computer lab (I know, I know, why call it a "computer" lab if they didn't put any actual computers in it). I hated those things. They seemed so limited compared to the PCs I was used to at that point, and they crashed all the time, to the point that it was difficult to actually get anything done. I think Windows 2000 was coming out at about that time, and that's one OS that will certainly spoil you.

Needless to say, this experience soured me on Macs.

Unix

I took a Unix course at the local junior college while in high school. I remember enjoying it, and I remember getting an A in the class, but I don't remember anything it taught me about how to use Unix. This is not surprising, because after the class finished I didn't use Unix at all for about ten years. I didn't have a Unix machine, and I didn't know anyone with one. No practice, no retention. However, I didn't forget what the environment felt like: whatever odd task you wanted to do, there was always an elegant way to do it, piping your original content from one utility to another until you magically arrived at the exact desired result. I assumed that since this worked so well on the artificial assignments we were given, it would work on whatever I might throw at it, if I ever threw anything at it.

Apple today

My recent experiences with the Apple environment have been, understandably, focused on iOS. It seems like everyone wants an iPhone - after all, nobody makes rectangles like Apple does. They invented that shape, and they hold the patent to prove it! For larger devices, the iPad reigns. Again, Apple users value the creativity, originality, and innovation that goes into copying something that Microsoft released years earlier (the Tablet PC), and Star Trek: The Next Generation designed years before that (the PADD).

And what developer doesn't like paying a hundred bucks to be on the Apple Store, even if all they want to do is poke around in the environment? Not to mention the fun of learning a language that won't be useful for anything else (Objective-C) and the excitement of needing to buy a Mac if you want to compile your program. All those dozens of languages and ecosystems with no licensing fees and permissive hardware requirements are for peasants who can't afford black turtlenecks.

Anyway, sarcasm aside, what I don't like about using Apple stuff these days is that you're locked in to what they want you to do. If you're toeing the line, you'll have an easy time (assuming you're reasonably familiar with the Apple environment). But if you want to do something that the folks at Apple had in mind only as "I guess we should include that option, if someone REALLY wants it," prepare to battle your way through a maze of menus and options that seem to take a sort of malicious glee in leading you astray. The supposed intuitive interface and "it just works" style evaporates instantly. Have you seen someone try to configure their iPhone to grab email from their POP3 server and sync it with their spouse's iPhone? It's not pretty.

Returning to Linux

I have lately had reason to do things in Unix again (Linux, specifically). Firstly, my workplace uses Linux servers for some internal development, and our software runs on Windows and Linux, so l33t terminal haxxoring is occasionally necessary. Secondly, freezing a Python program on Linux means that Linux users can simply run the frozen package without worrying about libraries.

I ran into the same kind of problems with both scenarios: completing a given task depends on completing another task, ad absurdum.

Run this Perl script that the dev team created? Sure! Wait, it doesn't run for some reason, even though I'm following their directions to the letter. Oh, I guess you have to set those environment variables every time you log in - okay, I guess that's not too bad. Now I have to... source .cshrc? Is that a procedure I need to carry out, or the command I have to type? It's a command? Okay. source .cshrc then. Error message. Well, maybe the .cshrc is an argument? Let's look for that in my directory... Ah! There's a file with that extension, so I'll write the whole filename. Still doesn't work? Let's ask the developers. They say I have to add the commands to set those environment variables... I did that, then immediately used the source command, and nothing doing. Oh, I have to actually edit that .cshrc file in a text editor? That is good information to have. Now... how in the world do I, a Windows guy, do that? Well, I've been reading about Unix online, and there are apparently a few built-in text editors, so I'll use the basic editor vi, and... um... what now? My results look just like the old vi joke ("how do you generate a random string? put a Windows user in front of a vi terminal and tell him to quit"). Now I see where that comes from. Fortunately, I know the path to our Linux server, so I go there with Windows Explorer, open the file with Notepad++, edit it, and save it. Cool.

And now I get a workarea. What's that? After finding out from IT (and getting a workarea made for me - yeah, not mentioned in the documentation), I populate my workarea with a simple command. Simple is nice! But all it's doing is spamming the console with messages about what file is now being transferred to my work area, and it doesn't seem to be stopping. There's no progress bar (it's a terminal, of course), no percentage display, no "x of y files transferred," nothing. Eventually I ask the developer and they inform me that this little step takes about 24 hours. Again, good information to have. You'd think it would've been mentioned at some point, but Linux users must really love it when their friends ask them to help them run something with documentation that basically says "to run the program, run the program, ensuring that everything is correct" and they can use their hard-earned secret knowledge to get the thing to run. Those Linux folks sure are wizards! All I know is Windoze. If I were smart, I would be able to use Linux.

Same thing with trying to run my Python apps on Linux. All I wanted to do was run a simple Python app with a couple extra libraries on Linux. Easy, right? Python is even built into Ubuntu, right?

Excuse me while I chortle.

First, I'll want a console window so I can invoke my app with various command line switches, right? Yeah. Okay, that's probably somewhere here... uh... somewhere... maybe Google knows. Oh, Control-Shift-T for Terminal! Of course. Now, I'll just invoke my Python app, and... it failed. It didn't find tkinter? The GUI toolkit that's popular because it's included with Python? I guess it's not included with every build. Now, how to install it? I can use the standard command line installer, of course. The only problem is that, well, no I can't. There's no tkinter library in the database, and the Internet assumes that it's already installed, because what kind of Python build doesn't include tkinter?

Anyway, I found that every time I wanted to do something in Linux, there was a dependency. And that dependency counts as doing something, so it has its own dependency. I didn't want to find out how deep the rabbit hole went, so I bailed out. If someone wants to run my Python apps on Linux, I leave it to them. They knew what they were in for when they invited the penguin into their workstation.

Validation

Do you know where you can find an opinion similar to my own regarding Apple? Steve Wozniak, the guy behind Apple, had this to say:

Unfortunately, we made it very difficult for anyone to get access to the insides of the machine. We had hired some very bright people who figured, "This is the right way it should be done. So we'll give out enough information to do this and we won't give them any more, because they might try to do something they're not supposed to do." The right way for one person is not the right way for another. We closed that machine up to where somebody could have a very difficult time finding out how to add their own I/O drivers. We did not make it easy for the outside world. We thought we wanted all of the markets for ourselves.

You have to let the end users develop their own standards. You've got to give them the freedom to discover how they're going to use an operating system, what sort of things they're going to buy. And if you're really right and have provided a good solution, that's where they're going to settle. The thinking on the III was very much like a religion in that it could only be done one way - our way. We made it very difficult for outside developers, instead of providing all the information as we did with the Apple II.

[Interviewer: "Has that attitude changed now?"]

No. It's still the most negative thing in our whole company, and it will be for years.

He knows.

How about Linux? Are there any Linux fans who find that they're unable to do the simplest tasks because every task requires that you first complete another task, which may or may not be secret? As it turns out, Eric Raymond himself has had... difficulties when trying to complete the simple task of printing on a shared printer in Linux:

What a truly lovely, classic blunder this is. That they turned off the autoconfiguration support is understandable from a security-engineering point of view. But failing to mention this in the Administrator's Guide, and failing to warn the user during the configuration-wizard dialogue that operating printers may not be visible unless your site admin has performed the appropriate ritual on the printers' host machines... that is moronically thoughtless.

This kind of crap is exactly why Linux has had such trouble gaining traction among nontechnical users - and it becomes less forgivable, not more, when it's surrounded by a boatload of GUI cotton candy that adds complexity without actually delivering friendliness to the user.

...

Eventually I notice the Listen directive in the /etc/cups/cupsd.conf file. "Aha!" says I to myself, "Maybe this is like sendmail, where you have to tell it explicitly to listen on the server's IP address." I add "Listen 192.168.1.21", the latter being minx's IP address, restarts cupsd... and lo and behold my test job comes tumbling out of the printer.

...

It's been twenty years since the GNU Manifesto and nearly seven since The Cathedral and the Bazaar. I think it's time we stopped congratulating ourselves quite so much on our dedication to freedom and our ability to write technically superior code, and began more often to ask "What are we doing to serve the real users?"

Note: the "hilarious screed" Raymond mentions near the end of part 2 is a dead link, but you can put the linked address into www.archive.org and read a hefty complaint about trying to run Linux from a Live CD in order to back up a defunct machine.

If you'd like a brief summary of this wall of text, here it is:

• Apple doesn't let you do things.
• Unix lets you do things, but doesn't lift a finger to help you.
• Windows lets you do things, and it knows when to jump in to help and when to stay out of your way.

And that's why I prefer Windows.