Edit: I’ve locked this post since it’s outdated now, and the newer version of the howto is available. And some of these things changed from Herd 3 to the final release, so it’s inaccurate in places.

Since the release cycle is halfway through, and since Herd 3 looks more or less “stable,” it’s probably fair to start tweaking it, and seeing how it responds.

I suppose this isn’t much of a howto, really, since it’s primarily a rehash of standing Edgy tweaks, with lip service given to the fact that I’m using a slightly newer version. It shouldn’t surprise you that most of the Edgy tips, thus far, stand tall for Feisty.

This page won’t walk you through by the hand. For a complete step-by-step guide, dig up that Edgy page. There’s a list of top posts on the right; it’s usually in the top three.

Remember that the standard disclaimers still apply:

1. This is mostly aimed at the 1Ghz and below crowd.
2. Your mileage may vary.
3. I am not a Linux expert.
4. You might really hose your system doing these things.
5. Speak up if you have an idea.

The test machine is my banged-up, beaten-up, battered-around 300Mhz Pentium II. It’s old, it’s ugly and it’s fantastic. See my Arch blog for reasons why.

Blank the drive

Start clean, people. It’s worth it.

Partitions

Feisty wants to assign all my hard drives (and other drives) sdXY identifiers, which is probably okay. It does require a little getting used to, particularly if you’re like me and you are used to typing hda all the time. This is how I build mine:

/dev/sda1 Primary 96Mb Linux Bootable (/boot)
/dev/sda2 Primary 4096Mb Linux (root)
/dev/sda5 Logical 512Mb Linux Swap/Solaris (swap)
/dev/sda4 Primary ~Gb Linux (/home)

I still believe a ~100Mb ext2 /boot partition is the way to go. The uber geeks insist that a small, ext2 partition mounts faster and needs no journaling, and that will improve boot times. It also frees you up to use XFS or another Grub-unfriendly filesystem for root.

Filesystems

If you’re working on sub-1Ghz machines, I still strongly endorse ext3 with dir_index as a file system. You get the best of both worlds with this: low CPU overhead, some data reliability and minimal IO delays.

It also looks like this feature didn’t make it into Feisty as default … unless someone sees it in place after a default partitioning scheme. I didn’t. I did notice that the installer doesn’t squawk when it runs into the dir_index flag any more.

If you’re on a sub-400Mhz machine, you might be tempted to go straight ext2. I can see the benefit in that, since you’re working with equipment so old as to need every available ounce of processor and IO space. To heck with the journalling. I’m with you on that one.

Filesystem tweaks

journal_data_writeback, noatime and elevator=cfq (which isn’t really a filesystem tweak, but what the heck) all still work fine.

As an afterthought, I would leave the elevator queueing tweak off the alternate boot option, since you’re using that as a recovery mode. The rootflags=data=writeback has to stay there though, since it’s telling Grub to expect that journal_data_writeback tag. It might behave funny if it isn’t warned.

And remember to keep the single, initial hash marks on the defoptions and altoptions lines. 😉

Concurrency

There is still a concurrency option inside /etc/init.d/rc, and it still has a huge effect on boot times. Set it to shell for best results … even if they are sloppy.

Processor-specific kernel

Feisty uses the same nomenclature as Edgy: generic SMP is installed by default, 386 is installed if you need Nvidia support, and so forth. If you need a processor-specific kernel, check the package search pages. Personally, I haven’t seen much of an improvement between kernels, but that might differ for you.

And if it’s that big a deal for you, recompile one that fits your hardware. That’s where you’ll see a big improvement.

Unused packages

ubuntu-minimal and ubuntu-standard still contain some packages that might or might not be of use to you. For me, I threw out pppconfig, reiserfsprogs, wpasupplicant … and some others. You’ll have to check those two metapackages and see what was installed. If it’s of no use to you, throw it out and lighten the load. Will it have a huge effect? Only if you’re on a 75Mhz Pentium.

Prelink, preload and readahead

The unholy trio is still in Feisty, and still influence booting and loading times. On very slow machines, like 300Mhz and below, you might be adding to the workload in an effort to speed up the process. In other words, make sure readahead and preload aren’t making things worse.

Services

sysv-rc-conf is still useful, and tampering with the runlevels and start sequences is still very useful. Both work the same under Feisty.

Sysctl.conf

Remember that if you’re not on broadband, it won’t help a whole lot to tweak your network for broadband. It might make things worse.

vm.swappiness on machines with less than 128Mb is probably a bad idea. Make sure you can afford to turn it off before you do.

Disable ipv6

I still do this. I hate that half-second lag. I can’t imagine what it’s like on dial-up. (Shudder.)

Installing the system

Remember that x-window-system-core in Dapper is now xorg in Edgy and Feisty.

Reoptimize directories, reprofile boot

This and the concurrency trick are still my favorites. It’s worth the extra reboot to reoptimize and reprofile. You’ll be glad you did.

Remember that if you’re not using ext2 (or ext3), you won’t need this step. But you will want to reprofile.

Some added stuff

It’s worth installing localepurge to keep the ballast trim, especially if you’re working with minimal hard drive space. If you’re on anything with less than 4Gb total, DO IT.

deborphan and debfoster are also useful for plucking out packages that aren’t doing anything.

PCMan‘s trans-purge, mime-purge and gconf-purge are also worth installing, although you have to build them from source, and that might be intimidating. (It also means installing build-essential, so don’t forget to un-install that when you’re done or any space you saved with those three tools was negated when you added the 140Mb or so build-essential took up. 🙄 )

If you can do it, put your swap partition on a separate drive. That’s a simple fact of hardware: Your system can access both drives separately quicker than it can access the same drive with an additional workload. Got it? Do it.

Ramdisks. … Well, you tinker with that one and see if you get anything out of it. It might be useful for old, old machines with rotten access times. If you’ve got a 120Mhz machine with 64Mb of memory … sure. Otherwise you’ll have to try it yourself and see.

Nvidia users can disable the startup logo, overclock their cards and even manage some screen effects through the xorg.conf file. Look into that if it applies to you.

Xscreensaver: I avoid this like the plague, especially on older systems. Outside the K/X/Ubuntu suites, it actually makes more problems than it solves. It is set up with enabled screensavers that aren’t installed, and the first time you open the preferences dialogue, you’ll be hit with a dozen error messages telling you /usr/share/backgrounds doesn’t exist. Add to the fact that it’s another daemon waiting in the background, pulling on your system load. … No thanks. I just set the screen timeouts in X and let this go. Don’t do it, people. I like Noof too, but I save it for the 1.4Ghz Celeron in the next room.

Netboot installations are even cleaner than installing from an alternate CD, but they take longer and aren’t necessarily an improvement. Save it for the machine with the flaky CDROM but a fast ethernet connection.

DHCP is slower than a static IP address. That should be self-explanatory. DHCP means your computer has to ask the router for an address, whereas static means your computer barges in and says, “I’m here!” If you can get away with it, go with static.

Font smoothing is accomplished through a .font.conf file in your home directory; you’ll want that if you’re setting up a GUI from scratch. Otherwise, your fonts look a little smeared.

Remember that alsa-mixer is a viable way of controlling the sound, without a GUI package. No added packages, no added weight, and it was free with alsautils.

If anyone has gotten hdparm to do anything useful, let me know. I’ve tried it on three or four different machines with three or four different hard drives and by following three or four different guides, and I get no real improvement out of it.

Autologin is still the way to go. Don’t use a *DM, either: It’s an added weight and does nothing for your system load or boot time. Either log in at the terminal prompt and start X manually, or compile the autologin script and have the entire business taken care of in about a second.

Extra tty consoles … I’m of a mixed opinion on this. A lot of people seem to think it’s a drag on the system to have those extra tty terminals hanging useless in space. I would agree with them, except they don’t seem to make that much of a difference to me. And as an added quirk, if I’m using a really slow system, like 200Mhz or less, I’d rather use a tty than a terminal emulator. But that’s just one guy’s opinion. 😀 tty1 through tty6 are still in /etc/event.d, if you want to take them out.

Finally, a word to the wise.

Let’s be honest, people. If you can get through this monstrous list of tweaks and tune-ups, and you haven’t gone mad with all the effort and time it takes to get things going at an improved pace, and you’re not daunted by possibility of something going wrong … the question arises: Why bother?

Ubuntu is all about usability. It’s about Linux that works on the first try. It’s a distro that features some of the best autoconfiguration and autosetup you can get. It (usually) takes almost no effort to get going, and it’s not going to fight you every step of the way. But it has a shortcoming, and that’s what I, personally, have learned from all these tweaks.

It’s not about speed. It’s a little plump. It’s meant for modern machines with modern hardware and modern interfaces. Sure, it’s flexible and mild-mannered, but it’s no star athlete. It’s not going to set any speed records.

If you’re really keen on speed — like I am — go with something else.

If you really want Ubuntu, it can be done. You can install this on machines as far back as the 486DX series and probably get away with it.

But is it fast? Only to a point. There’s an asymptote for each distro and each variant that limits how much and how fast you can push it before you’re expending more effort than it’s worth. Ubuntu’s event horizon, for what I’ve seen, falls around the 500Mhz point. After that, there’s only so much you’re going to get out of it.

Linux is linux, whether it’s Ubuntu or Debian or Slack or DSL or Zen or Gentoo or Sabayon or Arch or what have you. You’re not abandoning the Ubuntu team by putting a different distro on your old K6-2 450. You’re not committing heresy by installing a one-floppy distro on a 386.

And if it makes you feel better, there are theme packages by the dozens that will make a Zenwalk desktop look like Xubuntu, or make Ubuntu look like Foresight, or Fluxbuntu look like Dreamlinux, or make Arch look like Sabayon.

That’s the beauty of it. No matter how we get there, we’re all going to the same place. So don’t spend hours and hours trying to tweak your system to get that last split-second of boot time trimmed off. Spend the time making your system happy and pretty.

And now, having said that, I’m going to put Arch back on my little 300Mhz Pentium II. I’m sure I can get my boot time down to 36 seconds. 😈