Init freedom declared as 
systemd-free Devuan hits stable 1.0.0 status The self-described “Veteran Unix Admin collective” that in 2014 promised to give the world a cut of Debian without systemd has delivered: Devuan 1.0.0 LTS hit the web today. The collective's objections to systemd were rooted in the belief that its inclusion in Debian created “a lock in systemd dependencies which is de-facto …
I'm already running Debian without systemd BTW (approx. for a year or even more), but I'll switch all my computers to either a hardened Gentoo or to Devuan if Debian doesn't root the fucking systemd out soon. And I'm already running the said Gentoo on one notebook, and while it was a fucking hell to install I'm starting to like it.
I've been running Devuan (on all my personnal and some work machines) for quite a while now, and I couldn't agree more. Debian without systemd works, too (with popularity-contest installed of course), but it often causes trouble in upgrades, while the Devuan project nicely filters sneaky systemd-as-a-dependancy problems.
Slackware is my primary desktop, and has been for a long time, but I support Devuan and will have at least one machine here running it for the duration.
IMO, systemd is a cancer that is growing out of control, and needs to be cut out of Linux before it infects enough of the system to kill it permanently.
"Slackware is my primary desktop"
Sooo, that has changed. May I ask how much effort it took?
I'll be honest, I don't even run Debian anymore, strictly Ubuntu flavors. Granted, I haven't ran Slackware since back in 2004, but I did run it as a primary machine to write a SCSI driver for about 8 months, and it wasn't at all enjoyable. I had a old Voodoo graphics card that would in no way run past 640x480. I had to stop using my Logitech keyboard because I couldn't get the USB to power past BIOS. Actual SCSI support was limited on speeds (at least for the Ricoh I was sampling). But, yeh, I did get the driver to work.
You hardcore C coders can go on with your bad selves, I'm just too old and lazy to tweak Unix anymore. But I'm still surprised you're running Slackware as a PRIMARY desktop. When I think primary, I think graphics, sounds, wireless keyboards, multiple displays...the works. Have you really set all that up on Slackware? I wonder because if I get bored and attempt to write a driver (need one for a ELO touch screen right now), I'll probably skip Debian all together and go back to something like Slackware.
Back when I was distrohopping I ran Salix, a Son of the Slack, and liked it. As I recall, it was easy to install and handled the hardware fine -- though I didn't try multiple displays. Or bluetooth. So no guarantees. But very user-friendly. And init, not systemd.
"Sooo, that has changed."
Has it? From what?
"May I ask how much effort it took?"
I honestly don't remember, so probably not much ... Except I had to run out to Fry's & get a brick of floppys to burn the installation set onto. (I haven't shopped at Fry's since 1996, when they started treating customers like criminals).
Yes, I have all that running, and more. 99% of it worked out of the box (I had to tweak a few bits & bobs to get my third display working). Give Slack 14.2 a whirl. You might be surprised. Report back.
IMO, systemd is a cancer that is growing out of control, and needs to be cut out of Linux before it infects enough of the system to kill it permanently.
Sadly, that ship has sailed. systemd is here to stay apart from niched like this fork of Debian.
Personally, I thought that it was a problem that didn't need fixing but what do I know eh? Zilch.
but I grit my teeth and get on with it.
"Personally, I thought that it was a problem that didn't need fixing but what do I know eh?"
My experience is that I have as many systemd-related troubles in any given month since installng it as I'd had in the previous _decade_. And almost as many as I had running Linux the decade before that.
The problem does need fixing.
I know it's a lot to ask for, but one can wish. I run a lot of machines in my crazy heterogeneous network, and some are raspis. Wow, would it ever be nice if the same code could run on all...a lot of the customizing I've done runs afoul of systemd here and there - and if I have to fix it anywhere, I have to fix it everywhere.
If you have a Pi, installation instructions are here: install link.
Distro build instructions for rasp11,2 & 3 are here: git.devuan.org link.
You can also try Slackware, if you want "One OS to rule them all":
"Maybe people who have actually used (as opposed to just flaming) a systemd-based system for some time, and got used to it?"
I have, and I regularly have weird behaviour that's annoying. I don't know how much of that is due to systemd, and how much of it is due to all that Freedesktop crap, but it's certainly another step down for me.
"Maybe people who have actually used (as opposed to just flaming) a systemd-based system for some time, and got used to it?"
systemd's integration breaks a few important features, depending on the distro. on Mint it caused 'startx' to screw up the X display (I had to remove all of the settings manually), because it's now FRICKING IMPOSSIBLE to find "that one file" that has all of the settings in it.
It's no longer obvious how to do simple things LIKE boot into a console instead of a GUI.
It's no longer obvious how to troubleshoot startup problems.
Some of learn to "live with it" because we pretty much didn't have a choice. Now I have to think about downing my Debian Jessie system long enough to bring up Devuan, and re-install all of the packages. Fortunately everything in /home is most likely portable
"got used to it" with systemd is like being tolerant of a daily paddling
"got used to it" with systemd is like getting used to the bad smell coming from your neighbor's house
"got used to it" with systemd is like getting used to chronic pain
and so on
I selected No because the choice of init system really makes almost no difference to me. I've been using Unix since 1975, and taught courses on Unix programming and system administration, so I find the issues relating to init systems interesting, but they have very little effect on me on a day-to-day basis. I've survived BSD init, SysV init, upstart, and now systemd, and none of those changes has made an appreciable difference to me, other than some minor modifications to scripts. Obviously, some sysadmins might find that such changes necessitate a great deal of work; but that hasn't applied to me.
Now do I find systemd's design offensive? Yes, I do. But then I find most features in modern distros kind of offensive (the cat and true commands are exceptions ☺) . I tend to like systems that are consistent, have as little clutter as possible, and match my notions about workflow. I would personally have liked it if Plan9 had been modernized and made a solid OS. But it wasn't, and Ubuntu and Debian do a fine job for me.
So what about Devuan? I hope the developers can produce a solid system. If it's easier to use, or more robust, or more scalable than Debian, good for them; maybe other distros will pick up on their ideas. The computer scientist in me finds such matters interesting; the computer user in me is happy with what he has.
This.
Is it architecturally monstrous? Dunno. Been booting with it in some distros, and without it in some distros. It's pretty much this: thanks for all the fish. Gawd knows I will never be skillful enough to code anything like an init system, so ... viva Linux, whether Devuan or Debian.
@OP "I can't believe anyone voted for this option. Were these people joking, or did they accidentally click the wrong button?"
I asked my wife; she said "It doesn't offend me." She's quite happy with windows and I'm happy to let her be.
How do you know when you've got SystemD? When you boot your computer, after its been running for 5000 years of course, does it pop up on the monitor like Jack through the toilet door in "The Shining" and slap your face, leaving you looking like you've been Tango'd? Is it evil like that?
No, its when randomly your computer wont boot like usual and your left fishing round in the dark wondering how to get the blob to tell you what the problem is.
We installed debian as something had a hard dependancy on it as a distro, and it seemed ok, and a couple of days later it wouldn't boot cleanly and had to do the whole trying to get logs out of it before it had come up properly mess wondering if it might be quicker to reinstall a linux box than fix it for the first time, then we decided we'll do that old diagnostic method of removing everything it could possibly be starting with a innocent looking usb bluetooth dongle. And lo and behold up it came. Left in at boot, machine again failed to boot. Take key out, machine comes up fine. Replicated it on another machine too as we couldn't believe leaving a usb peripheral would cause boot failure under linux.
This is apparently not a flaw in systemd but broken hardware. *WONTFIX* ...
Disclaimer I'm one of the people running devuan already, and the above experience is just one of the reasons why.
Sounds like you didn't use UUIDS in your fstab and that blew out your partition order with the USB stick in.
Yeah that will be a systemd problem won't it.
Your other point about logs just shows you're ignorant, lazy and unwilling to learn the skills you need to execute your job.
It was the debian installer that handled fstab configuration but I fired up the second box we verified the error with as thats still not been repurposed yet , and its using UUID's in fstab for the hard disk partitions. There was no tty's alive and it didn't time out and drop us to a emergency shell after waiting 5 minutes which I would have expected if a mandatory mountpoint failed either. Yes we could probably have dug into it further to find the complete answer, but I was reeling at being able to bring a linux box down with a usb device. We found out early on about the making a system unbootable with a automounted nfs mount if the nfs server was down at boot time too, so that was set to noauto.
For the logs, given it hadn't mounted the partitions at that point, journalctl wasn't writing anything to anywhere we could interrogate easily, yes we tried systemd.unit=emergency appended and it was still wouldn't come up, at that point the systemd troubleshooting docs recommend to reinstall the operating system as some core libraries must have been corrupted.
Just what was so bad about a dmesg on the console screen that you could just *see* that needed killing with fire by this mess anyway?
Your attitude is par for the course on what we have come to expect. Every bug or bad behaviour in systemd is luser error.
"Sounds like you didn't use UUIDS in your fstab and that blew out your partition order with the USB stick in."
When I read the post you're referring to, it mentioned a USB Bluetooth dongle, not a USB stick.
"Your other point about logs just shows you're ignorant, lazy and unwilling to learn the skills you need to execute your job."
Glass houses and stones spring to mind.
systemd is handling far more than just the init function. And as more and more bits of the running system are incorporated into systemd (unnecessarily, for the most part), systemd will become MANDATORY to run Linux. In other words, systemd will become a choke point.
And the choke point is controlled by whom, exactly? It sure ain't "the community" (whatever that is!). Are you certain you want Linux to become capable of being held to ransom? To me, it sounds foolhardy, at best.
And that's without going into any of the technical arguments against it.
As a long-term un*x user, are you sure you are not offended?
And the choke point is controlled by whom, exactly?
Systemd is licensed with LGPL. So anytime the current developer tries to act up, and annoys enough users, it gets forked. Just like happened with Xfree86, MySQL, and OpenOffice, among others. That is one of the reasons for the existence of GPL and other free software licenses: Nobody has a chokehold.
It's called inertia, MacroRodent. Once systemd is entrenched deep enough, getting all the other projects that depend on it to change will be virtually impossible. None of your examples were designed to preclude similar software running along side them, on the same machine, often at the same time.
systemd is designed to do exactly that. The authors want control.
Some of us; believe it or not:
1) Do not have any problem with systemd.
2) Have actual problems that sysv can't deal with effectively.
3) Like systemd.
4) Understand systemd.
5) Have had bugs fixed by the systemd developers after politely reporting them.
6) Are extremely happy with systemd.
7) Think systemd is a massive improvement over sysv which is/was great on its day but falls waaay short in the current year.
I'm sick of the systemd crap people post online, out of 1000's of posts I have seen maybe 1 or 2 issues that were genuine issues with systemd, the rest was people who do not know/are not familiar with systemd and just complain when they do not know what to do when their sysv hacks don't work on systemd.
For all the hacks out there who hate systemd, create a unit, and run your fucking script from there:
/etc/systemd/system/lowgpu.service
[Unit]
Description=Set the RADEON R290 to low energy profile
After=lightdm.service
[Service]
ExecStart=/usr/local/bin/lowgpu.sh
Type=oneshot
TimeoutSec=20
User=root
Group=root
[Install]
Alias=lowgpu.service
WantedBy=multi-user.target
systemctl enable lowgpu.service
Oh my god, it is so complicated, all that to get a little script to start at boot with complete control of when and how!
HERESY!!!! I want muh "rc.local" and my sysv scripts (never mind that systemd supports rc.local and sysv cripts just fine)
"I'm sick of the systemd crap people post online, out of 1000's of posts I have seen maybe 1 or 2 issues that were genuine issues with systemd"
Presumably those "1000's" of posts were somewhere else on the internet. Most of the posts about systemd problems on this forum have been from experienced people who certainly don't need to be given a "dummy's guide" to how to write a unit file. It's Friday. Calm down and have a beer.
To be brutally honest, as these days mainly a desktop user rather than sysdamin and or developer, I had to run `ps` to see if this Mint flavoured machine was running systemd or not.
I THINK it is.
And that is the point, at some level I dont really care. So long as it works. Frankly I loathe the idea of X windows, and Postscript*, but they are now sufficiently bug free and processors are sufficiently powerful that the alternatives are not worth pursuing.
I am fully aware of why systemd is loathed, and at a given level I agree. It's one man's ego trip, not a pragmatic advance in OS design. but as long as better men take it and lash it into shape, and document it and get the bugs out, that is merely a problem to be solved, not a show stopper.
And of course Linux itself is one man's ego trip in a sense. Its just a frantically GOOD man's ego trip.
Unlike systemd...
In the end, like a Porsche, success is often more about the triumph of rigorous development over a really poor design.
(hanging an aircooled flat 6 out the back of a sports car is a really bad place to start a design, and it will always be a noisy tail-happy bitch, but there you go).
*Adobe: A brick made of straw and mud.
What many youngsters forget is that the Unix philosophy wasn't invented to make yourself look cool or to set you aside from other existing systems. The whole idea is to cope with the increasing rate in which (software) systems become more and more complex. Although several models exist to try and help you keep control and remain having a grip on the systems design despite its complexity (my personal favorites being UML and SysML) you can only go so far. Not to mention that in some cases those design models may require a whole study of their own.
So instead we have the Unix philosophy which can basically render UML/SysML completely useless (more or less anyway). Mind you: I say this as a pretty devoted fan of those modeling languages. For the simple reason that it's implementation is simple and to the point, prone to help people keep an overview of what it is they're doing: make something small, make it work well, make sure it can interoperate with other systems and make sure to maintain that. Sure, the downside can sometimes be a cascading effect: if something goes wrong with one small part (think of an exploit) then it might affect others which rely on that part as well. But because it is a relatively small part its fix shouldn't be too hard either.
But this monstrosity?
"You don't like choice"
No. Choice isn't a bad thing per se.
It just feels like the whole "community" is spreading itself thin as so many people are inventing the same wheel yet again with slightly different configurations. Are you unhappy that there ain't a few dozen forks for kernel and CUPS to chooce from?
Ha!...Here's my patented wheel invention. It has the spokes on the outside. I know its not the most intuitive design but I think once I have the problems sorted its going to be an absolute smash.
If I just shrink the rim down to the size of the axle then cover the spoke ends with something to stop the juddering...It could just work!
Or just install debian following these instructions:
Debian Wiki: Installing_without_systemd
Already installed? Simply follow these instructions:
How to remove systemd from a Debian jessie/sid_installation
This works fine on a few debian jessie vpses I run.
To those who said they voted no because they haven't had any problems running systemd: more fool you. You almost certainly will have problems one day. Problems happen when you do something that is outside your normal routine. For example...
I have a six-month old Dell XPS 13 that came with Ubuntu pre-installed. I tried out Ubuntu for a few days and all seemed fine, until one day I booted into recovery mode. I was happily typing commands into the recovery mode shell when all of a sudden systemd pipes up that something has timed out and it is going to start an emergency shell. I now have two shells running, both reading from the same terminal. And they are not getting one line of input each or one character, but something in between, which made getting out of the situation an interesting problem-solving exercise. Needless to say the next thing I did was to install a different Linux system with good old sysv init. (Not Devuan as I didn't think it was mature enough at the time, although I may switch to it sometime.)
I am currently running Arch with systemd (and some other systems). It mostly works and I cannot be bothered to replace it, but I do not believe it will always work. I have been around long enough to take failure for granted and prepare for it. Which is why I support Devuan (via regular financial contributions) and am happy that they reached milestone release. I need to have a choice when the time comes.
"Happy with systemd? You won't be one day"
Not using something because there's a possibility of it not working later on is a bit of a dumb reason really.
Eventually you're going to have problems with anything. I don't expect my car to be entirely problem free for the next 50 years, I'm going to expect to need to do some maintenance on it at some point.
Exhibit a)
hostnamectl
This is infected with the command-string instead of switch to control what it does. Setting the hostname is done by:
hostnamectl set-hostname <name>
not:
hostnamectl sethostname or hostnamectl set_hostname
and not hostnamectl set-h (even though there is no other command that starts with the same characters)
Who knows what it does aside form editing /etc/hostname?
Exhibit b)
firewall-cmd
Creates an arcane and opaque wrapper around iptables. For anything other than the simplest case, it's actually easier and safer to just write iptables commands directly.
They do different things, "hostname" only reads the current hostname. "hostnamectl" is able to set the hostname, standardizing what used to be a per-distribution custom mechanism. Despite being shipped with systemd (to make sure everyone can rely on it) it doesn't actually depend on systemd and in no way goes through it.
also hostnamectl is the agreed replacement for "lsb_release -a" and provides other information (like the underlying virtualization platform) useful for orchestration all in a standardized manner.
firewall-cmd (firewalld) is more of the same, an effort to standardize configuration, however on this one I have to agree that after learning how to use IPTables directly, I do not have much use for firewall-cmd as for me it gets in the way, however:
systemctl disable firewalld
And we're done here, thank you very much ladies and gentlemen.
Firewall is a separate task and it must be provided by a separate package thus. Tea at 5 o'clock is also part of standard routine, why don't you include it in systemd too? Take job from cron (and anacron) and reimplement their functions in a "more efficient way" with bells and whistles added? In an effort to standardize configuration, yeah?
Sigh. I can only sympathise. I remember when on SUNOS and other Berkeley derived systems we could have a printer going in ten minutes.
Then SysV Unix arrived.
And the horror that was lpadmin.
It took over a decade before CUPS essentially wrapped that cesspit in something remotely usable.
sadly the history of engineering is littered with bad ideas that became de facto standards simply because the effort to bugger them into shape was slightly less than the effort to write them from scratch again.
If we wanted to get to where we are now, would we today start with postscript, X windows. Sys5 printing, socket based network code, PHP, JavaScript or even MSDOS?
Legacy dear boy, legacy. And if it ain't totally broke, fix it.
As a friend who died a fortnight ago said in his last phone call to me 'it hardly seems to matter now, does it'
Is the heavy-handed tactics Red Hat have used to force this down everybody's necks.
Both Gnome and systemd are basically Red Hat projects. Gnome is pretty popular, and the systemd people have used that to force systemd upon everybody's distribution by making Gnome absolutely depend on systemd.
Canonical tried for a time very hard to have their own non-RedHat init by trying to reimplement the systemd protocols in their own daemons. Surprise, surprise, every bl**dy point release of Gnome somehow changed the protocols and broke Ubuntu's daemons. It may not have been intentional sabotage but it was certainly not distinguishable from it by its effect.
To me these tactics remind me a bit too much of the famous tactics of a certain Redmond-based company.
"Gnome ain't done until alternative init's won't run."
With respect to the actual systemd code, I think it has its architectural problems, but the real issue is the effective stranglehold Red Hat has gotten on the init world. So for example, yes you can fork systemd, but it is extremely likely that Gnome will then suddenly change its protocols again. And your fork will be broken.
/* sinit (2014)
* http://core.suckless.org/sinit
* Because complexity killed the cat.
*/
# MIT license.
#include <sys/types.h>
#include <sys/wait.h>
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#define LEN(x) (sizeof (x) / sizeof *(x))
static void sigpoweroff(void);
static void sigreap(void);
static void sigreboot(void);
static void spawn(char *const []);
static struct {
int sig;
void (*handler)(void);
} sigmap[] = {
{ SIGUSR1, sigpoweroff },
{ SIGCHLD, sigreap },
{ SIGINT, sigreboot },
};
static char *const rcinitcmd[] = { "/bin/rc.init", NULL };
static char *const rcrebootcmd[] = { "/bin/rc.shutdown", "reboot", NULL };
static char *const rcpoweroffcmd[] = { "/bin/rc.shutdown", "poweroff", NULL };
static sigset_t set;
int
main(void)
{
int sig;
size_t i;
if (getpid() != 1)
return 1;
chdir("/");
sigfillset(&set);
sigprocmask(SIG_BLOCK, &set, NULL);
spawn(rcinitcmd);
while (1) {
sigwait(&set, &sig);
for (i = 0; i < LEN(sigmap); i++) {
if (sigmap[i].sig == sig) {
sigmap[i].handler();
break;
}
}
}
/* not reachable */
return 0;
}
static void
sigpoweroff(void)
{
spawn(rcpoweroffcmd);
}
static void
sigreap(void)
{
while (waitpid(-1, NULL, WNOHANG) > 0)
;
}
static void
sigreboot(void)
{
spawn(rcrebootcmd);
}
static void
spawn(char *const argv[])
{
pid_t pid;
pid = fork();
if (pid < 0) {
perror("fork");
} else if (pid == 0) {
sigprocmask(SIG_UNBLOCK, &set, NULL);
setsid();
execvp(argv[0], argv);
perror("execvp");
_exit(1);
}
}
My home server hit a systemd snafu today when I updated it b/c of the recent samba fix. systemd failed to reload daemons because it (now) has a strict 16M "safety" buffer requirement. So when I did apt-get upgrade, none of the services reloaded, and I was spammed with errors. url: http://forum.doozan.com/read.php?2,34313
One can argue that 16M is a reasonable safety margin. Or that such an ancient device is ok to be thrown under the bus. However, the box has been rock solid (and surprisingly untaxed given all the services this puny device handles) for upwards of 8 years. So I have to write workarounds to be able to update the system thanks to someone making wrong decisions about this particular device. Or more broadly, 1) get new hardware, or 2) move to something w/out systemd.
It is tough to consider getting new hardware because this device has been so completely stable for so long. But I may do it, I mean the newer options are barely 15 dollars. However, if I do, you can rest assured that i will ALSO be choosing option 2.
I would consider OSS better. It is a very Unix-like interface. You just use standard Unix open() and write() system calls to write raw audio data to /dev/dsp.
You can even just 'cat' raw audio data and redirect into /dev/dsp.
Similarly, capturing sound from the microphone just involves the read() system call on /dev/dsp .
Except when it comes to modern sound renderers, that's TOO simple. Too raw. It's basically exclusive mode to a sound device, and we left that kind of sound world back in the 90's. You're going to need some kind of audio compositing layer on top of OSS to handle the more intricate matters of multiple streams, multiple targets, and so on. If PulseAudio isn't to everyone's liking, then we need an alternative.
You may want to research how FreeBSD handles the /dev/dsp interface. It is not a single audio device, rather it represents the "preferred" audio source/sink. Multiple applications can write to /dev/dsp concurrently and it gets mixed together. The actual audio device can be switched, and there are also configurable policies like "use best device" and "use last plugged-in device". Finally, audio can be redirected to a " virtual" audio device where a user-space program can process and redirect it in any desired way.
Arguably this can do anything pulseaudio can do.
> Debian can run with any init system, including systemd.
To my best knowledge there is no option to install sans systemd. Yes, there is that kludge (I used it) to remove systemd. This breaks stuff, such as gnome.
More things will depend on systemd in the future under Debian, and I cannot find _any_ commitment that Debian is even supported w/o systemd (pointers are welcome).
Hence I thank Debian for all their good work so far and move on.
But yet again, we have to point out to those who swallowed the lied and misdirections from the systemd camp :
This isn't about init !
If all systemd was was an init system, that could be swapped out for a different one, then there'd be no complaints.
Systemd was sold as being an init system, it isn't. It's a whole furball of crap that doesn't belong as part of an init system, all tightly bound up in such a way that you basically need it all or none of it. And because they've been aggressive in what they borg into it, too much has now gained dependencies for it to be easy to remove. Yeah, you can (almost) run Debian Jessie without systemd - as long as you don't want to run many useful packages. But that will get harder and harder to do as more and more gratuitous dependencies get stuffed into everything.
The approach taken by the systemd camp is to borg more and more functions into systemd, changing the API in such a way that if you want your program to run on a systemd system then you need to link against their libraies and use their APIs. Once you do that then your program won't run if systemd isn't running - and so you end up having to maintain two variants of the program.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
