Why is this downvoted? Knowing very little about the debate, just seeing this comment grayed out doesn't help inform me. If the comment is not helpful, I wish someone would reply with information to explain why that's so. Is Devuan a bad project for some reason? Is this spam? Or is someone just dismissive of the need for an alternative?
This whole init vs systemd has been a very divisive (and ongoing) debate, and both sides feel very strongly on their particular stance. Just look up the pages that come up for a "init vs systemd" search on the net.
From what I see on the devuan page, in the spirit of FOSS, the people that prefer to keep init as part of their setup, have forked debian into devuan, and propose to retain the "init based debian", for people that prefer init scripts.
That's the shortest summary I could come up with for you.
It looks like their domain/project name has changed, but this was discussed on Hacker News recently; the project got a fair bit of flak: https://news.ycombinator.com/item?id=8477659
Maybe the downvoter(s) were some of the same folks who raised their concerns in the above thread? Or maybe it's just the typical systemd holy war going on. I'd guess the former though.
Many people consider it an overreaction to fork Debian for its choice of some defaults. Instead of creating this website and community, they could help Debian support its non-defaults. It's the same work anyways.
I believe the problem here is that systemd can be introduced to a "non default" Debian system via package requirements, whereas they hope to prevent that in Devuan.
Which won't allow you to install certain core pieces of Debian software which have decided to rely on systemd.
If I understand Devuian correctly, they will port releases of core software off of systemd and back to init, giving you the option of still using core software packages without systemd.
> Devuan will derive its own installer and package repositories from Debian, modifying them where necessary, with the first goal of removing systemd
> Which won't allow you to install certain core pieces of Debian software which have decided to rely on systemd.
Debian is committed to support sysvinit for the next release at least. I really doubt anyone in Debian will add dependencies on systemd "just because": if they do so they may have compelling reasons (eg. ConsoleKit is unmaintained and broken) and the correct reaction would be to fix the issue (eg. like the ConsoleKit2 people are trying to do) rather than forking Debian just to ignore the issue.
Not that forking Debian is bad and people should not do it for whatever irrational reason if they want: it's just that in this case there's no rational reason the same task couldn't have been carried over in Debian itself other than the fact that in your own fork you may accept lower quality contributions more easily.
Never heard about it before, but I would warn greatly against any one actually using Devuan in a production setting. If, down the line, Devuan can consistently maintain the work of pulling security updates from debian fast enough, or have their own security team doing the work, then and only then would I ever dare to use a different distro. Exception would be live-cd's, which tend to live in their own universe.
I know this has been discussed all over the place to the point of exhaustion but I am still somewhat shocked that Debian adopted systemd so quickly. For a distribution that is known for it's stability and conservative approach to new software I just think this happened way too fast.
I've been a happy Debian user for many years but lately I've fallen back to using *BSD (particularly OpenBSD). I guess that puts me in the "old and afraid of change" camp but for me it's nice to be back using something that looks and, more importantly, _works_ like Unix.
Debian will remain my goto distribution when I want/need Linux but it's no longer my first choice...
I've recently replaced three lenny servers (two LAMPs and a name server) and rather than go with Wheezy I migrated the three of them to OpenBSD. On one I added apache from ports, the other I was able to use OpenBSD's new httpd and I found I really like OpenBSDs built in named.
Other than that I've been playing around with FreeBSD and have revisited Slackware which was the first Linux I was introduced to via a book/cdrom back in the mid 90's.
Having had some success with OpenBSD on servers I'm running it on a laptop as one of two workstations at work. The other has Wheezy on it. I'm able to do most of my day to day work on OpenBSD but do find myself remoting into the Linux box for some things (e.g. mysql-workbench).
> For a distribution that is known for it's stability and conservative approach to new software
I imagine many people might trust systemd more than the overlapping set of init/cron/at/supevisord/monit/forever/user generated SysV init shell scripts of varying quality.
Personal opinions from the user perspective aside, it's significantly easier to maintain from a distribution / package maintainer perspective, so it's unsurprising they'd want to switch.
The fact that it did many things easily and correctly that init/cron/monit only did after navigating a minefield of gotchas, reinventing the wheel, and employing obnoxious hacks to do things that ought to be simple (parallel init). Init scripts are easier to tweak, no doubt about it, but I'm equally sure that if I was actually throwing together a distro I would want a modern init system.
Also, remember that launchd on OSX has been around for a decade. People from the linux world who encountered it tended to think "hey, this is kinda nice, I wish we had something like it." Perhaps launchd itself had a predecessor somewhere, I dunno. But the point is that people had seen these systems in the wild, so when someone showed up who was serious about seeing the project through there were a bunch of maintainers whose reaction was "about damn time" rather than "what is this?"
I've found service files much easier to tweak then init scripts. When 90% of all init scripts become a single line exec command, there's not a lot to go wrong.
Just this periodic strange urge to adopt superior technology that fixes several broken things at once, instead of keep going with what you're familiar with and sorta-works for decades...
One major thing that we get from systemd is cgroup management, that gives resource and namespace management at a per process level. This has actually been in the kernel since 2008 but to use it you had to have some really bad ass programmers to give you an access interface to the features. It's now trivial to run a hosting server where each site has a set amount of cpu and ram without the virtualization overhead. Before that the option was openvz and before the option was virtualization.
There is a very loud minority in the linux community that doesn't want things to change. There are a ton of linux users who's lives this improves, and they are not as noisy.
Debian is the larges distro and when the maintainers took a vote systemd won with like a 60+% majority. Almost all other distros that are going to, have switched over the last 3 years.
1/ Maintaining init scripts is a significant part of the work to be done in a distribution, and systemd makes this task easier.
2/ Gnome started requiring systemd (via the dependency of GDM on logind). So, if they want to keep supporting Gnome, they have a choice between switching to systemd or developping some shims. And it's probably safe to assume other major pieces of software (KDE?) will adopt similar requirements.
I think Debian has taken a conservative approach. For example, Arch adopted systemd as its default years ago, which means it was already stable enough for daily use years ago (although I think Arch helped pave the way for its adoption by the larger distros). systemd is not really "new" software anymore; it's been around the block a few times. Even RHEL7 has adopted systemd.
I suppose one might say that this is a core component of the system and even three or so years of testing is not enough... But, I think at that point, we're off in the realm of opinion.
Fedora was using it as default for a year before Arch. Redhat definitely paved the way. Many were slow to adopt it because it was such a radical change and most of the changes were seen as boons only for the virtualization stack that Redhat was working with.
I love Arch too, but damn! I remember the "upgrade" process to systemd that wrecked my system (not unrecoverably, but before they released the fix path, I already reinstalled.)
Huh. I didn't know that about Fedora. I admit I don't keep up with the Red Hat world as much as I should. So, apparently systemd has been in production distros for, what, four or five years now?
I don't remember the systemd transition in Arch being too bad, though it was sort of rough around the edges. I guess that roughness is why (mentally) I hadn't expected anyone to have adopted systemd before Arch.
It wasn't even bad on Fedora, it was in rawhide for over a year being worked on before entering Fedora 15, albeit they transitioned from upstart to systemd, which I'd think is a lot less significant a transition than from sysv to systemd.
Also, systemd has really "grown" over the years. Adopting systemd when it was just about handing services was one thing. But now it does networking (firewall management included), job scheduling, and more.
It is almost as if you can see the frog slowly boiling...
It was devastatingly bad for desktop consistency to have networkmanager not be default on so many distros for so long. It made writing GUI network managers a tremendous PITA.
And nobody is even shipping a distro with networkd as the only network daemon. They are all still using networkmanager. I doubt anyone will switch any time soon either, since the faculties of networkd are a lot more limited.
And I'm wondering how a project that is meant to encompass a common base userspace OS is boiling anyone by adopting things like network management into it. That seems pretty base OS nowadays to me. I'll worry if once everyone is on systemd we start getting horror stories of the upstream systemd developers blocking contributions and fixes because they conflict with what they want in the project (a la Gnome, not like KDE).
1. I wonder how many "disable networkmanager" comments i have seen around the net in relation to fixing some networking issue. Seems to be up there with Pulseaudio...
2. It would really surprise me if networkmanager finds itself being anything more than a frontend for networkd within a year or two.
At this point in time i am starting to think that going back to pre-freedesktop Linux may be better for my ulcer than trying to keep up with the desktop (developers) uber alles threadmill.
What are you talking about? Debian had systemd on the discussion list for years and it was the default init system for other distros for just as long. What exactly about years of discussion doesn't align with the conservative choices of their other software defaults?
Here's an article where debian is talking about systemd in 2011 [0]. Forgive me for beign a bit shocked when people say things like 'it happened so fast!', but it's almost like people just sincerely want to hate systemd.
edit: I really wanted to ignore this, but it's eating away at me.
>and, more importantly, _works_ like Unix.
Maybe I'm just cynical, but I get the feeling people who pretend their interpretation of the unix philosophy regarding systemd is the superior interpretation, probably didn't even know what the tenets of unix philosophy were before the drama.
Maybe it's relative to systemd reach in the OS and the fact that it's not a no brainer (this topic as proof). How many deep changes Debian did before (I think there was a glibc/eglibc swap at one point) ?
So how many years of discussion have to happen before you would consider it thoroughly discussed? How many years of top distro's using it by default before you would consider it vetted?
From my interpretation of smhenderson's post, one of Debian values was a very slow pace of change and old but well known pieces. In this light, systemd still seems too controversial. Fedora adopted it because it was an in-house project, archlinux tries to use cutting edge as much as possible, so it's irrelevant for that interpretation.
I only read part of the Debian voting process, it's wasn't years but I admit not knowing how long systemd was discussed in Debian's ML before that. On archlinux board's, adoption was quickly reached (without too much user troubles).
Well in the typical Arch way it was a case of dictatorial "we are going systemd, deal with it".
Also one of the busybodies within systemd development is directly involved with Arch maintenance...
Btw, the big pedia claims that OpenSuse and Mageia(?) also use systemd. At least one of them is a fork of what used to be a RHEL fork with a more desktop orientation.
Then again, the adoption may well have happened before systemd started absorbing/reimplementing so many other functions.
Look, I come to hacker news to agree to disagree. If you like systemd than great but as far as I'm concerned it's still a moving target, does way more than replace the init system, uses binary where traditional Unix uses text and in general inserts itself into way too many things for me to be comfortable with it.
Smarter people than me have done a great job of debating both sides of the issue and it looks like systemd has won. That doesn't mean I have to like it and thankfully I can fall back to using OpenBSD since I want a Unix that looks and feels like the Unix I've been using my whole career.
I don't care if you disagree with me but please don't assume that I "don't even know the tenets of unix philosphy" becuase I happen to view systemd in a way that you apparently do not. If all the major distributions are going with systemd than OK, but the beauty of free software is that I have choices and I've made mine.
So quickly ? This non-issue has been pending for months now, mainly because of non-technical, ridiculous (ie. religious war with sysv) reasons, and we will at last go forward with it. Yes, it is far from being perfect (I personally never really liked systemd), but this is a huge step forward anyway. It's 2015 and we are still using crappy init shell scripts to start demons, and crappy text files to configure every piece of network. We need to move forward.
It's actually because of, I'm sorry to put it so bluntly, distribution maintainer incompetence in the form of not modularizing common script functions, bolting on hacks like start-stop-daemon, startpar and insserv to achieve primitive asynchronicity and service dependencies, and to an extent the failings of sysvinit itself with providing little tools to contain the environment and enforcing messy symlink farms.
What you're doing is the equivalent of looking at some old Mach performance statistics and concluding that microkernels cannot possibly work... never mind there's one alongside every smartphone.
Around 1998 or so. They always were an incompatible mess of differing configuration formats, "standards" and kludges, but it was ok for the first 2-3 decades of UNIX...
I have been looking at OpenBSD as well for an upcoming Debian related transition. I have nothing against systemd as such, this is pure selfishness. I an happy to let others do the debugging...
One of my favourite things about FreeBSD is that it acknowledges that updating will always have edge cases you don't think of. So there's a text file that you read as part of the update workflow, and when specific steps are necessary, you follow them. I've never had an upgrade go wrong with FreeBSD, which is more than I can say for any flavour of Linux.
For what it's worth, Gentoo has a similar system. Packages can show a message when they are installed (including updates) and for system-wide changes the package manager will tell you to to read 'eselect news'.
I loved Gentoo's package management system. I managed to break my system more with Gentoo than any other distro, but that wasn't the package manager's fault—mostly mine and/or package maintainers. I wish it'd gone as mainstream as dpkg and rpm—I prefer widely-used distros these days because I like being able to google any problem and find an answer (I'm well past the days where I found managing my OS to be anything resembling fun) but I miss Portage.
I miss OpenRC, for that matter. Using that is the only time I've felt something like contentment while managing init.
It's more that when you do need to get hands on, the code's pretty minimalist, the manuals are very good quality, there are fewer moving parts so less to go wrong, there's a good focus on code quality etc etc.
Couldn't agree more. OpenBSD is a great bsd for those that want to understand their system inside and out and feel confident that the code quality is there, but it's just not designed to be an ease of use, low barrier to entry, bsd.
It's more that when you do need to get hands on, the code's pretty minimalist, the manuals are very good quality, there are fewer moving parts so less to go wrong, there's a good focus on code quality etc etc.
Systemd has been in use for a little over 4 years. There may be some issues with distro specific implementations but that should be flushed out in the normal debian testing which had been going on with systemd for over a year?
>I know this has been discussed all over the place to the point of exhaustion but I am still somewhat shocked that Debian adopted systemd so quickly. For a distribution that is known for it's stability and conservative approach to new software I just think this happened way too fast.
Yeah, they should give it a few decades of thought...
And maybe check out if this ANSI C thing is worth supporting over plain ole K&R C.
Only neither is new. One is several decades old and broken, the second is newer but still almost a decade old, and we know it does work and what it fixes...
This is the great part, because the will probably have API compatibility for a lot of the little parts.(like logind) That means we will not have a mono culture going forward.
Where did you get that idea? The BSD people (just FreeBSD, mostly iXsystems employees) are simply working on a port of OS X's launchd, which has no similar session/seat management component as logind, from what I know.
It is a herculean task to replace such a core piece of the Linux system architecture and it is amazing that this has been generally a success.
This will lead to a lot more efficient and maintainability of the Linux OS for a long time to come once we get past the near term hurdles of reduced stability and various regressions (and obvious design issues to be resolved) that come from such a huge change.
> This will lead to a lot more efficient and maintainability of the Linux OS
How does consolidating functionality and control into one piece of software increase efficiency and maintainability? In my past experience, monolithic software efforts can be more efficient in the beginning, but they quickly become a maintenance nightmare as fewer and fewer people understand all of the moving parts.
You don't have to look far to see the effects of this: the Linux kernel is filled with small "I'm not sure we can remove this but I don't think it does anything" comments. You can also see it in the SaaS market as they move towards microservices, away from the monoliths of yesterday. You can see it in the giant corporate structures who take 6 months to requisition a smartphone for testing which will be obsolete in another 6 months.
The init system has the flaw of being too distributed to offer intelligent coordination between processes, but I'm not sure that following the pendulum swing to the complete opposite end of the spectrum was the best choice either.
Systemd is not a big blob, it is actually fairly well structured in its source repository. Each part has its own disable flags on compilation and makes independent binaries. You should think of systemd less as a "program" and more as a software compilation for the core system.
Yes, there is a chance that components of systemd could suffer bitrot, but I'd argue its less likely that a project under the tutelage of Red Hat in the interests of its enterprise crowd will see the rot that other projects like xinetd have in recent years, where major contributors just stop, the whole project grinds to a halt, but because its not part of some broader software project nobody notices to pick up the slack (note, my example has gone through periods of rot and revival when someone notices its become a problem). If one component starts rotting the bugs will pile up on the systemd bug trackers and the broader project will notice and respond more efficiently since everything in systemd uses the same semantics and code formatting and the developers will be more comfortable changing their working directory than their repository.
Each part has its own disable flags on compilation and makes independent binaries.
Except for generators, certain auxiliaries like rfkill, journald, udevd and others. It's rather inconsistent, as is the specific libraries that can be disabled.
> Each part has its own disable flags on compilation and makes independent binaries.
I'm not speaking of the entire systemd daemon ecosystem (which already displays coupling between logind and journald), just the systemd-as-init daemon.
> I'd argue its less likely that a project under the tutelage of Red Hat
I'd argue in return that if the Lennart Poettering bus factor suddenly went critical, systemd development would indeed hit a significant roadblock. Perhaps not insurmountable, but how many people understand the entirety of the systemd ecosystem? How many resources would RedHat be capable of devoting to this one project?
> the bugs will pile up on the systemd bug trackers
The RHEL bug tracker is currently at 250 open bugs, with 40-50 of them in the "NEW" category, with some of those dating back to 2013. The oldest open bugs date back to 2011. In my opinion, this shows a lack of bug triage, one of first outward signs of "bug pileup".
What's monolithic about systemd? Sure it includes a lot of stuff, but so does Gnu coreutils and the BSD ports tree. It's not a single binary like docker.
I can use a GNU cat with a busybox grep if i want to. Can i use logind with anything other than systemd-as-pid1? (btw, they really need to rename that damn init binary. But then i wonder if it is done willfully).
Systemd includes no only comprehensive process management, but also socket management (to the level of listening on a socket and starting a service), device mounting, process isolation... and this is just the init daemon, not counting the remaining daemon projects which come with systemd.
> How does consolidating functionality and control into one piece of software increase efficiency and maintainability?
Because people working on components that interact with each other are working in the same project now. They see each others commits. They see each others question on the mailing list. etc.
Let me ask the reverse question: How would this be improved by splitting systemd into independent projects?
It won't. It will lead to more unstable systems that are used in production and that, in turn, would lead to more instability.
sysvinit bootstraps and shuts down the system. That's its job. It does it very well. It is irrelevant that it is slow. Absolutely no one should be rebooting systems 100 times a day.
I have to say I am surprised. From where I sit migrating to systemd doesn't look like the best solution. But, said that, I'm gonna get some popcorn and watch another holy war starting.
Some people claim SystemD is not in line with unix philosophy. Some think it is bug ridden. Some just feel its adoption was strong armed by political heavy weights. Some feel other solutions might be better. And others believe there was never a problem with the current solution to begin with.
(I don't agree btw, just giving some info on opinions that others have)
> Some people claim SystemD is not in line with unix philosophy
One example of this interpretation - we can no longer reliably use `netstat -nlp` to determine what process is responding to requests a particular socket. In certain configurations, `netstat -nlp` will show systemd owning the socket, not the process who receives and responds to the process.
e.g. Systemd will own port 80, and feed it back to Apache who listens over 8080.
To determine who will truly respond, you need to know the proper systemctl incantation, or find the configuration file (there are 8 locations across 3 folder hierarchies where these can live[0]).
>you need to know the proper systemctl incantation
Isn't this true for all commandline programs? It's a different way to do things in many ways, but this argument doesn't really talk about the merits or pitfalls, only the fact that it's different.
Well, it's both different and inconsistent. I still have to use netstat for processes who manage their own sockets, but I can't rely on the output for all processes anymore.
Also, netstat has existed and worked for more years than I've been a sysadmin. I'm not opposed to learning new things, but this magnitude of change and inconsistency is hard to keep up with.
But `netstat` was already broken for xinetd-started services. I get that it probably didn't affect you, but it means that `netstat` already had its shortcomings.
Now that socket-activated services may see more widespread usage, hopefully someone interested will add to `netstat` the ability to tell who is listening on the socket and not only who opened it (all the data is available in /proc, which netstat is using already).
And in the meantime there's always `systemctl list-sockets`.
Well, it depends. In some cases, it's opening the file descriptor for a port then giving it to the daemon after the daemon has finished starting up. The service ends up maintaining the socket, but Systemd opened it.
In other cases, Systemd acts as an advanced xinitd and start services on demand, which means that Systemd listens and starts a service, but the service does the accept and responds.
So... it's hard to say without digging into the systemd configs.
Within individual process trees, yes. Across all process trees via the init system, not so much.
I agree that it is a very useful thing to do and has been technically possible forever (since spawned processes need to have their inherited file handles over 2 intentionally closed), but it adds a bit of uncertainty and unnecessary coupling when it starts crossing the (admittedly arbitrary) process role boundary.
The benefit of faster startup time is negligible for the typical non-desktop.
> You also get socket activation, for free.
Socket activation has been available for many (10+) years via xinitd, but it is infrequently used for a variety of reasons. For one, it's slow. The time required to spin up a new process to handle the requested information is non-0, particularly in cases where socket activation is most likely to be used (shell scripts, Python/Ruby/Node applications). This is OK for services used only occasionally, but for any frequently used service it is usually unacceptable.
Plus, the overhead of keeping an occasionally-used service running in memory and listening to its own socket is typically pretty low, yet it provides the benefit of knowing exactly what is responding to a given socket.
> e.g. Systemd will own port 80, and feed it back to Apache who listens over 8080.
No, Apache actually listens to port 80, just on a socket created by systemd. systemd opens the TCP listening socket, spawns Apache (potentially on demand when connected to), and passes along the file descriptor for the socket. Apache then treats that file descriptor as though it had opened it itself. Similar to inetd, except that it isn't limited to stdio.
That said, since netstat -p shows who opened the socket rather than who is using the socket, socket activation does make it less useful. Given that netstat -p already reads all the necessary information from /proc, it'd be nice to teach netstat to show multiple programs listening on a socket, not just the opener.
A lot of people don't like systemd for various reasons, ranging from personal to political to technical. The Debian Technical Committee voted that systemd sysVinit needs to be replaced, and that systemd is the best option. Since then, there have been a number of attempts from within Debian to overturn this decision, or at least force Debian to officially support multiple init systems, with the most recent ending with a result of basically "no further discussion is needed."
Number one pet peeve - I can't disable mic auto-volume.
Number two - if you don't run Gnome, you're screwed having to resort to very complex, not-self-documenting command line tools to do the simplest of stuff. How do I change the volume of the box from the command line ?
Number 3 - everytime I plug my laptop's DisplayPort into a TV (used for presentations here), PA routes the audio automatically over the TV. But when I plug it out, the sounds happly continues into the depths of /dev/null, and I have yet to find a way to re-route it to my headphones without killing the PA daemon.
And I can continue. PA works ok only if you if you run Gnome, and you never plug in/out audio devices. It's a horrible software piece, but I'm stuck with it because it's not my priority to write audio daemon replacements.
> Number two - if you don't run Gnome, you're screwed having to resort to very complex, not-self-documenting command line tools to do the simplest of stuff. How do I change the volume of the box from the command line ?
You can use pavucontrol without Gnome. Don't know what command-line tools, if any, are available for Pulse Audio.
I still can't have multiple login sessions properly sharing audio, and for some reason sometimes different sessions start using the wrong audio output.
If you have a system with more than stereo (say 5.1) then by default pulseaudio upmixes all sources with fewer channels by simply duplicating all the channels on the same side and mixing everything to the centre channel. This makes it impossible to listen to music recorded with any meaningful stereo separation. The workaround is to mute all the extra channels.
There is an option to disable upmixing entirely but that triggers at least a couple of bugs. One involves the VU meter indications (shrug). The other causes pulseaudio to emit silence instead of mono streams (fatal).
This bug has been open for over a decade now. At least one patch has been submitted and shrugged off. If you look at the tracker you will see lots of bugs like these where knowledge of the entire system is required to fix them. What seems to have happened is that once the original developers left, some bugs became eternal.
I think Jessie already uses Systemd on new installations. This is just upgrade path, which makes sense, since other init systems are unsupported (nobody is doing the work).
I thought this was already the case? My systems that run jessie seem to have made the switch some time ago.
I'm not a fan, it has caused a variety of problems (which may be teething trouble or not), I'm not a fan of its logging and I don't like that when I make changes to 'legacy' stuff in /etc/init.d systemd tells me I need to issue more commands to get it to re-read the startup scripts rather than just use them... feh.
I'm pretty much abandoning linux due to systemd and the fact that a tiny group of people have basically forced it on everyone despite few people wanting it and huge objections.
This might not be the end of linux but it's really really harming it.
Same here. With everything going on with government spying it is totally realistic to expect Systemd is being forced upon Linux to open up new entry points into the OS. This would have been a crazy conspiracy theory five years ago but it's the new reality.
I'm not abandoning it because of systemd specifically but the whole Linux boot/init stuff is hell and the platform is death by a thousand papercuts when something goes snap. That's reason enough on its own. I recently had to rescue a CentOS 7 box with failed mdadm RAID1. Between grub, md, initrd, LVM and systemd it was three hours of hell. This was due to an md failure causing corruption on a mirror disk rather than a physical disk failure as well.
Windows and FreeBSD with ZFS are beautiful in comparison. I've come to recommend those over Linux these days.
We've heard this argument time and time again, but the fact of the matter, is that there's a good chunk of people that really need these features. We may see a changing of the guard but I doubt the majority of installs are going anywhere.
This hurts though I know it's coming. Debian failed me after so many years' trusts. Sadly the other options are quite limited, which is the worst part. *BSDs are not really on par for what I want(Desktop, Server and Embedded), Windows is a totally different ecosystem, what should I do?
The resolution does mention there will be documentation on switching to sysv after an installation, so I assume this option will have to be officially supported; it sounds to me as though systemd is simply a default, not a requirement.
Yes, it will be officially supported as systemd is simply a default, not a requirement, as defined by previous CTTE deliberations and as implemented even before them by the Debian systemd team, which has gone to great extents to make sure you can happily switch back and forth with almost no issues.
Jordan Hubbard already said that FreeBSD needs an systemd equivalent. OS X was the first one to get one, Windows traditionally has a general design that resembles systemd much more than any other init system. I think you are running from reality.
Lennart has produced some "friction" in the past but now that he's been for such a long time on the other side, getting blamed and accused of every silly thing in the world I hope it has changed his ways a bit.
Truth to be told, the systemd community has been reported as one of the most welcoming and productive environment in the FLOSS ecosystem.
I hear that from you and others, and then I read debacles like the Sievers/Torvalds thing on the mailing list (and some other instances of buffoonery linked to there), and immediately conclude that the "welcoming"-ness must only apply as long as you are following the current groupthink and not disagreeing with the BFDLs.
Heck, even that wouldn't be a thing if the people involved had the ability to publicly say "I was wrong on that" - but not even that happens that I've seen.
Tbh I think in the Linus case the one using a less-than-welcoming tone wasn't Sievers. :)
Of course they have a strong vision, and popping up proposing something that has already been discussed to death and rejected won't be the most pleasing experience ever (it happens all the time here, I don't even want to imagine how tiresome it should feel for them).
OpenBSD for embedded? I used NetBSD in the past for that but is OpenBSD really for embedded? Interesting thought though.
On the other hand, the issues are also in the soft-realtime-ness, the hardware drivers, the embedded community,etc.
Indeed for Desktop or Server, *BSD might do it just fine, though many OSS development env these days are tested by default on Ubuntu/Debian etc instead of BSDs.
You really don't want anything like Windows services. The nice thing about Unix "services" is that they are just regular processes that happen to be started at boot (and know enough to daemonize themselves, typically). Windows services are a whole separate thing with special APIs and are kept track of in the binary registry. To manage them you have to use the arcane (and very old) sc.exe program, or some new-ish Powershell cmdlets. It's not possible to deterministically "delete" a service--it will just be marked for deletion, and the only way to be sure it's done is to reboot.
My nightmare is that systemd evolves towards a system like this--opaque, baroque and difficult to debug.
Sadly at this point in time the sysv vs systemd debate is a distraction, as systemd has grown to encompass so much more than sysv ever did. Damn it, it can be a full blown docker replacement now.
Personally, I'm excited for the change. Waiting any longer to adopt systemd could have had serious repercussions on the entire community (across distros). Big players are already using it; RHEL7 and CoreOS. It's time for a paradigm shift with our approach on managing infrastructure.
Both the sysvinit and systemd crowds have brought up great points - issues that needed to be addressed. The strong willed nature of the *nix communities is what makes them great. Strength in numbers. "Fighting" is a natural process; whether it's a team or a family.
Incredibly excited to see what kind of impact this has on computing as a whole. Time to learn something new.
This announcement isn't as significant as it seems. As mentioned in the mail, Debian has already transitioned to using systemd by default for the upcoming jessie release, for both new installs and upgrades, with a carefully orchestrated transition coordinated between the sysvinit, upstart, and systemd maintainers. (That transition includes the ability for sysvinit and systemd to co-exist on the same system, choosing which one to boot at boot time with init= or a GRUB menu option, rather than having the packages conflict at installation time.)
This announcement only occurred because, after that transition, someone formerly on the technical committee (now resigned, but a member at the time) attempted to use the technical committee to force a revert of that transition. This announcement is effectively the current technical committee saying "nope, the other teams in Debian have done a fine job arranging this transition, and we're not going to overrule anyone".
(I helped draft this proposal, and spent a fair bit of time trying to make sure it would not be taken as changing the current state of affairs in any way, only affirming the work others had already done.)
146 comments
[ 3.1 ms ] story [ 161 ms ] thread[1] https://devuan.org/
From what I see on the devuan page, in the spirit of FOSS, the people that prefer to keep init as part of their setup, have forked debian into devuan, and propose to retain the "init based debian", for people that prefer init scripts.
That's the shortest summary I could come up with for you.
Another short writeup by @tinco https://news.ycombinator.com/item?id=9094142
Maybe the downvoter(s) were some of the same folks who raised their concerns in the above thread? Or maybe it's just the typical systemd holy war going on. I'd guess the former though.
If I understand Devuian correctly, they will port releases of core software off of systemd and back to init, giving you the option of still using core software packages without systemd.
> Devuan will derive its own installer and package repositories from Debian, modifying them where necessary, with the first goal of removing systemd
Debian is committed to support sysvinit for the next release at least. I really doubt anyone in Debian will add dependencies on systemd "just because": if they do so they may have compelling reasons (eg. ConsoleKit is unmaintained and broken) and the correct reaction would be to fix the issue (eg. like the ConsoleKit2 people are trying to do) rather than forking Debian just to ignore the issue.
Not that forking Debian is bad and people should not do it for whatever irrational reason if they want: it's just that in this case there's no rational reason the same task couldn't have been carried over in Debian itself other than the fact that in your own fork you may accept lower quality contributions more easily.
http://lists.devuan.org/dwn/1424284246.7620_1.fork:2,S.html
https://git.devuan.org/devuan-infrastructure/dak (last commit 8 hours ago as I type this).
https://git.devuan.org/packages-base/dbus
I've been a happy Debian user for many years but lately I've fallen back to using *BSD (particularly OpenBSD). I guess that puts me in the "old and afraid of change" camp but for me it's nice to be back using something that looks and, more importantly, _works_ like Unix.
Debian will remain my goto distribution when I want/need Linux but it's no longer my first choice...
> but it's no longer my first choice
What is out of interest?
Other than that I've been playing around with FreeBSD and have revisited Slackware which was the first Linux I was introduced to via a book/cdrom back in the mid 90's.
Having had some success with OpenBSD on servers I'm running it on a laptop as one of two workstations at work. The other has Wheezy on it. I'm able to do most of my day to day work on OpenBSD but do find myself remoting into the Linux box for some things (e.g. mysql-workbench).
I imagine many people might trust systemd more than the overlapping set of init/cron/at/supevisord/monit/forever/user generated SysV init shell scripts of varying quality.
Who/what is driving this despite all the controverse?
Code contributions, even if controversial, pack a much stronger punch than emails, forum posts, blog posts, etc.
Also, remember that launchd on OSX has been around for a decade. People from the linux world who encountered it tended to think "hey, this is kinda nice, I wish we had something like it." Perhaps launchd itself had a predecessor somewhere, I dunno. But the point is that people had seen these systems in the wild, so when someone showed up who was serious about seeing the project through there were a bunch of maintainers whose reaction was "about damn time" rather than "what is this?"
There is a very loud minority in the linux community that doesn't want things to change. There are a ton of linux users who's lives this improves, and they are not as noisy.
Debian is the larges distro and when the maintainers took a vote systemd won with like a 60+% majority. Almost all other distros that are going to, have switched over the last 3 years.
2/ Gnome started requiring systemd (via the dependency of GDM on logind). So, if they want to keep supporting Gnome, they have a choice between switching to systemd or developping some shims. And it's probably safe to assume other major pieces of software (KDE?) will adopt similar requirements.
I suppose one might say that this is a core component of the system and even three or so years of testing is not enough... But, I think at that point, we're off in the realm of opinion.
I love Arch too, but damn! I remember the "upgrade" process to systemd that wrecked my system (not unrecoverably, but before they released the fix path, I already reinstalled.)
I don't remember the systemd transition in Arch being too bad, though it was sort of rough around the edges. I guess that roughness is why (mentally) I hadn't expected anyone to have adopted systemd before Arch.
It is almost as if you can see the frog slowly boiling...
And nobody is even shipping a distro with networkd as the only network daemon. They are all still using networkmanager. I doubt anyone will switch any time soon either, since the faculties of networkd are a lot more limited.
And I'm wondering how a project that is meant to encompass a common base userspace OS is boiling anyone by adopting things like network management into it. That seems pretty base OS nowadays to me. I'll worry if once everyone is on systemd we start getting horror stories of the upstream systemd developers blocking contributions and fixes because they conflict with what they want in the project (a la Gnome, not like KDE).
2. It would really surprise me if networkmanager finds itself being anything more than a frontend for networkd within a year or two.
At this point in time i am starting to think that going back to pre-freedesktop Linux may be better for my ulcer than trying to keep up with the desktop (developers) uber alles threadmill.
Here's an article where debian is talking about systemd in 2011 [0]. Forgive me for beign a bit shocked when people say things like 'it happened so fast!', but it's almost like people just sincerely want to hate systemd.
[0]http://lwn.net/Articles/452865/
edit: I really wanted to ignore this, but it's eating away at me.
>and, more importantly, _works_ like Unix.
Maybe I'm just cynical, but I get the feeling people who pretend their interpretation of the unix philosophy regarding systemd is the superior interpretation, probably didn't even know what the tenets of unix philosophy were before the drama.
I only read part of the Debian voting process, it's wasn't years but I admit not knowing how long systemd was discussed in Debian's ML before that. On archlinux board's, adoption was quickly reached (without too much user troubles).
Also one of the busybodies within systemd development is directly involved with Arch maintenance...
Btw, the big pedia claims that OpenSuse and Mageia(?) also use systemd. At least one of them is a fork of what used to be a RHEL fork with a more desktop orientation.
Then again, the adoption may well have happened before systemd started absorbing/reimplementing so many other functions.
Smarter people than me have done a great job of debating both sides of the issue and it looks like systemd has won. That doesn't mean I have to like it and thankfully I can fall back to using OpenBSD since I want a Unix that looks and feels like the Unix I've been using my whole career.
I don't care if you disagree with me but please don't assume that I "don't even know the tenets of unix philosphy" becuase I happen to view systemd in a way that you apparently do not. If all the major distributions are going with systemd than OK, but the beauty of free software is that I have choices and I've made mine.
But the worst part is probably init scripts.
$ wc -l /etc/init.d/smartd 653 /etc/init.d/smartd
653 lines of code to start a demon, because of the differences between all distros.
Guys, seriously ?
What you're doing is the equivalent of looking at some old Mach performance statistics and concluding that microkernels cannot possibly work... never mind there's one alongside every smartphone.
I miss OpenRC, for that matter. Using that is the only time I've felt something like contentment while managing init.
Yeah, they should give it a few decades of thought...
And maybe check out if this ANSI C thing is worth supporting over plain ole K&R C.
This will lead to a lot more efficient and maintainability of the Linux OS for a long time to come once we get past the near term hurdles of reduced stability and various regressions (and obvious design issues to be resolved) that come from such a huge change.
I'll be honest, I didn't think this was possible.
How does consolidating functionality and control into one piece of software increase efficiency and maintainability? In my past experience, monolithic software efforts can be more efficient in the beginning, but they quickly become a maintenance nightmare as fewer and fewer people understand all of the moving parts.
You don't have to look far to see the effects of this: the Linux kernel is filled with small "I'm not sure we can remove this but I don't think it does anything" comments. You can also see it in the SaaS market as they move towards microservices, away from the monoliths of yesterday. You can see it in the giant corporate structures who take 6 months to requisition a smartphone for testing which will be obsolete in another 6 months.
The init system has the flaw of being too distributed to offer intelligent coordination between processes, but I'm not sure that following the pendulum swing to the complete opposite end of the spectrum was the best choice either.
Yes, there is a chance that components of systemd could suffer bitrot, but I'd argue its less likely that a project under the tutelage of Red Hat in the interests of its enterprise crowd will see the rot that other projects like xinetd have in recent years, where major contributors just stop, the whole project grinds to a halt, but because its not part of some broader software project nobody notices to pick up the slack (note, my example has gone through periods of rot and revival when someone notices its become a problem). If one component starts rotting the bugs will pile up on the systemd bug trackers and the broader project will notice and respond more efficiently since everything in systemd uses the same semantics and code formatting and the developers will be more comfortable changing their working directory than their repository.
Except for generators, certain auxiliaries like rfkill, journald, udevd and others. It's rather inconsistent, as is the specific libraries that can be disabled.
I'm not speaking of the entire systemd daemon ecosystem (which already displays coupling between logind and journald), just the systemd-as-init daemon.
> I'd argue its less likely that a project under the tutelage of Red Hat
I'd argue in return that if the Lennart Poettering bus factor suddenly went critical, systemd development would indeed hit a significant roadblock. Perhaps not insurmountable, but how many people understand the entirety of the systemd ecosystem? How many resources would RedHat be capable of devoting to this one project?
> the bugs will pile up on the systemd bug trackers
The RHEL bug tracker is currently at 250 open bugs, with 40-50 of them in the "NEW" category, with some of those dating back to 2013. The oldest open bugs date back to 2011. In my opinion, this shows a lack of bug triage, one of first outward signs of "bug pileup".
This seems to be the initial design document for logind: https://docs.google.com/document/d/1_ev4f0gwBuvs6SH_N8fN5LO4...
But then seat tracking on any platform where IO devices can come and go while in operation seems like a gnarly issue to say the least.
Because people working on components that interact with each other are working in the same project now. They see each others commits. They see each others question on the mailing list. etc.
Let me ask the reverse question: How would this be improved by splitting systemd into independent projects?
sysvinit bootstraps and shuts down the system. That's its job. It does it very well. It is irrelevant that it is slow. Absolutely no one should be rebooting systems 100 times a day.
Can anyone give a (brief) explanation as to the background of the controversy?
(I don't agree btw, just giving some info on opinions that others have)
One example of this interpretation - we can no longer reliably use `netstat -nlp` to determine what process is responding to requests a particular socket. In certain configurations, `netstat -nlp` will show systemd owning the socket, not the process who receives and responds to the process.
e.g. Systemd will own port 80, and feed it back to Apache who listens over 8080.
To determine who will truly respond, you need to know the proper systemctl incantation, or find the configuration file (there are 8 locations across 3 folder hierarchies where these can live[0]).
[0] http://man7.org/linux/man-pages/man5/systemd-user.conf.5.htm...
Isn't this true for all commandline programs? It's a different way to do things in many ways, but this argument doesn't really talk about the merits or pitfalls, only the fact that it's different.
Also, netstat has existed and worked for more years than I've been a sysadmin. I'm not opposed to learning new things, but this magnitude of change and inconsistency is hard to keep up with.
Now that socket-activated services may see more widespread usage, hopefully someone interested will add to `netstat` the ability to tell who is listening on the socket and not only who opened it (all the data is available in /proc, which netstat is using already).
And in the meantime there's always `systemctl list-sockets`.
Either way, netstat -nlp isn't lying about who owns the port 80 socket. It's a terrible idea, but the data returned is not incorrect.
In other cases, Systemd acts as an advanced xinitd and start services on demand, which means that Systemd listens and starts a service, but the service does the accept and responds.
So... it's hard to say without digging into the systemd configs.
Nope, systemd only opens the socket and passes the fd to Apache.
> Or is it launching Apache on demand like some sort of advanced inetd?
Yes. Since it's already init's job to start services, it does not make any sense to have a different system to start socket-activated services.
You also get socket activation, for free.
Within individual process trees, yes. Across all process trees via the init system, not so much.
I agree that it is a very useful thing to do and has been technically possible forever (since spawned processes need to have their inherited file handles over 2 intentionally closed), but it adds a bit of uncertainty and unnecessary coupling when it starts crossing the (admittedly arbitrary) process role boundary.
The benefit of faster startup time is negligible for the typical non-desktop.
> You also get socket activation, for free.
Socket activation has been available for many (10+) years via xinitd, but it is infrequently used for a variety of reasons. For one, it's slow. The time required to spin up a new process to handle the requested information is non-0, particularly in cases where socket activation is most likely to be used (shell scripts, Python/Ruby/Node applications). This is OK for services used only occasionally, but for any frequently used service it is usually unacceptable.
Plus, the overhead of keeping an occasionally-used service running in memory and listening to its own socket is typically pretty low, yet it provides the benefit of knowing exactly what is responding to a given socket.
https://dougvitale.wordpress.com/2011/12/21/deprecated-linux...
At least for smaller tasks like toggling a interface up or down.
No, Apache actually listens to port 80, just on a socket created by systemd. systemd opens the TCP listening socket, spawns Apache (potentially on demand when connected to), and passes along the file descriptor for the socket. Apache then treats that file descriptor as though it had opened it itself. Similar to inetd, except that it isn't limited to stdio.
That said, since netstat -p shows who opened the socket rather than who is using the socket, socket activation does make it less useful. Given that netstat -p already reads all the necessary information from /proc, it'd be nice to teach netstat to show multiple programs listening on a socket, not just the opener.
I have not read this carefully enough to fully endorse everything it says, but the main point should be (lack of) modularity.
http://www.landley.net/notes-2014.html#23-04-2014
Remember the stability, flexibility and reliability that PulseAudio brought to Linux audio? Imagine that in your boot process.
I wonder if Lennart Poettering is secretly funded by a consortium of Microsoft, Apple and IBM.
Number one pet peeve - I can't disable mic auto-volume.
Number two - if you don't run Gnome, you're screwed having to resort to very complex, not-self-documenting command line tools to do the simplest of stuff. How do I change the volume of the box from the command line ?
Number 3 - everytime I plug my laptop's DisplayPort into a TV (used for presentations here), PA routes the audio automatically over the TV. But when I plug it out, the sounds happly continues into the depths of /dev/null, and I have yet to find a way to re-route it to my headphones without killing the PA daemon.
And I can continue. PA works ok only if you if you run Gnome, and you never plug in/out audio devices. It's a horrible software piece, but I'm stuck with it because it's not my priority to write audio daemon replacements.
You can use pavucontrol without Gnome. Don't know what command-line tools, if any, are available for Pulse Audio.
There is an option to disable upmixing entirely but that triggers at least a couple of bugs. One involves the VU meter indications (shrug). The other causes pulseaudio to emit silence instead of mono streams (fatal).
This bug has been open for over a decade now. At least one patch has been submitted and shrugged off. If you look at the tracker you will see lots of bugs like these where knowledge of the entire system is required to fix them. What seems to have happened is that once the original developers left, some bugs became eternal.
I'm not a fan, it has caused a variety of problems (which may be teething trouble or not), I'm not a fan of its logging and I don't like that when I make changes to 'legacy' stuff in /etc/init.d systemd tells me I need to issue more commands to get it to re-read the startup scripts rather than just use them... feh.
This might not be the end of linux but it's really really harming it.
Windows and FreeBSD with ZFS are beautiful in comparison. I've come to recommend those over Linux these days.
Jordan Hubbard already said that FreeBSD needs an systemd equivalent. OS X was the first one to get one, Windows traditionally has a general design that resembles systemd much more than any other init system. I think you are running from reality.
Give me the coolness of systemd maintained by someone that isn't impossible to work with, and i'd be all for it.
Truth to be told, the systemd community has been reported as one of the most welcoming and productive environment in the FLOSS ecosystem.
Heck, even that wouldn't be a thing if the people involved had the ability to publicly say "I was wrong on that" - but not even that happens that I've seen.
Of course they have a strong vision, and popping up proposing something that has already been discussed to death and rejected won't be the most pleasing experience ever (it happens all the time here, I don't even want to imagine how tiresome it should feel for them).
There are thankfully a few non-systemd linucies around - Gentoo, or others have mentioned Slackware.
On the other hand, the issues are also in the soft-realtime-ness, the hardware drivers, the embedded community,etc.
Indeed for Desktop or Server, *BSD might do it just fine, though many OSS development env these days are tested by default on Ubuntu/Debian etc instead of BSDs.
My nightmare is that systemd evolves towards a system like this--opaque, baroque and difficult to debug.
I clearly have tons left to learn as a Sysadmin
Both the sysvinit and systemd crowds have brought up great points - issues that needed to be addressed. The strong willed nature of the *nix communities is what makes them great. Strength in numbers. "Fighting" is a natural process; whether it's a team or a family.
Incredibly excited to see what kind of impact this has on computing as a whole. Time to learn something new.
It's the position of the verb that makes war. ^^
This announcement only occurred because, after that transition, someone formerly on the technical committee (now resigned, but a member at the time) attempted to use the technical committee to force a revert of that transition. This announcement is effectively the current technical committee saying "nope, the other teams in Debian have done a fine job arranging this transition, and we're not going to overrule anyone".
(I helped draft this proposal, and spent a fair bit of time trying to make sure it would not be taken as changing the current state of affairs in any way, only affirming the work others had already done.)