I have disappointed both my readers by not filling in yet another entry here.

This will be my lasting legacy.

Anyway. After this excitement, my em0 is still busted. I boot, start reading the code for the em driver and apparently the DUMB FUCKS who wrote it, namely Intel, map the EEPROM writable all the time. So one stray pointer in the kernel and your hardware is useless. Well, I was lucky enough that only some minor parts of the EEPROM were overwritten and after hacking the driver to forcibly update the checksum on next reboot it actually managed to come up and still work.

Now, this is a driver that Intel proudly gives away for free as some kind of flagship product saying "look how nice our code is". Does anyone actually believe that their closed blob drivers are any better?

This means that there is a running proc all the time, but that's easily solved by making the idle loop a proc with some special semantics, all MP architectures were allocating stacks for idle anyway, so the overhead is small.

Also, this change showed to me very simple ways we could vastly simplify locking of the scheduler data structures. Unfortunately, it would get too hairy to try to do those changes with ifdef, so I will not try to fix it all until all architectures have been switched to this mechanism. This will require all architectures to implement __HAVE_CPUINFO, but that is actually made much simpler since much less locore.s hacking necessary for CPUINFO and SIMPLE_SCHED.

After this is all done, we can start doing experiments with the scheduler, per-cpu run queues, different run queue schemes, more fair scheduling, scheduler classes, you name it.

Let's try that in practice, shall we?

$ cat > revoke.c
int main(int argc, char **argv) { revoke(argv[0]); }
$ cc -o revoke revoke.c
$ ./revoke
Segmentation fault (core dumped)
	

Hihihi. For me, it's like watching some old cartoon where the character is sawing off the branch he's sitting on.

$ sudo memconfig clear -o BIOS

Try it, it's fun. It's always fun to find obscure ways to shoot myself in the foot. The stranger, the better. The fewer people understand it, the more fun it is.

Don't worry though. The new disk is already making funny noises.

Try doing anything useful while having a chainsaw (both the sound and the pain) in your ear. And now I'm back to work and swamped already without doing anything interesting for two weeks. Thanks. I really feel useful.

Options are good. As long as they are optional.

I didn't do it! It's not my fault! These are not the droids you are looking for.

GRRR!

All this modularity and configurability only leads to one thing - shit doesn't work when you need it to. Plugging in a stupid keyboard isn't rocket science. Every fucking operating system out there supports it by default except Linux. When I plug in a usb keyboard or mouse into my laptop (no, it doesn't run windows) it's operational before I can move my hands from the cable. I can type on both the usb keyboard and the built in at the same time without restarting X or fiddling with the configuration anywhere. I can use both the clitoris on the laptop and the usb mouse at the same time without causing confusion. And I've been able to do this for _years_ on the operating system that's considered to be one of the _least_ "user-friendly" on the free software market. And I didn't even consider the need of building a custom kernel, the default just works. Btw. did I mention that pcmcia, cardbus and apm all work on the laptop without any configuration or other effort? Just plug in the wavelan card, type "dhclient wi0" (yeah, yeah, that should be automated) and I'm up.

I just don't understand how people even consider selling crap like this to end users. Want to get the same reputation as Microsoft got when they started to talk about "user friendly"? To any unlikely real developer of Linux who reads this, here are some tips:

• Things should work by default. The user should never be required to be aware of how kernel modules work (oxymoron in the same style as "Microsoft Works"), the user should never have to build the kernel. Actually. The default kernel should be good enough that rebuilding it should be more likely to degrade the performance than to improve it (where performance is much more than squeezing out the last cycle from the idle loop). I don't know how you can achieve it, but looking at the GENERIC phiolosophy in OpenBSD is probably a good idea.
• Hardware should just work. I'm really not interested in finding out what mouse protocol my mouse supports. Just invent some stupid generic event interface and let the kernel translate ps/2 mouse and keyboard events and usb events into that generic interface. wscons in OpenBSD and NetBSD is your friend. And guess what? wscons works on i386, alpha, sparc, powerpc and tons of other architectures. And it provides the same interface to userland for all architectures. Suddenly the code in X will just work and break on all architectures at the same time. Without duplicating 4711 different drivers all over the place.
• pcmcia and cardbus? Look at bus.h in NetBSD. It might not be the best interface performance-wise, but it really, really, really makes it trivial to add new hardware and bus support to the system. The same tulip driver is used for pcmcia, cardbus and pci. That has to be worth something? I don't really care about saving two minutes a month on faster leeching of porn or warez (or whatever people optimize for) when I have to waste several hours or even days a month to find a working driver because someone added an optimization that works on revision 1 of a chip, but not revision 2. Optimize your life (other way of saying "get a life") instead of doing all that shaving of cycles.
• Screw configurability. The ability to shoot yourself in the foot is not the same thing as forcing the user to do things to stop that anvil from falling on his feet. Make things work, then add modularity, configurability and tweakability. When you have things working, you'll soon realize that this fine configurability and modularity isn't worth as much as it sounds. Modularity (the lack of it) is probably fun to rant about, but it rarely solves more problems than it introduces.

Getting things to work instead of wanking isn't really rocket science.

If only I'd get paid for this too...

	With that skill that was hers alone
	She drove her clutches into me
	I was dumbfounded
	She was hungry
	She required me entirely

	All that's left is here to remain
	It's a dull and cruel pain
	That passes the ages unaltered
	Her stamp is in my heart
	I still feel disemboweled
	I clearly retain
	A blank
	The void
	The sore in my soul
	The mark in my heart
	Her acid reign

	Hot sun, global fun
	Needed action, start to run

	And that voice that was hers alone
	Still resounds in me
	She left me dislocated
	Disavowed
	And twitching
	Her rhythm is in my heart
	She inspired in me
	An acute sense of treachery
	

If we're making so free software, why are we playing all those word games about licenses? Is your "free" longer than my "free"? I'm now strongly considering (meaning: I will spend a few days thinking about it heavily) placing all my code into the public domain. At least there is something that can't be legally misunderstood (although there are a lot of morons out there that don't understand that Public Domain means that they can't set _any_ restrictions on how the software is used).

Do we really need huge documents crafted by lawyers to tell each other: "We come in peace"?

And they all died unhappily ever after.

So I spent a whole night looking for a better name. I dug through various names of Aztec Gods, Mayan, Incan, Egyptian, Sumerian, etc. mythology, various other resources that contain random words that could potentially be used as a name for a project, including a Latin dictionary, various lists of Latin words, other languages, I found the very cool Internet anagram server to try to find some random word or phrase that sounds good. Nothing. The only thing I found out is that all the good names are already taken, lots of the bad ones too.

Since I really suck at naming things and I know it, I left the issue unresolved until breakfast when by an association in a conversation about the complicated process of giving something a name I found a name that actually sounds good, feels good and is consistent with my somewhat bizzarre fascination with tractors. The person I was talking to was very happy that I used his name, although translated to Latin, for my project.

No, there is no reason to mention it here. It doesn't matter anyway.

Of course the first thing to do to confuse diffing is to reindent the whole code. I didn't like the indentation style of the original code and it wasn't as if I planned to submit back the changes since I didn't plan to make any relevant changes, just play around a little. But accidents happen and suddenly I realized that on at least two of the branches of the code I was doing really useful changes. Instead of backing off and starting to work on the real thttpd, I was fixing stuff on my messed up branches that could never be sanely submitted to the maintainer. ahttpd was born. I decided to continue working on the code whenever I felt like it, without any obligations and without caring what would happen with the code when I didn't feel like fiddling with it anymore. Thus came libevent-ification that removed tons of unnecessary code while making the rest much more efficient (removing lots of bugs in the process), then I decided to learn lex (which I've never managed to do before) to implement some kind of configuration file, then the web server became actually useful and I started using it on my own web server.

In the past few days I made even more interesting changes, like much more flexible configuration (in something that resembles XML, yeah, yeah, so sue me), various nice optimizations of the code, removal of static configurations and now I know exactly how to implement proper support for various features that would be nice to have, like php support and proper ssi, even more flexible configuration, etc.

This was never supposed to happen. I just wanted to test OpenCM (note - the code is in CVS now because OpenCM decided that it doesn't like me since I haven't upgraded in small steps). Instead I got a really useful web server that will fullfill all my needs while being more efficient than most other servers out there.

And it wasn't even complicated.

Good thing that I have enabled proper logging (as opposed to only 6 hours of logs) on the web server.

This might get interesting.

Why do people use bloated monsters as tools?

Now, some might argue that I'm a pedant because I whine about keeping the code nice and tidy. Who cares if it looks nice as long as it works, right? Sigh. Wrong. Anyone who has half a clue about making code that does something (as opposed to general wanking just to show off or to satisfy some urges) knows that much more of the time in a project is spent on debugging, not the actual act of writing code. Most people just turn on the debugger and hope that it points them to the line of code that's bad. When that doesn't work, spend a few k$ on some more advanced debugging tools and hope that they point them to the bad line of code. Just look at what Purify does, it performs vast amounts of magic just to find out where a memory location was touched and then provides you with a long list of those source code positions. The average programmer would be helpless without this amount of hand holding. If those tools don't help, insane amounts of time are spent on inventing workarounds or simply documenting away the bug. All this is done just to avoid what every programmer should spend most of his time doing - reading code. Code should be read and the read again, then tossed away in a dark corner to mature for a few days or weeks or even months, then read again, read, read, read. A good programmer should know every intricate detail of the code, every strange word used in comments, the layout of the comments, etc. Reading is also a great opportunity to reorder code - "Hmm, this variable assignment isn't used until much later in the function and everything would make much more sense if it was close to where it's used.", to fixup comments that don't really make sense after you've had some sleep and a coffee or two, and to actually spot the stupid minimal bugs that maybe even don't matter right now, but maybe will bite you hard in a month or two.

I've lost count how many bugs I've fixed in my and other peoples projects just by reading the damned code. And I fixed even more when restructuring code to make sure that if follows my own guidelines for indentation, variable naming and general formatting. When you get used to look at code that looks the same way every time (because you make sure that it looks the same way every time by formatting it to fit your standards of beauty), small bugs that are almost invisible in chaos suddenly have huge signs over them screaming: FIX ME!. The blob of organic pattern-matching hardware we have inside our skulls is really neat, it actually sees patterns and reacts to things that look almost like a known pattern, but not really. I've fixed numerous security holes, potential crashes of critical software, minor bugs, major bugs, memory leaks, performance issues (I changed a central algorithm from O(n^3) to O(n*lg n) in a cpu-bound application just by fixing up indentation and realizing that a couple of loops were incorrectly nested).

Now that I think about it. Maybe most programmers aren't morons, maybe they just don't care.

The end seems like a good start. To start something you have to end doing something else. Or at least you have to end not doing what you just started doing. It also gives me a very valid excuse to tell people who could get surprised about me writing something that could be considered to be a blog.

I can just point everyone to this place and show them that I'm done, I've already written the end.