Article posted on Nov 1
About two weeks ago, I had surgery for a somewhat serious injury. The weeks leading up to and since the surgery have given me a lot of time to work on personal projects (for the weeks before the surgery I was on strong painkillers which messed up my sleep, often keeping me up in the middle of the night, and the weeks since have been in recovery), which let me get Finnix 106 out the door earlier this week.
It has also given me time to make some long-desired architectural changes to the development environment, beginning with Project NEALE during the Finnix 105 development cycle. Here is a short update of what's changed lately.
As part of Project NEALE, all components of Finnix not contained in the compressed root (the CD layout, initrd, kernel and miscellaneous files) are now stored in udeb packages (neale-master, neale-initrd, neale-kernel and neale-stuff, respectively), which are extracted as part of build-neale. The method is slightly unusual; for example, the neale-kernel and neale-initrd source packages contain sources, as well as pre-built binaries for all supported architectures. But the net effect is all non-Debian sources are now contained in packages at archive.finnix.org. If you need the sources for a Finnix kernel from 106 onwards, grab the source package for neal-kernel.
Through Project NEALE, Finnix now has support for building ISOs with AMD64 userlands. While Finnix will not be releasing an official ISO with an AMD64 userland (for reasons explained on the Project NEALE wiki page), it is a testament to the versatility and abstraction that NEALE allows versus the old, manual method of assembling releases.
Packaging for all Finnix packages are now being managed in version control via bzr on Launchpad. I sent a mail to the debian-derivatives list recently, detailing my experiences in undertaking this.
The archive at archive.finnix.org is managed by a tool called reprepro, a mid-end system for managing Debian-style apt repositories. I have written a plugin for reprepro, which takes source uploads, scans for changelog entries with "LP: #12345" (the same format Ubuntu uses), and will update the corresponding bug's status, add an "archive-fixed" tag, and add a comment with a copy of the .changes file. This is similar to what both Debian and Ubuntu do on their respective bug tracking systems.
And example of a recent Finnix bug fixed by a source upload is here. Originally the plugin was specific to Finnix, but I have expanded it to be a general purpose tool. So if you manage an apt repository with reprepro and also use Launchpad for bug tracking, this tool may be of use to you.
Article posted on Dec 12
I am experimenting with tracking development on Launchpad, specifically bug tracking and new features. A number of bugs have already been filed for the Finnix 104 milestone. If you have a bug or a feature request not already listed, please file a bug through the Launchpad interface.
The mailing list will continue to be the focal point of Finnix discussions, and Launchpad will not be used for things like package management. Still, it's already proving to be a decent bug tracking interface, and beats the method used for the previous 12 years (namely, a text file in a screen session on a development machine).
Article posted on Jun 30
In my previous post, I mentioned switching to xz compression without much explanation.
Software tends to get larger over time. Finnix deals with this in two ways: looking for things to cut while still retaining as much functionality as possible, and just accepting that the size will continue to grow over time. Larger kernels, larger software, etc. The smallest release of Finnix was Finnix 86.2, at 92 MiB (x86). The last release, Finnix 101, was the largest so far at 128 MiB (x86).
During development of Finnix 102, the simple act of adding upgraded kernels and upgrading existing Debian packages to the latest versions was seriously adding to the size of Finnix, nearly 150 MiB at one point. And I had done all I could to reduce the size; there was just nothing left to cut out. Then I found out about xz compression. Xz is based on LZMA2, offers 10-20% more compression than Gzip, and in particular has optimizations for architecture-specific bytecode (program binaries, etc). Xz support was added to Linux 2.6.39, and could be used for kernel, initrd and SquashFS compression (previously, all three used Gzip compression).
So I tried it out, using Linux 3.0-rc (as of right now, if 3.0 comes out soon, it will be included with Finnix 102). I used xz compression for the kernel, initrd and SquashFS root filesystem, and was seeing 20% space savings versus using Gzip.
No compression: Root FS: 385,187,840 initrd: 7,534,080 Final ISO: 400,162,816 Gzip compression: Root FS: 136,921,088 (64.45%) initrd: 2,495,967 (66.87%) Final ISO: 146,857,984 (63.30%) Xz (LZMA2) compression: Root FS: 109,469,696 (71.58% none, 20.05% gzip) initrd: 1,733,032 (77.00% none, 30.57% gzip) Final ISO: 118,644,736 (70.35% none, 19.21% gzip)
Overall, it looks great. Though one consideration is performance. LZMA is known for being very processor intensive. LZMA2 is more processor efficient than LZMA (and BZ2), but still slower than Gzip. Compression times are roughly 5 times slower than with Gzip. But the real question is how well decompression would work in the real world (that is, when booting Finnix). I don't have any hard numbers on that, but I did put dev builds through the gauntlet of everything from an i586 AMD K6 to a Power Mac G3 to a Core 2 Quad Q9450, and could not perceive any slowdowns.
So barring any major problems, Finnix 102 will actually be smaller than its predecessor, for the first time in over 3 years.
As a reminder, the standing goal of Finnix is to keep the distribution CD below the size of a Mini CD (185 MiB). While I doubt many people actually use Mini CDs, it's a good round goal, and while Finnix would still be within the 185 MiB limit without xz compression today, a proactive approach to keeping the distribution size low helps it from becoming a crisis too quickly.
By the way, the build scripts have been updated to allow a builder to choose which method of compression (xz, Gzip, or even none), and scripts within Finnix that rely on reading/modifying the initrd (finnix-netboot-server, for example) have been updated to detect which compression method is being used, and will use that method when rebuilding the initrd.
Article posted on Jun 28
Finnix 102 is coming along well. At this point, everything on my list is done, and I'm just waiting for Linux 3.0 to be finalized (I've been testing against 3.0-rc builds for awhile, with good success). A changelog so far (subject to change before final release):
* dist-upgrade
* Upgraded kernels to 3.0 (Debian 3.0.0-xxx)
* Added xen-blkfront to the initrd (AMD64 kernel)
* Added initrd loading attempt of xen-blkfront and xen-netfront
* Added ability to set manual IPv4 addresses and basic resolv.conf info via boot parameters
* Changed kernel, SquashFS compressed root, and initrd to xz compression
* Changed finnix-netboot-server and finnix-netboot-biginit to detect gzip/xz/uncompressed initrd, and build initrd_net accordingly
* Fixed console boot flag
* Fixed automatic update of /etc/fstab during hotplug device update
* Upgraded Memtest86+ to 4.20
The current x86 dev build is 2520, which gave me the idea to go back and look at what builds corresponded to what releases.
* 86.1: 1435
* 86.2: 1504 (+69)
* 87.0: 1617 (+113)
* 88.0: 1776 (+159)
* 89.0: 1961 (+185)
* 89.1: 1969 (+8)
* 89.2: 2011 (+42)
* 90.0: 2084 (+73)
* 91.0: 2154 (+70)
* 91.1: 2185 (+31)
* 92.0: 2270 (+85)
* 92.1: 2296 (+26)
* 93.0: 2318 (+22)
* 100: 2359 (+41)
* 101: 2473 (+114)
Prior to the 86.0 release, I picked build #500 as a rough guess as to how many builds I had made since then. 86.0 itself didn't have the build number shown publicly, so I don't have that data. Most testing is done on a VM (formerly VMware, today VirtualBox), so comparatively few builds are actually burned to CD (I would estimate about 200, which is still a lot). But nearly every build has at least been booted.
PowerPC builds use a different build number which is much smaller, 226 as of today. This is because the primary dev machine is an older G4 Mac Mini, which takes much longer to build compressed roots (formerly about 5 minutes, now over 20 minutes due to the switch to xz compression as mentioned in the changelog), compared to a minute or so on x86, a Core 2 Duo E7200. So most development and architecture-agnostic testing is done on x86 in a VM, then the changes are transferred over in bulk to the PPC environment and built.
Article posted on Dec 25
Finnix is used a lot for remastering for administrators' specific projects, so if you're a remasterer, you're going to both love and hate Finnix 101 -- love because Finnix 101 ultimately makes it a lot easier to remaster in the long run, and hate because a lot of things have changed in incompatible ways, hopefully for the better. This post should help give you a rundown on what's changed.
The following wiki guides have been updated for Finnix 101:
Article posted on Dec 20
I'll be honest, Finnix 100 was a rush job. Not a bad rush job per se; I have found no major problems with it and continue to use it on a daily basis. But there's nothing particularly great about it. The entire development cycle was about 2 weeks, to get a release out the door to reverse a one-year hiatus. Just enough to bring the software up to date, compile a new kernel, and run through regression testing.
Finnix 101 will be different. I've been working non-stop since October, and behind the scenes, Finnix has basically been completely re-engineered. To a casual eye, nothing will look different. Same boot menus, same minimalist boot, same quick boot times, same overall look. That's fine -- that's what gives Finnix its appeal. But the underlying architectural changes have been a long time coming, and will be useful for development and re-development (that is to say, remastering).
The current dev changelog is quite long by now, but here are a few highlights:
The release is feature complete, and I was hoping for a Christmas launch, but at this point I don't think I can go through the required testing and get the ISOs to the mirrors in time. 3 months since Finnix 100 will be late January, though I hope to have a release before then.
Article posted on Oct 23
Today is the 5 year anniversary of the "modern" incarnation of Finnix, which started with Finnix 86.0. Happy birthday, Finnix!
I sent a message to the Finnix mailing list today, apologizing for hiatus Finnix has been on for the last year, and detailing a roadmap for the near future. Please read the post for the full details, but the main points are:
Article posted on Aug 7
Reposting an email I sent recently:
Yes, I started a few weeks ago after a (too long) hiatus. 2.6.30 kernel, which is looking nice. (SquashFS is now included in mainline. That means UnionFS is now the only kernel patch that is absolutely required.) The latest Debian testing stuff itself is pretty stable, but managed to break pretty much all of Finnix's init scripts in one way or another, but it's coming along. Unfortunately Debian's base packages are a little larger, and the kernels have ballooned between 2.6.26 and 2.6.30, so this will probably be the largest Finnix to date, about 125MiB for x86 at current estimates. It's still well under Finnix's long term goals (never to exceed 185MiB, the size of a mini-CD), but unfortunately there really isn't anything to trim.
Still, I'm happy with what the next release is shaping up to be. Looks good!
Article posted on Nov 24
... or the "I waited 5 months for this?" release.
Hopefully a release announcement will be made tomorrow; otherwise it will be next week, as I will be on vacation for the Thanksgiving holiday. Finnix 92.1 will be a maintenance release, with a dist-upgraded environment, a "new" kernel, 2.6.26 (2.6.27 has not yet entered Debian due to the Lenny freeze, and I didn't deem it important enough to break with procedure and use a vanilla kernel this time around), and a few small fixes.
Also, a little teaser: This will not be released with Finnix 92.1 -- it will be sometime after release -- but I will be announcing Finnix on a new architecture. Which one? It's a secret... One hint is it is an architecture I have discussed in relation to Finnix before.
(No, it's not that iPod April Fools port from 2006.)
Article posted on Jun 14
Finnix 92.0 will be released soon. It will have a new 2.6.25 kernel, updated software, and, most visibly, a new boot menu.
There have been suggestions for a new boot menu for awhile now. I liked the idea in theory, but there were various problems with most implementations (no graphics; graphics, but no fallback to text mode; no easy way to add boot options, such as toram, testcd, etc; no way to default to 64-bit boot options). Debian's recent announcement of debian-installer for lenny beta 2 introduced a new installer boot menu system based on bootmenu.c32, which looked very nice and solved most of the problems I mentioned. However, no default 64-bit option on multi-arch CDs, which the announcement mentioned and lamented.
I used Debian's configs as a base for a Finnix test. The results were very nice, and I was ready to do as Debian did and accept that the improvements were worth the loss of 64-bit autodetection. However, an acquaintance encouraged me to look into it ("Sounds like it's time for some OPEN SOURCE MAGIC"), and within a few hours, I had a working patch.
The debian-installer guys loved it and had the patch applied within an hour, and as well, it will be in Finnix 92.0. Here's a development screenshot: