I have up­dat­ed my Boot­ing with runit sto­ry for the com­mands in runit 1.5.1 and in­clud­ed a men­tion for my easy runit RPM (which is now al­so up to 1.5.1).

If you are look­ing for an al­ter­na­tive way to boot your lin­ux ma­chi­nes, or for a re­li­able way to run and con­trol your ser­vices, please take a look. Runit is cool.

Here are runit RPM and SRPM for Cen­tOS 4.2 (prob­a­bly works on some oth­er dis­tros as well).

You install it, then clone your GRUB (or LILO) entry so you boot passing init=/s­bin/runit-init to the kernel and when you boot it, it should start on a rather normal-looking runlevel 3.

To re­boot or halt, use re­boot-runit and halt-runit, please!

Keep in mind that this is just a be­gin­ning, since all your ser­vices (ex­cept your ttys :-) are still run­ning with­out su­per­vi­sion!

Should not de­stroy any­thing, but use at your own risk.

You will have to work fur­ther if you want to do more.

Included is /etc/runit/services/test a trivial template service.

Sor­ry about the spam­my host­ing, but I will get a de­cent serv­er space for these files some­where even­tu­al­ly. These rpms are just a teaser, any­way :-)

Have been read­ing the plan­ets late­ly (I mean plan­etkde.org and plan­et.g­nome.org, not as­trol­o­gy) and run in­to posts by Aaron Sei­go and Luis Vil­la which are, let's say, in­ter­est­ing.

Luis' post took me to this page which is in­ter­est­ing too, and I would like to see some­thing like it for KDE (and I am sure it is some­where, but I can't seem to find it)

And I don't mean the page is in­ter­est­ing on­ly for hav­ing Aus­tralia list­ed as an asian coun­try ;-)

Some of the items talk about hun­dreds of thou­sands (or hun­dreds of mil­lion­s) of desk­top­s, and oth­ers talk about 11 seat­s.

Is there noth­ing in the mid­dle, or is it just not re­port­ed?

I de­cid­ed to put out an­oth­er dat­a­point.

Here in Ar­genti­na, the best-selling OS has KDE as the de­fault desk­top. It's a Lin­ux from Pixart , and is more or less what on oth­er coun­tries is sold as Xan­dros.

It seems Pixart made some de­vel­op­ment work for Corel, and then for Xan­dros when they bought the lin­ux dis­tro busi­ness. Their boss is the for­mer (?) boss of Corel ar­genti­na, too.

Al­most ev­ery white­box clone is sold with one of their dis­tros in­stalled and pre­con­fig­ured.

Oh, sure, most of them get wiped out and re­placed with a stolen win­dows xp in 24 hours, but it's quite a num­ber. Think 100K or 200K sold each year, at least.

Of some con­cern is that some of the GNOME de­ploy­ments used to be KDE de­ploy­ments. For ex­am­ple, the Sao Paulo tele­cen­tros used to be Conec­ti­va box­es with KDE (and win­dows, in du­al­boot).

The City of Largo used KDE for quite a while.

But what the heck, we are both desk­tops squeezed in­to a ketchup bot­tle, there's a whole world out­side to spread in­to ;-)

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.

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.