Skip to main content

Ralsina.Me — Roberto Alsina's website

Change of plans

Well, uCrux is not for me.

The main prob­lem is what lead me to it in the first place, uClibc.

Sad­ly, I can­not rec­om­mend it ex­cept for em­bed­ded de­vices. It has some prob­lems build­ing or link­ing spe­cif­ic soft­ware, but that's not it. The prob­lem is there is no up­grade route.

Since it prom­ises to break bi­na­ry com­pat­i­bil­i­ty ev­ery ver­sion, you have to re­build the world to, for ex­am­ple, see if a bug is fixed in lat­est snap­shot.

So, back to glibc, at least for a while.

And, since I de­cid­ed to switch to glibc, why not look at Crux's child, Arch? It's down­load­ing now.

UNIX stuff that makes no sense ( the rant)

First of al­l, I love Lin­ux. I have used it ex­clu­sive­ly since about 1994 (yeah, the last Win­dows I ac­tu­al­ly used for re­al was WfW 3.11).

Let's see how it makes no sense.

The Bin

Your sys­tem has /bin /s­bin /us­r/bin /us­r/s­bin /us­r/lo­cal/bin /us­r/lo­cal/s­bin 6 dif­fer­ent bi­na­ry lo­ca­tion­s.

What sense does it make to split bin and sbin? It on­ly makes it hard­er for reg­u­lar users to use tools the can need, like net­stat and if­con­fig.

As for /bin and /us­r/bin, it makes lit­tle more sense, if at al­l. Sure, put a ba­sic, func­tion­al sys­tem out­side /us­r, be­cause /usr can be a net­work FS. Well, who does that?

I mean, I have seen al­l-lo­cal and al­l-net­work sys­tem­s, but I have nev­er seen a /-lo­cal, /us­r-re­mote sys­tem in ten years.

And I sup­pose some­one does it, but that does­n't mean it makes sense. If you want a re­al, func­tion­al, un­break­able sys­tem you can use in case of net­work fail­ure: use a sep­a­rate par­ti­tion. Or use a Live CD. Or use a flop­py. All of those are more re­silient than your /.

As for /usr and /us­r/lo­cal... that's just a throw­back to when peo­ple were scared of in­stalling soft­ware. Peo­ple should in­stall pack­aged soft­ware any­way.

The Libs

/lib /us­r/lib and /us­r/lo­cal/lib. Just as much sense as the above.

The vari­able

/usr and /var. Here's what I think I heard: /usr is for un­chang­ing ap­pli­ca­tion da­ta (bin­s, lib­s, doc­s, etc.) /var is for mu­ta­ble da­ta (logs, spool­s, caches).

That way, you put /var in a sep­a­rate par­ti­tion and if apps run amok, your / does­n't fil­l.

Well... ok, I sup­pose. Ex­cept that the right way to han­dle that is to make sure your apps don't freak­ing run amok!

Say, logs? Ro­tate them by size, not by date!

Spool­s? Use disk quo­tas, and max­i­mum sizes!

Caches? They should be space-lim­it­ed.

And all ser­vices should be kind enough to fig­ure out when your disk is about to burst and do some­thing grace­ful with it.

Fi­nal­ly: if your /var fill­s, all your ser­vices will crash just as hard as if / filled. So what's the point? That you can log in­to the crashed box and fix it? You can do that with a full /, too.

The root of all evil

We live with the con­cept of a sin­gle almighty ad­min. Why?

If ev­ery ser­vice ap­pli­ca­tion had a sin­gle point of con­fig­u­ra­tion and mon­i­tor­ing (ie: /etc/app and /var/ser­vice/app (in runit ;-) and /var/log/ap­p, it would be triv­ial, us­ing ACLs, to al­low par­tial man­age­ment of the sys­tem.

Sure, there would be a re­al root for stuff like pass­word man­age­ment and such, but that's not so bad.

Why has no one both­ered do­ing this?

Per­mis­sion to barf

The Unix per­mis­sion sys­tem is at the same time hard­er and less pow­er­ful than ACLs. That on­ly on the last two years it has be­come prac­ti­cal to use ACLs on Lin­ux, and that still you can't count on them in ev­ery dis­tro is... ug­ly.

I could go on, but... I think you get the idea. Com­ing some day: a pro­pos­al to fix the mess.

Booting with runit

The first tu­to­ri­al com­ing from my cus­tom-dis­tro ex­per­i­ments. Since it's a good idea to start at the be­gin­ning, here is... Boot­ing with runit.

Linux: a not-unix-like OS.

Well, I am still ex­per­i­ment­ing with my con­cep­t-dis­tro.

I am now up to a run­ning PyQt us­ing uClibc, which I thought un­like­ly ;-)

I com­plete­ly re­moved all the sysv init stuff, and re­placed it with runit, which has an in­ter­est­ing ef­fec­t:

It boots to a graph­i­cal lo­gin in about 15 sec­ond­s. In­side qe­mu. In a 900Mhz duron. In­clud­ing ker­nel load­ing.

Of course the trick is that you have the lo­gin while stuff is still load­ing, but I am work­ing on that, too.

Since us­ing runit it's pret­ty sim­ple to get a over­view of where the boot­ing process is (ser­vices have de­pen­den­cies, they sim­ply get start­ed in or­der, and in par­al­lel), I will hack a sys­tem-wide ksplash-­like thing on a side of the xdm (prob­a­bly will end up writ­ing my own what­everd­m).

Think of it as Fe­do­ra's rhg­b, on­ly you can lo­gin in­stead of get­ting bored.

I al­so switched to a root-free sys­tem Ubun­tu style. Not de­cid­ed yet on it, but it's not hard to do (or use).

Next step: hack Knop­pix HW-de­tec­tion script (or rather re­write them in a re­al lan­guage).

I un­der­stand why there are 743 Lin­ux dis­tros. It's quite a lot of fun to hack one to­geth­er.

Oh, and it needs a name. It's not go­ing to be use­ful for any­one, it's just a per­son­al toy, but it needs one.

Come on, Plan­etkde guys, throw me names for a non-u­nix like lin­ux, if you dare ;-)

Source-based distributions, the good side.

I am no fan of source-based dis­tri­bu­tion­s. I think that for most prac­ti­cal pur­pos­es, a dis­tri­bu­tion where in­stalling KDE takes over a day (I own a low­ly Duron as my fast com­put­er) is use­less.

How­ev­er, they are good for one par­tic­u­lar niche.

Cus­tom dis­tri­bu­tion­s. Weird dis­tri­bu­tion­s. Per­son­al dis­tri­bu­tion­s.

I have sev­er­al com­put­er­s. Most of them too slow and small.

As I was con­sid­er­ing re­in­stalling Lin­ux on my Li­bret­to for fun, I looked at what was in­stalled in it, and de­cid­ed that re­al­ly, 90% of it was of no use what­so­ev­er.

The prob­lem was, since it had De­bian in­stalled, it has a rather wide net­work of de­pen­den­cies that sim­ply could not be done with­out.

On a reg­u­lar com­put­er, that's not an is­sue, but in this tiny workhorse, with 16MB of RAM and a 800MB HD, it makes a lot of dif­fer­ence. The small­est I could get De­bian to be, and still have net­work, PCM­CIA and X11, was about 250M­B.

And the per­for­mance was not awe­some, ei­ther (but not ter­ri­ble).

So, what would hap­pen if in­stead of a reg­u­lar dis­tri­bu­tion it had some­thing like this:

  • uClibc in­­stead of glibc

  • runit in­­stead of SYSVinit

  • drop­bear in­­stead of OpenSSH

  • X built as kdrive (former­­ly tinyX)

  • python/qt (or maybe python/fltk) for ba­sic ad­min tools

And so on. Ba­si­cal­ly re­jig­ger the whole soft­ware se­lec­tion slant­ing it to­wards the small side, and drop­ping a bazil­lion non-­fun­da­men­tal de­pen­den­cies along the way.

Well, it can be done. It's just that it's a heck of a lot of work. But here, a source-based dis­tri­bu­tion gives you a head­start.

For ex­am­ple, I de­cid­ed to start from ucrux, a uClibc-based port of Crux. Since the na­tive toolchain in ucrux is uClibc, I don't have to wor­ry much about a whole class of mess that hap­pens when you build uClibc-based bi­na­ries on a glibc-based sys­tem (it's prac­ti­cal­ly cross-­com­pil­ing).

Qe­mu lets me in­stall ucrux and work on it some­what faster than on the tar­get P75 (if I could make KQE­mu work I'd be hap­pi­est).

Since crux's soft­ware pack­ag­ing mech­a­nism is sim­plic­i­ty it­self (a shell script that in­stalls to a fake root), al­though it's se­vere­ly un­der­pow­ered (no de­pen­den­cies), I can start from ucrux, hack the build of one pack­age at a time, then put ev­ery­thing on a CD very quick­ly.

So, if you want to hack your own dis­tri­bu­tion, Crux (or some oth­er sim­i­lar kit) is quite a nice thing.

For gen­er­al use... well, my re­quire­ments start at ap­t-get or equiv­a­lent ;-)

Now, if on­ly Tiny­CC worked for more pro­gram­s, that P75 would be a pock­et de­vel­op­ment pow­er­house!