[ Home page | Things which suck ]
A year or so ago I wrote an email to a friend in which I described my experiences trying to install some recalcitrant piece of Linux software. I can't now remember what I was trying to do, but I can remember that I wasn't successful. I closed with the words
I give up. I'm going to buy an Apple Macintosh and live under a rock.
Searching through my past email, I see that I expressed a similar sentiment on a number of occasions during 2002. I liked the turn of phrase and I'm not a terribly original person anyway, but the moral is that, somewhere, deep down, I had absorbed the idea that Apple Macs Just Work in a way that Linux machines often don't.
From time to time I had occasion to actually look at Apple Macs, if not to use them very much, and I was, broadly, impressed. There were obvious little problems -- the machines have only one third as many mouse buttons as they need, and they sport strange glowing Apple logos and so forth -- but, I thought, little that ingenuity and, if necessary, gaffer tape, couldn't fix. And from time to time, Linux continued to irritate me -- mostly when I found that I wanted to use some piece of software, and was left tangled up in dependencies trying to establish whether I actually needed to compile GNOME just to play a video clip or perform whatever other basically futile task I yearned to complete. Equally, I seemed to have acquired a great pile of PCs in varying condition, and it would be nice to be able to get rid of some of them. The Mac, so the theory runs, is an appliance: plug it in and it works. Plug other things into it, and they work. It's the future of computing, 1984-style, and it would enable me to discard much of a pile of obsolete PCs.
So, I bought an iBook: a quick, elegant machine which would replace my desktop PC and yet one which I could take anywhere I want. The machine would be a triumph of industrial design which would make me the envy of friends, enemies and colleagues. Should I ever need to use it on a train or aeroplane it would put mere PC-users to shame. And Mac OS X -- being, after all, UNIX underneath -- would permit me to run the software I already use, while also supporting all those video players, graphics programs, word processors and so forth which rarely function under Linux.
The iBook is certainly a nicely designed machine. Unlike typical PC laptops, which are stuffed with fans, sound like hovercraft and with a bit of extra ducting could probably be made to skate around the desk, the iBook is quiet and unlikely to be useful as a space heater. Its exterior is smooth, with no protruding parts to break off. A comparable PC laptop has bumps and crevices to put the surface of the Death Star to shame. And the iBook was cheap -- 600 quid if you get it on Wednesday from Apple's on-line `refurbished' shop. (Naturally, I wasn't told what went wrong with my machine which required it to be shipped back to Apple and resold. I shouldn't be surprised if I eventually find out, though.) The screen is very nice -- even if it does have a glowing Apple logo on the back, wasting photons from my backlight. The lid closes with a sensible metal catch. The power adapter connects to the machine with a little plug which lights up green when you plug it in -- I cannot imagine why, but it's kind-of pretty.
The system itself is an odd mix of the childish and the sophisticated. When you switch on the machine for the first time, you are prompted to insert three Mac OS software CDs. Rather than asking for ``CD number one'', the installer displays a picture of the CD and invites you to match the hieroglyph on the CD to the one it displays. Cute? Or patronising? Well, it doesn't matter. You only have to do it once, and it gave me a moment's amusement. Once installed, you get to run a terminal and find yourself in actual UNIX, which is very cool. One huge download later -- for some reason Apple don't ship the Developer Tools CD with iBooks, which must save them several whole pence per machine -- and the thing runs GCC, CVS and so forth. Another download and you have `fink', a distribution of Free software for the Mac based on apt, the Debian packaging tool. More downloads net a `rootless' X11 server which works pretty well: xterms, gimp windows and so forth mix indiscriminately with the `real' Mac OS (``Aqua'') windows.
Things look good. The machine works, runs UNIX, has UNIX software. Networking works, though it's at about this point that I discover that ``AirPort Ready'' means ``Does not have an AirPort [802.11] card''. No matter, my flat is too small to need wireless networking. Plugging my camera into it immediately makes a little icon appear on the Desktop, and a filesystem under /Volumes. Sure, the filesystem is laid out a little crazily, but that's nothing a few symbolic links won't fix. Apple's photo album software, iPhoto, which launches when you plug in a camera, can even be told to fuck right off forever with a single mouse click -- for all I know, it's a lovely piece of software, but what I have already works just fine.
On the down side, the machine is s-l-o-w. Just starting Internet Explorer takes a while and makes the disk thrash. Running several programs at once seems out of the question unless you have no ambition to switch between them. Putting another quarter of a gigabyte of memory in helps, but the machine still feels sluggish typing at the shell. Alistair's computer game, which does a good forty frames per second on my 800MHz AMD PC, does only about twenty on the Mac, but it is written in Java, so that may just be the fault of a crummy JVM.
(Just to get it in perspective, a 700MHz PowerPC chip probably performs in an hour more calculations than were done by the entire human race in all recorded history before the twentieth century. And still I have to wait a substantial fraction of a second after typing ``cd /tmp'' before the prompt reappears. This is a surprise and no mistake.)
Macs ship with an `HFS+' filesystem. Unlike a UNIX filesystem, HFS+ is case-insensitive (but case-preserving). It's possible to run Mac OS X on the case-sensitive UFS filesystem, but there's no conversion tool -- you have to back up, reformat and reinstall. How much of a problem could this be? Not much, probably, but I was surprised that I actually encountered it in actual use:
$ vi foo.c $ cc foo.c ... many errors ... ... reads documentation -- ah, these are C++ libraries ... $ mv foo.c foo.C mv: `foo.c' and `foo.C' are the same file
Oops. This isn't exactly earth-shattering, but it's not as if I needed to be reminded that I'm Not In Kansas Any More. Actual Mac applications are a little strange: traditionally they lived in single files with `resource' and `data' forks, but under OS X these are expressed as directories full of files, just like on the Acorn Archimedes. So to run, say, Mozilla, you need to type
$ /Applications/Mozilla.app/contents/Mac\ OS/Mozilla
which is a bit of a mouthful. (Obviously fiddling with $PATH will fix that, if you feel so inclined.) Even more amazingly, you can't just pass it a command-line parameter telling it which URL to open. I think there's a special tool to do that, but it's all a bit demented.
Mac OS's windowing system is radically different to typical X11 and Microsoft Windows configurations. Famously, the menu-bar goes at the top of the screen -- a sensible innovation which makes it much easier to hit with the mouse. Switching between the windows of different applications is semantically different from switching between the windows of the same application, since the menu bar must change to reflect the new program. In older versions of Mac OS, the windows of different applications couldn't be interleaved, but happily this limitation has been removed. Other strange foibles remain: clicking on a window brings it to the front, but doesn't propagate the click to the window. So you can't, for instance, bring a window to the front and simultaneously push a button or focus a text field in it; either operation requires two clicks. I've no doubt that Apple's usability labs could produce a great pile of results to explain to me why this is a Right and Good and Proper way to do things, but I find it pretty disconcerting.
More serious, Mac OS is click-to-focus only. There is no way to configure the window manager to focus a window simply by pointing the mouse at it. This is a big problem. Point-to-focus is incredibly useful, especially on a laptop where screen space is at a premium, since you don't need to have to manually bring windows to the front to type into them or to select text from them, so that you can effectively use windows only small parts of which are visible. More important still, it's what I'm used to. (Again, Apple's usability people will no doubt explain how tests show that point-to-focus is terrible and unintuitive and hard to learn and inefficient and any number of other unhealthy things. This is quite beside the point. I find it very difficult to work without it and since I use other machines which do use point-to-focus, it's very annoying to have to change behaviour when moving from one computer to another.)
Opinion seems to be divided over whether point-to-focus can be implemented in Mac OS X.
There's a product which has a go at it -- CodeTek Virtual Desktop, which, as the name suggests, also provides virtual desktops and does so pretty well -- but its point-to-focus mode works by bringing windows to the front whenever you move the mouse over them. This is incredibly aggravating and probably erases all the efficiency advantage of having point-to-focus in the first place. In particular, since the menu bar is at the top of the screen (or, perhaps, a different screen: more on that later), you often have to move across other windows -- perhaps owned by different applications -- to use the menu. When another window gets moved to the front, you wind up using the menu for that window, not the one you wanted. So to use the CodeTek product you have to leave clear paths of desktop between the windows you use and the top of the screen in order to be able to use the menus. (There is a timer option which will only promote a window after the mouse cursor has been inside it for a certain amount of time, but that's a pretty kludgy solution and one which still demands considerable care.) In any case the CodeTek product is quite useless for my purposes because it's unable to interact with X11 windows for reasons which aren't explained. (I'll leave aside the issue that you're expected to pay another $30 for the CodeTek thing, while other windowing systems supply all its features for free. You don't even get the source code for your cash.)
The issue here is that point-to-focus isn't built in to Mac OS X. You have to write a bit of code which will emulate it. That doesn't sound too hard, right?
Wrong. Mac OS X is a complicated beast, with a collection of different, overlapping and poorly-documented APIs which would put Microsoft to shame. Apart from the underlying BSD UNIX and Mach microkernel, which probably aren't used much by real GUI applications, you have a choice of writing graphical programs linked either against `Carbon', a C API designed to make it easy to port code from older versions of Mac OS, or against `Cocoa', which can be used only with Java, or -- get this! -- Objective-C. This is the old NextSTEP API, brought back from the dead for some reason I'm at a slight loss to understand. (In fairness, Objective-C is apparently quite an easy and productive language to use; I can only assume that it's been paired with Java as a sort of sick joke.) These two APIs apparently produce subtly different results on screen, just like 16-bit Microsoft Windows programs did on Win32. (Remember 16-bit Windows?)
Sitting above -- or below, depending on how you hold the diagram -- Cocoa and Carbon is a thing called Quartz, which is the underlying windowing system and graphics engine used by the Mac. This is apparently PDF-based, which doesn't seem to have any significant impact on the everyday UNIX refugee other than in the form of Preview.app, a PDF-viewing program which is faster than Acrobat Reader but very reluctant to talk to printers. (The difficulty of printing is a whole separate rant which I haven't the energy to go in to now.) Quartz implements Aqua, the present Apple `look-and-feel' (naturally, as we speak, Apple are trying to defend it with lawsuits and threats of lawsuits). Aqua has window transparency, strange distorting effects when you minimise windows and all sorts of other visual tat which is apparently implemented using the 3D hardware in the graphics processor. Frankly I don't very much care how it's implemented, but it's pretty obviously contributing to the machine's less-than stunning performance. I can't really imagine to whom this stuff is supposed to appeal, other than perhaps the Enlightenment crowd, but I shouldn't have thought that Apple really need their business anyway. Anyway, the upshot of this is that you have at least three places in which to attack the point-to-focus problem: in a Carbon program, in a Cocoa program, or in a program which talks to Quartz itself though the `CoreGraphics' API. (For a system so full of pictures there are certainly a lot of names to learn....)
In fact a little research -- dragged out to a lot of frustrating web surfing by Apple's rather sparse documentation -- reveals that only the third of these offers any hope at all. Although the general setup looks somewhat promising -- the front window need not be the same as the `active' or `key' window which receives keystrokes, and although it doesn't seem to be possible to hook into a global event loop like in Win32, you can poll the position of the mouse reasonably sensibly -- the simple steps you'd need to implement a proper point-to-focus utility can't be achieved using the high level graphics APIs. In particular, it's apparently impossible to manipulate or even find out about the windows of other applications through Cocoa or Carbon. The only way to do it is through CoreGraphics.
Or, rather, through undocumented features of CoreGraphics. There's a useful-sounding function called CGSGetWindowList which probably does exactly what's needed, but it's not part of the official API and no header ships with the system. Although somebody's reverse-engineered it, there's obviously no documentation and the API isn't exactly trivial (for a start, there seem to be at least three ways to identify a window -- window numbers, window IDs, Objective-C objects, ...). This is the approach the CodeTek people use and it seems a bit of a waste of effort to go delving about inside the internals of Mac OS just to see whether they were correct when the say that it's impossible to do point-to-focus without raising the focused window. Quite apart from that, CoreGraphics is an Objective-C API and I can't really see myself learning a new programming language, two new APIs, an integrated development environment and the internals of a whole new operating system just to implement something which can be turned on in one line in fvwm2.
I could, of course, turn off point-to-focus in fvwm2 and make my Linux machines more like my Mac, but that would be quite counterproductive. While I admire the concept of making everything equally inefficient everywhere, actually trying to realise it seems to be going a bit too far. There is of course some possibility that Apple will realise their mistake and implement point-to-focus in a forthcoming version of Mac OS X (the next one is apparently to be released in June) but Apple actually charge for updates to their software! How 1980s. And we're not talking trivial amounts of money-- on a previous occasion, users were apparently expected to shell out $120 or so for the bug fixes. Extraordinary.
One thing which works extremely well is multiple-monitor support. Oddly, this is something which Apple don't want you to use on the iBook -- they switch it off with a firmware configuration option which the graphics driver interrogates to find out whether it's supposed to hobble itself. Pleasingly, Apple now use an open firmware architecture rather like SUN's, and a nice German bloke has posted helpful instructions on how to fix this problem. Aside from Apple's rather shabby attempts at price-discrimination, this is one of the best features of the machine. You can plug a monitor in, click a button and move windows between screens. Unplug the monitor and all your windows appear on the LCD panel. Plug it back in and the ones which were on the CRT move back there. It really does Just Work, and it's clearly been thought through very well.
(Once the `System Preferences' program crashed, leaving everything badly adrift, but the problem didn't recur. Naturally this happened when I was demonstrating the feature: ``This is great-- I can plug the monitor back in, and the windows move back to where they were. It doesn't even crash....'' When an application does crash, the system pops up a message box telling you about it, with a little paragraph about how `the system and other applications have not been affected'. Obviously this is designed to impress old-time Mac OS users whose machines would go tits-up at the slightest provocation, but I find this sort of thing a bit patronising. Well, sure, they haven't been affected -- so can I have their damn windows back now?)
Two monitors went a little way to compensate for the absence of point-to-focus, since I could use X11 on one screen and the Mac applications on the other, but the menu bar problem remained. For some reason it doesn't seem to be possible to have the menu bar duplicated on both screens, which seems a bit of a deficiency, but there we go.
Traditionally, laptops have had lousy keyboards. This one is no exception. It's better than many I've used, but I'm probably too heavy a typist to find it really comfortable, and after pressing a key it can feel as if I'm going to pull off adjacent keycaps when I lift my finger. I don't really know whether that's possible -- certainly, all the keycaps have remained affixed -- but the feeling is disconcerting. Author Charlie Stross apparently gets through iBook keyboards at a rate of three a year, and although I don't write anything like as much as him, it's obvious that I oughtn't to pound on the keyboard too much. So, when the machine's on my desk I want to use my trusty IBM Model M keyboard (as used by neanderthal man to club woolly mammoths to death in between hammering out COBOL programs). One life-sapping shopping expedition later I have a little PS/2-to-USB adapter which will connect my keyboard and mouse (yay! three buttons!) to the iBook. Naturally, this works the instant I plug it in, which is nice.
Of course, the IBM keyboard has rather different layout to the iBook's. Apple persist in believing that @ belongs above 2 and that \ lives next to Enter. This turns out to be easy to solve. Apple, being a fully buzzword-compliant twenty-first century corporation, have defined an XML-based standard for writing keyboard mapping files, just like xmodmap but with more < >. All you need to do is write a complicated XML document to map the keys the way you want them. This is largely a matter of trial-and-error, but since all the modifications are simply swapping symbols, it's not very hard. Apart from the propensity of the Input menu to display `Arabic' as an option, rather than my `British - Model M', this works fine.
Unfortunately, this only allows me to remap the actual character keys, not the shift and modifier keys. This is a more serious problem.
Apple keyboards have a `Command' key with a clover leaf and a picture of an apple on it, which is a special shift key used to indicate keyboard shortcuts. So, for instance, the keys for copy and paste are [Command]-C and [Command]-V in Mac OS. (Apple sued Microsoft when they started using ^C and ^V in Windows.) Of course, the IBM keyboard doesn't have this key, so that means I have to find some other key for the purpose. It's assumed that you'll use the `Windows' key that's available on modern keyboards, but of course the Model M predates that by a good few years. The IBM keyboard has lots of keys which aren't used in Mac OS, such as Alt Gr and Print Screen, and others which are redundant, like Caps Lock, but there's no convenient way to remap them. Even worse, the Scroll Lock key which is used to operate my keyboard-video-mouse switch is interpreted as `dim screen', so that after switching between machines a few times, the iBook's screen goes blank. This confused me utterly the first time it happened, and I took a while to realise that I could press Print Screen (!) to brighten the thing up again....
Again, there is software to solve this problem.
Sort of.
In the top-left corner of the iBook's keyboard is a little button which ejects a CD. In older iBooks, the slightest touch of this button would cause the CD to come popping out, which was, I gather, extremely aggravating. So Apple fixed the problem, by requiring the button to be held down for a second or so before the CD ejected. But before that, there was a software fix, called iJect, which worked by modifying the kernel to suppress the eject-CD key event. This sounds like a good idea which could easily be adapted to my problem, and, after the point-to-focus muddle, it seems commendably UNIX-like. The iJect people even release their code under the GPL, rather than demanding $30 for a binary.
Unfortunately, looking at the code dispelled any confidence I'd accumulated up to this point. Although the Darwin kernel upon which Mac OS is based is open-source, it's not really recommended that you recompile it yourself on an actual Mac. (Some people do run Darwin without Quartz and so forth, in which case I suppose it behaves pretty much like bog-standard BSD.) So the iJect thing and other code derived from it work by substituting code into the running kernel.
And as if that weren't bad enough, the `IOKit' layer of which the keyboard driver is part is a C++ API. So replacing the running code means that you have to somehow insert a new, derived object into an existing -- running -- C++ bit of a UNIX kernel. This, of course, means that it's extremely important to get the vtbl layout of the derived object which does the key remapping exactly the same as that of the original class. If you don't, bad unpredictable undefined things will happen, right inside your machine's kernel! This obviously makes the code pretty fragile.
I didn't get around to modifying iJect (or, rather, one of its more modern derivatives) to do what I wanted, but I'm confident that with a little work it could be done.
At about this point in the narrative I found myself reflecting on my purchase. Approximately 3500 words ago I explained that I bought an iBook because I expected it to Just Work. Which it did, just fine, until I came to actually try to use it. At that point, I discovered that there are serious incompatibilities between how I want to use the machine, and how I'm expected to use it. Nor are these problems ones which can be fixed by reconfiguring Mac OS X, although there's no good technical reason they shouldn't be. Anyone with sense bemoans the mess of X11 window managers, `desktop environments', `themes' and other kinds of preadolescent graphical dribblings which adorn typical Linux distributions, but just see what happens when you can't select the bare minimum of features you need to be able to work effectively.
Allowing myself to drop into the rôle of Passionate Mac Advocate for a moment, I'd point out that
Neither argument should detain the attention of a thinking person for any length of time. If usability testing shows that endless test subjects found click-twice-to-focus easier to use, good for them. I don't. And, as I said above, I wanted to buy an appliance. It has to Just Work, and that means that it has to Just Work in a way that I find convenient. No dice on either count for Mac OS X here.
With my Senseless Mac OS X Bigot hat on, I'd point out that
... it isn't, and you can't, not unless you're prepared to go to herculean and basically pointless effort. A lot of the Mac OS X advocacy on the web seems to come from people who don't actually use it....
I'd forgotten how dispiriting proprietary software is. I used to use Microsoft Windows, and wrote a number of little programs to make it work more efficiently for me. A thankless and basically pointless task, especially when you have to go digging through reams of documentation just to find out whether something is possible at all. Mac OS, for all its `BSD heritage', is no better.
Which is sad. Because, after all, the machine is very nicely designed, and anyway I'd spent a bunch of money on it.
So, what is it that we do with recalcitrant laptop computers? We install a 1990s knockoff of a 1970s operating system designed to run computer games on 1960s mainframes, and struggle to make it work.
When I first got the Mac -- before I'd found out any of the above -- I mentioned to Mark that, if it didn't seem to work, I could ``just run Linux on it.'' Presciently, he replied that this ``sounded like a world of pain.''
Linux has run on PPC for a while. A web search reveals that lots of people have Linux successfully running on the iBook and other modern Macs, and this seemed like a sensible way out of my troubles. There's even a product called Mac-On-Linux, a sort of PPC analogue of VMWare which will allow me to run Mac software under Linux. Yay! QuickTime!
A number of Linux distributions have PowerPC ports. The big ones are Suse, Gentoo, Debian and Yellow Dog. Suse, Gentoo and Debian are the same ones we know and loathe from other environments; Yellow Dog is, basically, a port of Red Hat, which is not available in a PPC build. Technically, Debian seems to be the best to go for, but I've never been a great fan of Debian's package system or its politics, and in any case my Other Computers run Red Hat and, as you will recall, the whole purpose of this exercise was to make my life simpler. The last thing I need is yet another Linux packaging tool. So, Yellow Dog it is.
I'm guessing that there's a statutory requirement that Linux installation tools are atrocious -- I can't think of another explanation for their uniform awfulness -- but Yellow Dog's really takes the biscuit. You get the choice of a `graphical' or a `text' install; the former, which is the default, displays a tiny dialog box with tiny fonts in the middle of the screen, which is flickering crazily, apparently because they use an out-of-date framebuffer driver. Editing partitions crashes the installer with a Python stack trace.
The text-mode installer is much like Red Hat's, which is an improvement, but a few minutes into installation the screen backlight switches off and Yellow Dog apparently forgot to include any way of switching it back on. They even document the problem, or something like it:
During long installs, your screen may `blank out', or even display illegible video. If this occurs, do not panic, the X screensaver is active.
-- but they don't describe how to fix it. In this case, the Mac did not Just Work.
The solution? I used a desk lamp. I was hoping that I would actually get some value-for-money out of the silly window in the back of the screen, so I tried shining a halogen lamp through it to replace the backlight. Unfortunately Yellow Dog do not arrange their menus to fit inside the vaguely apple-shaped splodge of light this cast on the screen, so I was forced to illuminate it by reflection, just like with laptops from 1990. Peering closely enough at the LCD enabled me to determine which buttons to select in order to complete the installation, and, happily, the screen switched back on when installation completed and the machine rebooted.
(I should note at this point that I was installing the 2.3 version of Yellow Dog Linux. I'm not really sure which version of Red Hat that corresponds to, but I see that Yellow Dog have released a 3.0 version of their distribution, which presumably has more modern software in it. But -- get this -- you cannot download Yellow Dog Linux version 3.0, or, at least, you can't unless you pay them a big heap of money. (They release it to us ordinary mortals on 28th April.) Obviously this is strictly OK GPL-wise, since they only have to release the source to people who've got binaries, but it's pretty annoying. And their web site doesn't really seem to tell me enough to determine whether it's likely to solve my problem or not.)
On boot, the machine worked fine, but X didn't. This probably won't surprise anybody who's ever used Linux. Also, the framebuffer was all messed up (the Mac presumably doesn't have a text video mode). Naturally the first thing I tried was to recompile the kernel, which fixed some things and broke others. A good couple of evenings' hacking -- why is this so difficult? -- yielded a sort-of-working X11 install, but this entailed, among other things,
On the bright side, when I plugged in my Model M keyboard and three-button mouse through the KVM switch and PS/2-to-USB converter, they did Just Work. I have no idea how this happened, and that makes me suspicious.
This serves to illustrate something odd about Linux. On most systems, you debug things when they don't work. On Linux, you have to debug things which do work, so that you can find out what happened and determine whether that's something which you want, or something which will break horribly next time you plug anything in.
I haven't had time to figure out the USB keyboard thing. I'm sure it will turn out to be harmless. Instead, I tried to make the machine work with two screens, just like it did under Mac OS.
This doesn't sound too hard, right? XFree86 supports a thing called the XINERAMA extension, the Radeon card in the iBook plainly supports two screens, and there's good support for the Radeon card in XFree86.
Nevertheless, I was not able to make this work. I could get a corrupted display on an external monitor and a real display on the LCD, or I could get crap on both screens, but I couldn't make the external monitor work in a real graphics mode. The base Linux kernel doesn't actually support AGP on PowerPC hardware, which is why I needed the forked version, but in addition to that there seem to be separate modified versions of the kernel DRI modules and XFree86 graphics drivers which are needed to make the Radeon really work well under Linux for PowerPC. I'm not really prepared to pick apart the Debian package which seems to be the sole source of this code to install it on my machine -- that seems like a foolish thing to do if I want to stay sane. I could compile my own version of XFree86, but that also doesn't resemble something I'd ever really want to do. And, oh, did I mention? -- it's not exactly a fast machine to start with. I'll reevaluate my options after April 28th when I've seen whether Yellow Dog manage to sort this bollocks out.
So I can't yet report on whether I've managed to make my Mac do good Mac stuff like displaying on two monitors. It seems to behave like Linux, and run the software I want. I've got it to the stage where I can run fvwm2 (not, by the way, included in the Yellow Dog distribution) and read my email, and I think it will do everything I want it to.
I've even managed, mostly, to remain calm through the whole procedure.
So far.
The conclusions?
And, no, my life is no simpler. Instead, I'm £600 poorer, and I'd have been better off spending my time with the six-foot stack of unread books on my floor. Thank you, Apple, for wasting my evenings. I hope you find my money useful, since you won't be getting any more of it. Unless I need an 802.11 card, of course.
Neither of these is quite addressing what I say above, but Eco's essay is a lovely analogy and Stephenson's advocacy is better written than most. There are a few other pieces on `Mac OS X for UNIX users', but they're mostly pretty thin and you all know how to Google already.
Copyright (c) 2003 Chris Lightfoot. All rights reserved.