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?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
