Slashdot Mirror
Devuan Releases Beta of Systemd-Free 'Debian Fork' Base System (devuan.org)
jaromil writes: Devuan beta is released today, following up the Debian fork declaration and progress made during the past two years. Devuan now provides an alternative upgrade path to Debian, and switching is easy from both Wheezy and Jessie. From The Register: "Devuan came into being after a rebellion by a self-described 'Veteran Unix Admin collective' argued that Debian had betrayed its roots and was becoming too desktop-oriented. The item to which they objected most vigorously was the inclusion of the systemd bootloader. The rebels therefore decided to fork Debian and 'preserve Init freedom.' The group renamed itself and its distribution 'Devuan' and got work, promising a fork that looked, felt, and quacked like Debian in all regards other than imposing systemd as the default Init option."
I'm not going to bother saying anything about Lennart or other core systemd developers since it's been widely established that they have proven to be disagreeable on numerous occasions.
What I will say, however, is that after spending the time reading up on systemd and learning how to use it, how to write unit files and all that jazz, I really fail to understand what the furore over it is. My systemd machines are ready to go much faster than any bash-script based init system and writing a new unit file for some daemon that lacks one already is easy peasy.
The only place where I feel it falls somewhat short is in systemd-networkd which currently lacks good support for policy routing. Fortunately, it doesn't bar me from running a post-network-up script to do command-line based route installation, so until it develops that functionality, that's what I'm doing.
Systemd scripts and other init scripts can coexist peacefully in the same package, so I don't see why maintainers can't work together. If there is a willing team of people who want to maintain these scripts I see no reason why the Debian team should stop them.
A beautiful thing about open source is you have the choice to go against the flow. Sometimes it pays off. Often times it doesn't. If someone stops you then fork, but I really don't see what the big deal is. Let's keep our egos in check and hopefully we can see maintainers working together even if they have slightly different methodologies.
I am new to this and I have seen a fair few "systemd is 3vil" posts, but with little indication as to why people dislike it, compared to the alternatives? Just to be clear I don't have a position here, rather I am looking for some insight.
Jumpstart the tartan drive.
I really dislike systemd. It ruined my Debian installation. But I'm also really displeased with the Devuan project, too. I followed it briefly when it first started up, and I think it was a fucking joke. The smugness of the people involved was terrible. The first months of the project were constant accusations of people being "systemd trolls". I found everything about it to be shameful and amateurish. And it became clear pretty quickly that it wasn't going anywhere. So instead of waiting for it, I moved to FreeBSD. And you know what? I couldn't be happier! It brought me the best parts of the traditional Debian experience: stability, reliability, trustworthiness, and robustness. But it also didn't subject me to systemd. The more I use FreeBSD the more I regret not switching sooner. As far as I'm concerned, there's no need for a project like Devuan because FreeBSD is a full, systemd-less replacement for Debian, and Linux in general.
Yes, this, uh, adult, reasoned, calmly and rationally stated essay really instills confidence in the maturity and professionalism of the maintainers of this distribution.
(That son, I say that son, is a a a joke son, I say a joke.)
You are not alone. This is not normal. None of this is normal.
It prevents it. The init part of systemd is just a small part of it. It has started to replace many (and a growing number) of core Linux userspace subsystems. It has gotten to the point where you may not be able to run the desktop environment you want without systemd. The generic, modular bits that systemd has consumed are now components that more and more pieces of software are depending on. In the very near future, it may not be possible to run a modern Linux desktop without systemd.
And, for what benefit? None that I've ever seen. There is nothing that I can now do with my laptop that I couldn't do before. But, there are plenty of things that I can no longer do since the introduction of systemd.
...my take on systemd is this: As an init system, I actually like it - far better than other SysV replacements, especially SMF on Solaris and friends. Where it goes off the rails, though, is the ever-expanding mission creep into things that really aren't an init system's purview.
If systemd would just be an init system and get out of the way, I'd cheer it on. But one of the first things I do when I set up a CentOS 7 server is to shut off firewalld and use iptables directly. Firewalld is OK on a laptop where you're connecting to a variety of different networks, but leave it off my servers, please.
Oh, no! You have walked into the slavering fangs of a lurking grue!
So, doomed to failure, then?
To me, systemd is a solution looking for a problem. Ego has little to do with it; rather, trying to get shit done is what the issue is all about.
Also, systemd reminds me of the time I got soap suds up my pee-pee hole.
Systemd scripts and other init scripts can coexist peacefully in the same package, so I don't see why maintainers can't work together.
Found the guy that has never dealt with Debian developers.
So, doomed to failure, then?
Well , as much failure as any Linux distro has. The best thing about this is it's one more solution for those who really hate systemd.
However, this dislike has a life of it's own, so I don't expect any diminishment of the complaining.
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
So who is taking the initiative to maintain the bits that "systemd has consumed and replaced"? What happened to "build it and they will come"? I'm asking for people to bring on the code and all I see are people bitching that "systemd is taking over everything".
We run SUSE SLES 12 with systemd on our 1020 node Cray XE6 and it works just perfectly. What a joke, "veteran unix administrators", it doesn't get much more complex than a 1020 node, 21,824 processor Cray XE6 with Nvidia Tesla on each compute node. Node management and integration with the job scheduler is significantly simpler than older versions. The older system was a mess of shell scripts, perl scripts, and who knows what else, the new system is all streamlined in a simple config file and few modules.
Glad your have not been encountered with any corner case yet. And I'm pretty sure nosh would do the same thing better, without bloat either in scripts or in the init system itself (well, you really want to define "simplification" as replacing several MBs of debuggable scripts with several MBs of spaghetti C code?), and without the "you are not supposed to hold the phone that way" cases.
You know i for one welcome our new systemd overlords. Part of why non-systemd users don't get supported anymore is because there are no non-systemd services anymore with a rich API as systemd. And very often unification is very good.
You know there have been multiple projects for standardisation among linux, and many of them have failed. Most of them just published a standard nothing more. systemd offered an implementation, without a standard, and it was successful, didn't fail.
Oh the problem is there alright.
See here for example: https://www.youtube.com/watch?...
You want to replace sysvinit with something.
Now whether that is upstart, OpenRC, systemd or something else is the question.
systemd's service dependency tree and triggering is definitely attractive, and you can do some cool server configurations with it. For example, assign resources to a service, and that restriction applies to all sub-processes. Or find all processes launched by a service.
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
The problem was service inter-dependency in startup/shutdown was quite awkward in SysV, plus the opportunity to increase service startup/shutdown speeds by handling unrelated services in parallel.
People who have this perception aren't using inittab properly. We are yet to see a use case presented that init cannot deal with and these two are already covered. Dependancies are meant to be initialized via rc scripts and services are maintained via inittab.
People seem to be hung up on using runlevel scripts to do everything. It's this mis-use case of red hat's runlevel scripting system that is being used as an excuse to replace initd with systemd. It's pretty reasonable for people to be skeptical about these efforts to replace initd when the issue is not functionality but education.
I sometimes wonder if their is a perception issue with the use of inittab files, like the server will explode if you do something wrong in an inittab script. However it's quite simple once you get you head around three key things:
Use a combination of run level scripts and scripts executed from inittab to acheive a system configuration. Runlevels are available to inittab entries when the rc scripts complete or execute in the background. Make sure your inittab shell scripts don't exit if your service is running properly.
That's pretty much all you need to remember to create very powerful and elegant patterns to manage the activities of any *ix system.
My ism, it's full of beliefs.
The problem with systemd isn't its replacement for scripts.
Well, kind of it is, since they arrogantly didn't bother to provide any way of getting certain things done that scripts were doing, but that's only where the outrage begins.
The problem with systemd is that it doesn't want to coexist peacefully. It wants to own everything. Not just resource control, but logging and other things as well.
I still have no idea why they needed to fork from debian, instead of just maintaining packages/patches required to provide a systemd alternative from within debian.
When choosing a distribution, why anybody choose a distribution whose only clear philosophy was that it is not something else? Unlike debian which is ultimate software freedom and stability or whatever.
SURELY NOT!!!!!
"systemd is a solution looking for a problem." - if that was the case, it would have withered and died.
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
There is a very small percentage of cases where systemd cannot make use of the scripts. You could check here to see if any of your problems are listed https://www.freedesktop.org/wi... Logging is one of the fantastic bits about systemd, its far more comprehensive than anything else. Its just a matter of learning about the new features and tools.
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
Oi !!! sit down and give your mouth a chance
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
"And, for what benefit? None that I've ever seen. There is nothing that I can now do with my laptop that I couldn't do before. But, there are plenty of things that I can no longer do since the introduction of systemd."
well, if nothing has changed then they've done such a good job as you carried on as normal. What can you no longer do?
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
you need to practice your trolling as that was painfully bad.
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
Except for its ability to happily hand over to scripts, it's ability to happily log to a syslog daemon, and happily hand over networking, NTP, and all other functions to another system of your choice.
Key word "choice". Configure it how you want to. This may require you to read a manual or do a Google search but that's hardly a new thing in Linux.
So either you get a new hotplug environment within runlevel 5, which then handles all the temporarily running services, or you just accept that the hotplug environment does nothing else than init (starting and stopping services depending on a set of constraints), just in a more flexible and granular manner, and init with runlevels 1, 2, 3 and 5 is just a special case of the hotplug environment, which just duplicates the functionality of the hot plugging environment in a more clumsy and less flexible manner.
Yes, this, uh, adult, reasoned, calmly and rationally stated essay really instills confidence in the maturity and professionalism of the maintainers of this distribution.
It has always struck me that I can't seem to find a critique of systemd that lacks namecalling, cursing or at least one suggestion that Poettering do something that sounds anatomically unfeasable. It's as if the critics are largely middle-schoolers who don't actually have any skin in the game.
This comment is fully compliant with RFC 527.
“..At first I hoped that such a technically unsound project would collapse but I soon realized it was doomed to success. Almost anything in software can be implemented, sold, and even used given enough determination. There is nothing a mere scientist can say that will stand against the flood of a hundred million dollars. But there is one quality that cannot be purchased in this way -and that is reliability. The price of reliability is the pursuit of the utmost simplicity. It is a price which the very rich find most hard to pay.” – C.A.R. Hoare
All my systems are now switched to Devuan.
The essay made people like me (linux-only since 1998) switch.
Indeed. No tangible benefits for many people and at the same time massive mission creep. If it were a sane design and just stuck to being an init-system, it would also be very easy to fully support other init-systems in parallel. The systemd developers have made that hard, and I think intentionally so. I call that one thing: "sabotage".
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
And that is just it: This thing does not exist to solve any exiting problem, it is a power-grab, plain and simple. That is also why it grows though Linux like a cancer and absorbs everything it can, so it cannot easily be ripped out. If it had stuck to being a better init-system, it may have had merit, but this way it is a huge threat to Linux, nothing else.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
As someone who started with Slackware in 1997, and has been running GNU/Linux in some form or another ever since, his primary desktop GNU/Linux 90% of that time, I can tell you your "made people like me" statement is an exaggeration.
Frankly, this kind of essay is more or less standard fare from systemd opponents, and it's probably standard fare because it's actually hard to come up with a reasonable criticism of systemd, especially considering what it replaces. sysvinit should have died the moment the Internet became a thing, but it's soldiered on, a ghastly mess of hacks that results in virtually unrecoverable machines far too easily.
systemd is not perfect, but it's a hell of an improvement on what preceded it, and virtually every criticism of it is either overblown (OMG it has a 'sudo' command? How terrible! The world is going to end!) or downright misleading (binary logs... that can be dumped using the strings command. Yeah, big problem, not. stderr not logged? Perhaps you should fault your distro for turning it off, rather than systemd that happily logs stderr?)
You are not alone. This is not normal. None of this is normal.
And LaunchD
thats an unreliable anecdote, he can't find anyone else with the problem and seems like he's not even logged it as an error.
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
another load of anecdotal nonsense, he should have linked to a bug report
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
systemd logs perfectly fine to rsyslog. Stop acting like a parrot by repeating FUD.
"I know I will be modded down for this": where's the option '-1, Asking for it'?
I'm 61 - took me about an hour to figure out systemd - not that I asked for the change - but it wasn't a big deal. In the end I realized it fixed a few issues and all the hate-flame-bait crap was uncalled for.
I've come to realize it is must be only a minority of really old farts that complain about systemd - I get it - as people age they can't learn new things - can't see why the changes are happening - growing old sucks.
I suppose it is really the old guys over 70 just can't adapt to these changes - so I have some notes for them:
https://wiki.xtronics.com/inde...
I'm 61 - took me about an hour to change over to systemd syntax. I didn't ask for it - thought it was a bother, but in the end I see it fixed some things and it is working fine - the hate-flame-bait-carp was uncalled for.
I have come to realize that it is only the really old guys over 70 or so that no longer can learn new things or see other points of view. Growing old and losing metal agility must really suck. I put up a page with notes for these guys that can't adjust on their own:
https://wiki.xtronics.com/inde...
I am really glad the Debian did not fold to the pressure of the geriatric community to become set-in-their-ways.
systemd is about getting stuff done. sysvinit basically became obsolete around 20-25 years ago, at around the time network services became a thing and when security required more than just deciding who could log into your box from a network you largely controlled.
I've had to recover too many boxes using boot CDs because a faulty network card has prevented some resource from starting that the existing sysvinit scripts rely upon causing sysvinit to just hang to think sysvinit is the utopian ideal systemd opponents portray it as. And, before anyone mentions the various rivals, most don't solve the same problems, and none support Linux's security model. Starting services in boxes using cgroups, for example, which ought to be the default for any network facing service, requires manual hacking together of shell scripts to create something that can't easily be managed by a centralized service manager.
systemd is a good idea. It's not perfect, but judging by the fact its opponents insist on using "faults" that are misleading, minor, or irrelevant, I don't think we're likely to get anything better than systemd for a very long time.
You are not alone. This is not normal. None of this is normal.
Servers sitting in a light's out facility rarely have things plugged ind unplugged.
The whole controversy could have been avoided if systemd was properly designed as a plug-in component. System starts up under the old init. At some point (after the basic system has been brought up), an rc script or inittab starts systemd (a series of event listeners) to deal with hot-plugging and such. Make sure it doesn't block others from listening.
Poof, no controversy, no objections.
Did you even read the summary? You know, the one about the group building and maintaining a systemd free distro who just released a beta?
initd starts the event manager in that use case.
My ism, it's full of beliefs.
I value having frivolous boxes around that I can just "do whatever" with, but I value even more having root on boxes that I wouldn't alter frivolously.
My first linux was slackware 3.0 which I got by buying a magazine that had the CD glued to the cover. Then I spent 3 days downloading a newer slackware over dialup. Before that I had to telnet into my ISP's SunOS 4 box if I wanted some *nix.
Throwing my hat in with, "a hell of an improvement [over SysV]."
The types of "technical complaints" people come up with... they aren't even enough of a challenge to make the daily list of sysadmin annoyances. They're all just small changes people would have to make in which program is in the first part of a long chain of piped commands. I mean, if getting ASCII logs is hard, what would happen if you needed to pipe the output through sed and on to xargs to do some work with it?
None of the companies I work with care if a person, place, or thing "sounds like a... ladyboy." If a person wants to be a ladyboy, that is fine with us. If they want to identify as a man or woman instead, that is fine too.
But if they make non-technical complaints about technical things, or have a passionate dislike for something that is merely not their first technical preference, then they're out the door, and if they don't want their desk contents in the mail, they'll sign the paperwork and leave promptly.
No, I've never worked at github. Yes, we prefer systemd. So that is the only reason not to use Devuan. It lacks important modern software.
One of my friends is a ladyboy. Some people think he should either stop wearing dresses, or at least shave his legs. I think, if he wants to have hairy legs and three days of stubble and wear a foofy dress, who cares? If it's warm out, I'm going to wear my cargo shorts and I'm not interested in people's opinions of it. Same.
Systemd scripts and other init scripts can coexist peacefully in the same package, so I don't see why maintainers can't work together. If there is a willing team of people who want to maintain these scripts I see no reason why the Debian team should stop them.
The problem isn't the init-scripts, the problem is supporting two different init-systems at the same time, including replicating and fixing bugs.
That is why Devuan is removing systemd from their Debian fork, even though Debian Jessie at present can support both SysVinit and systemd.
The problem with systemd is that it doesn't want to coexist peacefully. It wants to own everything. Not just resource control, but logging and other things as well.
I don't think you have actually studied the design of systemd; it is exactly designed to co-exist peacefully with other components. It is a major reason why it was adopted so successfully and fast:
You can use any syslog daemon like Rsyslog or syslog-ng with systemd's journald.
You can use you own homegrown resource manager using cgroups instead of systemd's. systemd uses cgroups for two things; tracking and grouping services, and resource control. But the latter use is entirely optional and you can compile systemd without such support.
Really, people are so misinformed about systemd. It is like they never even read a systemd man-page, but just uncritically iterate whatever some random blog guy once wrote.
I thought this whole Linux thing was all about freedom to choose?
Not when it comes to Devuan; they won't let you choose systemd as init. No "init-freedom" there.
But why keeping init, if a system is in place anyway that does the same thing as init, just with more control and much higher flexibility? It doesn't have to be systemd, but if you want to be able to reconfigure on the fly without rebooting the whole system, you need something more versatile than a few runlevels. For instance, systems that power parts of the hardware down if not needed to save power would need something more granular than init 3 vs. init 5.
And if the system in case has several power save modes, does then the event manager power down services whose hardware was just put to sleep? And if so, how does init react of some services it has started, are shut down without init's involvement? Or should those services should be started from the event manager instead of init? And what's the point of init, if most services are started by the event manager anyway, because otherwise, the event manager could not manage them?
Just stuff that into the event handler and let it be responsible for it. That's the beauty of such a modular system, it's versatile. The new parts can come in early, late, or not at all depending on need. There can even be more than one so they can specialize in subsystems or special cases.
I am not in principle opposed to a replacement init so long as it plays well with others, but I would need a compelling reason to do it that couldn't be otherwise accomplished
It's not perfect, but judging by the fact its opponents insist on using "faults" that are misleading, minor, or irrelevant
This, a thousand times this. I gave up worrying about systemd when I noticed that most of the anti-systemd campaigners spanned the spectrum from exageration, via lying, to insanity.
Watch this Heartland Institute video
Bug report?
Watch this Heartland Institute video
Sorry? You can run Debian without systemd.
Just try running Devuan with it.
So much for "init system freedom".
Watch this Heartland Institute video
And if the system in case has several power save modes, does then the event manager power down services whose hardware was just put to sleep?
No. An event manager (or controller) should reconfigure the service via inittab and signal init to change that service's state because init is a *process* manager for system processes.
And if so, how does init react of some services it has started, are shut down without init's involvement?
It restarts them, as it should. init should be responsible for maintaining system services that require root permissions. An event manager is a good candidate because
Or should those services should be started from the event manager instead of init?
user level services that terminate at the end of their sessions should be managed by an application controller that interacts with the event controller.
And what's the point of init, if most services are started by the event manager anyway, because otherwise, the event manager could not manage them?
It should be managing events and not processes. It should be passing messages about them to various processes that perform the reaction. It should not even capture them, that functionality should be abstracted into an input or device controller that generates messages for the EM.
My ism, it's full of beliefs.
"The whole controversy could have been avoided if systemd was properly designed as a plug-in component. System starts up under the old init. At some point (after the basic system has been brought up), an rc script or inittab starts systemd (a series of event listeners) to deal with hot-plugging and such. Make sure it doesn't block others from listening."
Just like inetd has been doing since time began. Borrowing a few tricks from years past, there is absolutely no reason why inetd needs to be used *only* for starting inet servers. Inetd can be used to start and manage anything. Most folks just don't get that creative with their systems -- I sure don't! I saw that trick in an O'Reilly book yrs ago.
So, to make your point even stronger, the capability that you speak of has already been around for decades. But nobody actually seems to play with it.
C|N>K
- waiter, a capricciosa without mushrooms please.
- here it is, sir.
- thank you, can you bring me some extra mushrooms for the capricciosa?
- whatever, sir. *turns to the cook who makes the international "he has a loose screw" sign*
---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
That's a good point, and it's even event driven. I haven't done much with it in a long time but it demonstrates how to add event driven behavior and still play nicely.
Huh? Are you agreeing with me or trying to say that I'm not running my system the way I'm running it which is that EVERYTHING is logged to rsyslog in text including things that weren't possible before?
http://www.without-systemd.org... I count 64 distributions* without systemd. Install one of those. Oh you want to run without systemd on another distribution? Then why not become a senior maintainer and actually get your voice heard in discussions on where the distribution should head or better still fork it and run it the way you want.
*I'm on a bouncy train so make that 64 +/- 5 for difficulty in counting.
We are yet to see a use case presented that init cannot deal with and these two are already covered.
Then you're not looking. Especially not looking at the whole host of tools that exist to implement functionality that sysvinit doesn't allow.
Sysvinit wasn't replaced for shits and giggles, and systemd is far from the first package that tried to do more to handle all those use cases that sysvinit doesn't allow.
There were already programs that did exactly as you describe.
Systemd offered more functionality by taking control earlier in the boot process. e.g. logging before the syslog daemon is even up and running as PID1.
The only problem with systemd is that Debian moved to it and that hurt everyone's feelings. Debian was forked and now there's an alternative. People didn't migrate servers en-mass to BSD, the world kept spinning, and I am told the sun will rise tomorrow just like it did yesterday, despite what people said when Debian initially announced they are moving to systemd.
Linux is about choice. Not your choice, but the choice what the developers present to you. Pick a distro that suits your needs and you'll be just fine.
I have no strong feelings about systemd. I do have strong feelings about the raving lunatics that infest message boards and article comments about how systemd is cancer--likely pushing hundreds or thousands of people away from free software, to Microsoft instead. So I'm happy that Devuan and Slackware still offer sysvinit, if for nothing but the PR of saying "you can use Linux without systemd."
Many chose to stick where they were to give time to find an option. CentOS/RHEL 6 are still in support as is Wheezy. Many saw that while systemd can't be totally stripped from (Debian) Jessie, it can be stubbed out for a server or if you switch to XFCE. Of course, Slack and Gentoo are options.
So the tale won't be told at least until Wheezy and Centos 6 go EOL. The final chapter won't be written until Debian Jessie goes EOL.
Sorry, I misread your post for sarcasm, implying that systemd did not log to syslog.
"I know I will be modded down for this": where's the option '-1, Asking for it'?
hahaha. You can never tell the FUD from the sarcasm in a systemd debate. It's much easier having a discussion on religion on here :-)