Computers, part 2

[mdlbear]

Last week I inherited an Apple PowerBook from a recently-departed coworker. What a piece of crap! In spite of the fact that it's supposedly Unix underneath, Apple manages to hide it very well. For example, you have to install the development tools (from a disk confusingly called "Xcode tools") before it will deign to move such dangerous toys as make and gcc out of their hiding place and into /usr/bin. Or maybe it just installed new ones -- who knows?

Right now I have an Emacs install (via fink) that's been grinding away for three hours apparently rebuilding huge swaths of X, and two copies of Firefox popping in and out of my dock. If it weren't for the fact that some of my coworkers' projects use proprietary file formats that aren't supported on Linux, I'd chuck the damned thing. Well, it has X11 and a nice screen, so if nothing else I'll be able to use it as an X terminal most of the time, and only have to deal with the miserable Mac menu bar when I have to. I hate Macs -- they're almost as bad as Windows machines. Worse, in some ways.

Meanwhile, I have the new computer mentioned earlier today happily up and running. That was a simple matter of putting in a hard drive, (which I had pre-partitioned on another system, since the Debian installer's partitioning tool is pretty tedious to use), booting the DeMuDi installer disk, answering a few questions, and waiting. I did it in the morning before going to work, so that I could do some configuration work and fire off a dist-upgrade before I left. Late in the afternoon I ssh'ed in and finished off a few minor configuration tasks.

Comments

[mrlogic.livejournal.com]

Apple's UNIX works fine for me. Sometime we'll have to have a conversation about what it is you don't like about Macs.

[mdlbear]

The main thing I don't like about Macs is the UI: the one-button mouse, the need to use keystrokes to cut-and-paste (and the fact that they're different from the corresponding Emacs keystrokes), the single menu-bar at the top, and the fact that the single menu-bar forces you to use click-to-focus.

Being a long-time Unix geek I'm used to a three-button mouse, focus-follows-mouse, autoraise on some windows, menubars on all windows that need them, paste with the middle mouse button, Athena scrollbars, and Emacs keybindings. I've been using essentially the same X setup for about 15 years now.

It's true that down underneath OS-X is pretty Unix-like, but there's a lot of Apple stuff on top of it, and it means that all of my Unix knowledge just gets me into trouble and causes endless frustration. For example, you can't use cp, rsync or tar to copy files -- they don't copy the Mac resource fork or whatever other crud gets tacked onto files. That means that none of the tools I normally use to make backups works on a Mac.

And, of course, it ships with all the usual development tools, but none of them are in /usr/bin unless you install the development environment (which is on a disk labeled Xcode for some unfathomable Macish reason).

And let's not even mention the inconsistencies in the UI. I see you no longer have to drag a disk to the trash in order to eject it, but I still have no idea whether clicking the "X" button on an application's title bar will cause it to quit. Some apps quit, others leave their menu up. And typing ^D in a terminal window never quits! It's a nightmare.

[mrlogic.livejournal.com]

If you want to copy files with resource forks or metadata, you can use ditto with the -rsrcFork option, or you can use the CpMac tool that Apple provides in /Developer/Tools. Either works fine, and of course it's simple to alias cp to CpMac if you want to. There are relatively few files I ever need to copy in this way, and if I do I just use the Finder to do it most of the time. However, I can sympathize with your frustration about your backup scripts not porting. I remember the first time I got burned by that...backed up all the data on a drive using non-Mac-compatible tools, initialized the volume, looked at the backup, and swore a lot. Only took once, though, to learn to do it right the next time.

It's noteworthy that going forward, OS X is designed to minimize the metadata and resource-fork issues; most of the files that you'll run into that involve them are legacy in one way or another.

Can't help you with the UI issues; of course, that's entirely "what one is used to". Myself, I find menus attached to windows disorienting and I don't like them, and I find the keyboard shortcuts for copy-and-paste convenient and easy to use. I suspect it's possible to buy a 3-button mouse and software package for OS X that would emulate most of the mouse behavior you prefer (if such were your goal).

The Development disk is called Xcode because that's the name of Apple's development environment...that doesn't seem that unreasonable to me. The dev tools are not in /usr/bin by default because they assume (probably mostly rightly) that no one but developer-types will want them, and that developer-types will probably install the developer tools.

As for the inconsistencies...well, it's a hell of a lot more consistent than Windows, at least. Your point about closing windows and whether or not it quits an application is valid. But why do you want ^D to quit the terminal app? You might have other active windows. Whether a shell window closes or not when you logout of that shell depends on the preference settings.

[mdlbear]

In my world, it's rare for an application to control multiple windows; in particular xterm is a single window and the way you get multiple xterm windows is to run multiple instances of the program. In Unix, the overhead for this is very low, and it means that there's no possible interaction between the instances (in any case, they may be running on different systems, because X is really a network protocol). But no matter how many windows a program is displaying, its default action is to quit when the last of them is deleted.

So ^D (control-D) is the universal Unix end-of-file character for terminals, and closing the input file on the shell running underneath an xterm causes both the shell and the xterm to quit. See why Apple's terminal behavior is confusing to a Unix user?

Similarly, the fact that a program exists that will copy resource forks from one part of the filesystem to another doesn't really help me replace rsync, which can copy between systems efficiently, or tar, which creates archives that can be read on other systems.

I can see why a long-term Mac user who has never used Unix might be happy with OS-X, and might find all the Mac wierdness comforting rather than confusing. But it isn't particularly Unix-like as seen from my perspective.

[mrlogic.livejournal.com]

Certainly. Makes sense.

Seems to me either you want to run just UNIX (or linux) (which you can certainly do on Mac hardware), or else you want to run OS X, and perhaps be able to take advantage of some of the UNIX underpinnings.
If you want just UNIX or linux, then the files you'll be using won't have resource forks or other metadata, so your tools will work just fine and do whatever you want them to.
On the other hand, if you're using OS X, then it doesn't seem quite fair to dis the UNIX layer for having aspects that are un-UNIX-like; the intent of the configuration is that you will primarily use the OS X operating system and its GUI. If you choose not to do that, you can hardly blame Apple.

You may not particularly like the OS X GUI, but I don't entirely understand how that translates to "I hate Macs." Perhaps it's similar to how I might say "I hate PCs" (i.e., non-Macintosh hardware), when what I really mean is "I loathe Microsoft Windows."

[mdlbear]

While it's true that my most intractable problems are with the GUI, there are plenty of others. But you're right; I could presumably ditch the OS entirely, install Linux, and have an attractive (if somewhat heavy and expensive) Linux box.

I can't, because what I need it for is precisely the set of proprietary programs and file formats that don't exist yet on Linux. So I'll just go on tripping over things until I finally reach some kind of an accommodation with it.

[mrlogic.livejournal.com]

Fair enough. Let me know if I can ever be of any assistance.

[mdlbear]

OK, though many of my coworkers have bitten the apple, and my boss used to work there, so there are plenty of folks around to gripe at and to ask me "why would anybody want to do that?"

Let me know if I can help with Linux or Unix questions.

[mrlogic.livejournal.com]

Oh, also, re: rsync: you might be interested in this. It includes full HFS+ support for resource forks and metadata.

Also, see hfstar here.

You might also be interested to know that the next version of OS X ("Tiger") will include HFS+ support for tar, cp, rsync, etc., by default. So, aside from the fact that there are 3rd-party solutions, Apple is thinking about this stuff, too.

[mdlbear]

Good to know that Apple is thinking about it; I don't want to spend a lot of time tracking down third party stuff. I've gotten very used to Debian, which has a huge collection of packages that all play well together. Even fink, which is based on Debian's package tool, has serious problems if you actually try to use it in the most obvious (to a Debian user) way.