Arguments against systemd

JoshuaFlynn · 2017-10-05 22:41:06

Whilst I'm aware most users here will be familiar with the arguments I'm about to present, this is more aimed at new users who are unfamiliar with the whole systemd crisis, and is built to both inform and refute some pretty stale arguments I've seen. Please be aware that for the purposes of this argument, I will have to quote adversarial sources to catch key points, and users are informed this list is not exhaustive.

Arguments against:

1) Systemd was declared an init system which has bloated beyond scope and context. Programmers call this "feature creep", and it's well known for producing buggy and unstable code. Quoting the least informed source of information Wikipedia:

Following its integrated approach, systemd also provides replacements for various daemons and utilities, including the startup shell scripts, pm-utils, inetd, acpid, syslog, watchdog, cron and atd.

https://en.wikipedia.org/wiki/Systemd#C … _libraries

Annnd it also controls the firewall, port forwarding.

It has gone from an init system to a total bloat that guzzles packages like Red Hat's paychecks depended on it. Besides "feature creep" this has a number of issues:

a) Red Hat were dishonest regarding the intention of systemd as 'just an init system' from the outset, and used it to deceive members of the Linux/Unix community (duping them into accepting it), and thus is basically a trojan, and thus cannot be trusted.

b) Systemd replacing everything violates the Unix philosophy of 'do one thing and do it well'. We'll cover why this is important in more depth later on, but basically this move does not allow the best packages to succeed, but only the systemd ones, which degrades user performance.

c) Systemd has no boundaries, and ergo is basically turning into a monolith. Monolith OSes are extremely hard to maintain (see Windows), and this undermines package flexibility, which in turn stifles competition.

d) Any OS that does not fall within systemd's grasp is fundamentally rejected, which lowers the number of available OSes for users to choose from. This is bad from the user's perspective.

2) Red Hat, who build systemd, work for the NSA, XKEYSCORE (a notably X-server themed name) is deployed on Red Hat servers to that effect.

3) As no surprise to anyone, systemd is inherently insecure, such as allowing remote code executions via DNS, or gaining root by adding a digit to the start of your username. Having dug into this, systemd's main developer Poettering had stated that 'users are root by default', as opposed to be, err, users.

4) Poettering & co often refuse to fix blatant bugs within systemd. Including the two security flaws above, quoting the register verbatim:

The issue was raised through a GitHub Issues submission a week ago, but Lennart Poettering, one of the lead maintainers of systemd, insisted the software is working as intended and declined to implement changes.

http://www.theregister.co.uk/2017/07/05 … _accounts/

IE systemd is intentionally insecure by design. The attitude of not fixing bugs and blaming everyone else also means buggy code that might even crash your machine has no fix date or period. Not so much collaborative as controlling.

5) All of this. The biggest eye openers from that list include:

a) "pid 1 does DNS" (for non-nerds, PID1 is the master process, which should only be occupied by a simple OS process restarting script. Giving an internet connection access to your master process is basically backdoor city)

b) "systemd-nspawn can patch at will any kind of file in a container" - basically encrypted containers can be backdoored.

c) "remote pid 1" - I think this one is pretty self-explanatory.

6) Systemd prefers to dial home to google servers by default, quoting:

Since the Google resolvers are a very reliable widely anycasted service
which third parties are encouraged to use they actually look like a sane
fail-safe default, hence I am closing this bug.

https://github.com/systemd/systemd/issues/2447

Ah, good job reliability of a single server service is the only criterion and not say, DNS redundancy (IE multiple DNS fallbacks) through several censorship resistant networks.

For those of you unfamilar, Google were previously funded by In-Q-Tel, the CIA's investment arm[1][2], regularly found abusing their positions of power[1][2][3] and regularly censoring people[1][2][3][4][5], or even plotting coup d'eats certainly make it a questionable choice, especially against the backdrop of free and open software for the greater good not censored by anyone.

7) The design of systemd is bad for anyone who runs servers (which is ironic given Red Hat mostly deal server side).

The increased bloat of 'ever more' dependencies means 'bare metal' OSes running in VMs is not realistically possible, and those wanting to keep their servers as lightweight as possible (you know, to save footprint space and CPU) are immediately denied by the presumptious nature of systemd that basically tells you, the user what it wants (perhaps an accurate reflection of the attitudes of the systemd developer's writings). It's no coincidence that Alpine Linux, built primarily for servers and VM containers (and security) boots up with... err, OpenRC. The over-reliance of sticking everything into PID1 which increases the risk of an actual system crash runs contrary to the mandated stability required by servers and their uptimes.

8) 'Do one thing and do it well'

There's a reason why programmers, developers, coders, designs etc do not have 'all-rounder' abilities; most try to specialise in a specific area of knowledge, and get good at that one specific area. For example, I would not expect a network programmer to start handling graphics (unless there was, somehow, overlap between the two, such as a remote session), or for someone who builds user interfaces to go around telling library developers what to do.

Systemd, by adopting so many disjointed and unrelated packages to it so-called 'init' claim, is arguing that it doesn't just specialise in 'inits', but in every other package that it absorbs, which is patently absurd (they can't even do the init part right, what with it's backdoors and crashability, see above). Even if we assume they're walking masters of everything (which they're obviously not), the more packages they take on, the less manhours they have available to package development, which means, you guessed it, fewer bug patches and fewer security patches.

This also means another thing; fewer features. Packages having their own dedicated developers who know it inside and out can build features into it in a dedicated way (IE more efficiently, thus using less code and less CPU), which in itself allows other developers to use those packages more effectively. By absorbing everything into a monolith, it becomes the monolith's maintainer's responsibility to add features, which means their knowledge is applied more generally.

There's a famous saying: many hands make light work, and in this case, merging too many packages spoils the broth. What exactly is systemd? Init? Networking? Login? Logger? Firewall? Calendar? We don't know; the overall monolith itself becomes less maintainable because more knowledge is required by new developers before they can even properly approach the thing, where-as separate, isolated packages can be easily taken up and managed.

So to round off, who exactly benefits? So far, we've established:

a) Desktop users don't benefit (less package selection, less OS selection, less security, bigger footprint space on their harddrive, greater odds of crashing).

b) Server users don't benefit (repeat).

c) Developers don't benefit (more entangled mess that 'absorbs everything', giving package developers no way to be able to introduce their own packages, hard to read documentation, poorly kept code, inaction on bug and security issues, refusal to collaborate, refusal to accept blame when appropriate).

d) Corporations [other than either Red Hat, Microsoft, and possibly Google - assuming they're okay with Android systemd pwnage] don't benefit (see counter-arguments).

Who in their right mind would want this kind of setup?

1) Red Hat (removes competition, more profits to them if everyone is using their kit, if it causes issues they get consulted)

2) Agencies (introduces insecurity, exploitable bugs, backdoors) [irony here is given they use Red Hat technology, they're making their own stuff insecure.]

3) Microsoft (remove competition. The division alone is scoring them points).

And as far as the Linux/Unix community is concerned, at least two of those are the bad guys.

Counter-arguments:

P1) Systemd offers improved boot times.

A1) Boot times are pretty unimportant in the grand scope of things. Rarely do users complain of how long their computer takes to boot (unless it happens to be loading a Windows OS on a decrepit machine), and Linux init systems have always kept boot times within perfectly acceptable constraints, which comes down to a subjective psychological perception and not a logical hard fact (for what purpose are we trying to make boottimes 'faster'? This isn't an episode of 24 where a missile will detonate unless we can run a bash script within 30 seconds).

It's curious that this is one of the few arguments 'in favour' (if boottime is your only justification, I've got a brick over here that boots instantly), when a system has a multi-tude of factors (and boot times must be pretty unimportant given how many people still use Windows OSes), factors which include:

1) Security. [systemd violates this]

2) Portability. [systemd violates this]

3) Compatibility. [systemd violates this]

4) Development capabilities (IE how easy is it for the developer to build or implement what he/she wants?). [systemd violates this]

5) CPU speed. [systemd does not offer any enhancements]

6) Flexibility. [systemd violates this in a big way]

7) Visual appearance (EG text versus graphics, ability to choose desktop enviroments). [systemd violates this]

8) OS footprint size. [systemd violates this]

9) Stability [systemd violates this, see bug patching attitudes and PID1 obsession above.]

Essentially, Red Hat is asking 'are you willing to sacrifice major features of your OS (IE complete freedom) for a couple of seconds off your boot time'? Any sane person would say 'no'.

P2) Systemd offers corporations predictability/consistency.

A2) Corporations looking for 'predictability' or 'consistency' can and usually do go one of two routes; they either choose to build their own in-house OS (often on-top of a Linux/Unix etc system, for example, Apple, Google, Nintendo, Sony etc), or they go down the Windows route (Windows already offers 'consistency' plus a huge dollop of 'adaptability').

If corporations go down the former route - which they often do - they want to be able to customise the OS to their needs, and this is where systemd crashes into a wall and bursts into flame. By restricting init systems and blocking package flexibility, corporations cannot customise their copy of Linux/Unix etc type OSes because it's already 'locked in'.

There's a double downside to this, because it also means only Red Hat holds the experience (can anyone say 'money'?) and 'as a service' organisation, being able to anti-competitively form a monopoly on Linux/Unix etc designs actually hurts corporations when it comes to Linux/Unix because it means they can either choose Red Hat with systemd, or they basically choose nothing at all. I'm sure someone from FreeBSD will scream out they're systemd-free (try installing KDE or XFCE and then eyeballing for /lib/systemd), but the trojan horse nature is unlikely to stop at just 'every Debian OS ever'.

In conclusion:

If users truly care about privacy, security, stability and freedom, and does their due diligence research into systemd, they would recognise no-one in their right mind would want a systemd setup, and should not merely adopt a passive approach to it, or sit on the fence and watch, but take an active participatory refusal as if the NSA itself had come round in person and offered to install backdoors. If we don't show we wholly reject such a monolithic monstrosity, it will merely encourage them to try again, sooner and elsewhere.

Last edited by JoshuaFlynn (2017-10-05 22:50:26)

golinux · 2017-10-05 23:00:11

My favorite systemd analysis:
http://lkml.iu.edu//hypermail/linux/ker … 02496.html

And data from the systemd camp tells the story . . . If you scroll down this page you will see two graphs that say it all:
https://www.freedesktop.org/wiki/Software/systemd/

If all the "wontfix" issues were included in this graph the numbers would be MUCH higher:
https://in.waw.pl/systemd-github-state/ … issues.svg

devel · 2017-10-06 06:38:46

Yes, systemd sucks, but this is really misinformed and undermines the credibility of devuan. Systemd is a project with lots of parts, PID1 is only a very small part of all the code. We should all understand these basics if we want to be taken seriously!

1) Systemd is an umbrella project, that contains a lot of different pieces. Most of it is unrelated to PID1.

2) This needs a lot of tin-foil, but at least it is factually correct from all I can tell.

3) Some parts running in a severely restricted environment had bugs. These are unrelated to PID1.

4) That happened, but things got fixed anyway.

5) PID1 does not do DNS, that is a separate process, Being able to change any file in a container is inherent in all container management tools, never heard of remote PID1 (do you have a reference here?)

6) A part of systemd will use Google DNS servers if nothing else is configured by the distribution nor the administrator. So if this ever happens, it is far from systemd only that fucked up.

7) But systemd restarts services that break! It surely is great for servers!

8) is mostly a matter of preference.

Developers like systemd a lot, that is why it gets used everywhere, leading to the entanglement that devuan sets out to unmake.

In the counters to systemd section:

* "Security": I ran into a lot of people that claim that their systems get more secure with systemd since it makes it so simple to restrict what daemons can do. It would be great if Devuan could tune its init scripts to run all daemons with the same restrictions as they run on Devuan to show that this can be done with any init system.

* "Portability": The systemd crowd will argue "Why is that important?" Do you have any argument for that? Is there any init system that is used widely between different OSes?

* "Development Capabilities": Why does so much software depend on systemd if developers are hindered to do what they want? Any good argument for to counter that?

* "Flexibility": Why is that? All inits just start stuff up, why would one way to start stuff be less flexible than another?

* "Visual Appearance": I do not understand what this point is about at all. You can surely run X11 and wayland and text based terminals in systemd, too?

* "OS footprint size": The counter to your argument I get to that is "but systemd does so much more" and "sysv-init needs a shell, core tools and a lot of other cruft that is built into systemd, so systemd is actually lighter on resources". How to counter that?

* "Stability": I have not seen anybody debate that systemd is more stable than sysv-init yet. Did you run into that claim yet?

Last edited by devel (2017-10-06 07:25:19)

devel · 2017-10-06 10:07:56

golinux wrote:

If all the "wontfix" issues were included in this graph the numbers would be MUCH higher:

"WONTFIX" is not a thing on github, it is just something used colloquially to mean "a bug closed without any action being taken". All the "WONTFIX"es in systemd are just closed bugs and thus part of the graph you referenced.

It would be nice if we could get the facts straight so that it is harder to reject our claims as invalid.

FOSSuser · 2017-10-06 10:53:28

I don't want it, I don't need it, It isn't the unix way of doing things, it doesn't do anything better than what was before it, & it is mainly so that RedHat can make money out of selling service packages to businesses that don't understand its inner workings!

If they want to create their own operating system, go ahead & do it, but leave our Linux system alone!

Last edited by FOSSuser (2017-10-06 16:34:13)

golinux · 2017-10-06 14:40:15

devel wrote:

golinux wrote:
If all the "wontfix" issues were included in this graph the numbers would be MUCH higher:
"WONTFIX" is not a thing on github, it is just something used colloquially to mean "a bug closed without any action being taken". All the "WONTFIX"es in systemd are just closed bugs and thus part of the graph you referenced.
It would be nice if we could get the facts straight so that it is harder to reject our claims as invalid.

Maybe I'm missing something - wouldn't be the first time - but just because Lennart has decreed a bug as wontfix doesn't mean that the bug doesn't exist so it's in effect still an open bug. Which means the number of existing bugs is probably much higher than the 'open' bugs indicates and the number of fixed 'closed' bugs much lower..

JoshuaFlynn · 2017-10-07 01:39:06

Foreword: Your post reads like a pro-systemd user, but at a few select junctions you say 'other people say'. Poe's law. Regardless of if you're parodying systemd supporters or being legitimately serious, I will direct the argument at you as if you are one and the same. If you're not, don't take it personally, you're just getting how I would naturally react.

devel wrote:

Yes, systemd sucks, but this is really misinformed

Strawman argument, citations were provided, you even immediately contradict yourself on that line by saying:

but at least it is factually correct from all I can tell.

So which is it? Misinformed or factually correct?

2) This needs a lot of tin-foil,

Ad hominem. As you already acknowledged, it's factually correct.

Feel free to point out which parts aren't and I will dig out appropriate additional references for those.

1) Systemd is an umbrella project, that contains a lot of different pieces. Most of it is unrelated to PID1.

Strawman argument.

Firstly, systemd was not presented as an 'umbrella' project but an 'init' system (I quoted the fedora magazine which is about as pro-Red Hat as you can get on that one). You know what a systemdaemon is, right? A background process classically in charge of one thing. Saying there's 'lots of different pieces' doesn't refute the fact parts of it still hook onto PID1 making it pretty crashable.

Citations you'll find are on suckless, some of which come verbatim word of mouth.

3) Some parts running in a severely restricted environment had bugs. These are unrelated to PID1.

This is a gross generalisation. 'Some parts'? What parts? What part are you actually trying to refute?

4) That happened, but things got fixed anyway.

Again, generalisation. 'That happened' - what happened? 'Things got fixed' - what things?

5) PID1 does not do DNS,

Source?

Here's mine:

systemd-resolved now includes a caching DNS stub resolver
and a complete LLMNR name resolution implementation. A new
NSS module "nss-resolve" has been added which can be used
instead of glibc's own "nss-dns" to resolve hostnames via
systemd-resolved. Hostnames, addresses and arbitrary RRs may
be resolved via systemd-resolved D-Bus APIs. In contrast to
the glibc internal resolver systemd-resolved is aware of
multi-homed system, and keeps DNS server and caches separate
and per-interface. Queries are sent simultaneously on all
interfaces that have DNS servers configured, in order to
properly handle VPNs and local LANs which might resolve
separate sets of domain names. systemd-resolved may acquire
DNS server information from systemd-networkd automatically,
which in turn might have discovered them via DHCP. A tool
"systemd-resolve-host" has been added that may be used to
query the DNS logic in resolved. systemd-resolved implements
IDNA and automatically uses IDNA or UTF-8 encoding depending
on whether classic DNS or LLMNR is used as transport. In the
next releases we intend to add a DNSSEC and mDNS/DNS-SD
implementation to systemd-resolved.

https://cgit.freedesktop.org/systemd/sy … ec9c#n1128

that is a separate process, Being able to change any file in a container is inherent in all container management tools, never heard of remote PID1 (do you have a reference here?)

Yes, if you had bothered reading my post, you'd have seen the link under 5. Here's another reference:

systemctl's -H switch for connecting to remote systemd
machines has been extended so that it may be used to
directly connect to a specific container on the
host. "systemctl -H root@foobar:waldi" will now connect as
user "root" to host "foobar", and then proceed directly to
the container named "waldi". Note that currently you have to
authenticate as user "root" for this to work, as entering
containers is a privileged operation.

https://cgit.freedesktop.org/systemd/sy … ec9c#n1500

6) A part of systemd will use Google DNS servers if nothing else is configured by the distribution nor the administrator. So if this ever happens, it is far from systemd only that fucked up.

Sounds like a terrible argument trying to justify systemd decisions, which:

undermines the credibility of devuan

Google servers point is easily refuted:

1) Systemd was an init process. Since when did they go from calling themselves an init into a DNS? And who authorised that expansion? What vote? By what group?

People only approved adopting it as an init system. Not a 'lets connect to google by default' system.

1) Even if we irrationally ignore that first point, who, if anybody, did they consult with when determining which DNS service, if any, they should pick as a fall back? Tor browser manages DNS lookup without being reliant on a single one, so what's the deal?

2) Why was google specifically chosen and none of the other countless other DNS services? Don't say 'reliability' because it presumes universal accessibility, which ignores geo-politics. Ever tried to connect to google from a country (Egypt, Libya, Syria, etc etc) that tries to kill off it's internet? Systemd developers thinking with an American-centric viewpoint, which is not particularly all inclusive.

3) Why was the option to have no default DNS service at all not, more importantly, chosen, or even instead a list of selectable DNSes (should a user so want that), picked?

Google are the absolute worst choice for numerous reasons, as previously provided (abuse of power, censorship, eagerness on backdoor politics involving destabilising governments, oh and major point: profit by datamining), and it's clearly highly questionable.

7) But systemd restarts services that break! It surely is great for servers!

This doesn't refute my point, given I refer to systemd itself. If systemd breaks on PID1, how it's going to restart then? PID1 should be as simple as possible to avoid the biggest chance of crashing. Adding DNS and remote access and everything else through it is asking for trouble.

And why are you arguing a pro-systemd stance when falsely claiming stuff about 'undermining devuan's credibility'?

8) is mostly a matter of preference.

Preference implies freedom of choice, which systemd removes. See earlier point.

Developers like systemd a lot,

Citation? Statistics? Numbers? What is 'like a lot'? In comparison to what?

Weasel words don't work here. Where are your facts?

that is why it gets used everywhere,

Really? Because I don't see people with a viable alternative. Looks more like it got injected into Debian upstream and OSes were forced to adopt it (being based on Debian, EG Mint, Ubuntu and their derivatives likewise), which given the large numbers of complaints across the board (including the existence of Devuan itself), absence on Alpine, and the total verbal rejection by the BSD community largely suggests otherwise.

Wasn't Ubuntu working on Upstart before they were forced to ditch it?

leading to the entanglement that devuan sets out to unmake.

Devuan can only do that by offering a genuine alternative, which is my primary criticism levelled at systemd, which takes that freedom of choice away. All of my favourite OSes have systemd on it, and I hate systemd, but by your inferred logic, because I didn't choose 'otherwise' I 'like it' (because you reverse justify by suggesting if someone owns systemd they must implicitly like it, which makes huge assumptions to users unaware).

Now to address your other blatantly pro-systemd arguments (for someone supposedly anti-systemd?):

* "Security": I ran into a lot of people that claim that their systems get more secure with systemd since it makes it so simple to restrict what daemons can do. It would be great if Devuan could tune its init scripts to run all daemons with the same restrictions as they run on Devuan to show that this can be done with any init system.

Weasel words. Citations please. Who are these 'lot of people'?

You didn't even address the root privilege exploit or the remote DNS code execution that Poettering refused to patch and you call it 'more secure'? You do realise the code exploit works by a DNS lookup, right? Just a DNS lookup?

Sounds super secure to me (not).

* "Portability": The systemd crowd will argue "Why is that important?" Do you have any argument for that? Is there any init system that is used widely between different OSes?

Ability to be deployed on a wide vary of systems, especially with the emerging 'Internet of Things' and embedded systems (used pretty much everywhere these days) is extremely important. Unless you have a narrow 64-bit desktop only view.

From what I've seen OpenRC and sysvinit held that position, until a 50/50 vote split (apparently meaning 'popularity' and not 'controversy') forced systemd through the door, which I do believe violated general voting priniciples as it's usually by a large margin and not a small one, so someone must have been pulling a few strings.

* "Development Capabilities": Why does so much software depend on systemd if developers are hindered to do what they want? Any good argument for to counter that?

Software doesn't 'depend' on systemd so much as systemd ripped out their previous dependencies with no choice and developers were forced to adopt it or die out.

How are you going to hook a shutdown event without systemd if systemd oversteps it's boundaries and controls that? Or the firewall? The port forwarding? The DNS? What the hell doesn't systemd control that developers can call?

Removal of choice does not equate to acceptance, and you know it.

Plus, no citations bro.

Next lame pro-systemd argument:

* "Flexibility": Why is that? All inits just start stuff up, why would one way to start stuff be less flexible than another?

Except you contradicted yourself because you stated, and I quote:

Systemd is an umbrella project

So which is it? An init system or an umbrella project? An umbrella project infers no flexibility because it absorbs everything. If it's an init, why the hell is it picking DNS services for me? Can't just pick and choose 'what systemd is' to suit one situation over another.

* "Visual Appearance": I do not understand what this point is about at all. You can surely run X11 and wayland and text based terminals in systemd, too?

What, text based terminals rendered inside graphical environments like Wayland? I refer to text-only login systems used by servers to keep their processes lightweight (believe it or not servers rendering graphics is unnecessary, consumes CPU, and servers do not equate to desktop systems, which is surprising because surely a Red Hat developer should already know that, right?). Saying that 'another init system provides this service' is entirely my point that 'systemd doesn't'.

The fact you can only offer two options, either X11 (a graphical system that has been around since forever and didn't need systemd, so this isn't something 'systemd offers' anyway) or it's blatant systemd replacement Wayland, which is basically GNOME-only (because who wants a different desktop environment? Not all those other users out there with Trinity and Lumina, KDE, XFCE and however many other environments I can't count), proves my point it has no diversity. Do I have to rip out systemd if I don't want Wayland too?

You woo me with your diverse options.

* "OS footprint size": The counter to your argument I get to that is "but systemd does so much more" and "sysv-init needs a shell, core tools and a lot of other cruft that is built into systemd, so systemd is actually lighter on resources". How to counter that?

All inits require 'core tools' (to quote Cinema Sins 'why is it called the CORE if it isn't central to anything?'), systemd included (doesn't matter if it absorbs them, it's still there), and this argument is dishonest because it presumes systemd already contains less resources. Are you honestly suggesting that systemd, which 'pulls in everything', has no option to remove anything and has no way of knowing what I want in advance, could compete with a system I've manually selected the packages for?

This cannot be answered by anyone honest, because who has done a 'systemd only' bare metal base OS install in the Red Hat team to set a baseline? Is it updated every time they absorb a new package? We don't know because systemd keeps adopting more and more things.

Why would I need graphics, DNS and a firewall on an embedded system whose only job is to operate a power system?

And does sysvinit have a remote code DNS backdoor? No.

* "Stability": I have not seen anybody debate that systemd is more stable than sysv-init yet. Did you run into that claim yet?

My stability argument is on the PID1 crashability basis on the OS level. Because systemd isn't an init but a Monolith (your own Devuan page states how it was like stripping everything off a bicycle), it's crashable because PID1 is no longer a simple 'restart shell script' but a complex monstrosity.

If we're talking some bizarro 'sysvinit versus only the init components of systemd and not systemd as a whole' which is pretty fallacious (given the 'umbrella project' argument), I've encountered quite a few pages where developers have complained about the difficulty in initialising processes using systemd (back when it was still an init), which were incredibly buggy, and when they filed bug reports, they often got slammed by the EWONTFIX technique. The absence of documentation on processes greatly impedes stable development. I doubt I could find those links again, but I can testify I read those and it's what initially soured my opinion of systemd.

If they want to however strip out systemd into a stand-alone init, it'd allow tests to be done for stability, but I treat systemd as a whole, and not just it's init system parts (because that would be like saying the 'US military' is responsible for wars but not the 'US government').

I think the real proof though is if systemd remained as just an init (and didn't absorb everything and force other systems to become dependent upon it), it would have been fairly subject to competition from other init systems. The fact it's been designed to stifle competition suggests they're not interested in the best one succeeding.

"WONTFIX" is not a thing on github, it is just something used colloquially to mean "a bug closed without any action being taken". All the "WONTFIX"es in systemd are just closed bugs and thus part of the graph you referenced.
It would be nice if we could get the facts straight so that it is harder to reject our claims as invalid.

The onus is on systemd to provide accurate numerical reporting of which bugs are closed under which heading (as we're not privvy to systemd's statistics because we're not Red Hat). If they purposefully merge statistics of bugs reported and bugs closed but don't delineate between which have been fixed and which haven't been acted upon, the only one that can be accused of inaccurate reporting is systemd itself for purposefully blurring the numbers.

The fact there are news articles reported in major news outlets reporting on the EWONTFIX attitudes of systemd developers itself suggests it is a systemic problem, especially when one considers the context of not acting on a remote code exploit that is injectable via a DNS server. Good job Google with their DNS services have 'never' been caught underhandedly working with any agencies or we would all be boned.

Now I just need to find where I left my tin foil hat...

golinux · 2017-10-07 02:06:03

Good grief . . . 2641 words (including quotes). You really have outdone yourself this time. Perhaps this might a good time to lock it?

JoshuaFlynn · 2017-10-07 02:26:24

golinux wrote:

Good grief . . . 2641 words (including quotes). You really have outdone yourself this time. Perhaps this might a good time to lock it?

It's good, no need for a lock, as you said in the questions thread, forum has a lack of code of conduct, and as a man of freedom I'd like to see if anyone else has replies or anything else to add.

golinux · 2017-10-07 02:58:32

We do not have a "lack have of code of conduct". We have an (almost) No Code of Conduct. I personally don't see how anything good can come of rehashing this topic (which has been beaten to death for many years). it is also a waste of bandwidth, But let it continue for a while. Hopefully it will grind to a halt with not even a whimper.

JoshuaFlynn · 2017-10-07 03:34:34

golinux wrote:

We do not have a "lack have of code of conduct". We have an (almost) No Code of Conduct. I personally don't see how anything good can come of rehashing this topic (which has been beaten to death for many years). it is also a waste of bandwidth, But let it continue for a while. Hopefully it will grind to a halt with not even a whimper.

So, hold on, let me get this straight, you said you weren't worried about trolls because you had 'almost no code of conduct', but you're concerned about serious, fact citing debates? Your own code even says "We are all adults capable of having intelligent, adult discussions", and I've not done anything to dissway from that position.

Of which, lets be clear here, is presented in the spirit of Devuan, a community I had presumed to be opposed to systemd (I mean, you spent the last 2 years trying to rip the thing out so you can't be fond of it) and would therefore welcome a key summary with points that, naturally, boost the position you've taken and encourage others to join your particular community - "We accept everyone's contributions".

No ad hominems were presented, citations applied appropriately, civil presentation utilised and you added your own points without it being an issue at that point (the graphs were excellent, haven't even seen those). I've not encountered any place that centralises or explains any of the concerns of systemd in a clear enough manner (not even the anti-systemd wikipedia which fairly technical), and is certainly scattered through-out the internet (certainly, the diverse sources cited are a hat tip).

I wanted to both summarise and counter a lot of cliche arguments I've read.

If you feel I've misguaged Devuan (I had presumed it to be anti-systemd), I will gladly leave, including dropping all associated projects, and resume my search for an OS that is opposed to systemd in spirit.

golinux · 2017-10-07 04:00:27

This thread serves no purpose except as troll bait (and it worked). So can you please take a deep breath, leave the dramatic gestures and defensiveness aside and take it down a notch. Thanks.

JoshuaFlynn · 2017-10-07 04:23:28

golinux wrote:

This thread serves no purpose except as troll bait (and it worked). So can you please take a deep breath, leave the dramatic gestures and defensiveness aside and take it down a notch. Thanks.

Firstly, no-one does research for 'troll bait' and that's clearly not my intention, so I do find the point insulting and confusing (and are you inferring devel is a troll?). Trolls use emotive, generalised rhetoric that aren't substantiated by facts. Why would I waste numerous months compiling information for a 2 day troll? Why not just make a generalised thread and be done with it?

On the contrast, you've got a literal baity style thread comparing systemd to Windows. This is a factual analysis of it's flaws, you know, using citations and facts.

None of these gestures have been dramatic (text never conveys intention well), nor are they 'defensive'. I'm simply not interested in investing time and resources into a group if they are, in-fact, not anti-systemd, so it's more a query for clarification.

If I'm not able to factually reason why a person would want to logically swap out systemd for an alternative (which is the main reason a person would want to adopt Devuan, note), then there's no point me aiding an OS development that actively inhibits it's own userbase from arguing in favour of it's own existence. I'm not interested in investing time putting things together if it's only going to either get locked or classed as 'troll bait'.

If you had, alternatively, explicitly stated in your code of conduct (which is absent any real codes) that you prohibit debates over systemd, or indeed, any information regarding systemd, not only would I have likely not posted this thread here, I likely wouldn't have registered at the forum either. Users do not expect to find implicitly held admin rules by 'discovery' because it implies a time investment that might, ultimately, be wasted.

ralph.ronnquist · 2017-10-07 05:59:43

Why don't you find yourself a blog site somewhere, where it'd be good and natural to line up all those beautiful words. This forum is populated by mostly intelligent people with no need or desire to waste (more) time and thought on systemd.

JoshuaFlynn · 2017-10-07 06:21:39

ralph.ronnquist wrote:

Why don't you find yourself a blog site somewhere, where it'd be good and natural to line up all those beautiful words.

Post pro-Devuan arguments not on a Devuan forum? Even if we take it strictly as being systemd, wouldn't this just iterate the point about systemd counter-arguments being 'scattered over the internet'? Why would someone be searching for a 'blog site somewhere' for arguments on why to adopt Devuan or oppose systemd?

This forum is populated by mostly intelligent people with no need or desire to waste (more) time and thought on systemd.

But that's the thing, as my first post notes in the very first line (which anyone should have read upon entry), that the people of this forum already know most of these points. But it also clearly says "this is more aimed at new users who are unfamiliar with the whole systemd crisis". New users of Devuan. It does not ask forum users to contribute (nor would I expect them to), just that it's an option if they wish.

New users who aren't necessarily on your forums, nor familiar with the systemd issues. Intelligence is only capacity to process, it does not mean one already possesses knowledge. More users means more developers, more donations, there's no logical reason why you'd want to brush why someone would want to switch from Debian to Devuan under the carpet.

For example, what do you guys do if someone asks 'but why don't you use systemd', or 'why is systemd bad', or 'why should I use Devuan instead of Debian'? What collated thread or repository of information do you point them to? Do you expect them to assume it as true without knowing the whys and hows? Init comparisons are long since gone because the nature has changed, and merely saying 'package freedom' would merely involve stating the above points (point 8, specifically), except you'd then have to answer 'why is systemd not free?'.

You guys are already here, why would I be trying to win you over to Devuan? It's the new users, the undecided you want to encourage to join.

golinux · 2017-10-07 06:57:59

If you think that reinventing the wheel is a good use of your time, go for it. We have more important things to do. Devuan will fail or succeed on its own merits, There is no need to 'win' over users who should be intelligent enough to find the many excellent analyses that are already available (and have been for years).

JoshuaFlynn · 2017-10-07 07:47:43

golinux wrote:

If you think that reinventing the wheel is a good use of your time, go for it. We have more important things to do.

I certainly feel I could definitely contribute, and this thread is not intended to prevent you guys/gals from your developments, nor would I expect anyone to specifically contribute or aid me or this thread as such, nor was any such help asked for. In-fact, I would go so far as to explicitly decline that help but I did not want to be rude. I'm perfectly content to debate solo, and this was my assumption from the outset.

Devuan will fail or succeed on its own merits,

Certainly (I was not suggesting Devuan did not have merits, just that advantages over systemd are not clearly stated), and I intend to draw attention to those merits and encourage other users to switch over to Devuan (which means ideally this thread will see re-use as a reference point so I don't have to rehash the same points when introducing them to it, I like to save myself future work, as any smart person does).

There is no need to 'win' over users who should be intelligent enough to find the many excellent analyses that are already available (and have been for years).

And I intend to collate such analyses here, such users don't, as you say, reinvent the wheel by ending up doing similar searches, uncovering similar information, and putting it together to form similar conclusions, all of which takes time and resources (in a technical sense, they are being indirectly won over). Hopefully they will find all that they need here. Nor do I want to make exclusive provisions for only technical users (as your code of conduct says, you welcome all types of people, and I intend to befriend all types), but also users who may find certain concepts unfamiliar, I try to avoid assuming anything about my audience if I can, so it is accessible for all, I find a lot of analyses tend to be pretty technical, and I wouldn't expect a newcomer from Windows (who asks me what Linux distro should they use and why) to understand, so don't be surprised if my comments seem 'rudimentary' or 'obvious'. One thing I've learned is to never assume someone else knows what I know when it comes to learning.

I feel that we have perhaps gotten off on the wrong foot here, and I feel, to paraphrase Thomas Hardy's poem, had the circumstances been different, we'd be - perhaps, not to assume - friends. I merely wish to offer, besides the background images and planned contributive support (such as the assimilation conversion kits), verbal rhetoric supporting Devuan. I'm not your enemy! I must admit these responses did kind of surprise me. I waited the 2 years as Devuan matured into RC (I had tried the early beta release that had only XFCE - I was the guy who made that one-off post requesting LXDE and mentioned the package modules idea on the early discussion board buried in one of the long early threads, and I was pleased when you guys added it along with KDE), and I wouldn't wait those 2 years to just scuttle it now.

Friends? Or at least maybe neutrals?

ralph.ronnquist · 2017-10-07 08:45:13

Sorry. I lost interest there. Too many words. To paraphrase Ramsey: "What you can't say in just a few words, you should whistle.".

JoshuaFlynn · 2017-10-07 09:15:24

A better saying; if you don't have anything nice to say, you shouldn't say anything at all.

JoshuaFlynn · 2017-10-07 09:41:15

I mean, I don't get it, if you're not going to read the post (either the first one, the direct response or even a single line), why even reply?

You're all but effectively ignoring the thread, so why waste the effort of coming here to 'not read' a post and then posting a reply to a post you've 'not read'?

I mean, who's writing the troll bait now?

Last edited by JoshuaFlynn (2017-10-07 09:41:52)

FOSSuser · 2017-10-07 09:57:15

I wanted to both summarise and counter a lot of cliche arguments I've read.
If you feel I've misguaged Devuan (I had presumed it to be anti-systemd), I will gladly leave, including dropping all associated projects, and resume my search for an OS that is opposed to systemd in spirit.

Devuan is an operating system, & this forum is for those who use it, the fact that it is systemd free is why we are here.

If you can't make up your own mind about systemd, that's not a suitable subject matter to be discussed here, It's like talking about Microsoft, & of no relevance at all.

JoshuaFlynn · 2017-10-07 23:09:40

FOSSuser wrote:

Devuan is an operating system, & this forum is for those who use it, the fact that it is systemd free is why we are here.

Actually, Devuan still has a lot of hanging dependencies.

dpkg -l | awk '$1=="ii" {print $2}' | xargs -rn1 -I+ sh -c "dpkg -L + | grep --label=+ -Hw systemd" > systemd-references.txt

Seems to certainly suggest otherwise. Renaming something to 'libsystemd0' doesn't change the fact it's a systemd surrogate.

If you can't make up your own mind about systemd,

This thread seems pretty decisive on where I stand on the matter, and this is clearly not even a valid argument.

that's not a suitable subject matter to be discussed here, It's like talking about Microsoft, & of no relevance at all.

Really?

This search for systemd in posts producing over 5 pages and a thread literally titled "When you can't tell the difference between Windows and systemd" and the fact Devuan's entire purpose is to be systemd free seems to suggest otherwise. I imagine the Windows and Microsoft quips are just as regular here.

What I really don't get is you've got a guy - devel - who only literally registered yesterday (seems for the simple intent of replying to my post as a sock account), who, not only is their name Red Hat based (when installing dev packages on a Red Hat system it ends with the term 'devel'), advocates a pro-systemd position, which by itself isn't a problem, but the second I refute their position, you guys go ape and start attacking me.

I mean, if you guys already know all the systemd rebuttals, aren't interested in systemd topics, and are opposed to systemd, why are you clicking on a thread literally titled "arguments against systemd" and then attacking the guy who is actually opposed to systemd (whilst ignoring the pro-systemd guy)?

What is this, a secretive pro-systemd club?

golinux · 2017-10-08 00:26:33

That is pretty twisted. It's obvious to anyone with connected brain cells that devel was a troll. But your first post was the flame into which the moth flew. Your continuing argumentative responses defending your poor judgment indicate that you are STILL clueless. That's why you're getting the heat. It seems that not all trolls are pro-systemd . . .

ralph.ronnquist · 2017-10-08 00:37:42

I liked post #19 though; it was short and succinct, and its mere presence so elegantly violated its own sentiment.

JoshuaFlynn · 2017-10-08 01:24:02

golinux wrote:

That is pretty twisted. It's obvious to anyone with connected brain cells that devel was a troll. But your first post was the flame into which the moth flew. Your continuing argumentative responses defending your poor judgment indicate that you are STILL clueless. That's why you're getting the heat. It seems that not all trolls are pro-systemd . . .

Indeed, seems some anti-systemd users are trolls as well.

Even if devel is a troll, if the points (no matter how badly argued) aren't refuted, people will assume that naturally they have validity. I will still refute the 'hypothetically someone else's argument', even if spurious.

You guys seem to be operating on a subset of clique knowledge where you seem to expect people to know the implied social rules of your forum, and if I'm taking the heat for that, gladly, means another user doesn't have to suffer it.

ralph.ronnquist wrote:

I liked post #19 though; it was short and succinct, and its mere presence so elegantly violated its own sentiment.

And yet a man who professes to be an intellectual has trouble reading two paragraphs requires said posts be broken down into an overly simplified idiom, likes it, but not to the degree that he follows through on it.

(Also, I take it you didn't like the post pointing out the hypocrisy of you 'not reading' a post but then 'replying' to it anyway?)

I thought you guys were extremely busy, why are you still here?

Last edited by JoshuaFlynn (2017-10-08 01:28:58)

The officially official Devuan Forum!

#1 2017-10-05 22:41:06

Arguments against systemd

#2 2017-10-05 23:00:11

Re: Arguments against systemd

#3 2017-10-06 06:38:46

Re: Arguments against systemd

#4 2017-10-06 10:07:56

Re: Arguments against systemd

#5 2017-10-06 10:53:28

Re: Arguments against systemd

#6 2017-10-06 14:40:15

Re: Arguments against systemd

#7 2017-10-07 01:39:06

Re: Arguments against systemd

#8 2017-10-07 02:06:03

Re: Arguments against systemd

#9 2017-10-07 02:26:24

Re: Arguments against systemd

#10 2017-10-07 02:58:32

Re: Arguments against systemd

#11 2017-10-07 03:34:34

Re: Arguments against systemd

#12 2017-10-07 04:00:27

Re: Arguments against systemd

#13 2017-10-07 04:23:28

Re: Arguments against systemd

#14 2017-10-07 05:59:43

Re: Arguments against systemd

#15 2017-10-07 06:21:39

Re: Arguments against systemd

#16 2017-10-07 06:57:59

Re: Arguments against systemd

#17 2017-10-07 07:47:43

Re: Arguments against systemd

#18 2017-10-07 08:45:13

Re: Arguments against systemd

#19 2017-10-07 09:15:24

Re: Arguments against systemd

#20 2017-10-07 09:41:15

Re: Arguments against systemd

#21 2017-10-07 09:57:15

Re: Arguments against systemd

#22 2017-10-07 23:09:40

Re: Arguments against systemd

#23 2017-10-08 00:26:33

Re: Arguments against systemd

#24 2017-10-08 00:37:42

Re: Arguments against systemd

#25 2017-10-08 01:24:02

Re: Arguments against systemd

Board footer