[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Survey answers part 3: systemd is not portable and what this means for our ports

> since some people might not read planet debian, here is a link to my
> third blog post in a series of posts dealing with the results of the
> Debian systemd survey:

Well I am behind on my mailing list reading just at the time when it
matters for my concerns for debian. I disagree with many of the points
roger has/atleast had settled on for merging /usr and especially
discounting arguments but haven't had time to collate them and formulate
a comprehensive response as I had planned and unfortunately my care
for Linux is diminishing daily.

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. 

What this survey that I have only just heard about after the fact and
don't know how the questions were put has pointed out to me is that
there are many very clever devs who disagree with the so-called
majority () and have very valid reasons against systemd. It is also of
such low total participants that it should be discarded on that alone.

What percentage would be perfectly happy with sticking to a simple and
standard script based system? Probably a far higher percentage, after
all anything useful systemd can do, a script based system like openrc
and optional daemons can do.

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.

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.

What do you really lose by sticking with a script based system,
potentially nothing is the point.

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.


'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

Reply to: