What I don’t find very cool about it is that its so closed… maybe I’m wrong. I find it lame that apple can’t de-couple the hardware vendor / software vendor relationship. Personally, I would really like to own an iPad, but I would much rather run my own, customized kernel & software on it. What’s even worse, is that apple has patents on a lot of the hardware/interface (e.g. multitouch), which means that if I want a similar hardware/interface, then I have no (or at most little) choice about who I buy that product from.

That’s just my 2-cents.

In any event, good luck with LaTe development.

part of the key reason for such dreadful startup times on the openmoko is the fact that the CPU throws away its cache on a context switch. in combination with udev firing off scripts which can go to a process tree depth as high as 20 or 30, that’s an _awful_ lot of time utterly utterly wasted on context switches.

and if you look at the number of devices with /dev/tty* such as pty etc. you find that there are at least 768 ttys and pseudo-ttys - 3 groups of 256 at least, plus a few more.

each and every single one of these pseudo-ttys must be initialised and waited for using /sbin/udevsettle.

even on a 1.6ghz Pentium 4 laptop, udevsettle for so many devices caused something like a 10-15 second addition to startup time.

so, the ABSOLUTE top priority when i was working with depinit was to write a “mini” udevsettle startup script which took care of all other devices, and only initialised the first TEN of each of the pseudo TTYs.

this took only a couple of seconds.

THEN i had dependencies to start up other services AND initialise the remaining 700 or so pseudo-ttys in parallel.

then, also, because depinit is a parallel system, i was able to start up the X Server at the same time as kicking off other (unimportant as far as login) services such as Apache2 and even SSH server.

by the time the user actually logged in at the KDM x server, those services would have finished starting up.

on the 1.6ghz laptop i installed this on, the startup time to KDM was reduced to 25 seconds, which i achieved _well_ ahead of anyone else doing this kind of “startup optimisation”. it was over a year before gentoo announced they had got 15 second startup times.

and the shutdown time using depinit, thanks to it doing kill signals in parallel, is something like 3 to 5 seconds.

so overall it is a stunning advance over what is used now, and because depinit’s core code is so simple, it hasn’t actually needed any maintenance.

so, the fact that it’s sitting there not being used by anyone is irrelevant: it’s still useful.

_do_ look at it _before_ going and reinventing it, please.

richard lightman already did a complete and extremely thorough job on depinit, which he rewrote back in 2003.

it is increedibly comprehensive, and was adapted into the “linux from scratch” project.

depinit is a parallel boot system, with *automatic* restart of services, and unlike the crap /sbin/init that it replaces, it catches ALL signals and allows you to react to all of them.

so not just SIGQUIT i mean absolutely EVERY signal is caught.

it’s also possible to do recursive testing: you can run depinit under depinit, i.e. you don’t have to run it as process 1, but there are limitations (due to the linux kernel, ironically) if you do that.

don’t for goodness sake go writing yet another init system until you’ve evaluated depinit.

I’d be stunned if you find that you get any noticeable speedup from replacing init, when compared with doing something like getting init to just run fso-boot alone (by defining a new runlevel, and making that default, say).