Slashdot

So, we have a working toolchain, and now I am testing a chroot setup. I have found another round of non-fatal but dumb mistakes of mine in sys-bootstrap, which I have corrected, and I still rebuild sys-bootstrap from scratch every time I can. I created a meta-package called z and set up my dependencies accordingly so that things would build according to the LFS recommendations.

I created a new tree, called sys, which will be used for all the system stuff, and for now, I will fill it up with all the LFS recommended software. I might split it up later on, if somebody comes up with a good reason for it, though. There are two meta-packages in there right now, chroot and z. chroot is supposed to re-create the usable linux structure inside the sys build directory, so that we can chroot into it and access everything transparently. As of right now, everything is copied from sys-bootstrap's build dir, but somebody might complain about disk space usage. I guess I should set some kind of flag so that people can preserve their sys-bootstrap, or else move it out of there.

I have thought about integrating some Apple stuff like Rendezvous, and the XGrid client, since it would be fun to interact natively with the platform that has "usable" written all over it. BUT, I have no Apple computers, so that'll have to wait.

And now, for something completely different, I would really like to talk about the init system. Right now we have this bunch of scripts and stuff, and the way Fedora-RedHat-Mandrake make it seem simple to people, is through implementing some interface inside the init scripts and some cleverish python programming. I dislike those, yet I do not feel like I have a better idea, and imposing yet another standard on people "just because" does not seem right to me. I have to look into it, and see what I'd do differently.

I also have this probably dumb idea for package management that involves a filesystem which allows us to modify file metadata. We could store what package and version a file belongs to, and possibly duplicate that metadata for any copies made from that file (if a file is a configuration file, for example). Thus, when cleaning up packages at uninstallation time, we can prevent the leftover files that occur when users mess around with package contents, and we avoid having to use a package contents database that will in most cases not be accurate after user-with-root-intervention.

Department of Redundancy Department

So, I was away for a while, doing college term papers and whatnot. As a side note, my college uses trimesters instead of semesters. Strange, huh? We're supposed to finish faster, but I'm not sure about the quality of the education we receive in such a short period. The classes are intensive, though...

I have been regression testing the toolchain up to util-linux, as per LFS recommendations, and I have found a bunch of dumb mistakes of mine. Progress is slow, since I have to rebuild from scratch everytime I fix a problem (I guess this is what regression testing is all about, isn't it?).

I did find out that the LFS howto is missing something when it gets to building perl 5.8.4, since I have had to add gdbm 1.8.4 and db 4.2.52 to the toolchain tree, otherwise perl would not want to build. I'd attribute it to the fact that the GAR ports tree sets a bunch of environment variables like LD_LIBRARY_PATH, and PATH amongst others to paths inside $(main_prefix). Since I believe (possibly incorrectly) that the toolchain should depend as little as possible on binaries that might or might not be available on the host system, I decided to try and make the toolchain tree (from now on we shall call it sys-bootstrap, ok?) as self-contained as possible. So while you might have gdbm or db on your system, I'll build my own, and possibly to my liking (this is to aggravate all you gentoo with a lowercase g people with your CFLAGS and stuff). While we're there, I should remember to check for sed being used before I have built my own sed inside sys-bootstrap.

I have to implement an $(ARCH) variable that does a "uname -i" before setting the path to $(main_prefix)/bin:whatever. On the GAR architecture site (here) there's talk of a $(GARCH) variable, but the GAR ports I ripped from garnome doesn't seem to be too recent, since there's no such variable to be seen. I guess I'll finish sys-bootstrap, and once everything builds fine, I'll import the most recent GAR makefiles from Nick Moffit's site, probably breaking the sys-bootstrap tree. Then, I'll go cry in the corner, thank you very much.

I am not very sure about security and the system that I'm building, though. I guess that security is supposed to go beyond the classical "is your software all patched up to recent versions?". But since I have never put an operating system together from separate pieces, any recommendations would be welcome.

Oh, and one last thing. I intend to remove X. There, I said it. Linux has a framebuffer device that kinda works on a bunch of platforms. Maybe we should have some kernel space windowing system, with a user space window manager that took advantage of the framebuffer. You must be asking yourselves why I'd drop something that already works (namely, X) from my distro to replace it with something new, unstable, untested, that some idiot (that would be me) is going to code up all by himself.

But I will tell you that I was promised flying cars and regular space travel for civilians by the year 2000, back when I was seven. It's 2004 already, and all of the stuff I was promised has failed to show up. At the very least, my OS should boot directly into graphical mode by now. I don't want to see any text that I won't be able to read scrolling on the screen. That looks ugly. I don't want an X hack that shows up whilst booting. That looks ugly too. I want something graphical right from the start without switching to X (without the ugly blank screens in between). I now realize I should buy a Mac.

I will make some sort of xlib that people will link to, and voilá, their programs would work with my windowing system. My goal would be to have GNOME and KDE compile and run properly with this. I do believe this will be a temporary solution, since I dislike both KDE and GNOME, and would rather have applications that are "native" to the new windowing system that are designed to be "usable", much unlike most KDE and GNOME apps. Difficult? Yes. But it is necessary if we ever expect Linux to be used by people who do not have time or the desire to RTFM. Oh, and get ready to learn Objective-C... (aren't I an Apple fan?).

I have a dream.

Let's start this by establishing the fact that I'm an idiot. I hope this will work as an excuse for my talking out of my ass.

So, er... um... I'm starting on building what will be yet another GNU/Linux distro in the sea of irrelevant GNU/Linux distros (can you hear me now, RMS? Good!)... But don't expect anything brilliant to come out of this one, though. I'm trying to pay attention to the down to earth stuff, like making things simple for people, instead of all that 1337 emerge-nfs-over-a-tin-can-live-cd-on-reiser-fs-xp stuff. I hope to be able to call it "Usable Linux", if the name is not taken if and when I release it upon the two people who are still using OS/2.

As I said, I'm trying to keep it simple, and I try to make it simple right from the start. I'm building my system per LFS recommendations (read this) but I'm trying to make it automated. Right from the start I wanted to make an automated build system, so that anybody could bootstrap the system, without any help from the local witch doctor.

I really liked the BSD (look at this) ports tree, since I used a VIA Epia @ 800 MHz running OpenBSD for about two years before I bought the Athlon (I hope it runs HL2!) running FC2. So I wanted the same for my bootstrap system. So I looked at gentoo-emerge-ebuild, etc, and I shuddered at that. I wanted something a bit simpler, something that would use software that is readily available to most distros to build itself. Most distros already have a gmake package, and a bash package, and some gcc flavor and all that, yet I don't know how much of a hassle building emerge would be to those on strange custom flavors of GNU/Linux.

So I looked around, and I remembered Nick Moffit's GAR ports system (read here) from the garnome project (here). So I downloaded a garnome package and ripped all the GNOME out. Now, I bet Nick Moffit gets all the ch1x0rs. At the very least, If I were a chick, he'd get laid like Georgia Carpet (no, seriously).
Having said that, the GAR ports system is a very simple way of making a ports tree work. I'd recommend it highly.

Now, I know some guys beat me to the punch on the simple bootstrap thingie with a magic ruby script that builds the whole system. But I would guess that most people do not have ruby installed. Am I wrong? Still, kudos to them, since building a linux system will at least make you break a moderate sweat. And making that build process automated is a bit complex. After you've tried bootstraping glibc with a gcc that's missing some weird patch, and having to start over. Again. And again. Until you realize you missed the patch.

And somewhere in the distance, a dog barked.