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.
So, how do I install systemd on this?
How does this affect anyone? Linux has 2% market share. That tiny percentage is dominated by Ubuntu and Red Hat. Why does anyone care about this distribution? Nobody will use it. It is inconsequential and isn't news at all.
Developers use Ubuntu; server admins use Debian. And server admins who consider systemd to be a destabilizing atrocity that chucks reliability out the window in favor of GNOME edge cases now have an option.
What I'd really love is a Fedora fork (or EL clone, such as Scientific Linux) that reverts to the EL6 initscript build-out and considers systemd as just another option to be used on top of a standard SysV base -- much like xinetd. There if you need it, but not affecting the core.
Hire a Linux system administrator, systems engineer,
but i already have slackware14.2 fixed up nice the way i like it, and i am not wiping all that off to try out a 1.0 release, but still i have to say kudos to Devuan because i am one of those hardcoded systemD haters http://without-systemd.org/wik...
Politics is Treachery, Religion is Brainwashing
How does this affect anyone? Linux has 2% market share. That tiny percentage is dominated by Ubuntu and Red Hat. Why does anyone care about this distribution? Nobody will use it. It is inconsequential and isn't news at all.
While I agree with your general sentiment, I think your counting is off. I think there are a few non-desktop systems that run linux, so that 2% number may be a little low.
If Devuan was offered as a default AWS AMI, I would prefer to use it over Debian.
Often wrong but never in doubt.
I am Jack9.
Everyone knows me.
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.
> I learned Unity.
Unity3D, the multiplatform development environment, or Unity, the now-defunct user interface?
> I learned systemd. It's not bad at all.
The problem is really how quickly it blazed through the community, as major distro after major distro switched to it, and how it was suddenly present in everything. Opting out was overly difficult. If it had moved slower, you'd have seen systemdless distros pop up in due time, instead of after the fact.
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.
That does make it terrible to use systemd on a server. Had a typo yesterday with BIND. Before systemd, the error message would have been displayed on the console. Now, it is dropped by the journal so it made troubleshooting difficult especially since we host over 1,900 domains so we didn't know which file to look in.
server admins use Debian. And server admins who consider systemd to be a destabilizing atrocity that chucks reliability out the window in favor of GNOME edge cases
What are these server admins doing? I have the defaults on EL7 and Debian 8 and all I notice is the VM's come up much faster and with fewer race conditions than under previous inits.
This is over dozens of unique VM images, but they're all doing pretty standard server stuff. What unusual things are people doing that break systemd-based distros?
I understand that some people have philosophical objections - fine - but I haven't heard any of my colleagues complaining of actual instability or unreliability.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Amazon's Default AMI Linux is systemd-less, and is very possibly the most widely deployed linux distribution in use on servers.
and OS instead of children: R! /path/to/remove/.*
https://github.com/systemd/sys...
Pottering's Response:
I am not sure I'd consider this much of a problem. Yeah, it's a UNIX pitfall, but "rm -rf /foo/.*" will work the exact same way, no?
Unrelated, I also found sound worked much easier in FreeBSD than it did in Linux with pulseaudio. I wonder who designed that trash.
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 have installed Devuan on a laptop so far, and will be switching my other systems over time. I had one problem, the lack of a good replacement for network manager, and it seemed that as soon as I complained that the developers put network-manager in the next test release.
Bruce Perens.
Perfectly legitimate question. As a sysadmin myself, only problem I've had with systemd is when I upgraded one system. It had an entry in the /etc/fstab file for a removable USB drive. I had to append "nofail" to the options for that entry, to ensure the system booted properly.
Otherwise, it's been smooth sailing. From a practical perspective, systemd works fine.
Someone with mod points and a liking for sceptical attitudes will soon ensure you're modded up again.
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.
You got a collective shrug because the problem was with mdadm not reporting the UUID correctly early in the boot process and not with systemd itself. This was fixed last year in mdadm 3.4.4 and if you search on the topic you won't find a problem of booting degraded affecting current releases of Debian, Ubuntu or CentOS, unless your mdadm config specifically says to not boot degraded.
The thing people are complaining about is precisely what lead to this problem in the first place. Everyone complains about the monoculture of systemd, but the monoculture of sysvinit not being effected by some design bugs in other software is what is causing a lot of this other software to fail due to undocumented or unexpected behaviour. Then people misattribute it to systemd and complain when systemd developers don't bend over backwards to accommodate bugs in other people's software.
Sound on Linux in the late 1990s didn't really "just work". If you were lucky, you could get one application (and only one) to send audio to your audio card. The situation was so bad that many people used ESD, a quick and dirty hack from the Enlightenment people with horrible latency, to try to get something approximating to manageable sound on the GNU/Linux desktop.
The reason you probably think sound "worked" during the late 1990s was that it was considered a small miracle if sound worked at all, given the lack of drivers, and most people were happy if they reached the point that they got anything to work. Back then it wouldn't matter if running your MP3 player meant no notification noises, because the chances are the latter weren't important (and could be resolved with ESD anyway), and the MP3 player being capable of playing MP3s was "good enough". This problem ran right into the early 2000s.
It was once the drivers started to work, ALSA reached critical mass, etc, that the shortcomings of having the kernel manage audio as a single device started to really show up.
PulseAudio has a bad reputation not because it isn't necessary, but because early versions (1) had problems, (2) clashed with mountains of hacks that everyone else had installed to get around the problems kernel audio, and (3) the developer had a reputation for being a little bit prickly.
If PA wasn't necessary, then given 1-3, do you really think all significant GNU/Linux distributions would have adopted it?
You are not alone. This is not normal. None of this is normal.
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.
You would look in the syslog file you configured bind messages to go to. Or with that many domains, you would run a config test on all zone file before you reload the config. I don't have that many domains configured and I have scripts that alert me to config errors as well as scripts that alert me to domains that are no longer pointing at my server.
Feel free to use my email address to contact me if you need to improve your hosting environment.
I don't think many of the people complaining about systemd are "crusty old sys admins", I think we're talking about mostly hobbyists who don't like change. SysV init has never been considered a thing of beauty by those who have to maintain GNU/Linux (or any *ix) systems. That's why systemd is the latest in a long line of replacements, from Apple's LaunchD (also about to be used in FreeBSD) to Ubuntu's Upstart.
Strongly disagree here, at least from RedHat land. SysV-style init scripts have been a solved problem for quite a while. If there are problems, they're usually a result of the daemon/app itself having problems that workarounds are needed for -- workarounds that usually end up in the systemd.service files as well unless upstream finally did something about the underlying issues.
Seriously, when I need to create an init script for something in EL6, just cut and paste https://fedoraproject.org/wiki/EPEL:SysVInitScripts?rd=Packaging:SysVInitScript#Initscript_template, change a few variables and/or add customization needed, and you're done. It's not rocket science and worked perfectly adequately. BSD folks complained about using chkconfig to manage your rcX.d/ structure (compared to rc.conf), but that wasn't that hard to figure out.
Debian (and Ubuntu) init scripts, on the other hand, seem to more or less be an unmitigated dumpster fire of strange techniques and non-standardization. But I've been a RH guy for forever. If systemd had come out of Debian-world, I'd totally understand its genesis and probably sympathize more. That it came out of Fedora/RH strikes me as quite bizarre. The only thing systemd could use to really justify itself with at F14/F15 time was boot speed, something which Debian had seen good improvements at by swapping https://wiki.debian.org/DashAsBinSh. Had Fedora/RH adopted that, we might not have seen systemd exalted to the degree it was.
Hire a Linux system administrator, systems engineer,
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.