I've been feeling pretty bummed since Steve Jobs announced, earlier this week, that Apple would be moving from PowerPC to Intel x86 CPUs. I'm not sure why I'm so upset, or even if I should be upset. Part of me is sad because I genuinely believe (even in the face of little or no empiricle evidence) in the superiority of RISC architectures, or, possibly, in the obvious (again, without empiricle evidence) inferiority of Intel architectures. The rest of me, however, knows that, so long as the box feels like a Mac, I really won't care if it runs on a PowerPC, M68K, Pentium XVIII, or a hamster in a wheel: the user (my) experience is all that really counts.

Now people are speculating wildly about how Apple will keep people from running OS X on non-Apple hardware. They're talking about motherboard dongles and DRM features in the CPU. Behind all this speculation is the barely concealed assumption of RIAA-like lawsuits. I think that all of this speculation is off the mark.

While Apple has been known to bring lawsuits against vendors seeking to clone Apple hardware, these suits were brought at a time when Apple's only real source of income came from hardware sales and Mac OS (then called simply "System") was given away for free. Times have changed: Apple began charging for system software back in the early nineties with System 7.1 and they now have several distinct income streams including software (including Mac OS X), online music sales, computer hardware and consumer electronics.

When Apple released Mac OS X, in fact, they only guaranteed that it would function with a small set of current and recent systems, reneging on earlier promises to support all G3-based systems. Despite this hardware support policy, however, Apple took little or no notice of efforts to allow use of OS X on older, unsupported, hardware. I don't see any reason to think that they would reverse this behavior with OS X on Intel.

The people who wanted to run OS X on the beige PowerMac G3s, or on pre-G3 PowerMacs, were mainly interested in saving money: they were not likely customers for new Apple products under any circumstance. Given the choice of enforcing the OS X licensing policy and slightly expanding the OS userbase, Apple chose to expand the userbase. Since Apple now charges for each copy of OS X, they were probably not actually losing money to the Old-worlders, so long as most of the ilicit OS X installs were actually paid for.

The people who will want to run OS X Intel on non-Apple hardware are also the most price-sensitive segment of the market. Given the choice of ignoring technical license breaches and passively evangelizing to potential future customers, I think Apple will choose to invest in the future and let people run OS X Intel on anything they want (of course, Apple won't guarantee that OS X will operate with anything other than Genuine Apple (R) hardware, and they certainly won't provide any kind of support).

It should go without saying, of course, that any attempt to distribute pirated copies of Apple software will be met by an army of rabid intelectual property lawyers.

Every installed copy of OS X represents a potential customer for other Apple products and makes the platform more attractive to application vendors. Apple would like it if every person using Apple software were also purchasing new Apple hardware. Even today, however, when the only realistic way to run Apple software is to have Apple hardware, many users either buy second hand equipment or nurse aging equipment along with upgrades and patience. Apple doesn't seem to mind the active markets for upgrades and second hand hardware (though Steve did kill the clone markets shortly after regaining the helm of Apple Computer Corp.) so I see little reason to expect this laissez faire attitude to change. Until Apple actually supplants Microsoft as the operating system vendor on the planet, it will be in Apple's interest to get their products in front of every person they can, regardless of official policy.

We got back from our trip to Istanbul last night (Thursday, 26 May 2005) after an unexpected stay in Frankfurt Germany. We appear to have planned our vacation to conincide with two important soccer games also being held in istanbul, one derby match between Galatasaray and Fenerbache the day after we arrived (19 May), and the other championship match between Liverpool and Milan the day we left (25 May).

Both matches meant that we would have been royally screwed for accomodations if our hotel reservations had gone awry and caused some extra crowding on the streets of the old city. The second match, however, meant that an extra 200 planes were flying into Istanbul on the same day we were trying to fly out, which delayed our flight by almost an hour. As a consequence, we missed our connecting flight in Frankfurth.

Lufthansa was nice enough to put us up for the night and book us on the first flight out to Washington D.C. the next day, but we both had to take an extra day of vacation (which is a dear price for an American to pay, since we don't get very much vacation to begin with). Even with the extra day, however, I didn't manage to satisfy my craving for good German sausage. I guess we'll just have to take a trip to Germany (oh, the sacrifice).

We had a great time in Istanbul: we saw the museum of achaeology, Ciragan Palace, Topkapi Palace, Dolmabache Palace, San Sophia, The Blue Mosque, Dolmabache Mosque, the Yerebatan Cistern, the book Bazaar, the Egyptian Bazaar and the Grand Bazaar. We also wandered around Beskitas and Taksim quite a bit and took a ferry over to the Asian side of the city for one evening out.

My friend, Ozan, showed us around the city the entire week and had us over for dinner at his apartment one evening. His apartment is very small, but it has a great view of the Bosphorus. It was only a few blocks from our hotel, but most of the distance was straight up (Istanbul has a geography similar to San Francisco or Ithica New York).

Lina and I are finally going to visit my friend Ozan in Istanbus, Turkey. We've been planning to do this ever since Ozan went back to Turkey two years ago. Unfortunately, we'll only be there for six days (actually, only five days, since about one day will be eaten up in air travel) so we won't get to see much of the country: just Istanbul itself. While this is disappointing, I'm not too upset about it, since the main reason to go to Turkey, for any length of time is to see Ozan again.

Faced with the 12-15 hour flight from the east coast of the U.S. to Istanbul (we have two layovers along the way, in New York City and Munich) I have again been thinking about the hacker's handheld. Since there is no way in hell I'd get a home-brewed tablet computer past the security goons and the airport, I've put the last few days effort into getting a Toshiba Portege 3020ct working (in other words, wiping the Microsft filth off the hard drive and installing Linux).

Installing Linux on the Portege 3020ct is a bit of an adventure because the Portege doesn't have a CD-ROM drive (at least, mine doesn't have one) so I had to do an NFS install. The newest version of Slackware (10.1) did the job quite nicely, but with a few hickups.

The first installation went smoothly, until I had to install LILO: the non-expert options for MBR and superblock installation failed and screwed up the superblock on the root partition in an unrecoverable (by me) manner. All successive attempts to rerun the installer failed when it came time to actaully install the packages: once the package groups were selected, some text would flash by (too quick to read) and the isntaller would say everything was installed. In the end, I had to dismantle the install scripts and build my own scripts to untar the Slackware packages directly onto the destination partitions.

I probably could have just used the tag files, but I got fed up and decided to do it my own way. I was rather impressed that I could simply read the install scripts and duplicate the desired functionality in a few dozen lines. This is what I really like about Linux in general: all the inards are, with a bit of effort and patience, available for anyone to muck about with.

I don't want to make it sound like I'm complaining about Slackware, I'm not. Slackware was very good about recognizing the weird hardware setup on the Portege: I'd read web-pages a few years ago recounting the difficulty of installing and using Linux on the Toshiba Portege, but it just seemed to work (modulo the installer crapping out). Once installed, all I had to do was rebuild the kernel to get better support for VFAT and ACPI, download a few packages not found on Slackware, and fiddle a few configuration files.

I read this comment on Friday and was completely blown away by it (as, aparantly, were other folks, based on the Score:5, Insightful rating).

The essence of the comment is that when a market is threatened by a new, vigorous, competitor, the existing market competitors fold in order of financial strength (poorest to richest). As the poorer competitors exit the market, the richer competitors receive a portion of the orphaned customers. The result is that the richest competitors in a market can appear to do very well while their primary market is collapsing beneath them. Unfortunately, when all the poorer competitors have exited the market, the richest competitor must duke it out with the new, vigorous, competitor: often, the result is not good for the rich competitor.

The comment's author, jimfrost, uses DEC and Sun as examples of the pattern. He posits a law he calls Jim's Law: "The cheapest thing that gets the job done, wins." A corollary to Jim's Law is that trying to retreat up-market when faced with tough competition for comodity products is a losing strategy: By moving the more expensive, higher margin, smaller market products, you are moving away from the winning position.

I think the analysis is absolutely fascinating, even if Jim's prognostication is off the mark (I'm not saying it is off the mark, only that it might be).

After posting this comment to the article Why Microsoft Should Fear Bandwidth I wanted to write a little bit more about making system administration easier: I didn't want to leave the topic as vague assertions.

Other people have written elloquently on this same topic: all I want to do is point to some possabilities for solving the most serious administrative problems.

• Software Installation: Rather than rely on install/uninstall scripts, all the components of a piece of software should be contained in a single bundle or package that can be installed or removed as easily as copying or deleting a file.
• System Installation: I'd like to ignore this, on the grounds that it doesn't happen often, but I think that Linux system installation could still use some work. At the very least, an installation using sensible defaults should be doable with munimum fuss: user's shouldn't be forced to choose partitioning schemes, swap space size and select what software to install from a list of dozen's of inadequately documented options. Unfortunately, I don't have any pointers to good examples of system installation done right: maybe it is just an inherantly complex task.
• Network Administration: A prudent selection of default settings whould go a long way toward eliminationg network administration for most users. I think the OS X network and sharing preference panels are pretty good implementations, but still a bit baroque for my tastes.
• Printer Administration: As noted above, Eric has already written on this topic: his observations are accurate and his points are cogent.
• Backup Management: Here is one case where I think a reasonable business case might be made for a leased service: users could pay for a remote system to connect to thier computer periodically and copy and modified files, producing a set of CDs or DVDs which would be mailed to the subscriber. Obviously there are some serious privacy issues that may scuttle the whole enterprise.
• User Administration: This is also a relatively infrequent task, which could be justly ignored. However, I don't think it really needs much more than a simple UI over the existing flat files.

Rather than concentrate on making complex tasks easier, it may be better to try to eliminate as many administrative tasks as possible, in their entirety. In the early days of personal computing, this was the general case: personal computers were just much less complex than the centralized systems and users could handle them without much difficulty. Unfortunately, as personal computing has matured, administrative tasks have accumulated and made things more difficult to maintain. It's not clear to me that all of this complexity is really necessary, but eliminating it may mean some hard work for programmers and administrators.

I've been in a deep funk for the last four months: At the end of August one of our cats (Prudence) died suddenly, then there was the 'election' and my ongoing (and increasing) dissatisfaction with my job. I just can't seem to pull it together, so I tend to do neurotic web-surfing late at night. Tonight, I tried to look up some old, old friends. In the process I stumbled across the alumni page for my highschool.

Most of my friends have not bothered to submit their current statii, but a few have and even include links to personal web pages. I looked up one fellow in particular. We weren't close friends, and I thought he was obnoxious (he was a rabid, proselytizing christian), but otherwise a good enough guy, and we ran in the same crowd (theater, madrigal chior, etc.). Reading his web log, however, I think I'd like him better now than I did then. I feel a bit better knowing that at least some of the people I fell in with (largely by happenstance) in highschool I might actually have chosen to hang with if I'd had the choice outright. I have often thought that our highschool friends (my highschool friends, at least) were together more by chance than design, more by default than by any similarity of thought or personality: I could stand to be wrong about that.

Maybe there's a mystery in that somewhere: are our friends drawn to us (or we to them) by who we are, or do we become who we are because of who we have for friends? For family we have no choice and much of who we are is, likely, imposed upon us by the luck of being born to certain parents, but friendship has, at least, the appearance of free will.

So much for melancholy ramblings. I never found any trace of the old, old friend I was looking for in the first place, but, at least, I feel a little better.

Just some thoughts on an abstract checkpointed file library:

The interest in checkpointing comes from the desire to preserve a known good state of an actively read or written file in the face of unpredictable system failure. We would like to be able to resume processing from the last known good point.

It seems that we only really need a small set of operations to support checkpointed files:

First, we need routines to open and close a checkpointed file:

CP_FILE *cp_open(char *fname, char *mode);

int cp_close(CP_FILE *cpf);

Next, we need routines to read from and write to the checkpointed file (since we don't have a regular file pointer in hand, we can't use fread or fwrite):

int cp_read(CP_FILE *cpf, void *buf, int size, int count);

int cp_write(CP_FILE *cpf, void *buf, int size, int count);

Finally we need a routine to update the file's position in the checkpoint store and flush the file buffers to disk:

int cp_check(CP_FILE *cpf);

The cp_open routine will either open an existing checkpointed file (if one with the given name is found in the checkpoint store) or create a new file and make an entry for the file in the checkpoint store.

The cp_close routine will mark the file's entry in the checkpoint store as completed and close the open file.

We may want a few routines to round out the support for file operations:

fpos_t cp_tell(CP_FILE *cpf);

int cp_seek(CP_FILE *cpf, fpos_t fpos);

We also need some routines to manage the checkpointing system, specifically to adapt the framework to different implementations of the checkpoint store:

int cp_hooks(int (*ins)(char *fname, void **userdata), int (*upd)(char *fname, fpos_t fpos, void *userdata), int (*qry)(char *fname, fpos_t *fpos, void *userdata), int (*com)(void), int (*rbk)(void), int (*ini)(void), int (*fin)(void));

The ins hook is called when a new entry is needed in the checkpoint store for a named file. The insert routine may return a pointer to a block of user data.

The upd hook is called to update the file position value in an entry. The user data block is also provided.

The qry hook is used to query the checkpoint store for an entry for the named file. If such an entry exists the file position and user data are returned.

The com and rbk hooks are used to commit and roll-back changes to the checkpoint store.

The ini and fin hooks are used to initialize and finnish any connection to the checkpoint store.

Ok, again, not much has happened since last October, but a bit of progress has been made in the last few weeks:

First, I found a new board that is much closer to my desired specs (it uses the Samsung 2410X that I was interested a year ago and includes a CrystalLAN CS8900A providing an ethernet port). The board, the LN2410SBC from ClabSys, costs $250 in quatity 1 from the U.S. distributor, LittleARM, but the documentation that I've seen so far is a bit sparse.

Second, I've found a neat way to build a custom, multi-output power supply: Texas Instruments makes these neat little, self-contained switching power supplies in DIP packages. You can pretty much build a power supply as if you were plugging together lego blocks! Sure, you need to add a few passive components (bypass caps and a couple of pullup resistors on the regulated devices) but it's a hell of a lot simpler than building a buck/boost supply from NatSemi Simple Switcher, which come in nice TO-220 and DIP packages, but require external inductors, or the Maxim/Dallas parts, which usually come in surface mount packages and require external inductors. In either case, the circuit layout for a good switching supply is non-trivial and the TI parts have it all done for you.

Anyhow, with the TI parts I can, relatively quickly, construct a power supply that will provide logic voltages for both the SBC (5V) and the LCD (3.3V) as well as the LCD bias voltage (-36V) and 12V for the CCFL inverter. Right now I'm putting together tools to etch and drill simple circuit boards.

Ok, either the state of support in the Linux community has gotten a lot worse in recent years, or I've gotten a lot grumpier. Since I was pretty grumpy to begin with, I'll have to lay the blame at the feet of the Linux community.

So, if anyone is reading this journal, they will know that I just built a new Linux box and installed a recent version of Slackware on it. I found out, too late, that Linux doesn't directly support AC97 sound cards (not that I had much choice: all the motherboards I considered had built-in AC97 audio), so I went on another little adventure build ALSA for the 2.4 kernel.

The available documentation on building ALSA is less than stellar, so much so, in fact, that I gave up on building for 2.4 and went directly to 2.6 (which I wanted to do anyhow). But that's now what I'm here to talk to you about tonight. (queue Arlo Guthrie: "I'm here to talk about the Draft") I'm here to talk about kernel booting errors.

Specifically, I'm here to talk about the error message "No Setup Signature Found..." The message itself is less than helpful, especially since there is no discussion of setup signatures in the Linux documentation (not that is immediately evident, at least).

After pawing through the Documentation directory in the linux source for a while, I gave up and did a web search. The results, for the most part, were less than helpful: Most of the responses to questions concerning the "No Setup Signature Found..." message were too vague to be of any use, even if they had been even close to correct: one response claimed that the question couldn't be answered because the CPU on which the kernel was built had been overclocked. Another response blamed the failure to run lilo on the new configuration. Another suggested a configuration or compilation error.

The correct answer came from an OP in response to his own question: This is really not an acceptable level of support. It's really not so unlikely that technically underpowered users will be building and installing their own kernels: mainly because custom kernels are pretty much required to get proper hardware support. It's not just kernel configuration either, almost any software that doesn't come with your distribution requires a modicum of development and administrative expertise. Without a reasonable level of community support, it is nearly impossible to figure out what needs to be done or how to do it, even for experienced developers (like myself).

Anyhow, the answer to the "No Setup Signature Found..." message was simply this: The kernel image was empty. I had built a bzip2 compressed image (bzImage) but had copied the regular compressed image (zImage) into /boot. Obviously, since the make zImage had failed, it had not written a complete zImage file (why is there any zImage file? Either the zImage shouldn't be built at all or the incomplete zImage should be deleted when the build fails) which I then tried to boot from.

Even if the build process, leaving the incomplete bzImage around to trip up the unwary, can be justified, the cryptic error message from Lilo (or whoever is generating that message) is inexcusable. Given the abominable level of foresight on the part of the kernel and lilo coders, there is a positive requirement for the Linux support community to be more helpful to unfortunate users suffering through this mess.

If, as a community, we can't be patient and helpful with the folks we have already convinced to take a look at Linux, we deserve to be stomped into the dirt by Microsoft, SCO, and whoever else wants to take a shot at us. We are supposed to be better than them, to treat our users (nay, not users, not even customers, but comrades and friends) with respect. If we can't even do that, we don't deserve world-domination.

We are beset by a multitudinous terror. They have arisen from the long sleep to reclaim the world we, mistakenly, call our own. The stride a century as if it were a week. Their long, slow march treading patiently back into dark prehistory and forward to the unknowable future. A crawling horror with a million legs, lofted on chitonous wings. Their red eyes peering from every corner and crease, from the sky above our heads and the ground below our feet.

In other words, the periodical cicada are back. I saw the first nymphs emerge last Wednesday (May 12) with the bulk of the brood emerging on Thursday and Friday: the discarded skins of the nymphs adorn tree-trunks, grass and flower leaves, walls and most any other vertical surface, like holiday ornaments designed by H.R. Geiger.

The song was first audible on Thursday, but has built, since then, to a continuous uulation, ringing over the distant hills from all directions: omniprsent and opressive. The song sounds like nothing more than the Phaser sound effect from the first Star Trek series, except for its duration. Mercifully, the sound effect only ever lasted for a few sends on the television show, here it goes on for hours, from dawn till mid-afternoon. It is most noticable outside, but can still be heard indoors.

There is, also, a noticible odor. It is not, yet, very strong, but it will get stonger as the brood reaches its peak. It is mildly offensive, sweet and cloying, like the stench of rotting leaves in the fall. I have been told it is the smell of dead cicadas, of which there are plenty, but have no way of knowing if it is true. It may be the smell of their discarded skins, or some effluence of their bodies, but it clearly associated with and unique to this brood.

Here are two more links that I couldn't fit comfortably in the text above. Both links are especially pertinent to the emergence I am describing, since I live in Silver Spring, Maryland.

I was a bit peeved today to find out that a google search for my name didn't turn up my web-page. It turns out, at least in part, that the problem was in the search. I searched for the string "Jeffrey Dutky", because that's what I call myself, but it appears that I wrote my page using the name "Jeff Dutky" because that's what I'm usually called by others. The search using "Jeff Dutky" turned up my web-page in the top three results.

I still don't think that's good enough. I think that my personal web page ought to come up as the fist hit for my name, rather than some random usenet posting I made recently. I can understand why references to me in CaTB might outrank my personal web-page, but not usenet posts!

So, the question is, what can I do about it? I've pretty well ignored the recent discussions of google hacking, not to mention the O'Reilly book by the same title, so I'm not too sure how things like this are done. I know what just about anyone of an overly geeky nature knows about pagerank, but it's all generalizations and handwaving.

So, this is part of my half-hearted attempt to improve the page-rank of my page. I have no idea how long it will take, or if it will even work, but I suppose it's worth a try.

A couple of weeks ago a friend of mine gave me an old Athlon CPU chip he had lying around. It's nothing exciting (800MHz K7, 200MHz FSB), by objective standards, but when you compare to what I'm using as my current Linux desktop (350MHz K6), it doesn't look half bad.

I had been putting off building a new desktop until either the current crop of AMD goodness came down to my strike price (somewhere south of $500 for a base system), which didn't seem to be happening too quickly. In fact, as AMD's prospects have improved, their prices have risen. It had been so long, in fact, since my last system upgrade, that I was pretty much resigned to using my current machine until I could get a nice Opteron system second-hand. Having an Athlon CPU, admittedly outdated, in my hot little hand, however, changed my attitude.

A little bit of research revealed that there were plenty of nice motherboards on the market still that would support my old Athlon, some at absurdly low prices. I had the remnants of a friend's computer (the left-overs after I transferred all the important stuff to his new machine), and I meant to pull some other stuff out of my currnt desktop, so I would only need to buy a few components.

Here is the laundry list that resulted:

• Athlon Motherboard (EPoX EP-8K9A7I)
• 256MB DDR DIMM
• 60GB Hard Disk Drive
• Case & Power Supply
• CPU Heat Sync & Fan

The total price, even with shipping, came to less than $200, which was pretty hard to resist. I found out, later, that I should have ordered a video card as well: all of my current video cards are AGP 1x cards, and the motherboard has an AGP 4x/8x slot. I'll worry about that later, though, since I was able to scrounge a PCI video card for the purposes of initial assembly and software installation.

Which brings me to the subject I really wanted to write about: Linux distributions. I've been using Linux for about 8 years, though I was aware of it almost since day-1 (back around 1991/1992), and for most of that time I've been a slackware user. For two short periods, however, I had been using RedHat-ish systems. My first Linux installation was RedHat, and I used a Mandrake installation for a few years around 1999/2000.

I didn't like RedHat very much, too much custom crap, too many not-quite-unixy things, and RPM just drove me bonkers. Slackware was much simpler, more 'unixy' and packages installation, while tedious, was much less frustrating. I am, however, a fair-mineded fellow, and I thought I should give RedHat another chance. Besides, I'd seen some programs that looked usefull (e.g. Evolution) that really wanted a RedHat system to install on.

I went out to LinuxISO.org and had a look at some of the options. I wanted something that was reasonably up-to-date (i.e. kernel 2.6.x, XFree86 4.3.x or 4.4.x, GCC 3.2 or 3.3, etc.) and came with full installation on CDs (no live CDs with install off the net). I settled on the following three:

• Slackware 9.1
• Fedora Core 1 or Fedora Core 2 test 3
• Mandrake Linux 10.0

I downloaded ISO images for Slackware and both Fedora versions with few problems (I really need to install a BitTorrent client: sites willing to serve ISOs are getting scarce, and, when you can find them, the available bandwidth is pretty piss-poor), though the product web-pages were not as helpfull as I would like: Slackware's page pretty good, all the major ingredients are listed on the front page in plain english. The RedHat/Fedora page, however, is an exercise in evasion. The Mandrake page is pretty cluttered and it takes some work to find the technical specs.

Incidentally, there was another problem with Mandrake Linux: they don't actaully make their product available to the general public in a timely manner. I understand that they have a business to run, and I'm actually quite sympathetic to their financial plight, but they don't have the kind of market share that would allow them to artificially restrict the market for their product without further injuring their business. I'll probably shell out some cash to become a Mandrake club member, more because I want to support the company than to get access to their software, but it sure put a damper on my entusiasm over the weekend.

Again, what I really wanted to talk about was Fedore Linux, and how I was utterly unable to complete an installation of their product:

I burned a copy of the Fedore Core 1 disks and set to work. The first disk failed to verify during the installation process, even though the downloaded image's MD5 checksum matched what LinuxISO had posted, and the CD burning software said that the burnded CD verified against the image. I decided to ignore the installation process' warning and proceed, only to have the installation crap out while trying to unpack the linux kernal package.

Next, I burned a copy of Fedore Core 2 test 3. This time the installation process' verification phase said everything was peachy, but the process crapped out during package installation on some other vital package. Again, the MD5 checksums matched and the CD burner's verification had been good. If the Fedora folk can't get their act together enough to produce working ISO images, I don't have time to screw around with them.

This leaves me with the Slackware CDs. Since the machine is a home machine, I guess I can do without Evolution (I have no need to desire to be LookOut compatible at home), and I'm more comfortable with Slackware anyhow. Maybe, if my enthusiasm returns before I put the new machine to real use, I will join the Mandrake club and try Mandrake 10.0, but it's doubtful.

I tend to discount all the talk about how we need to make Linux easy to install. I don't think most users care about ease of installation. Most users never install their operating own systems: the OS comes pre-installed on the computer when they buy it. This weekend's esperience, however, has given me new appreciation for the argument. The Slackware installation process is pretty primitive, but even the Fedore install is a chore (pretty graphics not withstanding).

The same complaints I had 8 years ago apply today: there are too many choices that need to be made at installation (without even reasonable default values) and there too little immediate help with those choices (Slackware, for example, asks you to choose a kernel package from a list, but doesn't offer any description of what each package contains, aside from the package name: bare.i, bareapci.i, jfs.s, etc.). I'm not just saying that this is too much for novices to keep track of: even seasoned Linux veterans (like myself) are daunted by the task.

Anyhow, that's enough bitching for one day. I'm sure that some of my complaints are equally valid or other OS's (Windows, *BSD or MacOS X), and that some of my vitriol is run-of-the-mill Monday morning crankiness, but I wouldn't write off the entire rant on those counts. For all the progress Linux has made in the past decade, some of the worst problems have not been addressed.

I haven't done too much on the project since October of last year (the holiday season was pretty distracting), though I've put a little work into the power supply for the LCD. A friend, however, gave me a better name for the project than I am currently using: DayTripper, becuase the device is meant to be able to run for a full day (at least a full work-day) on a single battery charge.

At least I won't have to think too hard about what the product's theme music should be.

Success! I got the kernel to compile: all it took was a the right configuration options and a bit of manual fiddling (I needed to recompile mm/filemap.o to fix a mess of undefined references). After you've applied the Sharp patches for the LH79520 and LH7A400, you should be be good to go. If you run into probelms, however, the best advice I can offer is: 1) only select the configuration options you absolutely must have and 2) use the FastFPE rather than NWFPE (NWFPE didn't seem to compile successfully).

I haven't downloaded the kernel to the board yet, but at least it compiled. I need to read a bit about how to boot a linux kernel from the micromonitor.

In other (somewhat premature) news, I've ordered a bunch of hardware for a custom breakout board for the CSB335. I've also been looking into USB controllers. The ISP1161A1 and ISP1362, from Philips, look pretty good. They both support host and device modes, and they both have 16-bit bus interfaces. Connecting them to the ARM system bus shouldn't be too hard. The ISP1161A1 supports standard USB 2.0, while the ISP1362 supports USB-OTG.

Anyhow, assuming that the linux kernel boots and works minimally, the next task is getting the LCD connected. I've ordered the connector for the LCD data cable, now I need to generate the required voltages. Part of this can be done with a relatively straightforward switching power supply (the LCD drive power requires 42V), but the other part requires an inverter (the backlight CCFL requires 450V under normal operation and over 1000V to start up), which I can get either from ERG Power or, probably, pick up something acceptable from a a car or computer customization place (both of which sell cold-cathode lamps like the one used in my LCD backlight).

Not much new to report: I've been pretty busy with other things for the past few weekends, so I haven't had lots of time to devote to the project. I did get a Linux kernel that is supposed to work with the Cogent board (directly from Sharp), or, at least, with the MCU on the board (I can dummy up a driver for anything that doesn't already have something in the kernel tree). I've tried to compile the kernel a couple of times so far, with no real success, but I think I'm just a few configuration options away from a successfull compile.

Next up, once the kernel is minimally functional (booting to a serial console) is to build my own breakout board with some custom interfaces: Line Power and power supplies, IDE connector, LCD connector (for the LCD I have), serial and ethernet ports, a PIC MCU on the SBC's I2C bus, and, possibly, a USB interface hanging off the system bus. I'll do the board layout in the Douglas CAD/CAM program (I'm pretty familiar with it and they can manufacture the breakout board) and I'll give a try at stuffing and soldering the board myself (the SMT stuff, like the LCD and touchscreen connectors, might be a bit of a challenge, but if I can't do it by hand, I can always use this approach).