Slashdot Mirror
Devuan Jessie 1.0 Officially Released (softpedia.com)
prisoninmate quotes a report from Softpedia: Announced for the first time back in November 2014, Devuan is a Debian fork that doesn't use systemd as init system. It took more than two and a half years for it to reach 1.0 milestone, but the wait is now over and Devuan 1.0.0 stable release is here. Based on the packages and software repositories of the Debian GNU/Linux 8 "Jessie" operating system, Devuan 1.0.0 "Jessie" is now considered the first stable version of the GNU/Linux distribution, which stays true to its vision of developing a free Debian OS without systemd. This release is recommended for production use. As Devuan 1.0.0 doesn't ship with systemd, several adjustments needed to be made. For example, the distro uses a systemd-free version of the NetworkManager network connection manager and includes several extra libsystemd0-free packages in its repository.
Obviously, they didn't do it for market share. They did it for themselves and then shared it with everybody. Bravo to them.
> Linux has 2% market share.
He said, posting from a machine that doesn't use Linux, the packets quickly routed through a machine that uses Linux, to a farm of Linux boxes, to a box that runs Linux, which stored the information.
Maybe systemd has won the day, but that's no reason to stop people from working on a systemd-free system if that's what they want to do. Maybe systemd will turn out to be the disaster the naysayers were predicting and we'll all be happy they didn't give up. More likely, it will remain a hobby project for a handful of people who are resisting change for the sake of resisting change.
Ultimately, though, that's their choice. When systemd really started taking over, one of the regular comments was that people who didn't like it were free to fork their own distributions that didn't use it. Nobody who said that back then should complain because somebody took them seriously. As long as they aren't actively interfering with anyone else, they should be free to pursue their interests. Real freedom of choice includes the freedom to make unpopular choices.
There's no point in questioning authority if you aren't going to listen to the answers.
I genuinely mean it, good on them. Systemd isn't of that bigger deal to me, but at least these people have gone ahead and done something instead of just sitting around complaining about the fact that they don't agree with having systemd in a Debian default install. That's my biggest peeve with a lot of people in the Open Source community.....they're good at complaining, but they never do anything about it. These people actually have.
I wish them all the best and I hope Devuan has a long and happy life. Perhaps I'll check it out some time :)
I gave systemD a spin on a VM to see if it would be suitable. Unfortunately, it flunked when I disconnected a redundant drive and it flatly refused to even attempt to mount /home in degraded mode. It just dropped me to the emergency shell. I attempted the mount command by hand to see the diagnostics and iot worked perfectly. It seems there is no way to make a command imperative. I looked on the mailing lists and found exactly the same problem with RAID. The response was a collective shrug.
I can absolutely work around that problem, but I can't just put aside the fact that the developers just don't give a crap because it would be a hard problem and their architecture won't accommodate a solution cleanly.
It's just too brittle for me to want it in charge of a server.
Problem is, when it doesn't work it is 99% usually one of the following problems,
A) They intentionally broke it, or were doing something to workaround missing initd functionality and it clashed with systemd. For example, see above post where user is using wicd without disabling an already existing network daemon, probably networkmanager. They blame this on systemd. Solution: use a clean systemd distro, and migrate old configs on a case-by-case basis as the need arises. Many old and crusty initd workaround are no longer needed, and if you blindly go in trying to use them anyway, you are going to create problems for yourself.
B) Software has bugs in it, bugs that were not noticed before with initd because initd did not depend on that functionality working correctly. For example, see above post where user couldn't boot in degraded mode because of a bug in mdadm. They blame this on systemd when all systemd is doing is depending on mdadm to report the drive UUID correctly. The fix in mdadm fixes the problem. Probably, in this case, initd is not affected because it doesn't (or can be made to not) use the UUID when mounting the pool, which is a generally bad practice overall. There is a fair quibble to be had here with distro maintainers who have not properly vetted all aspects of the system to uncover these bugs earlier in the process, but getting these bugs out into the open is the only way they get fixed.
Since I was using BTRFS, I sincerely doubt mdadm was the problem. What I was seeing was another manifestation of the same basic issue, systemD THOUGHT it understood the dependencies but in fact, it did not. That's why it wouldn't even try the mount command.
The systemd design failure is that it refuses to acknowledge that there can be such a situation where it has no idea what the dependencies might be. It demands that everything else must conform to it's concept of what constitutes a dependency. It doesn't even have a way to tell it "use this external program to decide if dependencies have been met" nor does it have a way to tell it just give it a try and if the command returns no error, all is well.
Bottom line, stubbing systemd out and using SysV to bring the VM up worked flawlessly. One of MS's sins is that they demand a perfect world in order to work correctly and will not allow the admin to tell it to just give it a try. Systemd shares that sin. Without systemd, a great advantage of Linux is that when the actually intelligent human knows more than the system, the system will defer to his of her judgement and the job gets done.