From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Rj4zY-0006Vs-2O for garchives@archives.gentoo.org; Fri, 06 Jan 2012 08:17:37 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 69FD521C07F; Fri, 6 Jan 2012 08:17:25 +0000 (UTC) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by pigeon.gentoo.org (Postfix) with ESMTP id 5DA0221C03A for ; Fri, 6 Jan 2012 08:16:51 +0000 (UTC) Received: by wibhq2 with SMTP id hq2so1103769wib.40 for ; Fri, 06 Jan 2012 00:16:50 -0800 (PST) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Received: by 10.180.20.39 with SMTP id k7mr5636792wie.6.1325837808784; Fri, 06 Jan 2012 00:16:48 -0800 (PST) Sender: antarus@scriptkitty.com Received: by 10.227.199.5 with HTTP; Fri, 6 Jan 2012 00:16:48 -0800 (PST) In-Reply-To: <1325816141.2385.14.camel@TesterTop4> References: <20120103212215.GU780@gentoo.org> <20120103230918.GA7247@linux1> <4F03A1AA.6070205@gentoo.org> <20120104091743.0e1cd91a@pomiocik.lan> <4F0440B3.4090500@gentoo.org> <20120104163734.07439f2b@pomiocik.lan> <20120104163315.GV780@gentoo.org> <20120104174742.11d7002d@pomiocik.lan> <20228.34930.732592.657243@a1i15.kph.uni-mainz.de> <20120105193024.GA8291@linux1> <20120105200844.1124e9d4@googlemail.com> <1325797329.2385.1.camel@TesterTop4> <20120105210935.48306bb9@googlemail.com> <1325798764.2385.4.camel@TesterTop4> <4F0643D8.40009@gentoo.org> <1325816141.2385.14.camel@TesterTop4> Date: Fri, 6 Jan 2012 00:16:48 -0800 X-Google-Sender-Auth: -Np1_oAlwN0D_UIHZpVpEc_RFhA Message-ID: Subject: Re: [gentoo-dev] rfc: locations of binaries and separate /usr From: Alec Warner To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 7dd2e1d3-d32f-4afc-a582-d6e8eebfe430 X-Archives-Hash: b262424bfe191f35881afb375dc40848 2012/1/5 Olivier Cr=C3=AAte : > On Fri, 2012-01-06 at 08:44 +0800, Patrick Lauer wrote: >> On 01/06/12 05:26, Olivier Cr=C3=AAte 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.. =C2=A0and then when stuff breaks they call Red Hat's sup= port > 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=C3=AAte > tester@gentoo.org > Gentoo Developer