Once again, the modern-xiafs kernel module has been updated, this time to cover kernels 4.9.6 and 4.10.1. (Strictly speaking it was updated a few weeks or so ago, but only now am I getting around to noting that fact.) These kernels each have separate branches (linux-4.9.6 and linux-4.10.1, respectively) that need to be used to build the right module for that kernel. As usual, even if your current kernel doesn’t exactly match one of the kernels modern-xiafs has been built against, a branch that’s close to it may work.
The modern-xiafs kernel module has been updated to work with (at least) the 4.7.10 and 4.8.7 versions of the Linux kernel. That code is in the current master, but also lives in the linux-4.7.10 branch. There’s also a small fix for mkfs.xiafs - there was a bug with setting the umask (or, at least, there was a typo in the original program and it was trying to set the umask in a totally obsolete way) that made it so any filesystem created with it would have totally open permissions.
It’s rather been a while since I’ve worked on the xiafs module, but while I was flying to NYC last week I ended up working on it some on the plane and got it caught up with more the recent Linux kernels. Specifically, kernel version 4.0.9 still works with the 3.16.4 branch, so there were no changes there. Kernel version 4.1.3 and kernel version 4.4.0 had very small updates, so they have their own branches.
The modern-xiafs kernel module for Linux kernel 3.16.4 still works, with no modification, for the 3.18.11 and 3.19.3 kernels. Presumably it will work with other 3.18 and 3.19 series, along with 3.16 and 3.17 kernels, but that hasn’t been tested yet.
I’ve been busy with work and goiardi lately, but I recently checked to see how modern-xiafs did against the 3.16.4 and 3.17.0 Linux kernels. The file ops functions changed subtly again, so there’s a small update to modern-xiafs to work with those kernels. The same update fixes it for both kernels, at least, so there’s only one version of the module for both kernels. Usual warnings and statements from before, as always, still apply.
Another kernel version, another uneventful update. Once again, the modern-xiafs module needed no update to build, load, and mount filesystems with the 3.15.3 kernel. As before, the README has been updated, but that’s it; all previous warnings still stand, just like last time.
I just went and tested the Linux 3.13.5 modern-xiafs module against Linux 3.14.2, and it built, loaded, and works just fine. The README has been updated to reflect that fact, but there’s nothing else to add; all previous warnings about xiafs before still stand, as said before.
Once again, the new version 3.13 series of the Linux kernel has required an update to modern-xiafs. This particular update was quite small, although not quite as small as the update for 3.12.1. There’s not a lot more to add; all the previous warnings and statements about xiafs from before still stand.
The modern-xiafs module, a delightfully useless thing that allows modern Linux kernels to mount and use the ancient xiafs filesystem, has been updated to work with Linux 3.12.1. This was the smallest update yet (one function in inlude/linux/mm.h had been changed). Nothing else of note is in this update, and previous warnings not to use it in production (which would be pretty stupid, seeing as it has those max 2GB volume/64MB file size limitations) and that it could conceivably set your computer on fire or run off with your cookware/checkbook/long term companion remain in effect.
I took a break from sending Kerbals across the solar system to update modern-xiafs to work with the 3.11.1 Linux kernel. This, I’m happy to say, was a small and quick update; the only changes needed were to xiafs_readdir because they went and changed the directory operations in the kernel subtly for some reason. There isn’t anything of note here otherwise. Xiafs seems to work as expected with no currently known gotchas.
This is pretty nice. I’m happy to say that the bug mentioned in the previous post, where deleting a bunch of entries from a directory, then copying new ones in, would cause fsck to complain about bad directories and some inodes and zones to be “free, but marked in use” has been fixed. It was an interesting problem. To simplify the xiafs port, I had hollowed out the minixfs code to build on because xiafs was originally an extension of the Minix filesystem, but not everything carried straight over between the two filesystems.
There’s some good news and some bad news on the xiafs front. The good news is that the module loads into the kernel and mounts/unmounts xiafs filesystems just fine with the latest (as of this writing) Linux kernel, 3.10.1. The bad news is that I uncovered another bug (that I’m pretty sure is in the directory code) that affects at least the 3.10.1 and 3.2.0 versions, and probably the 2.6.32 one as well, where if you copy a bunch of files into a directory, delete them, and then copy a bunch more files into the directory, fsck will consider some but not all of the inodes and data zones to be “free, but marked in use”.
For the last couple of months, I’ve been working off and on on porting xiafs, an ancient Linux filesystem and competitor to ext2 that lost out and was dropped from the Linux kernel back in 1999, to a modern kernel. I’m happy to say that I’m able to announce the release of modern-xiafs on github. Currently it works with the 2.6.32 kernel that shipped with Debian squeeze, but I intend to get up up to date with the latest kernel versions shortly.
Linux on a S/390 or z/Machine is pretty similar to Linux running on any other architecture, but installing Chef on one is an interesting thought experiment. One major issue, though, is that binary packages are (not surprisingly) not built for s390 by Opscode, so you’ll have to do the more manual installation. First, unless you have a mainframe laying around, set up a Linux/390 VM running under Hercules. I found these instructions to be useful, but since I’m on a Mac I had to make a few changes:
Over at Daily Kos, Markos did a write-up of his experiences with his iPad and using it as a laptop replacement during a trip to DC. The reaction has, fairly predictably, been pretty strong. I'm torn on the issue. I'm acutely aware of the concerns with Apple not letting the iPhone and iPad be more open, but on the other hand they're amazing pieces of hardware and software. I still haven't made a decision on the iPad, but I've had one iPhone or another for quite a while now, and I love my iPhone.
Hot damn. After all this time, Adobe released a 64 bit Flash plugin for Linux about a week ago, and while it's still alpha, it seems to actually work. So far, YouTube videos play fine and the Daily Kos Electoral Scoreboard works better under the 64 bit plugin than it did under the 32 bit plugin running under nspluginwrapper. Time may show that it's still unstable, but at least npviewer.bin isn't sitting there sucking up CPU and memory now.
Or, a look at what I've been working on for the site.
It's been three months or so in the making, but today I've finally finished moving the site to its new hardware. Many of the major and minor things that could go wrong, went wrong, but at last everything's squared away and we're up and running on the new machines. Now that that's finished, I can even start rolling out some new features that I've been waiting on until this was all finished.
WARNING: There will be honest, frank discussion of computers and technology issues in this diary. Please, for the love of God, do not post a comment saying that you don't understand what I'm talking about. It will only antagonize the violent beast within.
Let's get started.