Devuan 2.0 Reaches Beta, Debian Without Systemd & Now Based On Stretch

[arokh]

Exactly that is the attitude I was talking about. Of course it should be fixed in the kernel, but that is no reason not to add a workaround in systemd. It's called defensive programming, because you can not expect that a user has always the latest kernel running or that the RTC is at the reasonable time. systemd should simply not lockup the system only because the RTC is wrong or the kernel reports something wrong.

Why on earth should workarounds be added in systemd? Your distribution is free to add such a workaround in their systemd package are they not?

What you forget here is that this bug report specifically mentioned arm based systems, and these usually run customized kernels that are often way behind the mainline kernel. Updating user space on such a system is normally quite easy, but getting kernel updates is difficult, so working around a kernel bug in systemd would help the users, and this is what earns you sympathy. What I asked myself when I read the comments on that bug report and also your comment: Why is it so difficult to take a user-centric view and simply do what's best for them - after all you want that you software is used.

You can't seriously blame systemd for ARM's shitty Linux support.

I'd say pushing to get a kernel bug fixed instead of adding hacks IS user-centric.

[jacob]

I'm really suprised they managed to somehow reach 2.0 of their Debian repack (it's not the fork, they use 99% packages directly from Debian). Especially seeing how their mailinglist (https://lists.dyne.org/lurker/list/dng.en.html) is full of conspiracy. Latest fad: rsync is evil.

It makes me wonder, is 2.0 the release, or the number of users? </sarcasm>

[jacob]

I want Devuan without Devuan, that's fuckin freedom !!

What about the freedom to have systemd without Devuan, is that allowed?

[cybertraveler]

What about the freedom to have systemd without Devuan, is that allowed?

Debian.

[BeardedGNUFreak]

Excellent work.

Surprised to see how fast these guys are making progress.

It is going to take years for Linux to recover from the systemd fiasco.

There are going to be lots of people a few years from now lying about how they never were supporters of the systemd fiasco.

Once distros start dumping systemd there needs to be a serious discussion in the Linux community on how to prevent future disasters like systemd. It should scare everyone that some clown and his fanboys managed to ram his junk pet project down the throats of the entire Linux world.

[oiaohm]

that's an awful lot of words to confirm that I did indeed only use one distro in over 10 years which had a sysv init style init system (slackware). I actually forgot to mention i used Knoppix from time to time, which I found out recently has its own home-brew, simple, single-script init system. This is the video where I found it out:
Defying systemd - or how to do wrong things the right way [en] - Klaus Knopper - YouTube
He discusses the very practical reasons why systemd isn't suitable for his distro and shows how he removes it:

Also watch the start of that video and is very clear that there are reason why you should not removed systemd as well. Klaus for his usage case is fine. But that video also makes it clear that sysvinit as some serous problems for many use cases.

You seem to have complaint with me calling it a "sysv init style" init system. I don't trust you.

Really this is believing a wikipage without understanding history. Sysvinit project where you see distrowatch saying sysv this package is used. Release 1991.

So SysV-style init is true of some other operating systems that implemented an init that behaves like SYSV init. But we are talking Linux there is a project called sysvinit release 1991 by Miquel van Smoorenburg when you compare major of Linux from 1991 to 2006 you will find over 90% of them are all using this 1 project.

I've read so far is telling me that no GNU/Linux distro is running the original SysV init code

This is bull Miguel had to cover this a long time ago because AT&T asked a few legal questions about possible code stealing so where fragments came from had to be documented. So nothing illegal in the sysvinit project of 1991 but is not 100 percent independent of the original sysv III/V inits.

Sysvinit project has snippets that can be traced back to books documenting Sys III and Sys V init system that sections were marked as public domain in the documentation for those operating system. So there are direct links of this project to the history sys III and Sys V init system. So sysvinit project Linux distrobutions a fork off the sysv and sys III documentation that did contain real snip its out of the real sys III and sys V init system that were released public domain for administrators to use and to understand what the init system was doing and if required code their own.

Basically the project it called sysvinit not just because it was attempt to be like the init system sysv had but because sysvinit the project also contains snippets from sysv and sys III documentation. So its a form of fork.

Really no I don't want systemd on everything. I want init systems that are properly maintained and are properly functional.

The main reason why there was so much noise about Debian dropping sysvinit is that the maintainer of sysvinit had been Miquel van Smoorenburg at debian and if debian was not using sysvinit any more someone else had to step up and take up the maintainer ship.

cybertraveler My big problem the maintainer of sysvinit has stepped down and project are still using it and no one has taken over. At least when you look at openrc or systemd you can find current active maintained project.

We all know sysvinit design is flawed. But its also not maintained. Now if this was a case that everyone was using sysv-init likes and they were independent sysv init like things this would be a different matter where each one had their own maintainer system. But all these distributions are using the 1 project called sysvinit that is current not maintained. Even Devuan is doing this.

The problem I have with you using sysv init like hides the fact that we have a big problem cybertraveler of 1 project used by everyone that is now not properly maintained.

What cybertraveler since I don't want to prase someone doing something totally incompetence I have to be pro systemd. You need to understand the history to know how big of a hole we are in. Debian changing to systemd left those using sysvinit swinging in the wind and none them have replaced what debian was doing.

So this is not just about init choice. Its also about who should be doing the init maintenance and who will take over the maintenance of a init if a distribution decides they are not using X init system any more and many other distributions are depending on it who have been skipping out on doing the maintenance.

[TheBlackCat]

Once distros start dumping systemd

And when will that be? Systemd opponents have been predicting this for years and so far zero distros have even hinted at doing this.

[oiaohm]

oiaohm:
This is the video where I found it out:
Defying systemd - or how to do wrong things the right way [en] - Klaus Knopper - YouTube
He discusses the very practical reasons why systemd isn't suitable for his distro and shows how he removes it:

Some of that video is also has clueless fooled. Hes having session problems. There is one big cause of this when debian stop maintaining sysvinit they also stop maintaining other parts.

https://packages.debian.org/search?searchon=names&keywords=consolekit

There is something in the above location that is wrong.

https://wiki.archlinux.org/index.php/ConsoleKit

You look around and you find that version number is not maintained.

Then you go and look at the current edition of Consolekit that is Consolekit2.

https://github.com/ConsoleKit2/ConsoleKit2/issues/10

Hang on it has logind emulation by its own version in 2014.

That video is 2016. The problem is simple no one has submit a current maintained consolekit2 to debian in all this time and this is why he was running into session errors and major issues removing systemd. Because it should systemd-logind out consolekit loginkitd in and applications go along using the logind interfaces and everything is normal.

Really a person like me want to know who that does not want systemd is going to put up their hand and maintain consolekit2 for debian?

There has been enough complaining if you are serous about you complains when are you going to get off ass and do something useful.

[arokh]

Excellent work.

Surprised to see how fast these guys are making progress.

What work? So far they haven't done shit

It is going to take years for Linux to recover from the systemd fiasco.

There are going to be lots of people a few years from now lying about how they never were supporters of the systemd fiasco.

Once distros start dumping systemd there needs to be a serious discussion in the Linux community on how to prevent future disasters like systemd. It should scare everyone that some clown and his fanboys managed to ram his junk pet project down the throats of the entire Linux world.

Just wow. You are obviously completely clueless, why do you even care about the init system? Most likely you are clicking windows all day.

[oiaohm]

Please note this gets even better. You hear all these complains that they will not use systemd because of Lennart Poettering. Most people don't check out who was consolekit maintainers from 2000 to 2012 its deprecation. None other than Lennart Poettering was co-maintainer for that time. So if people do have a anti Lennart Poettering it bent you cannot go back to sysvinit+consolekit. So they used a thing by Lennart Poettering for years and never complained.

So there is a big problem here. As Lennart has moved on to a new project no one has filled his maintainer-ship roles for sysvinit parts. Same with as the maintainer of sysvinit at debian has moved on to other projects no one has filled this maintainer-ship job either.

When you start getting to the bottom of what happen the story starts turning horrible. Its not a story about lack of init freedom. Its a story that no one bare very limit numbers are willing to be maintainers of key init parts. You cannot expect those people to work on stuff they don't like not at least without money.

Debian cannot offer multi init if they don't have the personal maintaining them inside debian and the upstream people maintaining those parts those inits require. For most distributions serous about quality for end user are forced into the same hard choices. Sysvinit is not option because no one is being willing to maintain it and all add on parts.

So the true elephant in the room is where are these maintainers going to come from.