- Never do a kernel recompile and update at 3:00 in the morning
- Don’t forget to copy your System.map file over to /boot
- Devfs requires symlinks to be made to “normal” device names. As such, you’ll have issues since /dev/mixer or /dev/misc/rtc don’t exist.
Good things for me….
- Although a patch existed to recognize my floppy drive with the 2.4.x series kernels, I was never able to get it to work (i.e. I patched the kernel properly, but no luck). My floppy drive now works.
- Significantly improved interactivity. I can now run a webserver, Seti@home and work on my normal everyday apps without _perceptible_ lag. However, I haven’t truly stress tested the system yet. I will leave it on for a couple of days and see how it responds. So far, I am pleased. The window system feels much more responsive. For example, while doing all the above, I can switch from viewport to viewport without delay…(although that might be cause its not reading from cache…) Actually, let me be honest, the more I work with it, the more excited I am. The system is feeling very, VERY responsive! :)
Of course, there are a number of other core improvements including the O(1) scheduler, much work done on the kernel to help with threads (happy because my Apache is using threads) and much _much_ more.
Of course there are problems…
- Weird problems under heavy IO load. A ls on /dev stalls while simulatenously doing a dist-upgrade. Vi stalls (?!) while reading /var/log/messages
- I would like someting _like_ devfs, but simpler and cleaner. Which means, that when I specify certain modules to load, and I have x hard drives and so on, all these nodes are automagically created in /dev. I do not want a listing of every single possible device node in /dev (for example – I don’t have SCSI drives). I also don’t want to have to deal with arcance devfs config files.
I’ve heard rumors of a userspace device file system but I don’t know if it will solve these problems. Ideally application developers will move to using the dynamic device system. Who knows.