Re: [gentoo-dev] rfc: locations of binaries and separate /usr

[Marc Schiffbauer]

* Olivier Crête schrieb am 06.01.12 um 03:15 Uhr:
> 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.

Oh, Are you really telling that the freedom of being able to "play
in random scripts" is a bad thing and that its better to make this
impossible by hiding everything in compiled binaries?

To me its kind of arrogant to think that the "everage admin" is too
stupid to handle her system properly. Sure there are admins that do
bad "one time things" with scripts. So what. Is this a reason to
prevent anyone from doing so?

Do you think there are also good admins, that are able to FIX a bug
in a script?

And about RedHat support: They PAY for being able USE it!

> > 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].

Yeah. And systemd will be 100% bugfree! Always! Granted!


> 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.

And if just ONE bug exists that wil make systemd segfault? A faulty
script will only fail to do the action it was made for (most
propably) ...

> > 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.

This is plain wrong and insulting. You can do more bad things with C
than you can do with a shell.


> 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.

I would be happy if it was really like that...

-Marc
-- 
8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134