First, a note: my system hard drive is actually an 8 GB CF disk, because I'm way too cheap to get an SSD. Programs load really quickly, but writing to it can be really slow, so I try to keep write-mostly stuff off of it in general.
SquashFS portage tree
The portage package tree is made up of about a squillion tiny text files, and it's mostly read-only - it's basically the ideal use case for SquashFS. I've combined it with unionfs to make a fully read-write portage tree that only takes up 32 MB, instead of hundreds.
SquashFS is included in the Linux kernel now (gzip compression only, though - not a huge deal), but unionfs isn't. You'll have to grab the patch from here. Apply it with "gunzip unionfs-whatever_for_whatever.diff.gz | patch -p1", if I recall correctly. Then enable SquashFS, unionfs, and tmpfs - I'm assuming you know how to build a kernel, not gonna get into that. You'll also need sys-fs/squashfs-tools installed.
I use a few incredibly trivial scripts to manage this; you can get them here. To get started, run make-portage-snapshot.sh, which clones /usr/portage into a new SquashFS image, called portage-snapshot-new.sfs. Then, create /mnt/portage-ro and /mnt/portage-rw. My setup has a read-only mount of the SquashFS image in -ro, and a tmpfs mount in -rw. Next, rename portage-snapshot-new.sfs to portage-snapshot.sfs, and run mount-portage.sh. If all of this went smoothly, you have a fully-functional copy of the portage tree at /usr/portage. If so, run umount-portage.sh, wipe the portage tree, and mount the unioned portage tree again. Congratulations, you have a few hundred MB extra disk space! To update the SquashFS image, just run make-portage-snapshot.sh again, unmount portage, and then replace the old snapshot with the new snapshot and remount.
For bonus points, you can drop the ChangeLog files from the tree, since portage doesn't actually use them - they're just there because they're sometimes useful. Add the following line to your make.conf:
PORTAGE_RSYNC_EXTRA_OPTS="--exclude ChangeLog --delete-excluded"
and then sync your portage tree again.
Moving stuff to /tmp
One thing that kind of sucks about Gentoo is having to keep an eye on /usr/portage/distfiles and /var/tmp/portage. I would guess that a lot of users don't even know that you have to, which ends up leading to a lot of wasted disk space. I solved this by moving both of them to /tmp, which (if you have WIPE_TMP enabled in /etc/conf.d/bootmisc) is wiped automatically at every reboot. The following two lines from my make.conf are the only configuration necessary:
PORTAGE_TMPDIR="/tmp"
DISTDIR="/tmp/portage-distfiles"
Another benefit of this: I'm one step closer to being able to mount /usr read-only! Which I'll get around to doing someday, I swear. >_>
Mounting by UUID
Know what sucks? Getting a new hard drive, or a new version of udev, and suddenly having all your disk devices under different names. None of your filesystems will mount! You have to go through them and fix all the entries in /etc/fstab! Oh noes!
Luckily there's a solution: you can list your filesystem UUIDs in fstab instead of your device names. Let's start with this:
/dev/hdb1 /home ext4 defaults,noatime,data=ordered 0 0
You can find the filesystem UUID like so:
$ ls -l /dev/disk/by-uuid
total 0
lrwxrwxrwx 1 root root 10 Jan 17 15:24 0f36c009-feff-4271-866d-a8796f5c92a7 -> ../../hdc2
lrwxrwxrwx 1 root root 10 Jan 17 15:24 1cb3076f-94ee-4a02-ab01-6186aaeb429a -> ../../sda1
lrwxrwxrwx 1 root root 21 Jan 17 15:24 43dd79e6-af80-4791-938b-0a53f4d6d645 -> ../../hdb1
lrwxrwxrwx 1 root root 20 Jan 17 15:24 902c0d0b-b184-4571-90c3-246f6664e7cc -> ../../hdb2
lrwxrwxrwx 1 root root 10 Jan 17 15:24 cbdcbf38-c8f3-4b32-82f1-26ebb7245273 -> ../../sdb1
We're looking for hdb1, so the UUID for the filesystem is 43dd79e6-af80-4791-938b-0a53f4d6d645. Then we can slap that into the fstab:
UUID=43dd79e6-af80-4791-938b-0a53f4d6d645 /home ext4 defaults,noatime,data=ordered 0 0
...and the system will find that filesystem no matter what the drive it's on is called.
Alternate keyboard layout
I use the Colemak keyboard layout, and switching was kind of a pain. :( You have to configure the console and X separately.
Console: Download this tarball, grab colemak-1.0/linux_console/colemak.iso15.kmap from it, gzip it, and drop it in /usr/share/keymaps/i386/colemak/ (which you'll have to create). Then, set:
keymap="colemak"
in /etc/conf.d/keymaps.
X: It used to be enough to set "XkbLayout" "us(colemak)" in the input section of your xorg.conf, but then they went and rewrote the configuration for Xorg completely. Awesome! For Xorg with HAL, save this file as /etc/hal/fdi/policy/10-x11-input.fdi, and you should be good.
Apparently, they're rewriting the configuration system from scratch again for the next version of Xorg. I can't wait to see what I have to do to be able to type with Xorg+udev. :-/
Default applications
There are two complementary approaches I'm experimenting with right now for default applications, because I don't especially trust gnome or KDE to get it right.
First: I have a symlink in /usr/local/bin that points to my current browser, and an eselect script which manages that symlink. I can then point all my applications at "browser" as the default browser, and control it pretty easily. Next best thing to the OS actually having some way to set a default browser built-in. This is pretty similar to debian's /etc/alternatives thing... actually, hmm, it's basically identical. I should look into this. >_>
Second: I've written a tool which can automatically find a program that supports a given file, and open it. I'm still not terribly fond of the configuration system for it, but it does work, and if I set it as the handler for a given file type in all my programs, I can change the program used to open that type in a single place, instead of doing it everywhere.
Automatically mounting external drives
Last I checked, there's no good way to do this that doesn't involve using gnome or KDE. halevt is a mostly acceptable solution, but it has some annoying quirks, like absolutely refusing to mount drives that are listed in fstab. Not only that, it's doomed in the long run, thanks to the inexplicable and premature deprecation of HAL. (2006: "Everybody, use HAL! It will make everything awesome!" 2009: "Guys, it turns out HAL is terrible! Stop using it immediately! Also, we've got this new thing called udev - it'll make everything awesome!")
Actually, I'm not even sure why I'm mentioning this, except to be bitter. Thanks, Gnome and KDE, for your tremendous contributions to Linux UNIX free software Gnome and KDE!
No comments:
Post a Comment