On 08/18/2013 09:39 PM, microcai wrote:
>
> 在 2013-8-19 上午5:55，"pk" <[email protected]
> <mailto:[email protected]>>写道：
>>
>> On 2013-08-18 23:08, Mick wrote:
>>
>> > I honestly cannot understand why we/Gentoo are allowing the RHL
>> > monolithic development philosophy to break what we have. Is
>> > Poettering the only developer available to the Linux world? Are
>> > RHL dictating what path Debian and its cousin distros should
>> > follow?
>>
>> Problem is that Linux is dependent on udev and udev is in the hands of
>> Kay Sievers which also develops systemd together with Lennart
>> Poettering which in turn used to be a Gnome developer... With that
>> said, what I cannot understand is why people advocating systemd (and
>> the kitchen-and-sink model) are using Gentoo in the first place. Are
>> they just trying to make the rest of the Linux distro landscape as
>> miserable as Fedora? Why don't they stay with Fedora instead of trying
>> to turn Gentoo into Fedora?
>>
>> Best regards
>>
>> Peter K
>>
>
> any one complant to systemd is not a programer. he does not understand how
> bad sysvinit it is from the code point of view..
>
> some one even say the old version is more stable than latest version
> even the author say no and drop the support.
>
> this is all the stupicy of non programer. they think they understand
> progam while in fact no.
>
As a budding programmer I understand that a lot of the functionality
that users take for granted in sysvinit scripts is hacked together and
prone to bash upgrades breaking them, syntax for outside programs to
change, and other auxiliary breakages. This is true of *any* program
that relies on code not written by the author, however, and it is
managed through something called "maintenance". All code needs
maintenance or it will eventually cease to work, unless the code that
the programs rely on does not change. It's a fact of life for
programming projects. Some would rather maintain C code than bash
scripts. Nothing wrong with that. I prefer C over bash as well, but it's
not like bash is *terrible*. It's a language that practically any
serious *nix user will know some variant of. Due to this, sysadmins and
users can gain familiarity with sysvinit or other bash-script-using init
systems much faster than with a broad, C-only init system like systemd.
This familiarity means end-users can fix their own problems without
needing to recompile or do backtraces or other higher-level debugging
tasks. This also ensures that the primary init binary stays untouched
and can still bring up a system.
sysvinit may not be perfect, but systemd's approach ("Include as much as
possible in one package") is just as bad, if not worse. At least
sysvinit is hackable, which adds to its versatility. Systemd is not free
of good ideas. cgroups can be a useful, optional build-time thing that
Linux users can opt into. Parallel boot sequences can speed up the
booting of a machine that launches many services. The fatal mistake made
from a technical point is that systemd became too ambitious. Taking on a
new feature or a new task in a project has a multiplicative or
exponential effect, *not* an additive one. Given the broad array of
features that systemd has, its purpose is spread too thin and tries to
do too much. It's not simple code and it does too many things.
People often forget that there are other init systems out there, as
well. runit is a great little package, and also uses bash scripts like
sysvinit. It's designed to be lightweight, supports a custom amount of
run levels, and a few extras I'm forgetting. The important thing about
runit is that *it knows what it is*. It's an init system with
service-management added in. It doesn't log things for you, it doesn't
manage your splash screen, it doesn't manage devfs/sysfs, it doesn't
make you coffee and comb your hair, it doesn't take over
security-related tasks. It knows itself and is *happy* to stay focused
on its one job. Because of this, runit and other specialized projects
can focus on being the best it can be on that single task. Compare this
approach to a project that wants to add tons of features or do a little
bit of everything to appeal to the broadest audience possible. This is
literally what systemd does, as a project and as code. It's a "yes"
project instead of a "no" project.
Lastly, programmers are not immune to the effects of cognitive biases.
They are just as prone as anyone else to social engineering and
groupthink influencing their decisions. To believe any group is immune
to social misdeeds is foolhardy. This doesn't completely discredit
programmers (or other groups that fall to kool-aid), but it certainly
casts an unfavorable light and earns them suspicion. By asserting that
only the programmers' viewpoints matter, you are forgetting the social
aspects of software development, which are equally important. Without an
audience and users who have good relations with the devs, there's not a
healthy dialogue to enrich the project and make bug fixes, feature
discussions, and so on easier to work with. Without users, software
doesn't mature and bugs are slower to be found. You need both the
technical and the social in order to have a healthy project. Excluding
the social aspect right out of the gate will alienate your potential
audience in the FOSS world.
