Re: Survey answers part 3: systemd is not portable and what this means for our ports
Le dimanche 14 juillet 2013 à 20:19 +0100, Kevin Chadwick a écrit :
> I certainly wouldn't run systemd on any of our systems including
> production systems or products and in fact could never run it on some
> of our embedded products because it is simply too resource hungry.
If you have requirements that are so low that the systemd memory
footprint is a problem, you should probably switch away from Linux and
definitely switch away from Debian. We do not practically support
systems with less than 256 MiB of memory.
> It is a far better and prove more workable and less problematic default
> for corner case and controversial features (almost all of systemd can be
> put under that category) that increase complexity and the number of
> lines of code to be optionally installable such as monit, redundant
> systems and carp or nagios for user access uptime than to make users
> work backwards.
What you do not understand is that systemd dramatically *reduces*
complexity.
> p.s. I haven't the time to talk about or even recollect a 20th of the
> problems that systemd poses which should be enough for anyone to say
> hang on, what is this mess, it is obviously not optimal or very
> close to suitable for all as any init system should and always
> has rightly been.
“We’ve been doing things this way for 30 years, and it never was a
problem!”
You know, I hear this sentence a lot. People who don’t want to migrate
from rsh to ssh despite the reduced user-level complexity. People who
don’t want to automate deployment because they already have a huge stack
of buggy scripts that often works.
And now people who want to stick with buggy shell scripts instead of
migrating to a much simpler, declarative mechanism.
Change resistance is normal. There is a cost to any change, and
questioning it is fine. But if we never actually did any change, we
would be stuck with Multics.
> P.s. whenever I hear someone talk about Linux and Modern it is simply
> proving to show that commenter's inexperience. Only idiots *require*
> cgroups or parallelisation the latter being only required/beneficial
> when the fastest bootup is required, which is almost never the case else
> bioses wouldn't conduct post tests or memory checks.
Systemd was not written to reduce boot time. It was written to handle
the boot process *correctly*. Reducing the boot time is a nice
side-effect for teenagers, but it was never the point.
Cgroups are not used to improve the boot time - and I’m pretty sure they
actually delay the boot process. They are used to put each daemon and
each user session in a container that can be throughly cleaned up when
needed, which is a giant step forwards in terms of reliability.
Parallelisation is not something new in systemd: we already have it in
Debian with insserv. And just like with insserv (which uses declarative
fields too, see how that makes things better), it is just a side-effect
of having done things more correctly.
Cheers,
--
.''`. Josselin Mouette
: :' :
`. `'
`-
Reply to: