|
|
This is a shortened version of my personal diary for February 2005, shortened to those entries of interest to computer people. See http://www.lemis.com/grog/diary.php for my personal diary.
He did that in a very professional manner. One of my concerns about buying a cheap laser printer was that I might have service difficulties, but that turned out not to be the case at all. About the only problem was that when he left, the printer didn't work at all any more: I had run out of black toner. Getting new toner doesn't seem to be instantaneous, either, and I'll have to wait until Friday. In the meantime, reinstalled the old faithful HP LaserJet 6MP. Based on the usage statistics, it should be another year before I need coloured toners, but I should make sure I get some in plenty of time.
Apart from that, more catchup work, notably the Makefile work I did last week. Some of our design choices require interesting dependencies, and I didn't get a reliable Makefile for the library finished before evening. Also lots of mail to catch up on.
Spent some time updating my Apple machine to the latest version of MacOS X. Documentation here could be better, too: I have 4 CDs, the fourth of which is marked “MacOS X Xcode Tools”. Nowhere is it obvious what an Xcode tool is, and the documentation makes the typical mistake of assuming that you know and just telling you about new features. It appears to be a software development package, but you have to guess that.
The meetings themselves dragged on, and as a result I missed the inaugural beer bust. We need to get our priorities clear: first the beer, then the meeting.
That wasn't as simple as it seemed. First I needed to mount the /src file system on which I keep all my sources. Root login failed. My best guess is that the update I did on Tuesday reset the root password to God knows what. After far too much searching through the online documentation, found a way to boot single user (hold down this funny “Apple” key and S during boot) and then ran passwd root. There was a bit of a delay, then the program finished. Reading the man pages revealed that:
Gave up on that and tried a different approach: it seems that the system has sudo, so after rebooting tried sudo bash and then passwd root—success!
Things weren't over then, though. Next I discovered that I couldn't start more than one shell window (“Terminal”) at a time; any attempt just brought back the first terminal. Spent some time messing around in the singularly confusing menu system and discovered a way to start additional shells. But what a pain!
I still can't remap the CapsLock and Ctrl keys. I tried a couple of days ago using uControl, but it doesn't seem to make any difference, though uControl seems to the think that the remapping has worked. As a result, just using the keyboard is a pain. It seems that Benjamin Herrenschmidt is correct when he tells me that the keyboard on this model is hard-wired, so you're lumbered with the broken layout. Spent some time working my way through the installation CDs and found a package of X clients that allowed me to run an xterm on my normal display. That made things a lot easier, but Emacs still doesn't understand X. At least I was able to use my standard shell defaults and Emacs preferences, so it's not too bad.
Then back to the make problem. Things weren't over yet. First, there's no gmake (GNU make); found a gnumake instead. It wasn't until a lot later that I realized that make is a symlink to gnumake:
=== grog@tomato (/dev/ttyp0) ~ 24 -> ls -l /usr/bin/*make -rwxr-xr-x 2 root wheel 237007 13 Sep 2003 /usr/bin/automake -r-xr-xr-x 1 root wheel 119676 1 Feb 18:38 /usr/bin/bsdmake -rwxr-xr-x 1 root wheel 148248 1 Feb 18:38 /usr/bin/gnumake lrwxr-xr-x 1 root wheel 7 1 Feb 18:17 /usr/bin/make -> gnumakeI suppose that makes sense; presumably if you like you can relink it to bsdmake. But why a symlink in the same directory?
Next I had problems getting FunnelWeb. Sure, Ross has an Apple version, but it's just a tar archive. So the whiz-bang GUI downloader downloaded it and put an image of it in a window. What then? Gave up on the GUI and created a directory /usr/local/bin. /usr/local existed, but not bin; I'm not sure whether that's what's intended, but there's nothing in the PATH variable to suggest an alternative directory.
Next, running ls -l across NFS appeared to hang; couldn't work out why, so copied the data across to the local machine. Finally ran make and confirmed the bug report—and that it wasn't Apple specific. Sigh.
Since I was there, carried on trying to do things with the Apple machine. I think that one of the problems I have is to understand what it's trying to achieve. I've never been a fan of eye candy, but the rest of the interface seems so limited. Tried to get something like rdesktop to work so that I can access it from a usable keyboard and with adequate screen space: 1024x768 is so restrictive. Unfortunately, I wasn't successful. The only references I found to something like that all seem to cost money. For me, that puts Apple at a definite disadvantage to Microsoft: as I found out last year, I can use rdesktop to put the entire Microsoft desktop in an X window. Some people on IRC pointed me to cotvns, but that's a client, and it doesn't seem to be compatible with Microsoft either.
Also tried IRC clients. Found a reference to Ircle, which is shareware. It started up, but I couldn't make head or tail of what it was trying to do. An excellent example of the kind of junk that makes me wonder where the industry is going. Then Wes Peters pointed me at X-Chat Aqua, which seems to work, though it doesn't seem to be even as usable as ircII. Maybe I'm expecting too many specifics, but it would certainly help if I could get some documentation that makes sense.
In summary, I found the whole thing very frustrating. It occurs to me that part of the problem is that I started using “desktop” computers before the current spate of GUIs aimed at computer illiterate people. I seem to be an exception here: the current distribution of the dates of birth of FreeBSD committers peaks slightly after when I first got my first computer “desktop”:
In that time I've come up with my own, efficient ways of doing things, and the GUI environment doesn't give me that flexibility. The command-line interface does, modulo a few silly decisions such as file names with spaces in them, but I don't need to spend money on an Apple if I just want that interface.
I also have difficulties with the GUI itself, things that look more than suboptimal. For example, sometimes (I think) you need to click once on an object, and sometimes twice. Unlike Microsoft (which doesn't do a very consistent job either, admittedly) there's no immediate feedback when you press a button, so I end up clicking too many times, typically resulting in accidentally starting Acroread (and not acroread), which happens to be the first entry in the Applications directory.
The other thing that seems so strange in all current GUIs is their insistence on breaking up the directory hierarchy. Not only with Apple I'm often left wondering where the directories are located. Even UNIX-based web browsers such as firefox create their own directories (or even, in some cases, try to store in the directory in which the executable is located). There seems to be a deliberate attempt to separate directories and their contents. I can't understand why, but I find it incredibly frustrating.
Where does that leave me with the Apple? I haven't given up. But the first impression is just as negative as with Microsoft. Gone are the days where Apple can advertise that the Macintosh is so simple that you can learn to use it in a day. I wasted one and still don't know how to use it.
More work trying to understand the Apple box, and didn't succeed very well. It's nice to have the BSD/UNIX interface to the machine, but what is put on top completely baffles me. There's this program called Finder, a name that rivals Microsoft in its re-use of a normal English word. As I discovered (and describe below), it loses mount points for NFS file systems.
If there's one thing about UNIX that has really stood out over the years, it's the file system hierarchy. One single address space to locate just about everything. For reasons that completely blow my mind, it seems that Apple wants to break this hierarchy apart and hide the details. Probably the best example of this is NFS-mounted file systems. After a bit of trial and error, I had persuaded Finder to show the root directory of the system, including all the mount points for my NFS file systems. I mounted an NFS file system, and... Finder removed the mount point from its directory listing. I can't imagine what good that could do. Obviously, though, it's misnamed: it should be called Loser.
More discussion on IRC suggested an alternative. It's obviously too difficult to type this:
# mount zaphod:/src /srcInstead, the user-friendly alternative is:
echunga:/ /echunga nfs rw 0 0 echunga:/home /echunga/home nfs rw 0 0 wantadilla:/ /wantadilla nfs rw 0 0 wantadilla:/home /wantadilla/home nfs rw 0 0 echunga:/dump /dump nfs rw 0 0 wantadilla:/dumpa /dumpa nfs rw 0 0 wantadilla:/dumpb /dumpb nfs rw 0
Of course, you have to go through the whole rigmarole for each file system. With /echunga/home something interesting happened: a new entry home (and not Volumes/echunga/home) appeared on the Finder window. Selecting it gave an empty directory (I think). Continuing further, mounting /wantadilla and /wantadilla/home gave another entry in the Finder window, again (and very confusingly) called home. I can't find any way within the GUI to determine which /home it is. Looking at it with df, I found (showing NFS file systems only):
=== root@tomato (/dev/ttyp2) /Users/grog 2 -> df Filesystem 1048576-blocks Used Avail Capacity Mounted on zaphod:/src 150214 79244 58952 57% /src echunga:/ 5814 5301 47 99% /Volumes/echunga wantadilla:/ 9912 4566 4553 50% /Volumes/wantadilla wantadilla:/home 51895 39296 8447 82% /Volumes/wantadilla-1For some reason my /echunga/home got umounted. echunga's log file confirms:
Feb 7 15:20:08 echunga mountd[827]: mount request succeeded from 192.109.197.153 for / Feb 7 15:20:26 echunga mountd[827]: mount request succeeded from 192.109.197.153 for /home Feb 7 15:20:30 echunga mountd[827]: umount request succeeded from 192.109.197.153 for /homeI'm pretty sure I didn't do that. In any case, at this point I still didn't have zaphod:/src showing either, so I tried mounting them both again. This time it worked, and I had two home entries in the Finder window, without any way to determine which is which. df now tells me:
=== root@tomato (/dev/ttyp2) /Users/grog 2 -> df Filesystem 1048576-blocks Used Avail Capacity Mounted on zaphod:/src 150214 79244 58952 57% /src echunga:/ 5814 5301 47 99% /Volumes/echunga wantadilla:/ 9912 4566 4553 50% /Volumes/wantadilla wantadilla:/home 51895 39296 8447 82% /Volumes/wantadilla-1 echunga:/home 6329 4543 1279 78% /Volumes/echunga-1 zaphod:/src 150214 79244 58952 57% /Volumes/zaphod
So now I understand what's going on. The question is: Why? It seems as if Apple has deliberately broken one of the most important things about the UNIX file system, but only in one view.
I didn't approach Apple with an intention to criticize it. I was really hoping for something good. What I find seems to be a deliberate obfuscation and complication. So far, I'm very disappointed.
On the way home finally picked up some shelving to install in the Mike Smith Memorial Room, in which I can hardly move any more.
Catching up with things in the afternoon. These meetings in town really cut into the day.
Today wasn't the day: first I had nearly 3000 mail messages accumulated since Friday, and secondly the Makefile saga was still giving problems. A quick hack that takes a week to fix. I should know better by now.
Apart from that, finally started doing something about the Mike Smith Memorial Room. The area in the middle was almost impassable:
Moved that out into the library and started putting the shelves together. How ugly they are!
Also finished putting the shelving together the Mike Smith Memorial Room:
Now to decide how to utilize the storage space.
That stopped after a while, though: the gdb process hung in a WAIT state. Repeatedly. Finally ran it under ktrace and generated hundreds of megabytes of trace output. I was able to confirm that I could reset the length of the trace file to 0 without problems. Finally it hung again, and I looked at the end of the 172 MB remaining trace file and found that it stopped with:
12325 gdb CALL ptrace(12,0x3026,0xbfbfd5e0,0) 12325 gdb RET ptrace 0 12325 gdb CALL ptrace(PT_STEP,0x3026,0x1,0) 12325 gdb RET ptrace 0 12325 gdb CALL wait4(0xffffffff,0xbfbfd808,0,0)This is the same sequence that repeats itself thousands of times in the trace: it should continue with
12325 gdb CALL wait4(0xffffffff,0xbfbfd808,0,0) 12325 gdb RET wait4 12326/0x3026 12325 gdb CALL kill(0x3026,0) 12325 gdb RET kill 0 12325 gdb CALL ptrace(PT_GETREGS,0x3026,0xbfbfd5c0,0)But it didn't: it hung. Looks like a kernel bug, presumably some kind of race condition. This is FreeBSD 6-CURRENT of 14 December 2005, so decided to upgrade to the latest version before complaining. On this old machine that would take several hours, so spent some time tidying up the Mike Smith Memorial Room. It takes quite a bit of thought to decide how to arrange things.
Then into town for a board meeting of the ICT council of South Australia. John Sanders, our new executive director (see my diary entry) is leaving us already, and there was a lot of tidy-up work to do.
Off to town after that for another set of Friday meetings. I suppose they're necessary, but they really tear the day apart.
Now to decide what to do with the rest. There's an incredible amount of mess there, much of which should be thrown away.
Finished building a new kernel for quartet, and now at least it doesn't panic shortly after boot. But the hang in gdb is still there. Discovered a sysctl to turn off individual CPUs:
=== root@quartet (/dev/ttyp3) ~ 2 -> sysctl -w machdep.hlt_cpus=14 machdep.hlt_cpus: 0 -> 14This masks off CPUs 1, 2 and 3, leaving only CPU 0 to run. It's quite convenient that you can do it on a running system.
With that, I was able to run and hit my conditional breakpoints. It's obviously an SMP So, do I fix the race condition, or do I put up with it? I entered a bug report, but based on the current state of debugging in FreeBSD, I fear that nothing will happen until I look at it myself, and I don't have time for that.
Found the bug, anyway, and continued investigating. Hopefully it will be downhill from now on.
After that, continued running the test—not a fast thing on this slow hardware—and by evening it had failed again: I had overflowed a link field (32 k copies of the same data). That will be easy enough to fix.
It wasn't easy: attempts to create new drives kept crashing the system, and most of the dumps I (finally) got were not readable. After a lot of messing around, connected the array to teevee, which is running 5.3-RELEASE, and used Vinum to create the objects. Clearly gvinum still has a way to go.
I heard later from Lukas Ertl, prime gvinum developer, that he hasn't tested gvinum with INVARIANTS set. It looks like a good idea to do so.
After getting the array up and running, spent the rest of the day copying 28 GB of data. I really need faster hardware.
In the meantime, spent some time trying to get my program to compile under Linux. That was more difficult than I thought: on the one hand, I had included BSD-specific code like the functions that produce the ls -l listing, and they pulled in so many non-standard functions that I spent a couple of hours unravelling them. On the other hand, Linux doesn't appear to have any standard functions to convert 64 bit values from big endian to little endian and back. It can use the standard htonl and friends for 16 and 32 bit conversion, but there's nothing like FreeBSD's htobe32 and friends, which include 64 bit variants. Looks like I'll have to bite the bullet and write them.
In the evening to Sydney for an AUUG board meeting, coincidentally my first flight with Virgin Blue. I fear they're the sign of the future: American-style no frills service. I suppose we'll survive, but it's lowering the level of service across the industry.
Also looking at the profiling code that I originally wrote in April last year. I could have sworn that I had got it to compile (though not to run) in December, but I can't find any evidence, and it needed more work done, in the process showing up more problems with the build process. sigh.
Apart from that spent some time looking at the intrusive profiling stuff. It's almost working, but I wrote this in a couple of days last April, and it's taking longer to port to Linux than it did to write in the first place.
More discussion about the way we build our software today. I really have a problem with the idea of the Makefile in one directory going into another and building it. It seems that I'm the only one within Rocksoft, though, so ended up reinstating what seems to me to be broken behaviour. As a sanity check, asked on various IRC channels (FreeBSD, Linux and NetBSD). FreeBSD and NetBSD agreed with me; Linux didn't answer. Here the transcript:
FreeBSD:
* groogle poses a philosophical question. <groogle> Assuming I have two subdirectories in the same source directory. <groogle> One contains the "application", the other contains a library that supports the application. <groogle> If I 'make' in the application directory, what checks should it do about the library? <Darius> if it was me.. <Darius> the makefile would only try to link to it and nothing else <groogle> $ make Darius <Darius> ie it would expect the library to be built first <groogle> And what if the library was not there? <Darius> groogle: *boom* <groogle> Fail? <Darius> the link fails, PEBKAC problem <groogle> OK. <groogle> Other opinions? <sjg> um, have the top level makefile traverse into the lib dir first, but the makefile under the app. directory shouldn't care. or 1 makine? <sjg> er <sjg> makefile? <sjg> makine? * sjg shrug <Darius> sjg: that's my opinion, get your own ;) <sjg> Darius: that's your opinion++ * Darius -> home <Darius> heheNetBSD. On request I've changed the nicks.
* groggy poses a philosophical question. <groggy> Assuming I have two subdirectories in the same source directory. <groggy> One contains the "application", the other contains a library that supports the application. <groggy> If I 'make' in the application directory, what checks should it do about the library? <foobar> heh <tbazz> groggy: i woudl say ideally nothing. the top level should descend into the directories below it and those Makefiles (or whatever) should make sure whatever needs to be done is done <groggy> Right, but this Makefile is not in the hierarchy. <groggy> i.e. I have two directories, app/ and lib/. <groggy> app/ depends on lib/. <bar> yeah, apart from checking that the libs it needs have been made and installed already, at least in an objdir <groggy> So if I say 'make' in app/, and lib/ hasn't been built, what should happen? <groggy> These are static libraries, so they get linked from their build directory <bar> then make should fail with something like 'don't know how to make ../lib/foo.a' i guess <groggy> OK, thanks. <bar> (a common objdir might help) <groggy> Right. <groggy> I'm just trying to DTRT. <bar> if foo.a is likely to be a standalone lib as well, optionally compiled if not already present on the platform, then you probably have configure fun <groggy> This is all application. <bar> but that configure lives in the parent dir <groggy> Consider it to be a package. <groggy> Yes, that's my view too. <bar> yah, if it's statically linked, it's less likely to be such <uep> bbl <anon> oi <anon> groggy; we do that type of things in various parts of the netbsd build <anon> the "toplevel" makefile usually does <anon> SUBDIR = libdir .WAIT appdir1 [...] appdirn <anon> .WAIT is bsd.subdir.mk magick to ensure libdir is built before the rest <groggy> anon: Yes, that's fine. <groggy> Now what happens if somebody goes into appdir and does a 'make' there before libdir has been built? <anon> groggy; dunno if freebsd's bsd.subdir.mk has that syntax <anon> it fails <groggy> anon: This isn't FreeBSD. This is at woork. <anon> using what make infrastructure? custom gnu make ? <groggy> I'm just trying to DTRT. <groggy> Yes, as it happens. <groggy> But I don't think that makes any difference. <groggy> Well, s/custom // <anon> you _could_ put a rule in the appdir makefile that automagically builds the lib if it's missing. i'm not sure it's worth doing, myself <groggy> That's what people at work want to do. <groggy> It seems wrong to me. <anon> so build the lib in the same dir and use normal make dependencies <anon> or are there multiple app dirs ? <groggy> And I'm just looking for other opinions. <groggy> Yes, there are multiple (2) app dirs. <anon> add a dependency rule then <groggy> Sure, that's easy. <groggy> The question is, is it correct? <anon> by what definition of "correct"? "stylistically correct?" :) <groggy> Yes, for want of a better term. <anon> depends on the project, really <anon> in netbsd we don't bother <anon> for a homegrown project using your own make infrastructure with sooky & lazy developers, it's probably "correct" <groggy> OK :-)
My program was still running in the evening. What a snail!
Meetings in the afternoon again. 14 people for half a day makes 7 man days. There must be a faster way.
Made quite some progress with the Mike Smith Memorial Room, but basically I just have too much stuff. I wonder how many of those big old 21" monitors actually work.
The DVDs were quite another matter. They had been recorded on my flaky Digitrex DVD recorder, and it couldn't play them back. I had already noticed that computers did a better job, and mplayer on FreeBSD plays them with no problems beyond its emetic user interface.
Today I decided to play them in the Apple—after all, that's what it's supposed to be good for. It's always difficult to guess what to do to play something, since there's no documentation, and obviously I don't have any “intution”, but after a while it became clear that there was no DVD player software installed on the machine. Finding out why that was so, and what to do about it, was a nightmare.
The pitiful excuse for documentation told me that it was installed automatically if the hardware was present, and how to detect if a DVD drive was connected to the machine. In the latter case, you'd expect the instructions to read “examine the drive and see what's written on it”, but instead I was taken through a maze of twisty little menus, all different, with the intention of finding whether the system thought it did in fact have a DVD player. The instructions didn't go as far as to say how you could tell, but everything seemed to indicate that the system did in fact agree that the hardware was installed.
OK, then, it should be simple enough to find the package and install it—I thought. In fact, another tiring search of the installation media showed nothing obvious; later somebody pointed out that it was in the directory "//Volumes/Mac OS X Install Disc 1/System/Installation/Packages/Essentials.pkg" (how I hate these stupid file names with spaces in them!). Tried to install that, but since I had in the meantime upgraded the system, it refused to install. Somebody sent me a “Stuffit” (what an appropriate name!) archive, but for some reason there was an incompatibility there, and I couldn't install it. After three hours I gave up. Apart from being incredibly frustrating, I'm always left wondering whether the problem is with the Apple machine or with me: millions of customers can't be wrong. I suspect that a generation of using menu-driven software has taken its toll, and vendors expect you to understand it, like they expect you to be able to read and write. It's a pity, though, that they've chosen such a horribly difficult and hard to use paradigm.
In connection with documentation problems it is interesting to note a couple of books I found while tidying up the Mike Smith Memorial Room: a total of rather more than 200 pages on how to use the “Microsoft Mouse”, dated 1984, and including detailed programming information. Times have changed, but not for the better.
First I continued with the Apple. Since I couldn't find a way to install the Apple DVD player program, installed VLC instead—once I had worked out how to do that. The instructions suggest that you drag part of the archive into the /Applications directory. It took me 5 attempts to get it to go there. When I did, I couldn't work out how to start it. It seems it hides some stupid image in the “task bar” at the bottom of the screen, and some undocumented mouse click brings it to the foreground. When I did, I couldn't get it to recognize the DVD (“no DVD present”; is it talking about the medium or the drive?). Inserting a pre-recorded DVD caused a delay (and no indication that anything was going on), followed by the disk being ejected. After searching in the the help, found a hidden menu to specify the action to take on DVD insertion, and set that to start VLC. No difference. Round about now I decided that there might be something wrong with the DVD drive, but it mounted data DVDs perfectly. Removed the drive and took at look at it: “Macintosh PowerBook G3 Series 2X DVD-ROM Module”. My best guess now is that the drive really doesn't support video DVDs, but there's nothing in the appalling excuse for documentation that mentions this possibility.
While working with the Apple, also upgraded to the latest version of MocOS X. In the process, it disabled my uControl keyboard remapping, not that that was so serious: it works very badly, leaving the Control key locked on after pressing. The result is that the next time I type a d at the beginning of the line, the terminal window disappears. But now it didn't do anything: it had been disabled and refused to load. It did offer to find a new version for me, and told me, yes, there is a new version. No offer, help or instructions to replace the version. I'm continually baffled by how bad this stuff is.
Gave up on Apple and tried installing VLC on eucla, my FreeBSD laptop. Once again ran into this bug:
automake15: configure.in: installing `./compile' autom4te259: cannot lock autom4te.cache/requests with mode 2 (perhaps you are running make -j on a lame NFS client?): Operation not supportedI had seen that before. It means that you have to install from a local disk. After that, got it installed, but when I started it, I got a whole series of this kind of error message:
VLC media player 0.8.1 Janus (:7025): GLib-GObject-WARNING **: cannot register existing type `PangoEngineShape' ** (:7025): CRITICAL **: file pango-engine.c: line 86 (_pango_engine_shape_covers): assertion `PANGO_IS_ENGINE_SHAPE (engine)' failedReinstalled pango, after which the program started with the following message and empty menus:
libdvdnav: Language 'en' not found, using 'ÿÿ' instead libdvdnav: Menu Languages available: ÿÿAt this point, decided that Linux might be better. Tried booting eucla under Linux: I had installed Fedora Core 2 on it last August, but now it wouldn't boot with some obscure error message. Since there had been problems with the X configuration anyway, decided to install Fedora Core 3. The first time tried an upgrade, with the result that, after nearly an hour, the reboot failed with a “Kernel Panic”—where do they get that name from? It looks more like a kernel halt to me, with no information about where it happened. Did a clean install and was rewarded by X still not being able to recognize the hardware. I have no idea why: the same software installed out of the box on FreeBSD last July.
Gave up on Linux and returned to FreeBSD. It was fairly obvious that some of my ports were out of date. Running portupgrade did nothing useful, so with the help of pkg_info -r found the dependencies (all 74 of them!) and removed them, then started reinstalling them. By the time I went to bed I had got as far as multimedia/ffmpeg:
texi2html -monolithic -number ffmpeg-doc.texi env: perl: No such file or directory gmake[1]: *** [ffmpeg-doc.html] Error 127Just a missing dependency. But it's really getting beyond a joke just trying to build ports nowadays.
-> *vendor* I'm having difficulty playing DVDs on the PowerBook. Any ideas? *vendor* I think you'll need to be running OS9 for DVD playback - at least that was the only way I could make it work -> *vendor* Hmm. Interesting. *vendor* The PB has hardware accelleration for DVD decoding but Apple only elected to support it under OS9 -> *vendor* Ah. -> *vendor* Nice for them to document that, isn't it? *vendor* I didn't use it much, ended up getting a "real" DVD player * -> vendor: groggy notes that Apple doesn't seem to think much of documentation anyway. *vendor* Yes, it's one of those documented by omission sorts of things -> *vendor* OK, I'll give up then. -> *vendor* In general, I find MacOS X to be impossibly badly documented. *vendor* Sorry, I didn't think to mention that at the time *vendor* (DVD playback, not OSX documentation :) -> *vendor* No worry. It serves its purpose. *vendor* Yeah, it is a bit light on for a "power" user * -> vendor: groggy notes that some purposes are to be a bad example.OK, this is an old machine (4 years), so this is all water under the bridge. I suppose it upset a number of people at the time, though. But, as I said on IRC: the documentation, such as it is, doesn't mention the possibility that some DVD drives are not supported under MacOS X. Another reason to dislike the machine.
Yvonne went into town and brought me back a couple of 200 GB disk drives today, finally allowing me to test my program under more typical conditions. I'm still waiting on the new dual Opteron box to run them (special order), so I had to put them into my long-suffering teevee machine, the one that was really intended to—coincidentally—play DVDs on the lounge room TV. That worked better than I expected, and it started off working at least as fast as our existing product, though as expected the performance fell off rapidly. Still, relatively encouraging results, somewhat marred by the discovery of yet another insertion bug.
Previous month | Greg's home page | Today's diary entry | Next month | Greg's photos |
$Id: hackers-diary-feb2005.html,v 1.1 2008/02/10 23:51:57 grog Exp $ |