systemd free trisquel variant?

25 risposte [Ultimo contenuto]
Starfish
Offline
Iscritto: 04/20/2020

Is there any plan in Trisquel to have a variant without systemd? I don't claim to understand the problems with systemd completely but I've been really interested in Devuan GNU+Linux's(https://devuan.org/os/init-freedom) "init freedom" campaign where they say "Init Freedom is about restoring a sane approach to PID1 that respects portability, diversity and freedom of choice." So can anyone explain in detail(or link me to somewhere) about problems with systemd and if Trisquel will have(or plans to have) systemd free variant in future?

Beformed
Offline
Iscritto: 01/13/2017

Lets see if I get it right. But basically there are hackers and users that loathe systemd. The main reason is its scope. It does too many things. this is contrary to the unix philosophy "Do one thing and do it well".

You can find some of the complains here: https://suckless.org/sucks/systemd/

In regards to Trisquel. I don't think Trisquel will create a version (trisquel developers can hardly release a version with systemD that is 2 years older than the ubuntu version it's based on) since systemd is free software and doesn't go against the objectives the trisquel project has.

systemd.jpeg
strypey
Offline
Iscritto: 05/14/2015

> [systemd] does too many things. this is contrary to the unix philosophy "Do one thing and do it well".

Please refer to the link MagicBanana shared:
http://0pointer.net/blog/projects/the-biggest-myths.html

This criticism is answered directly as:

"10. Myth: systemd is not UNIX."

But the underlying claim - that systemd is a single piece of software that does multiple things - is also challenged under both:

"1. Myth: systemd is monolithic."

AND

"6. Myth: systemd is not modular."

According to the arguments laid out here, systemd *is* 'many thing, loosely coupled', which means the claim that it doesn't embody the oft-referenced "UNIX principle" is utterly false. I think the burden of proof lies on the critics of systemd to prove that their other claims do not also fail to fit the basic facts.

Magic Banana

I am a member!

Online
Iscritto: 07/24/2010

systemd is free software. If you do not face technical issues with it, I see no reason to reject it.

Most points against systemd are conspiracy theory. It was fueled by sensationalist articles such as those of Paul Venezia, who announced "the Linux apocalypse", wrote that everybody should "choose [a] side on the Linux divide", predicted an exodus of server systems to BSD because "you have your Windows in my Linux", etc.:

The first distributions that adopted systemd as default did so more than eight years ago: Fedora in 2011, Arch, Mageia and openSUSE in 2012, etc. By 2015, essentially all the main GNU/Linux distributions but Slackware and Gentoo had adopted systemd as default: Manjaro in 2013, Mint, SUSE, Red Hat and CentOS in 2014, Debian and Ubuntu in 2015. Those distributions chose systemd for technical reasons: it was deemed superior. None of them went back. There was no apocalypse, no exodus to BSD, etc. The prophecy failed. And, as studied in the classical sociology book "When Prophecy Fails" by Leon Festinger et al., the "believers" have faced cognitive dissonance and the most fervent ones have coped with the dissonance by reinforcing their beliefs.

After comparing systemd with a disease ("There is a menace which is spreading like a disease throughout the Linux world, it is called systemd."), https://suckless.org/sucks/systemd/ exposes the conspiracy theory: "There has been a movement, especially around the Red Hat-related developers to copy Microsoft Windows and all of its features". The text continues: "Now this interpretation of how a userspace should look like is implemented and was introduced with big criticism and change in the Open Source world into many distributions. The debacle in Debian is the best example in how to not introduce such a changing technology into a distribution".

Again: Debian adopted systemd as default more than five years ago and did not go back. There was no reason to. In the Debian Technical Committee, the main debate has never been between systemd and sysvinit (that Debian was using until then) or between systemd and OpenRC (that is certainly the second most used init, nowadays) or between systemd and sinit (that suckless promotes, in the subsequent paragraph, and that no distribution uses, as far as I know). It was between systemd and Upstart, which is now defunct and was not minimalist. See the votes here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#6729 (seven of the eight members of the committee prefer both S = systemd and U = upstart to O = openrc and to V = sysvinit). Anyway, there is no doubt Debian's adoption of systemd was painful for the Debian developers... mainly because anti-systemd conspiracy theorists took part in the debate on the Debian mailing lists. Wikipedia summarizes the detrimental results:

In November 2014 Debian Developer Joey Hess, Debian Technical Committee members Russ Allbery and Ian Jackson, and systemd package-maintainer Tollef Fog Heen resigned from their positions. All four justified their decision on the public Debian mailing list and in personal blogs with their exposure to extraordinary stress-levels related to ongoing disputes on systemd integration within the Debian and open-source community that rendered regular maintenance virtually impossible.
https://en.wikipedia.org/wiki/Systemd#History

https://suckless.org/sucks/systemd/ then lists "a collection of links related to all the features systemd tries to enforce upon you as a Linux user, because »they know better«". I can only assume "they" refers to all those in the conspiracy. Right after, one can read: "Please add all the links you can find!". The first item says: "Your link here". It is an extremely common technique among conspiracy theorists: in absence of good argument, make a huge list of terrible ones. In that case, they are mostly links to issues that were closed, because they were fixed or because they were not actual issues. Do not believe me: randomly sample those links, click on them and see!

The huge list is an attempt to convert the visitor, who does not have the time and skills to check the links. She may indeed think "at least some of those links must point to significant problems with systemd". The list also supports never-ending discussions, where the believer picks a link (without reading the page behind it; many systemd haters do not know the first thing about init systems), submits it as a "proof" that systemd is evil and, if it gets refuted, picks another one, and so on until the interlocutor (who does all the work) gets tired.

boba
Offline
Iscritto: 08/28/2017

What about runit? Has runit development actually stalled in 2014?

https://www.slant.co/versus/12956/12960/~systemd_vs_runit

https://www.slant.co/topics/4663/~linux-init-systems

300 votes about init systems might not be highly representative, but there is always a legitimate concern that such a crucial system component might be subject to a lock-in effect, whereby lower quality candidates become de facto standards because their adoption rate is a geometric series. It happened with the VHS video standard, it also happened with some well known proprietary OS.

On the other hand, some interface components have to be standardized in order to improve portability.

So before any talk of campaign or plans for a given distro, an enlightening discussion about current alternatives and their respective merits might be beneficial.

Beformed
Offline
Iscritto: 01/13/2017

I think that is correct. The runit project has been stalled since 2014. I think it's a good init system. To include runit Trisquel would have to:

1. Change ubuntu even more. I'd think that may take time and effort.
2. Decide what init system would replace systemd.

I don't think it's critical to the Trisquel project to change init system since systemd is free software.

boba
Offline
Iscritto: 08/28/2017

There were two separate questions raised by the OP:

1. "can anyone explain in detail (or link me to somewhere) about problems with systemd"

2. "if Trisquel will have(or plans to have) systemd free variant in future?"

The answer to the second question is indeed probably negative. It is not only not critical, it is not something that seems to have any sort of justification: I have still not found any convincing argument answering the first question.

This 2014 zdnet article is not always very clear but refers to a "nightmare scenario" which had not materialized at the time. Has it now? We are still able to use KDE, XFCE, etc. on Trisquel in 2020, so I would guess that the answer is no.

On the other hand, I have found this which looks quite factual and open about systemd.

Beformed
Offline
Iscritto: 01/13/2017

I'd agree with you. The answer to the first question may be "no". I don't think there is a drawback. Most arguments against systemd are preferences like following the unix philosophy. But you can argue the same about emacs and that doesn't change the fact that emacs is a great piece of software.

Magic Banana

I am a member!

Online
Iscritto: 07/24/2010

This 2014 zdnet article is not always very clear but refers to a "nightmare scenario" which had not materialized at the time. Has it now? We are still able to use KDE, XFCE, etc. on Trisquel in 2020, so I would guess that the answer is no.

Indeed. And the same holds for other anti-systemd claims in this article. For instance, this quote from the now extinct boycottsystemd.org website:

There are tons of scenarios in which it can crash and bring down the whole system. But in addition, this means that plenty of non-kernel system upgrades will now require a reboot. Enjoy your new Windows 9 Linux system!

We still do not have to reboot after non-kernel upgrades and I do not think anybody on this forum has ever diagnosed a crash that would be caused by systemd, used as default in Trisquel since Trisquel 7.

jxself
Offline
Iscritto: 09/13/2010

"We still do not have to reboot after non-kernel upgrades"

And maybe not even after kernel upgrades either. Rebootless kernel upgrades are available from Canonical, Red Hat, and others.

boba
Offline
Iscritto: 08/28/2017

If systemd does not even get in the way of rebootless kernel upgrades, then this thread might have already come to its conclusion...

boba
Offline
Iscritto: 08/28/2017

...and might now as well be moved to the Troll Lounge. If the OP does not mind, that is.

Masaru Suzuqi
Offline
Iscritto: 06/06/2018

TLDR but they merely hate a blond man and wish his ruin is one of the things I learned from this community, if I understand it correctly.

Jaret
Offline
Iscritto: 12/19/2018

Blond man = Lennart Poettering?

boba
Offline
Iscritto: 08/28/2017

I think he means François Perrin.

https://www.imdb.com/title/tt0068655/

andyprough
Offline
Iscritto: 02/12/2015

>I think he means François Perrin.

I was thinking it was either Brad Pitt or Prince William of England, but your theory makes more sense.

Masaru Suzuqi
Offline
Iscritto: 06/06/2018

I don't know his name.

A8E72D86-5F25-4C61-94E3-49A0DCE84B9E.png
Masaru Suzuqi
Offline
Iscritto: 06/06/2018

I attached a wrong photo. It was my uncle. This guy.

Screenshot at 2020-06-25 01-58-15.png
boba
Offline
Iscritto: 08/28/2017

Wrong photo again. Here is the real François Perrin:

F_Perrin.jpeg
andyprough
Offline
Iscritto: 02/12/2015

One of the more recent critiques of systemd is here: https://blog.darknedgy.net/technology/2020/05/02/0/index.html#utopia

It's highly technical, but what it includes is the author's critique that systemd has bugs that cannot be solved because the workarounds to those bugs have become standard practice for distros and users, and fixing the bugs would actually break too many systems. Also, systemd is loaded with features that no distro actually uses, so even though development speeds along at a very fast clip, the development itself is not in keeping with the actual user needs.

And this critique should not be carelessly dismissed, as the author has put in a great deal of detail about individual systemd problems and bugs that are literally not going to be resolved.

The author concludes by stating in part that "Upstart suffered from nasty bugs that, at their core, boiled down to having its ad hoc job and event engine out of sync with the underlying kernel process model, producing nonsensical system states. systemd suffers from the same class of issues." And yet - he points out that Chromebooks still use Upstart quite successfully. Which means that init systems in and of themselves are not that important - you can run a highly successful platform with an otherwise misbehaving init system.

The problem as he sees it boils down to the idea that although init systems no longer really matter, systemd has made itself matter because there are many modern apps and software systems that cannot be run without systemd. It is no longer replaceable, especially if you intend to use software that will not run without it. If the author is correct and systemd does suffer from the same problems as the init systems it was meant to replace, and yet systemd itself is not replaceable due to software dependence, then systemd is a problem, and finding a way to use a different init system does become an important priority.

boba
Offline
Iscritto: 08/28/2017

Obviously, the main point of contention is about the nature and the scope of systemd. From what I could get, it is more than an init system but the optional nature of the extra components is debated. If it is its function as an init system which should be improved, why would it not be possible to improve it as such instead of replacing it by yet another system?

My naive question would then be, couldn't all these talented people, who are currently busy developing competing unsatisfactory init systems, gather in a room and draw a standard? As a Reservoir Dogs remake.

andyprough
Offline
Iscritto: 02/12/2015

> If it is its function as an init system which should be improved, why would it not be possible to improve it as such instead of replacing it by yet another system?

He does not believe that actually improving systemd will work, he thinks it will ultimately be replaced, and that it is already in the process of being replaced by projects that are moving a lot of functions to the kernel. He has a section on the problems with trying to fix systemd in the article:

> [Section Title] 3.6.4. Bugs as features: destructive transactions, implicit .wants, and PartOf= intransitivity

> Throughout the years, people have either grown accustomed or found interesting ways to make features out of systemd failure conditions, bugs and quirks, which can make attempts to “fix” semantics to be more consistent actually break many use cases that depended on said inconsistency.

> The Red Hat Customer Portal for RHEL 7, for instance, officially recommends deliberately creating a destructive transaction in systemd to act as a “reboot guard” feature so that a root user can be prevented from rebooting until some action is complete. Assuming systemd’s job mergeability rules are tweaked or that multi-unit atomic transactions ever become a thing, this could stop working.

> Up until systemd-242, device units would get an implicit .wants dependency on their corresponding mount units, with the appearance of a device always leading it to it being immediately mounted. This would cause mount units to get started up after being explicitly stopped by the user if a device unit state change (like a ‘changed’ event) occurred to pull them in. After the removal of this “feature,” it turned out many were relying on it as a poor man’s hotplug.

> Quite recently as of this writing, from systemd-245 onward, a patch that modified the GC logic for jobs was merged. It was suggested as a response to the issue of PartOf= dependencies being intransitive, i.e. the behavior used to be that PartOf A->B->C and then stopping C while B is inactive did not propagate to A, but stopping the already inactive B did.

> The patch led to a massive wave of regressions that is still ongoing as I write this. The Debian package for systemd currently contains a patch reverting this specific change. Among the strange side effects were the Plymouth bootsplash being restarted in the middle of a graphical session, with Debian systemd maintainer Michael Biebl going ballistic at the systemd developers over this. Additionally, services with failing condition checks would be continuously restarted (also reported here), thus clogging the journal.

> What this debacle shows is that seemingly minor enhancements to systemd’s state machine can have disproportionate effects on the entire user ecosystem that core developers cannot foresee until they actually deploy the changes and watch the outcome. This raises serious doubts about the possibility of systemd being reformed or overhauled in any non-trivial fashion.

boba
Offline
Iscritto: 08/28/2017

I see.

1. Sorry, I must have been chewing cabbage for too long so I got tired and I skipped the most technical section and missed these crying examples. I normally try not to skip relevant sources on these heated topics but I had been reading quite a load of nonsensical discussions about who's not answering whose questions and who's a pr*ck, and had a hard time trying to make sense of these given my limited technical knowledge (on the matter of pr*cks, particularly). Thanks for helping me by posting this link and pointing to relevant parts I had missed :)

2. It appears I had also missed this:

"Overall, following its developmental peak around 2014 and the subsequent loss of its identity, systemd appears to have mostly shifted its emphasis on refining tooling for containerized deployments, in line with prevailing business interests among Linux Foundation members. Poettering himself dropped an instructive hint as early as November 2015:

sysusers is definitely something we should make a Fedora default, that is used distro wide, as it makes user registration portable, and is also what Atomic wants.

“Atomic” being Project Atomic, a Red Hat cloud distribution project that overlapped with projects such as rpm-ostree and later being the base for Fedora CoreOS and Silverblue. An earlier September 2015 Q&A with Lennart by the CoreOS team is much more explicit about this shift."

I was suspecting the money track behind all these heated discussions but it is sometimes difficult to locate it without deeper knowledge of the flows (and of the alleged flaws) and without the full picture: some streams are clearly visible, some are flowing under the surface. Also, having some money going some way is not in itself an argument for or against a given piece of technology. It is important to keep in mind the bias it might induce in some minds, however.

3. "The quality and nature of [the] debate has not improved in the least from the major flame wars around 2012-2014, and systemd still remains poorly understood and understudied from both a technical and social level despite paradoxically having disproportionate levels of attention focused on it." I can only agree.

This part of the OP's original question reaches far beyond Trisquel users' scope, though, more of a general free software topic.

Masaru Suzuqi
Offline
Iscritto: 06/06/2018

Still TL;DL but his rage is deeper than the Pacific ocean, hotter than sand and sharper than teeth of a shark...

boba
Offline
Iscritto: 08/28/2017

Sorry, this post violated my own rules about not feeding trolls, so I overwrote it.

boba
Offline
Iscritto: 08/28/2017

Arguably more on topic, I just found this article about the choice made by Debian about systemd last December:

https://fossforce.com/2020/02/the-verdict-on-systemd-is-in/

Here are the detailed proposals and the outcome of the vote:

https://www.debian.org/vote/2019/vote_002