boycott systemd

News, happenings
Message
Author
chillinfart
Posts: 88
Joined: Mon 22 May 2006, 18:43

#376 Post by chillinfart »

I tried Parabola Linux (Arch based) due to a nice optimized Intel driver for my netbook, the ****ing system was hanging every 30 seconds thanks to a bug in a service (logind). Few documentation available about the bug, after finding the quirky service. Once i disabled some text in logind.conf, i can get rid of the setup.

Finally i gave up with Parabola after a minor thing (bad support for my Ralink RT3090 unlike Tahrpup), but thanks to this i found how systemd works since the POV from a final user.

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#377 Post by jamesbond »

How to crash systemd in one tweet (seriously!) - reported 3 days ago. The bug has existed for over two years.

If you think "but ... but ... every software has a bug, why is systemd singled out!", then please read the linked article to see why it is indeed so (hint: this isn't the only reason-defying bugs).
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

Elena

#378 Post by Elena »

For a non-Systemd Arch Linux, I can recommend Obarun Linux

It's already my favorite Linux (besides Puppylinux). A new .ISO will be out in just a few days...

EDIT: New ISO got released.
Last edited by Elena on Tue 04 Oct 2016, 13:58, edited 1 time in total.

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#379 Post by rufwoof »

Elena wrote:For a non-Systemd Arch Linux, I can recommend Obarun Linux

It's already my favorite Linux (besides Puppylinux). A new .ISO will be out in just a few days...
How quickly do security updates comes through from Obarun? Debian and its SystemD took a day for recent Chromimum and Openssl security fixes to drop into my system. How stable and extensive is Obarun's repository? If I install Openbox, will a version of Blender that works well with that version of Openbox also be installed (python libs etc.)?

Elena

#380 Post by Elena »

Thanks for your interest, @rufwoof.

Obarun is a rolling release using the Arch Linux repo (stable, but of course you can add testing etc.) The package lists of Arch as well as from the AUR repo are well maintained and update several times a day. Blender and Openbox should be up-to-date (using those myself too). Dependencies will install together with the the main application, as expected.

Yet Obarun also has it's own package list. Mainly with non-Systemd-packages and their different, reorganized init system (Runit or S6). I'm using ObarunS6_x86_64-v0.0.6.

For questions, the main dev's of Obarun on Github, Eric and bit, are ususally on IRC (irc.freenode.org, #obarun) and on their forum. Both are quite helpful and friendly.

You won't get Wine atm (because it's strictly non-systemd). For this need I'm booting Puppy Linux.
With some configuration yourself (browser, different Window Manager, implementing some PuppyLinux apps, etc.), it's a very good distribution.

User avatar
Colonel Panic
Posts: 2171
Joined: Sat 16 Sep 2006, 11:09

#381 Post by Colonel Panic »

I'm experimenting at the moment with running distros which rely on sysinit rather than systemd, and I find that when the computer boots up now it no longer runs a process for 1 minute 30 seconds before it finishes booting, which used to happen before. It's almost like a two year old computer now instead of an eight year old one.
Gigabyte M68MT-52P motherboard, AMD Athlon II X4 630, 5.8 GB of DDR3 RAM and a 250 GB Hitachi hard drive running Ubuntu 16.04.6, MX-19.2, Peppermint 10, PCLinuxOS 20.02, LXLE 18.04.3, Pardus 19.2, exGENT 200119, Bionic Pup 8.0 and Xenial CE 7.5 XL.

User avatar
darkcity
Posts: 2534
Joined: Sun 23 May 2010, 19:16
Location: near here
Contact:

#382 Post by darkcity »

"The Tragedy of systemd" by Benno Rice [2019, 48mins]

https://www.youtube.com/watch?v=o_AIw9bGogo

shevy
Posts: 3
Joined: Wed 13 Feb 2019, 17:07

#383 Post by shevy »

I watched the video but it was a huge disappointment.

The primary problem I have had was with the quality of the talk. The quality was very low. Here I mean the "arguments" given by him.

He brought mostly strawman arguments and whacked away at that rather than present an objective view.

It's even more hilarious since he is mostly a FreeBSD dude - the FreeBSD dudes don't have a problem with systemd since systemd does not work on the BSDs.

My primary problem in general is that there is not really a lot of quality in the whole systemd debate. It already begins with "systemd is a replacement
for init" - it actually is not. It is a lot bigger and does more things, so HOW can we even compare it to init?

> I'm experimenting at the moment with running distros which rely on sysinit rather
> than systemd, and I find that when the computer boots up now it no longer runs a
> process for 1 minute 30 seconds before it finishes booting, which used to happen
> before. It's almost like a two year old computer now instead of an eight year old
> one.

Yes that has been my problem too. Whenever I would compile programs again,
I had to take care that nothing in systemd breaks, since that would render my
computer unusable. And that happened too many times. I never had this problem
with oldschool init.

Say what you want about the reasoning, but simplicity IS easier to handle. I guess
I am not the target audience because Red Hat wants to target Average Joe + business,
rather than veterans or semi-veterans of Linux.

My biggest gripe with systemd in general still is not its low quality or snobbish dev team
but that developers in distributions such as debian attempted to dictate this onto the
downstream user. This was IMO the biggest problem and biggest abuse, not the
fact that Red Hat sponsored and paid the development for this corporate-piece
software.

If Puppy/Fatdog ever were to go the systemd route, I hope it would do it like LFS/BLFS
and come in two flavours. I could not want to stand anyone forcing systemd onto me.

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#384 Post by jamesbond »

Colonel Panic wrote:I'm experimenting at the moment with running distros which rely on sysinit rather than systemd, and I find that when the computer boots up now it no longer runs a process for 1 minute 30 seconds before it finishes booting, which used to happen before. It's almost like a two year old computer now instead of an eight year old one.
Which is ironic considering that one of the supposed benefits of systemd was a faster boot.
It already begins with "systemd is a replacement
for init" - it actually is not. It is a lot bigger and does more things, so HOW can we even compare it to init?
And that is exactly one of the points. In the beginning systemd was touted as a better init replacement so it looked harmless, but in the end it is obvious what it actually is - a system-management-software that wants to manage everything. It wants to be _THE_ operating system.
My biggest gripe with systemd in general still is not its low quality or snobbish dev team
They can afford to be snobbish because it doesn't affect their bottom-line. They don't need to listen to "users" because these "users" don't pay their salaries. RH does. And people who pay RH aren't these "users" who are complaining. So good riddance :twisted:
but that developers in distributions such as debian attempted to dictate this onto the
downstream user. This was IMO the biggest problem and biggest abuse, not the
fact that Red Hat sponsored and paid the development for this corporate-piece
software.
If you see a little deeper you will see that how the this was done. They (attempt to) make everything depends on systemd. You look at GNOME desktop for example, they deprecate everything and links with systemd libraries instead. But you shouldn't be surprised, since many GNOME people are paid by RH too ... The point is, they try to make it harder and harder to build system without systemd, until the point people just give up and include systemd as a dependency. And once it's in (as a dependency), then why not use is as well?

But all hope is not lost. People are reacting. Just like "apulse" library implements stubs to satisfy dependency links for programs that expects pulseaudio, there are already libraries that stubs out systemd libraries as well. Attempt to force "udev" to be part of systemd failed; we have "eudev" which shows that udev can and should be out of systemd (and some of the functions that were in udev were now done by the kernel itself).

I'm now more concerned about the future of Linux kernel without Linus. With all due respects to Linus stewards and lieutenants; it was obvious that Linus acted as a gate of sanity that prevented many half-baked ideas or agenda-laden stuff from being merged into the kernel (some of these ideas/stuff actually came from his closest lieutenants!). With him gone I wouldn't be surprised if there is a tighter integration between the kernel and systemd (for example).
If Puppy/Fatdog ever were to go the systemd route, I hope it would do it like LFS/BLFS
and come in two flavours. I could not want to stand anyone forcing systemd onto me.
If it is still humanely possible for us to do it, Fatdog will never switch to systemd.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

User avatar
perdido
Posts: 1528
Joined: Mon 09 Dec 2013, 16:29
Location: ¿Altair IV , Just north of Eeyore Junction.?

#385 Post by perdido »

I resurrected this thread to ask a question - is puppy using systemd?
It was once a major topic of conversation in the forum.

I ask due to some recent commits in woof-ce from December 13, 2019 that reference systemd-udev
https://github.com/puppylinux-woof-CE/w ... ts/testing

Is systemd a nothingburger now?
Maybe those commits are something entirely unrelated?

Or is-it-too-late and puppy linux has now gone to the dark side?

.

s243a
Posts: 2580
Joined: Tue 02 Sep 2014, 04:48
Contact:

#386 Post by s243a »

perdido wrote:I resurrected this thread to ask a question - is puppy using systemd?
It was once a major topic of conversation in the forum.

I ask due to some recent commits in woof-ce from December 13, 2019 that reference systemd-udev
https://github.com/puppylinux-woof-CE/w ... ts/testing

Is systemd a nothingburger now?
Maybe those commits are something entirely unrelated?
I don't know if it is a nothingburger or not but here are some related comments by wdlkmpx
(1) tahrpup64 - totally broken - X doesn't start, the PKGS_SPECS needs fixing, specially xserver_xorg [too many errors in log]
(2) xenialpup64 - broken only with common64 eudev. Should use the common64 sudo, xterm does not run, misc issues, etc..
(3) bionicpup64 - ok
(4) busterpup64 - broken only with common64 eudev [many .pets are missing] - also needs native kernel.. this needs lots of work
https://github.com/puppylinux-woof-CE/w ... -565569390

I know the even Devuan uses some systemd libs but Devuan is able to avoid this systemd lib by using eudev instead. I read one users comment where he said that he will use antix or MXLinux instead if puppy uses "systemd-udev". This lib added by wdlkmpx only effects the debian/ubuntu puppies. Slackware and Devuan puppies use eudev instead. The debian dogs also use eudev instead.

Personally, I would hope that the devs would explore non systemd-udev alternatives more. This is of course not the systemd init but a separate lib that falls under the systemd project. If this change gets pushed into future puppies it will be up to users whether they accept this change or use a version of linux (e.g. a slackware based pup) that does not include this lib.
Or is-it-too-late and puppy linux has now gone to the dark side?
I wouldn't say, "gone to the dark side" but perhaps our resistance is getting weaker. The justification, I suppose is the lack of human resources to go too much against the grain. From wdlkmpx:
It's quite easy to fix stuff and move the whole project forward -including core scripts- when all the compat distro versions include the minimum supported version for some key packages, but unfortunately it's a task that can only be achieved by a dedicated team of testers and builders.. woofce does not have a team.. of any sort.

Another way to deal with this is... [delete the old distros].
https://github.com/puppylinux-woof-CE/w ... -565569390

I know that puppy devs are volunteers but at the same time we must consider what helps facilitate people to volunteer their time. Many have felt unwelcome when they have tried to contribute to woof-CE.
Find me on [url=https://www.minds.com/ns_tidder]minds[/url] and on [url=https://www.pearltrees.com/s243a/puppy-linux/id12399810]pearltrees[/url].

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#387 Post by jamesbond »

perdido wrote:I resurrected this thread to ask a question - is puppy using systemd?
Absolutely NOT.
I ask due to some recent commits in woof-ce from December 13, 2019 that reference systemd-udev
The official name of "udev" is "systemd-udev", even though it does not really depends on systemd. (e.g. "systemd-boot" was originally called "gummiboot" and actually has nothing to do with systemd other than the name only). The association, or "branding", so to speak, of course, is to give the impression that:
a) systemd is all-encompassing
b) they would only only work with systemd
Both of which aren't true.

There are 3 levels of dependency to systemd:
a. A component depends on systemd library and requires systemd to run (as the init system) for that component to work. This is the worst offender.
b. A component depends on systemd library but does not require systemd to run at all.
c. A component only has the brand name "systemd-XXX" but otherwise has no dependency at all on systemd.

"systemd-udev" is either (b) or (c) (I can't recall. I know for sure that early versions of systemd-udev was definitely (c), but time has passed enough for me to not be able to give precise answer until I do more thorough checking on it).

Situation (a) and (c) is obvious, an OS is called as using "systemd" if it uses systemd as its init system (PID 1), that is, situation (a). Situation (c) is also obvious - we don't use systemd at all.

Situation (b) depends on how puritan is your view. But it is not the intermediate path to the dark side; because in most cases it is actually possible to replace the systemd-library dependency with a "stub" that does nothing (similar to how "apulse" library replaces pulseaudio).

---

There is a fork of systemd-udev which is called "eudev" and is maintained by the nice gentoo folks. It is basically "systemd-udev" which has the branding removed and all dependency on systemd library removed.
Is systemd a nothingburger now?
No, it is still a big matter.
Maybe those commits are something entirely unrelated?
If I read the commit notes correctly, it is because for a long time different builds of Puppy (ubuntu-based, slack-based, etc) chose to use a "commonly built" version of eudev. However, it is found recently that it stops working. The "workaround" (whether it is interim or permanent I don't know), is to use the "udev" component which comes from the parent distro. In slackware, this is "eudev", in ubuntu/debian based puppies, this will be "systemd-udev" but as I noted above, they are practically identical other than the name.
Or is-it-too-late and puppy linux has now gone to the dark side?
Into the dark side we will never walk. At least not willingly.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

s243a
Posts: 2580
Joined: Tue 02 Sep 2014, 04:48
Contact:

#388 Post by s243a »

jamesbond wrote: There is a fork of systemd-udev which is called "eudev" and is maintained by the nice gentoo folks. It is basically "systemd-udev" which has the branding removed and all dependency on systemd library removed.

...

in ubuntu/debian based puppies, this will be "systemd-udev" but as I noted above, they are practically identical other than the name.
Or is-it-too-late and puppy linux has now gone to the dark side?
Into the dark side we will never walk. At least not willingly.
What are the systemd dependencies? I see the udev has been incorporated into the systmd sourcecode/project [1] but from the following link:

https://packages.debian.org/sid/udev

there doesn't appear to be any obvious systemd dependencies.

Notes
------------------
1 - https://wiki.archlinux.org/index.php/Udev#Installation
Find me on [url=https://www.minds.com/ns_tidder]minds[/url] and on [url=https://www.pearltrees.com/s243a/puppy-linux/id12399810]pearltrees[/url].

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#389 Post by jamesbond »

s243a wrote:What are the systemd dependencies? I see the udev has been incorporated into the systmd sourcecode/project [1] but from the following link:

https://packages.debian.org/sid/udev

there doesn't appear to be any obvious systemd dependencies.

Notes
------------------
1 - https://wiki.archlinux.org/index.php/Udev#Installation
Then maybe there still aren't. As I said, a couple of years ago when udev was incorporated and re-branded as systemd-udev, it was for branding purposes only, which is case (c) above. Time has passed long enough that it could now be in (b), but your debian package link seems to confirm that it is indeed still (c).

Which, depending on how you see it, makes the whole scheme more insidious, isn't it?
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

User avatar
perdido
Posts: 1528
Joined: Mon 09 Dec 2013, 16:29
Location: ¿Altair IV , Just north of Eeyore Junction.?

#390 Post by perdido »

@s243a
@jamesbond

Before the explanations I had no idea there were multiple possibles as to how deeply enbedded systemd could be or that the mention of systemd does not necessarily mean it has been implemented.
Thanks for the detailed replies, it put it all in a perspective I can relate to.

.

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#391 Post by rufwoof »

jamesbond wrote:I'm now more concerned about the future of Linux kernel without Linus. With all due respects to Linus stewards and lieutenants; it was obvious that Linus acted as a gate of sanity that prevented many half-baked ideas or agenda-laden stuff from being merged into the kernel (some of these ideas/stuff actually came from his closest lieutenants!). With him gone I wouldn't be surprised if there is a tighter integration between the kernel and systemd (for example).
Shouldn't happen as systemD isn't portable whilst Linux (kernel) is (embedded systems etc.etc.etc.).

Once the kernel finishes loading it runs /init ... which can be just a simple script that runs /bin/sh at a console level, or that runs setsid cttyhack to associate to a tty (job control), a simple kernel/busybox type combination, or whatever ... without even running sysv (or systemd). In contrast SysV/systemD invoke services etc. - more for multi-user systems (for ram based single user desktop setups - not really a necessity). SysV is prone to collisions - you (init) might start one service in anticipation of another having already been loaded, maybe adding a sleep 5 or whatever, only to find that the timings sometimes don't fit in with each other. SystemD better manages all of that so that dependencies don't try to run/start until their 'depends upon' has actually started. However the more in-roads systemD makes the larger its front line, so does/will have the tendency to become the entire OS. At least from the Linux X/gui desktop perspective. A form of Windowfication of a Unix like OS. Similarly that desktop has generally moved towards being more Windows like anyway for many. Some of us however like the original Unix philosophy of individual elements each doing one thing well - lego bricks that you can use to build whatever with, rather than systemD being a pre-built monolithic take-it-or-leave it block. Tried it, its OK but don't like it - so cast aside as far as I'm concerned. The Linux kernel will IMO continue to remain a lego brick and not become all encompassed into the systemD monolith, as it is a lego brick that is more widely used than just as part of a Linux gui desktop/server system.
[size=75]( ͡° ͜ʖ ͡°) :wq[/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]

User avatar
Wyk72
Posts: 18
Joined: Tue 01 Sep 2009, 12:55

#392 Post by Wyk72 »

My little 2 cents: systemd is,in my point of view, a system-wide cancer. It mangles everything into a blob of obscure dependencies, even if it comes out with a kind-of neat interface. Upstart was messy, but still readable and "hackable" to some extent, this stuff (systemd) is plain intrusive. And I mean, heavily intrusive. Won't touch it with a ten-foot pole. Most of the linux desktops I have to tend to are Ubuntu 18.04 with gnome3, and they have become a real pain (printing system hiccups, video hiccups, messy interface,icons disappearing, not to mention office software crashing all the time). Not fun anymore.

For servers, I go Alpine Linux (mostly KVM/backup servers). I am extremely satisfied by the no-nonsense approach of that Linux OS.

For desktop, Puppy is still my favorite, it's a work of love&genius. But honestly,most people don't like it because of the "retro" interface.

Just like smartphones, it's become all about bells&whistles, flashy interfaces, nice fonts and that's about it. Not everyone has time or knowledge to deal with system "ethics" or from nuts&bolts perspective.

We'll have to deal with it.

User avatar
Mike Walsh
Posts: 6351
Joined: Sat 28 Jun 2014, 12:42
Location: King's Lynn, UK.

#393 Post by Mike Walsh »

@ Wyk72:-

Have to agree about the horrendous mess of systemd. Easy to see it came from the same idiot that foisted PulseAudio on an unsuspecting community, ain't it? :lol: The same one who seems to think that Linux has to 'beat' Windows at their own game.....by becoming more like them than they are.... :roll:

(Lennart Poettering, in my opinion, needs stringing up by the balls. The man, and his 'work', are, to my mind, dangerously insidious...)
Wyk72 wrote:For desktop, Puppy is still my favorite, it's a work of love&genius. But honestly,most people don't like it because of the "retro" interface...
Huh? You tell me what's 'retro' about this:-

[Click to enlarge:-]


Image


Hmm..? :lol: :lol:

('Salright; I happen to like a 'busy' desktop..!) :D


Mike. :wink:
Last edited by Mike Walsh on Fri 24 Apr 2020, 10:05, edited 1 time in total.

ozsouth
Posts: 858
Joined: Fri 01 Jan 2010, 22:08
Location: S.E Australia

#394 Post by ozsouth »

Systemd was a fine concept - when it was just a SysV replacement. But it seemed to be rushed in despite teething issues & then became pervasive & I believe a single point of failure, just like the OTHER OS. I started investigating BSD variants (OSX is supposedly a derivative), but found them so much less refined. I'm too poor to run Apple - with frequent expensive hardware updates, so I stuck with an older puppy for years until Slacko came along. Slackware - the oldest continuous linux distro - continues to resist systemd, as do very few others. So ScPup64 remains my favourite (thanks to Peebee).

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#395 Post by wiak »

Like many here I've used SysVinit for years and am well familiar with its scripting structure (though there are multiple ways it is implemented - alas not exactly standard config layout or scripts - different distros always have their own implementation ideas for exact arrangements and often very different and often very complex shell scrpts). But knowing it well makes it the easiest for me.

I've enjoyed using 'runit' alternative, which is the init system Void Linux adopted. Was a bit of a learning curve but not too bad. However lack of long-term familiarity with it means I already forget and need to continually remind myself how it is set up.

Similarly, having stuck to old SysVinit traditions I have a hard time when I have to do some related configuration on a systemd-based installation. However, I have been doing some of that recently and I have to say that I really enjoy the fine-grained control system "systemctl edit" facility provides. It actually makes some things very easy - for example. I'm loving how easy it is to 'override' an existing service, where you can create a tiny well-defined config file that is used to change a line or more in the overall service file. It's very much like adding an upper layer in a graphics program and without prone-to-error shell scripts. Systems service files have a standard and quite simple format, which removes the need for lots of spaghetti-like shell scripts. Alas that we love and are addicted to shell-scripts so much!

Anyway, personally I can see why systemd has been almost universally adopted despite my also worrying that it will replace everything I know and end up forcing some complications I'd rather not have. So I'm in two minds about it, but cannot deny its superior conceptual design (though I have no interest in arguing if that is true or not!). Fact remains, however, most systems have adopted systemd so I intend learning it thoroughly though I really hope the alternatives remain usable in Linux distros design (especially runit - I'm actually not so keen on SysVint because it really is a crude old, albeit familiar, system).

So overall I'm almost neutral about good and possible bad of systemd, whilst having to admit that some of its design is proving to be disturbingly attractive to me in practice. I also wonder if some of my own latent negativity about it is in proportion to my lack of overall practical familiarity with it. I'll come to a more definite opinion later; for now I'm simply going to practice and learn more about using it (I have to anyway) whilst giving credit where I definitely see some credit is due (simple control of services via standard service file format and wonderful layering override concept - my concern would be services depending on too many other services... but I need to check more about that in practice, rather than just reading opinion pieces on the issues).

wiak

Post Reply