2012/1/5 Olivier Crête <[email protected]>: > On Fri, 2012-01-06 at 08:44 +0800, Patrick Lauer wrote: >> On 01/06/12 05:26, Olivier Crête wrote: >> [snip] >> > The only thing I see them sacrificing is loose coupling, they provide >> > more functionality than any other init system, more correctness >> > (seriously, did you ever read most init scripts out there?), more well >> > defined behavior (all systemd systems boot exactly the same), more >> > stability (I'll claim that Lennart's C is better than any of the >> > boot-time shell scripts I've seen) and well understandability depends >> > who much you can understand C. Probably a bit less understandable for >> > sysadmins, but since they can just play with config files, it's >> > probably easier to understand in the end (and much less prone to >> > breaking than mucking around shell scripts). >> As you apparently have no idea what a sysadmin does I'd appreciate it if >> people like you didn't try to guess what would make things better and >> instead listened to people that have more than their desktop to run. >> (Hint: It's not pressing reset buttons) > > I know what they do.. play in random scripts until whatever they're > trying to hack together it seems to work, because oh well, its just a > one time thing.. and then when stuff breaks they call Red Hat's support > line.
Way to insult a large number of list members. > >> Given the choice between a single line of shell ( cat "$urandom_seed" > >> /dev/urandom ) or 145 lines of undocumented C (which, if naively >> modified by me, might just make systemd segfault) ... there is no choice. > > Actually, you don't have to do that, systemd does it for you and takes > care of all the annoying details [1]. > > That said, you can trivially disable systemd-random-seed-save.service > and systemd-random-seed-load.service and instead write a unit file that > runs whatever you want. You don't HAVE to do any C to run stuff from > systemd, but it does provide many things written in C that are much more > solid than the shell equivalents. > >> I do agree with you on one point - most init scripts are really bad >> code, but that doesn't mean shell is bad, it means that you need to >> educate people and file bugs. I've laughed at SLES' /etc/bashrc, I read >> most of upstart and wondered how ... why ... is it can be drunk tiem? >> Still that doesn't mean that rewriting it in bad C is in any way more >> agreeable, and you just made debugging exquisitely painful. Yey. > > The big reason for C vs shell scripts is that the type of people who > write them are not the same.. The type of people who write shell scripts > tend to hack together stuff until it works. The people who write C tend > to think about the problem for a long time and then write a complete > solution that tries to take into account all of the possible error > scenarios. There are plenty of situations where shell scripts are entirely appropriate. I am in agreement that most of the time initscripts are not one of them. That being said I am not a fan of the tight coupling here. Init is not supposed to segfault. A bug in one of the modules may cause this to happen, so us old codger-y sysadmins (who apparently love writing shell scripts and can't write real code to save our lives) would much prefer some kind of separation. Perhaps keep 'init' as a fairly simple codebase and run 'systemd' as pid 2 and they can chat with each other (over dbus?) -A > > [1] http://cgit.freedesktop.org/systemd/tree/src/random-seed.c > > -- > Olivier Crête > [email protected] > Gentoo Developer
