Interesting thread over at dyne.org

See [DNG] There seems to be some strong disagreement in Debian regarding usrmerge.

Just a few snippets from the posts on that thread:

It is so sad. So much unresolved conflict and friction within Debian community. I think the whole Systemd forcing did more harm to Debian community than anything else in the last 10 years.

..my fairly educated guess is, this harm was and is the whole idea; "kill off Debian with SystemD, and the whole Debian derivative tree comes crashing down." ..is why I propose Slackware as an alternative upstream, they are even more conservative than Debian was 20 years ago, their packages are easily converted with e.g. alien, and any file name conflicts can be fixed with a quick recompile appending e.g. "-slackware" to every damned file name in the recompiled packages.

The biggest problem with this systemd take over is the fact that programs are being written specifically for/to interact with it!

Even Slackware will have to remove all the systemd specific parts - Linux is being taken over by Commercial Interests...

Devuan will also need to remove all these too - I think all the non systemd distros will need to band together in their efforts to keep a version of Linux systemd free.

Personally, I'm looking at the BSDs for my future computing needs, if the day comes that we are forced to have systemd in Linux; (& may possibly use Haiku on the desktop).

Originally Posted by fatmac The biggest problem with this systemd take over is the fact that programs are being written specifically for/to interact with it! ... Devuan will also need to remove all these too - I think all the non systemd distros will need to band together in their efforts to keep a version of Linux systemd free.

AntiX has a separate repository, which contains not only the AntiX-specific stuff like the graphical control centre but also non-systemd versions of programs like cups.

... propose Slackware as an alternative upstream...

Gulp!

In the "beginning" in my Mint fling years, I tried the same to get rid of the artificial shimming and make things more "pure" Unix, but that proposal was quickly shot down!

"Good luck getting anything to run under Slackware"...

Originally Posted by hazel AntiX has a separate repository, which contains not only the AntiX-specific stuff like the graphical control centre but also non-systemd versions of programs like cups.

Yes, I used to be an avid antiX user, but I think even they will struggle with the onslaught of programs written specifically for/interacting with systemd, as is the trend......

Originally Posted by fatmac Personally, I'm looking at the BSDs for my future computing needs, if the day comes that we are forced to have systemd in Linux; (& may possibly use Haiku on the desktop).

I'm a long-time BSD user off and on. The problem is that my PCs just perform better on Linux and Windows than the BSDs. Not to mention no support for DRM streaming content(like Netflix) on the BSDs. I'm sticking with Linux.

we can fight some time , like no pulse ..no pam ...

When projects release new versions non admit build withour systemD , we are forced to go with it.

Imagine for a moment if kernel ...requires/forced to have systemD to build and run ..

Think all world stop for this?

Hope we can do --disable-systemd for a long time.

Or simply if non exists , no try to force like "Stop , no systemd detected".

Non-systemd distros/devs banding together is the most paramount action that must take place to prevent this hostile "elite" takeover of linux. Instead, people are mindlessly working on changing the GUI of a useless distro and giving it some fancy name instead of working on real stuff. I was using devuan for a couple years but I just wanted to go more raw. Tried BSD but it requires learning a different system. Most of the commands are different, I am used to iptables, even the ifconfig is different. Its more like MacOS. However, I, too, am prepared to move to BSD for my future computing needs should that day come where slackware devs become lax and no longer modify software to make linux work without systemd. For now I love slackware and so far I have only seen a couple files that I have read are to "mimic" systemd to satisfy some dependency requirements for specific software. Yes the software is being written to accomodate systemd. If apache, vsftpd, and the rest are forced to use systemd, I think even BSD is going to have to wrestle to keep it out...

Originally Posted by fatmac The biggest problem with this systemd take over is the fact that programs are being written specifically for/to interact with it! Even Slackware will have to remove all the systemd specific parts - Linux is being taken over by Commercial Interests... Devuan will also need to remove all these too - I think all the non systemd distros will need to band together in their efforts to keep a version of Linux systemd free. Personally, I'm looking at the BSDs for my future computing needs, if the day comes that we are forced to have systemd in Linux; (& may possibly use Haiku on the desktop).

This is why I love Slackware and Void. No systemd. Hopefully Mr. Volkerding and the Slackware Team can keep the hordes from storming the gate.

Originally Posted by hitest This is why I love Slackware and Void. No systemd. Hopefully Mr. Volkerding and the Slackware Team can keep the hordes from storming the gate.

Slackware and Void have no problem with elogind though.
I make this point because it is not just about what is the default init/pid1.
Many distros (including Slackware and Void) build packages with elogind/libelogind0 enabled.
elogind is systemd without it being the default init.
Trying to build a desktop environment without systemd/elogind entanglement in next to impossible nowadays whether you use Slackware, Void, or antiX.

fatmac is probaly right. In the immediate long term only the BSDs will stay totally free from systemd/elogind

https://manpages.debian.org/bookworm...mess.8.en.html

Wow.

https://lists.dyne.org/lurker/messag...a89ccf.en.html

"While all this is happening "in-and-around" us, within the non-systemd Linux communities there is an absolute lack of agency on how to solve what is *now* the most important problem at hand:

----> Debian dropping sysvinit support. <----

Every/anyone who can say *something* jockeys for their favourite init software option without understanding that what Devuan needs *now* is not a *choice* but to survive the lack of sysvinit support."

Double wow.

The original post is about debian's "usr-merge", not systemd. Some guy in that post rants about systemd 'cause hes on a devuan system, and that triggers a systemd rant here.

The "usr-merge" is where debian (and its forks I guess?) symlink '/bin' -> '/usr/bin'. Same thing with /sbin and /lib. Has nothing to do with systemd, other than Lennart Poettering supports the usr-merge idea from what I've read about it. The usr-merge does alter the FHS and I guess would break booting when / and /usr are on separate partitions.

I don't really get what the big deal is about. I'm fine with Slackware following the traditional FHS, given its roots. But as long as the filesystem is consistent and the package manager obeys whatever standard is in place, it should work.


About systemd: Slackware is doing fine without it.

Systemd is just a giant suite of programs. The ones that are required are already packaged separately and work fine on Slackware (eudev and elogind). The rest like the init program, or the service manager are not needed and we get by with Slackware's init and service scripts like always. There are other init systems and service managers out there other than systemd as well, if one would ever be needed.

Originally Posted by 0XBF I don't really get what the big deal is about.

The understanding I took from reading the thread linked in the OP is that the "usr merge" causes dpkg to break, and those responsible don't seem to care.

Originally Posted by 0XBF I'm fine with Slackware following the traditional FHS, given its roots. But as long as the filesystem is consistent and the package manager obeys whatever standard is in place, it should work.

Devaun's issue seems to be that there is seemingly no respect given to methods that have existed for >30 years, and that we should all of a sudden discard known & proven structures for something shiny and new for no obvious benefit... and much breakage.

The Debian devs are not considering the consequences thoroughly enough. The existence of a so-called "unmess" package is proof of that.

It seems like Debian is trying to play catch-up with RedHat instead of running it's own race... something which it once did so well that it set the pace.

Originally Posted by 0XBF About systemd: Slackware is doing fine without it.

Yes, and let's hope that continues.

Surely you can see that Devuan's beef with systemd is not unjustified? They're proposing to remove support for sysvinit. That is a drastic change, and I'd say they're right to be mad about it.

Originally Posted by 0XBF There are other init systems and service managers out there other than systemd as well, if one would ever be needed.

Comments like this one are a bit disappointing. The work Patrick has put into Slackware's init scripts over the years shouldn't be so easily dismissed. Slackware's init is hands down the most flexible, extensible and customisable of any Linux distro. It is not appreciated enough, IMO.

@ rkelsen:

Agreed on all points, except I didn't dismiss Pat's init scripts, just pointed out that other non-systemd init development is still going on out there so there would be options if Slackware would "need" a service managing init system, for example.

I've also tried a few various non-systemd init systems on Slackware out of my own interest over the years and always start from looking at Slackware's boot scripts for how to set up the system and imitate that into whatever format the alternate init requires. I wouldn't be able to do that if slackware's init wasn't written in shell code and easy to follow

These kinds of debates often are like watching Bugs Bunny and the aborigine yelling, "Unga bunga bunga," at each other (Bushy Hare, 1950).