EEE alternate OS installation plan

Constraints:
4G SSD
No optical drive (for install)

Requirements:
Should boot similar speed to default OS (10-15s on 630Mhz Celeron)
Reasonable wireless configuration tools

== Filesystem ==

Apparently reiserfs saves almost 200M in filesystem overhead. Plus it should store small files more compactly... but my calculations suggest journaling may be a bad idea, as confirmed by Asus choice to avoid it (mounting as ext2):

Maximum write b/w: 10Mb/s
Maximum reiser journal size: 127M (32749*4096)
SSD Write cycles: 100_000

Wear leveling will have very little effect. Typically wear leveling occurs in zones of around 4mb, and I assume this is contiguous (and so is the journal).

Now we should halve the bandwidth, since journal writes are accompanied by normal writes.

100_000 / (5Mb/s / 127M) = 100_000 * 25.4s = 2.54 mega-seconds, = 29.4 days.

This is absolute worst case - reiserfs only journals metadata, and it's not clear why one would generate 5Mb/s continous metadata writes without any data writes. But it looks better avoided. ext2 for me.

== Boot speed ==

Looks like Puppy linux might be good.
Alternatively, hibernation. Use swap file for flexibility (can resize). uswsusp can do compression for even more speed.

Boot times (Ubuntu)

I've been playing with bootchart (which I was very impressed by). I thought I should share my findings about boot time.

The biggest improvement came from generating a boot profile (booting once with the "profile" option), so that readahead worked well on my system. I found compiling a custom kernel to work _without an initramfs_ also had a significant effect. But I also found a couple of other tweaks which can save a second or two:

console-setup

ckbcomp is run by setupcon each boot (twice) to generate a keymap for the console, using the X keymap files. This takes a reasonable amount of CPU; it can take almost a second to run during boot. setup-con had already saved the generated keymap - this is done when the console-setup package is installed/reconfigured (or when "/etc/init.d/console-setup restart" is run manually). Unfortunately it only used it if /usr wasn't (yet) mounted. It wasn't immediately obvious how to make it do the right thing, so I just hacked it to always read my saved keymap. (It's a hack because I commented out the code which would regenerate the keymap if the configuration changes)

hwclock

hwclock is invoked twice during the boot process, from hwclockfirst.sh and hwclock.sh. Unfortunately it waits for the next second boundary before it reads/sets the clock. In other words, whenever it's run it will take an average of half a second. Two observations here:

1. This really ought to be run in parallel with something, rather than blocking the entire boot process. I enabled concurrency=shell in /etc/rc, renumbered the boot script to run in parallel with keyboard-setup, and removed the ".sh" extension which also prevented hwclock.sh from being run in parallel with anything else.
2. When built for a 64-bit intel system, hwclock does not trust RTC (hardware clock) interrupts. This means it has to _busy wait_ for the next second boundary, which consumes 100% CPU, slowing down the boot and generally looking stupid. I think it should trust the kernel - I patched it to use RTC interrupts and it worked just fine. This should be a low risk change: in the worst case it will time out and continue after waiting 5 seconds for an interrupt.

To be more specific: the kernel should return an error if it does not support RTC interrupts. However, on 64 bit intel systems hwclock does not trust the kernel to do this, so it always has to busy-wait.

 /* Turn on update interrupts (one per second) */
#if defined(__alpha__) || defined(__sparc__) || defined(__x86_64__)
/* Not all alpha kernels reject RTC_UIE_ON, but probably they should. */
rc = -1;
errno = EINVAL;
#else
rc = ioctl(rtc_fd, RTC_UIE_ON, 0);
#endif
if (rc == -1 && (errno == ENOTTY || errno == EINVAL)) {
  /* This rtc device doesn't have interrupt functions.  This is typical
     on an Alpha, where the Hardware Clock interrupts are used by the
     kernel for the system clock, so aren't at the user's disposal.
     */
  if (debug)
   printf(_("%s does not have interrupt functions. "),
   rtc_dev_name);
  ret = busywait_for_rtc_clock_tick(rtc_fd);

paranoia: "Use your CDROM drive to read audio tracks.... and have it actually work right!"

For some reason I use the latest testing version of cdparanoia (which hasn't been updated for a while now -

cdparanoia III release 10pre0 (August 29, 2006)

I think this is because the stable version, 9.8, wasn't being paranoid enough on recent versions of linux where my cdrom drive gets treated as SCSI, in some strange way. (It's a standard ATAPI drive). I was getting different results for rips of the same track, which is what paranoia is supposed to avoid.

I do cmdline ripping, no fancy tagging. I don't know whether the GUIs are paranoid enough, and its nice to know whats actually going on. Recently I've been using "picard" to add tags afterwards.

---
DEV=/dev/cdrom

# cd -> audio_??.inf audio.cddb audio.cdindex
icedax -device $DEV --info-only --cddb 0

# cd -> track??.cdda.wav
cdparanoia --force-cdrom-device $DEV --batch --abort-on-skip

# *.wav -> *.flac
for i in *.wav; do flac --best --replay-gain $i; done &

# *.wav -> *.mp3 (includes fast replaygain as standard)
for i in *.wav; do lame --preset standard $i; done &

A new years resolution

To log my tech experiences.

This is for purely selfish reasons, of course. Next time I re-install, I'll have my hacks and recipes recorded.