EasyLFS: The road goes ever on and on...
Yes, it really does. There is always something you can change. And sometimes it is hard to say "No, I'll take care of this in the next release.", but sometimes you need to get to a version-freeze, otherwise you'll never finish.
Free software develops rapidly. Over the time I am working towards EasyLFS 0.5 I have upgraded the kernel three times (an initial update to 2.6.25.something, then another one to 184.108.40.206, and now the latest to 2.6.26), and also the reference-policy has been updated twice.
Sometimes it is hard to keep track with all the updates. Of course one could say that keeping track of the roughly 150 packages used it EasyLFS is still easy compared to all the packages that are available in other distributions, like Fedora or Debian, where there are thousands of packages, but after all, these projects are not run by a single person. ;-)
And also those projects have freezes, feature-freezes, version-freezes and maybe even frozen toes... Just because it's a pain in the ... to keep track with all the changes and running all the tests again and again.
With two supported architectures EasyLFS supports less architectures than most other distributions, but still more than some, which only support x86. I think introducing generic support for x86_64, the architecture more and more people have at home, was an important decision for EasyLFS 0.4.
Download-numbers actually don't really support this step, but then there's also the problem that for some reason people seem to believe that running 32-bit software on 64-bit hardware is totally sufficient, and that 64-bit software might actually cause problems you won't have with the 32-bit version.
In my opinion this is simply untrue. There may be very few exceptions (which you probably can count on one hand), but overall this is just a myth.
EasyLFS64 offers the same functions EasyLFS offers. There is no difference in installation and in what you get in the end. The only difference is that you get real 64-bit binaries that won't run on a 32-bit OS.
Well, okay, there are other differences, but there are no disadvantages, only advantages. In 64-bit-mode the CPU by default uses the NX-bit. This helps preventing code-execution in memory, which for example is commonly used for buffer-overflows. If you want to have this in 32-bit-mode you either have to enable PAE (which has to be supported by the CPU, and thus cannot be default as older CPUs don't offer PAE) or you have to use security-extensions like SELinux. The latter, using some software that helps you can have drawbacks. Although SELinux works quite nicely it could contain bugs that might be exploited to bypass its protection, also it is additional work in terms of administration, especially SELinux is quite complex to install and I wouldn't suggest to anybody to try to upgrade his system with SELinux, too much has to be done for this. Including SELinux can only be done right at one point, when the OS is compiled.
Another advantage of using 64-bit software is that it simply works better on the hardware. In quite some packages there are optimizations for x86_64, including important packages like GLibC and GCC.
Another problem here may also be that people probably try EasyLFS in a virtual machine. From what I read VirtualBox seems to be pretty famous at the moment as it's pretty easy to use. The problem is just that it doesn't support 64-bit guests, even on a 64-bit host... I've mentioned this problem before, somewhere, and it's a big reason for me why I think VirtualBox (and in this respect also Microsoft's VirtualPC) sucks.
Well, back to the endless updating...
This weekend I've done two testruns, which I had hoped would be the last test-builds before I start working on the SELinux-policy. I was wrong...
The problem is that the latest version of the referency-policy requires the new SELinux-tools, the ones you find in the development-section on the NSA's SELinux-page. It shouldn't be a big deal to implement these, but of course this does mean another test-build, each for 32 and 64 bit (each taking around 6 hours).
So, what's the current status? And which plans do exist at this point?
First let me explain the current status of EasyLFS:
The current development-version is 0.4.4. This is because now the basic packages have been taken care of and now I am going towards the security-features, SELinux and the POSIX capabilities. All packages compile in both versions of EasyLFS.
I have imported the latest referency-policy into SLIDE (the SELinux Eclipse-plugin) and have done a few initial adjustments.
By now there is a script that "converts" a few programs (ping, ping6 and passwd) from SUID to POSIX-capabilities. This has been tested and it works. Other programs are quite likely to follow.
Okay, the plans about where to go from here:
As mentioned I will now have to do two more test-builds with SELinux to check out the new version of the SELinux-tools and libraries. I don't expect any problems, but you never know.
I also have to do another build to check out changes of the new Live-scripts. This one I will only do for the 3