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 ;-)

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!

As I blogged ear­li­er I am writ­ing a game (and yes, it's pret­ty much playable al­ready).

One thing I did­n't men­tion is that I nev­er wrote a game be­fore. Yeah, I know ev­ery­one does it as one of his first pro­ject­s, but I nev­er did.

So, there are some things I re­al­ly have no clue about [1], like sound and mov­ing graph­ics around.

For the graph­ics stuff, QCan­vas is just fine and dandy, but to make things bloop and war­ble and squeak when the time is right, I found Qt's sound sup­port some­what de­press­ing.

Come on, NAS? Who us­es that? And what about mu­sic? I had no idea.

So, I start­ed try­ing to fol­low one of my lead­ing prin­ci­ples of de­vel­op­men­t: find a way to make it Some­one Else's Prob­lem (T­M).

The usu­al way to do that is find­ing a li­brary that han­dles the prob­lem, write min­i­mal glue, stick it to the side of the pro­gram, tell the pro­gram that's his new ar­m, and for­get about it quick­ly.

Here's what I found.

Mi Dios!

I thought I should start by adding one of those an­noy­ing lit­tle tunes ev­ery game has. It's just a game tune, I don't want to have to in­clude a 3MB OGG file for it, so I want­ed an in­stru­men­t-based for­mat.

I re­mem­bered MI­DI tunes. You may know them as ring­tones nowa­days, but they used to be just cheesy tunes gen­er­at­ed by your SBPro's FM gen­er­a­tor, not your phone.

In fac­t, I re­mem­ber hav­ing a lit­tle prog­gie called playmidi, that would do that in Lin­ux.

Well, it seems that in the past few years, ei­ther sound cards have for­got­ten how to play them, they fell out of fash­ion, or some­thing, be­cause the on­ly things I found that could play MI­DI are mon­strosi­ties that re­quire a 9MB dig­i­tal in­stru­ment set. And how was I to in­clude that along with my 25KB game???

So, what's nex­t? I had a C64, so...

MOD me up!

MOD files are like MI­DI files, on­ly the MOD in­cludes it's own in­stru­ment set, called sam­ples, and in­struc­tions on how to re­peat and al­ter those sam­ples to make a tune.

Good news: there are nice-­sound­ing, fun­ny MOD files that are about 30KB in size.

Bet­ter news: There is a pop­u­lar li­brary to play them! It's called Mik­mod, and your dis­tro has it (and it's a de­pen­den­cy for KDE's mul­ti­me­dia pack­ages too).

Even bet­ter news: It has sup­port for play­ing sim­ple sounds (sam­ples in mod lin­go) by call­ing a cou­ple of func­tion­s.

Awe­some news: It in­cludes a soft­ware mix­er so you can just tell it to play this, then play that, then that, and a tune in the back­ground, and ev­ery­thing sounds at the same time.

So, we have a win­ner. This ba­by can han­dle ev­ery­thing I need for the game!

But... is that a snake in your pock­et?

I can't find a Python bind­ing for it. I am sure as soon as I post this ar­ti­cle some­one is go­ing to come up and tell me, here they are, mo­ron! But I just can't find any.

So, I de­cid­ed to do some­thing I want­ed to do al­ready and learn to use Pyrex. Pyrex is a tool to write python ex­ten­sion­s, with al­most-free ac­cess to C li­braries, in an al­most-python lan­guage (on­ly mi­nor syn­tax dif­fer­ences).

That way, I could write a Python mod­ule to use Mik­mod.

You know what? It was al­most scar­i­ly sim­ple [2]. I did­n't wrap all of Mik­mod [3] be­cause I don't need it, but now I can do stuff for games and apps al­most triv­ial­ly.

Even more: Pyrex has awe­some dis­tu­tils sup­port, so build­ing the ex­ten­sion­s, usu­al­ly a pain in the rear, is triv­ial (most­ly you just copy and delete stuff, with some search and re­place).

One thing I found I did nice­ly is this: Mik­mod re­quires you to call Mik­mod­_Up­date ev­ery once in a while so it fills the sound­card's buf­fer with stuff to play. If you don't, it skip­s.

So, I just start­ed a thread that loops and takes care of it. You don't even have to know about it to use the ex­ten­sion. Oh, sure, if your Mik­mod is not thread­safe, it break­s. Well, get a de­cent Mik­mod pack­age, then.

How does it look?

Here's a whole noisy prog­gie

#Load the modules
import mikmod, time
#Init the library
mikmod.init()
#40 voices, 20 for music, 20 for random sounds (overkill)
mikmod.setNumVoices(20,20)
#Enable sound, starts the thread that pushes sound, too
mikmod.enableOutput()

#Create a module, that is, a music track
module=mikmod.Module("BasicInstinct.mod")

#Load two samples, just a couple of noises
s1=mikmod.Sample("lost.wav")
s2=mikmod.Sample("swap.wav")

#Start playing the song
module.play()


#For the duration of the song, each second, make some noise


while module.active():
        s1.play()
        time.sleep(0.5)
        s2.play()
        time.sleep(0.5)

#Close the mikmod library, stop the thread, etc.

mikmod.exit()

I think some months of for­mal math train­ing would do won­ders for the av­er­age guy.

And I don't mean al­ge­bra, I mean log­ic, set the­o­ry, that kind of thing.

The ob­vi­ous ex­am­ple is, of course, com­par­ing two things. There is the con­cept of the well or­dered set. In a well or­dered set, for any sub­set, there is a larg­er and a small­er mem­ber.

In oth­er word­s, if you com­pare any group of things, one is the largest, one is the small­est.

That may seem ob­vi­ous, be­cause peo­ple on­ly think in terms of in­te­ger or re­al num­bers when they see > , but re­al life is dif­fer­en­t. Re­al life ob­jects are usu­al­ly not well or­dered, and that means you can't sort the whole set, noth­ing ev­er comes out on top.

Be­cause the crap­py math peo­ple learn makes them think in lin­ear terms [1], re­al­i­ty is ap­proached in lin­ear, lim­it­ed terms.

what I am think­ing about:

Peo­ple say Qt is bet­ter than GTK+ or vicev­er­sa.

Well, those are mul­ti­di­men­sion­al ob­jects you are com­par­ing, and in or­der to make it mean­ing­ful, you need to es­tab­lish a met­ric that will make the toolk­it-s­pace a well or­dered set.

That met­ric, sad­ly, is sub­jec­tive and per­son­al. While Bruce Peren­s[1] may see the ac­qui­si­tion cost for pro­pri­etary de­vel­op­ers as the most sig­nif­i­cant part of it[2], oth­ers may see techi­cal fea­tures as more im­por­tan­t.

But the telling point is this:

If you are a free soft­ware de­vel­op­er, why would you choose GTK+? What is your met­ric, where GTK+ is larg­er?

I re­al­ly have no clue on that, since I haven't touched GTK+ since I re­coiled in hor­ror from it in ear­ly 1996, but I will try my best.

• You pre­fer cod­ing in C

• You want your app to work well with GNOME

• You find the GTK+ API ap­­peal­ing

• You like some GTK+ de­vel­op­­ment tool, like glade

• You see bet­ter per­­for­­mance in GTK+ than in oth­­er tool­k­its

I can't find any oth­er rea­son­s, and even one or two of those seem iffy to me ;-)

You pre­fer cod­ing in C: Ok, that's rea­son­able. If you want to code in C, GTK+ is prob­a­bly the way to go.

But why, oh, why do you want to do that? Re­al­ly, come on, C is a poor lan­guage for al­most ev­ery use. Your lan­guage met­ric is prob­a­bly the guilty part of your choice of GTK+. But that's an­oth­er set.

You want your app to work well with GNOME: Ok, that is rea­son­able. I could say Qt apps work well with GNOME, too, but that's my own sub­jec­tive bi­as, and re­al­ly not de­fen­si­ble, since GTK+ apps do work bet­ter with GNOME.

The GTK+ API is ap­peal­ing to you: you are a sick per­son? ;-) Ok, that was harsh: you have bad taste in APIs? Ok, that was still harsh: I don't un­der­stand you. Yeah, that's bet­ter.

Luck­i­ly, you don't have to use it, you can use de­cent wrap­per­s, nowa­days.

You like a de­vel­op­ment tool, like glade: I don't see glade as a big thing com­pared to oth­er­s, but hey, that's just my taste. Rea­son­able point.

Per­for­mance: You want per­for­mance? Use fltk. Even pure Qt seems to be about on par with GTK+. Of course if you pair this with the C ar­gu­men­t, they sin­er­gize. Af­ter al­l, GTK+ does have bet­ter per­for­mance than Xaw3D or some­such. Maybe XForm­s?

Please, if any­one reads this, I am not try­ing to flame GTK+ or its de­vel­op­er­s. I am sure GTK+ is the great­est C tool­kit around, and de­vel­oped by smart peo­ple.

I just al­so don't see any com­pel­ing rea­son to use the thing for free soft­ware de­vel­op­men­t. For pro­pri­etary cod­ing? May­be, if you are low in cash. My own met­ric (for what­ev­er lit­tle it's worth) does­n't make me see GTK+ as an in­ter­est­ing tool. If yours does, please help me im­prove it.

Yes, I know stuff like say­ing the API is ug­ly can't be im­proved, be­cause you can't con­vince me that it is­n't[4], but you can help pro­vide new rea­son­s, or strength­en oth­er­s, or maybe tell me bad points about the tool­kit I see as bet­ter.

---

[1] Ok, peo­ple think that way even if they don't learn math, the thing is, math teach­es you to think non-­lin­ear, or mul­ti­di­men­sion­al.

[2] An in­ter­est­ing fel­low. Re­mem­ber when he quit De­bian in a huf­f?, and that he was go­ing to de­vel­op a Red Hat-based dis­tro that was more desk­top-ori­ent­ed? That was prob­a­bly around 1998 or 1999, IIR­C. BTW: you won't find all of it in the De­bian archives, "some­one" re­moved it.

[3] Which is re­al­ly a bizarre ar­gu­men­t, is­n't it?

[4] I al­so think most of Dalí's and Pi­cas­so's paint­ings are ug­ly. How can any­one con­vince me they aren't? They can't.

A Lin­ux dis­tro in my USB key­chain. I will do a write­up on it in a day or two, prob­a­bly, since the plan to work less is work­ing (tues­days and thurs­days off al­ready :-)