34 today - yes, I'm an old fart :D I've been treated to a fantastic weekend by my lovely fiancée, and she's bought me the worlds most comfy leather chair as my current one at home has seen too many years of hard computer usage. This should be a lot more comfy and last a long time :)She also took me out for 3 meals AND a nice walk - been really spoilt and I've loved it 8)Hopefully I'll be getting a Wii and Super Monkey Ball Banana Blitz as well. I've got the first SMB game for my old GameCube which Abbey and I really enjoy playing from time to time (mainly the sub games - heh) and this should be just as much fun :)
Every Gentooer knows RC - or rather /sbin/rc.It's the tool that handles the initial boot and then starts and stops services depending on the runlevel desired. It's also primarily written in bash. This is no bad thing, as it's a powerful shell, compared with say the standard sh shell from FreeBSD. But this is not without a price, and that price my friends is speed.baselayout-1.13 currently boots around 10 seconds faster than 1.12. This is purely because we moved the bash code that worked out service dependencies and ordering into a C program, rc-depend. Magnus Deininger (the author of eINIT) filed a bug requesting that our init scripts could call eINIT if that was running in place of sysvinit (our default). We discussed some things, and the end product is that we now have a small library in C that provides information about services, runlevels and their state. Infact, rc-depend is now just a front end to this library.Well, after having most of the basic foundations in a C library, and Vapier had already moved the system specific code out of RC for 1.12 it struck me that it wouldn't take that more more to have the entirety of RC in C. This has now been done, and my Gentoo/FreeBSD laptop is currently using it just fine. It doesn't yet support all the the bash functionality (parallel starts, interactive) but it does work :DFor you speed freaks out there it runs a full 0.5 seconds faster than RC in bash on a 2 Ghz laptop :jawdrop:Not much I know, but imagine a similar increase for each service as I intend to move most of runscript.sh into C runscript too. Now, this isn't ready for consumption yet, and won't be for sometime. I also don't intend this to ship in baselayout-1.13, although the library will so eINIT can use it but baselayout itself won't.And that's not the end goal either - once everything but our init scripts themselves are in C, there should be no more required reliance on bash itself. Current functions exposed by functions.sh (einfo, etc) are already built into C RC as mulitcall programs. The only issue with this is our lovely network scripts - purely because the user config is array based which is a bashism. The network scripts themselves use arrays very heavily and will have to be reworked a lot to work on other less powerful shells. I still think this needs to be done as running bash for every service on my Sparc64 is a major speed problem. Also, removing the bash requirement means that embedded devices would love us as bash is unsuitable for that environment.
Long time no blog! However, I have been a busy beaver :)baselayout-1.13 has undergone some serious stress testing by dsd and we've made some good improvements to reliability when shutting down, solving a few race issues and sorting out dependencies hopefully for once and all 8)Parallel startup has also had some speedups, and my hdd light is now hardly out once we enter rc properly (if anyone knows how to speed up udev, let me know)So how do we now compare to other init systems such as init-ng, eINIT and Upstart? Well, I don't know as I've not done a comparison on speed, but I'm not sure just how much faster the others are if any over baselayout as my hdd light is now pretty much always on. Comments - hopefully with bootcharts are welcome :)baselayout-1.13 has been the default init systems on Gentoo/FreeBSD for 3 months now and it's proven very reliable, so don't have that much fear about unmasking it. The only reason why it's still masked is that we need baselayout-1.12.9 stable as that can understand the on-disk service state from 1.13 so we can downgrade/upgrade cleanly.dhcpcd-3.0.9 will get a stable bug by the end of the month, so test if now if you have any concerns as I'll be punting older dhcpcd versions after it's stable on all arches.I've also been marking loads of GNOME packages with the ~x86-fbsd keyword. So, what still needs to be done? Well, patches need to be accepted for libgtop and gnome-vfs. Then all we need in Gentoo is for control-center to support a hal USE flag so it can be disabled on FreeBSD as it doesn't work there. That's it - just 3 little things for gnome-light to be fully keyworded. A few other GNOME packages require patched here and there, but work just fine :)