Design cleanup

Having partially read the first chapter of the excellent The Art of Unix Programming, by Eric S. Raymond, I've been thinking more about the design of mod-boot in terms of simplicity. One portion that called attention to itself was the blockList concept that I explored in an earlier post. It's an interesting concept I think, but it adds a lot of code that 99% of the time will only end up taking up more memory. It would be simpler and in most cases faster just to use either a standard array or a GArray or something.

Also, I've been thinking about the concept that if a program doesn't have anything helpful to say, it should just shut up. I'll have to work on this aspect, but it'll have to give what the user and other programs need; nothing more, nothing less (Good: Fedora. Bad: Debian. Worse: Slackware).

There's other matters I shall have to look in to as well to simplify the project.

blockList

I hit a wall recently with mod-boot. Basically, when I parse a script file, I need to be able to store all the data given. However, I don't know before-hand how many dependencies the script will have, or how many features it provides. I could use a standard array, but that would be inefficient since I would have to allocate like 25 memory slots of which I might only use 3, and if something needs more then 25 slots, well, that's tricky now ain't it? I could use a GArray, which is a handy little feature of GLib, but unless I'm wrong, whenever you exceed your allocated memory, it has to allocate more and copy everything over, which gets inefficient, and if it works like the C++ STL vector template, then I'm still wasting a lot of memory. I could use a linked list, but that's slow to loop through.

Hence the need for blockList. Basically, it's a doubly linked list implementation where each node has an array. When you first create the blockList struct, you give it a number of bytes per array element (as with GArray), and a default number of elements per blockListElement (basically a node; I should rename it). It then keeps track of the number of blocks currently allocated, and the address of the first and last nodes, so that it can get to any given element as quickly as possible. The programmer can of course manually allocate a block with X elements, but that should also be handled transparently when an element is appended. It's currently not yet finished, but it's getting there. And it's fully 100% memory leak free, too!

Of video card drivers

Those who don't use FOSS operating systems likely aren't aware of the many troubles we have with our uncooperative video cards. It is common knowledge in the shared intelligence of the FOSS community that in terms of Linux support that Intel and VIA have more or less perfect out-of-the-box FOSS drivers, that nVidia has reasonably good Linux drivers (but only closed source, so many vendors can't use them), and ATI has the spottiest Linux support.

This situation, I'm glad to say, is about to come to an end. The nVidia driver is being reverse-compiled to create a better FOSS driver called nouveau (however, it seems to be coming along slowly, and my last test with it found that it's rather slow and buggy), and following AMD's buyout of ATI, ATI has started paying much more attention to Linux drivers. This came to a climax recently, when AMD officially announced that they're going to start releasing specs for their drivers and hiring people to work on a full FOSS ATI driver. This is expected to be finished by March 2008, in time for Linux 2.6.25.

In summary, w00t!

Game show idea

I had an interesting idea for a gameshow today. Basically, there's two or so contestants, each with a whiteboard, a marker, and nothing else. Then, the host then gives them a programming problem, and they have X minutes to design the needed data structures. Whoever has the simplest, most efficient, data structures wins the round.

Hey, I'd want to watch it...