Hacker News Reader

Comment by tener | Hacker News Reader

If systemd is so horrible why is everyone switching to it? EDIT: This is an honest question. I read quite a few negative comments on it and yet people in charge seem to be convinced this is the way forward. I'm curious why.

View on HN

Because systemd makes certain desktop related tasks easier to present to the user. It's a huge loss imnsho because linux on the desktop wasn't held back by a lack of such niceties but by market conditions, at the same time linux on the server will be held back by systemd because of its tendency to do things 'its' way.

I haven't seen any single subsystem harm the linux eco-system as much as systemd has and while I understand the desktop vendors clout in this the server is where linux shines and that was territory that was hard won.

If all systemd had done was offer an alternative init system then that would have been a non-event, to take over the entirety of the linux system side tried-and-true and battle tested utilities is irresponsible at best and dangerous at worst. It wasn't broken, so it did not need fixing / rewriting.

You didn't provided any real argument besides the obvious one - change. I use systemd on my Debian servers and i just don't see it as something bad. I have created systemd services that i use and it's really convenient.

Yes, it is much more convenient, and as an init system there isn't much wrong with it. But in software change for change's sake alone is simply wrong, it creates friction because a lot of knowledge has to be discarded and then has to be replaced by different knowledge. Large amounts of regression testing suddenly become useless which will generate ample opportunity for re-hashes of old bugs and issues (see linked article).

Modular designs are good, monolithic designs are bad. Dependencies are bad and so on. Lots of choices at the design level were made against fairly hard won knowledge on how to architect complex software systems. All these dependencies translate into 'all or nothing' and that is never a good thing in the software world. It's just another form of lock-in, something that the world of closed source software is good at and I'm quite sad to see it pollute the world of open source.

Edit: I suspect a lot of the pushback against systemd - mertited or not - is because a lot of people in charge of little parts of the bazaar have seen their pet projects cast aside by the major distros and taken over by the systemd devs. In a world where street cred is a big force in motivating people to contribute to open source being maintainer of 'x' where 'x' is part of each and every linux distro out there and then to see 'x' taken over by systemd in a fairly rough manner without any kind of co-operation between the old maintainers and the new kids on the block there are bound to be a lot of ruffled feathers. But that's not technology, that's just ego.

systemd fixes a lot of problems for a lot of people, and it wasn't "change for change's sake" - SysV-style init was a mess, and a sad leftover from a time when disks were mechanical, and many other things that amount as anachronisms in 2016.

If we never replace things with better things, we'd be using superpowered DOS machines to this day. I don't get the "knowledge has to be discarded and then has to be replaced by different knowledge" argument if the new knowledge is of a better tool.

I'm not all in with systemd's ethos, but I don't see a significantly better tool around.

Your comment sounds like preaching.

> when disks were mechanical

DISKS are STILL mechanical. They will always be. That is why it's called a disk. You thinking is limited to fancy laptops and not considering enterprise servers.

> If we never replace things with better things

Better? That is far too strong. Things are not always better but making certain use cases easier. That does not mean it's better. Systemd has nice features, indeed; but it's also limiting in terms of losing the capabilities of full blown shell script. Sometimes this latter is very handy.

Edit: Downvote? Nice. Try commenting instead.

No downvote from me but spinning disks are on the way out, all across the board including enterprise servers. It will take a while but they will definitely not 'always be' around. See also: vinyl records. They still exist but mainstream has moved on.

Disks are still present. They are way cheaper, so especially under big data, they are still irreplaceable.

For now. Making unqualified statements about the future is where the problem lies. In the long run, silicon will win over spinning rust and 'the long run' seems to be a lot shorter than we previously thought.

Disks are more expensive for most server use today than SSDs. You can't just look at cost per GB. You need to look at cost to process per GB, and then the vastly increased IOPS and transfer rates provided by SSDs makes them cheaper for most applications where data is regularly accessed at this point.

There are niches, such as long term archival, backups, etc. where disks may still be competitive, but even those are rapidly being eroded.

For things like web servers or database servers, I'll never provision another machine without SSDs.

> You thinking is limited to fancy laptops and not considering enterprise servers.

All of the servers I manage except for a few legacy ones are SSDs by now, for the simple reason that they are cheaper to operate at this point:

They consume less energy, and while their price per GB is high, their IOPS per GB is high enough that we can get away with far fewer replicas of each item of data and still get good enough performance.

I can't afford not to use SSDs in every new server we provision.

Not using SSDs in your servers today means you're behind the curve except in certain niches where performance doesn't matter but sheer storage volume does. That too is set to change within the next couple of years with current rates of cost reductions.

You don't provide any argument. 'It runs on my machines' is akin to 'it runs on my laptop'. Previous system was working, battle tested, was _not_ broken, was not polluting user space. And these are just a few arguments fished from above and other commends here. Now - to defend the new system which will have to prove it's value and stability in the next 20 years or so- what good is it? What awesomeness brings to the table?

Maybe the previous init system was not quite broken, but it had massive drawbacks, and it was not for nothing that many alternatives have sprung up in the last 10-15 years. But most of those tried to limit their scope, while the current winner unfortunately doesn't.

From the little I know, socket activation seems to be systemd's main attractive item.

The main issue is that the amount of stuff that systemd does, and the level of integration all the various parts of systemd have with each other across undocumented or unstable APIs, means that it becomes more and more difficult to replace any of it over time - we're tied to systemd as the one true system management suite until somebody can replace all of it, it's very difficult (and decidedly unsupported) to replace it piecemeal.

In fact, the only reason systemd can do what it does is because those other systems were modular.

And thus if the tradeoff is worth it for you, then you should be free to use it. But do not foist it on the rest of us.

what annoys me is for all these changes linux still can't get a proper, graphical, flicker free boot sequence.

Patches are welcome

I use systemd on my desktop, mobile phone, and servers. I'm paid to maintain Linux servers. systemd is a great addition to the Linux server ecosystem. It's infinitely easier to write a systemd init script that is functionally correct, than it is to write the equivalent init script in shell.

> It wasn't broken, so it did not need fixing / rewriting.

Writing a robust init script in shell is a HUGE pain. Every distro seemed to have their own tools and methods for writing init scripts (e.g. Red Hat had /etc/init.d/functions, Debian had its own, Ubuntu had upstart) -- all of them sucked. systemd makes it easy (and for the most part, portable across systemd distros).

> Writing a robust init script in shell is a HUGE pain

In trivial case, it's simple in any modern distro [1]

In non-trivial case, it's complicated. And the complexity is not going away, all you can do is move the complexity to one corner or another.

When you add the complexity to the shell script, it's right there, plain and clear.

When you move the complexity to systemd, it's not magically goes away - it just moves to thousands of lines of C code (of not the best quality on this planet, to say the least).

[1] https://wiki.gentoo.org/wiki/Handbook:X86/Working/Initscript...

> When you move the complexity to systemd, it's not magically goes away

You're ignoring that complexity was added to every single init script. Every init script had its own potential bugs, issues, race conditions, dependency logic, etc etc.

Now you're moving it to one single master system.

No, it's not "magically going away". The repetition is going away. The code duplication of an extremely complex system is going away.

The repetition is easy. Any modern Linux distro solved the repetition problem long ago. You don't need systemd monster for that.

  depend() {
    need localmount
    after bootmisc
  }
  reload() {
    ebegin "Reloading configuration"
    start-stop-daemon --signal HUP --pidfile ${pidfile} ${command##*/}
    eend $?
  }

systemd the init system is by no means a monster (may I remind you and everyone else again that -resolved is merely a project under the systemd umbrella).

I'm not even sure where to begin when addressing a comment like this. You're biased against systemd in the first place so I don't see the point in discussing this.

It's really amusing that basic software engineering principles are thrown out of the window the moment things get political.

The modularity of systemd-the-monster is greatly overrated. The "basic software engineering principles" you are talking about are not about tightly-coupled interdependent in and out ball of mud with no documented protocols and APIs.

Things get political that very second back then when systemd crowd started pushing their agenda to the masses using strategies like gentle push.

You do, however, need e.g. an init that knows what to do about orphaned processes, or the above is not reliable. It also does not provide any ability to guarantee that process remains running without something other than the typical init, nor to ensure logging is done properly, or enforce resource limits.

To provide the features "just" the init replacement part of systemd provides isn't even possible with most other inits, no matter how you write your script.

An artifact of sysv, not of scripts.

. filename or source filename allow one script to effectively import another. This means that the various logic can live in one place and be reused.

I also love the systemd init system and unit system. What most people complain about isn't that. It's all the rest. Systemd is a huge, huge thing that tries to do everything.

Here, people are complaining that systemd replaces the name resolution system. People also complains it handles tmpfiles, the random devices, the journal, etc... People complains that it replaced perfectly working, battle-tested components with new, unaudited code.

I don't personally care one way or another, btw. I'm a happy systemd user. But I understand the concern.

You probably didn't realize that pain until systemd. Otherwise if you searched for alternatives, daemontools family is pretty easy to find. Or you would be using BSD instead, with better security.

But, well, since I saw a 5-year-ago Stackoverflow question recommending double fork to daemonize which goes against process management best practices dating back to 1990s IBM AIX, I realize the Internet is not smart enough to get such delicate things straight. Maybe djb stuff was not easy to find. Whatever.

*"Portable across systemd" is not portable at all.

I use systemd on all the servers I manage, out of choice. I refuse to set up non-systemd server-setups any more - it is just so vastly more pleasant to work with than the alternatives.

But it's not "taking over" anything at all. People choose to use these components.

And yes, it was and is broken. With respect to specifically DNS, have you tested the various documented options for resolv.conf, for example, and confirmed what your resolver actually does?

I have, and on several different systems with different distros, what I found was that none of them behaved as documented. DNS resolution on most Linux distros is badly deficient, which is one of the reasons so many applications pull in their own resolver libraries, and one of the reasons so some distributions end up e.g. running local Dnsmasq instances to farm out the actual resolution to something that's easier to get to behave in sane ways.

> It wasn't broken, so it did not need fixing / rewriting.

DNS has been broken on most linux systems for a long time. If you read the ubuntu mailing list post, this is the problem they are solving:

* On servers, cloud images etc. we did not have any local DNS server. Configured DNS servers (via DHCP or static configuration in /etc/network/interfaces) were put into /etc/resolv.conf, and every program (via glibc's builtin resolver) directly contacted those.

   This had the major drawback that if the first DNS server does not
   respond (or is slow), then *every* DNS lookup suffers from a ~ 10s
   timeout, which makes every network operation awfully slow.
   Addressing this was the main motivation for the blueprint. On top
   of that, there was no local caching, thus requesting the same name
   again would do another lookup.

I don't particularly care HOW they fix that issue (local dnsmasq/unbound/resolvd) but to pretend that there isn't a problem is sticking your head in the sand.

I am not an Arch Linux developer, but I am a systemd user on Debian 8 and Arch Linux systems.

Here is one answer from an Arch developer about why they adopted systemd:

https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_a...

This was a GREAT answer. The problem is that this is not a factual argument but more an emotional argument.

"From 2brainz (Former Arch Linux Developer for Init Scripts"

> I was the primary maintainer for Arch's init scripts for a while and I can share a couple of thoughts. Arch's initscripts were incredibly stupid. In their first phase, there was a static set of steps that would be performed on every boot. There was almost no way to adjust the behaviour here. In their second phase, the configured daemons were started in order, which only meant that a init scripts were called one after another. In the early 2000s, that seemed like a good idea and has worked for a while. But with more complex setups, the shortcomings of that system become apparent. With hardware becoming more dynamic and asynchronous initialization of drivers in the kernel, it was impossible to say when a certain piece of hardware would be available. For a long time, this was solved by first triggering uevents, then waiting for udev to "settle". This often took a very long time and still gave no guarantee that all required hardware was available. Working around this in shell code would be very complex, slow and error-prone: You'd have to retry all kinds of operations in a loop until they succeed. Solution: An system that can perform actions based on events - this is one of the major features of systemd. Initscripts had no dependency handling for daemons. In times where only a few services depended on dbus and nothing else, that was easy to handle. Nowadays, we have daemons with far more complex dependencies, which would make configuration in the old initscripts-style way hard for every user. Handling dependencies is a complex topic and you don't want to deal with it in shell code. Systemd has it built-in (and with socket-activation, a much better mechanism to deal with dependencies). Complex tasks in shell scripts require launching external helper program A LOT. This makes things very slow. Systemd handles most of those tasks with builtin fast C code, or via the right libraries. It won't call many external programs to perform its tasks. The whole startup process was serialized. Also very slow. Systemd can parallelize it and does so quite well. No indication of whether a certain daemon was already started. Each init script had to implement some sort of PID file handling or similar. Most init scripts didn't. Systemd has a 100% reliable solution for this based on Linux cgroups. Race conditions between daemons started via udev rules, dbus activation and manual configuration. It could happen that a daemon was started multiple times (maybe even simultaneously), which lead to unexpected results (this was a real problem with bluez). Systemd provides a single instance where all daemons are handled. Udev or dbus don't start daemons anymore, they tell systemd that they need a specific daemon and systemd takes care of it. Lack of confiurability. It was impossible to change the behaviour of initscripts in a way that would survive system updates. Systemd provides good mechanisms with machine-specific overrides, drop-ins and unit masking. Burden of maintenance: In addition to the aforementioned design problems, initscripts also had a large number of bugs. Fixing those bugs was always complicated and took time, which we often did not have. Delegating this task to a larger community (in this case, the systemd community) made things much easier for us. I realize that many of these problems could be solved with some work, and some were already solved by other SysV-based init systems. There was no system that solved all of these problems and did so in a realiable manner, as systemd does. So, for me personally, when systemd came along, it solved all the problems I ever had with system initialization. What most systemd critics consider "bloat", I consider necessary complexity to solve a complex problem generically. You can say what you want about Poettering, but he actually realized what the problems with system initialization were and provided a working solution. I could go on for hours, but this should be a good summary.

> The problem is that this is not a factual argument but more an emotional argument.

Most of the arguments against systemd are emotional arguments.

Now see https://news.ycombinator.com/item?id=11814419 .

Cool. Nice to have in contrast.

My personal feeling is this: systemd might be a software blackhole that eventually eat and destroy everything it comes close to and that's OK. If it is so bad then other developers can create a new or modified system that keeps the good stuff and eliminates the bad stuff, while working with other software projects to integrate better.

If we're stuck with systemd, is is better than others worse than some and it isn't like it is the first highly opinionated software project to grace us. A new ecosystem will get developed, wikis written, books sold, training courses packaged. Wise developers of other software will whisper in dark corners about the evil that stalks the land in the form of bad code and design of systemd, and crazed developers will haunt Slashdot, Hacker News, and LWN holding up the hand-lettered signs to make sure we understand how terrible Lennartitis is.

If something new comes along (more modular! less Lennart! doesn't insult the tender heart of tmux developers) developers will fight it out and we can go back to the 5 init systems that we're currently using.

The problem is there are better things before systemd, namely daemontools (and its derivs runit, s6, ...). It wasn't popular, presumably because people didn't care that much.

OTOH, Nosh offers a tool to auto-convert service files into equivalent daemontools shell scripts: http://homepage.ntlworld.com./jonathan.deboynepollard/Softwa...

Few seems to care enough either.

History of modern init FYI: http://blog.darknedgy.net/technology/2015/09/05/0/

Best i can tell, init as more than what started processes at boot, and stopped them at shutdown/reboot, only really became "important" as people used laptops as oversized mobile phones.

And as the concept of containers and *aaS/cloud took hold, some of the same things that benefited said laptops was found to benefit containers.

The reason systemd happened over any of the others though was that perhaps the main dev had a penchant for NIH solutions, and worked for the 800 pound gorilla of the Linux ecosystem...

Basically because RedHat has an obscene amount of clout in the ecosystem and can basically push through whatever they want.

See here systemd, pulseaudio, lvm, selinux, kvm, many more.

Some of these things are good, some of them are bad. The important thing is once RH has decided they want to take over another component of the ecosystem there isn't really a lot anyone can do. Not even Linus has been able to halt the systemd nonsense.

Why do other distros cave? Well because RH controls most of the other important projects too and they go to great lengths to create integration that is unnecessarily difficult to decouple. For instance Gnome. Probably impossible to run without systemd now (or at least highly impractical).

At the end of the day it has nothing to do with the technical merits of systemd and everything to do with how much power RH has to steamroll whatever solutions they want through.

> At the end of the day it has nothing to do with the technical merits of systemd and everything to do with how much power RH has to steamroll whatever solutions they want through.

RedHat is a premium member of our community that has a well earned reputation which makes whatever they do get noticed. Why are they to be the focus of a witch hunt like if they were MicroSoft of the Steve Ballmer era?

If these things didn't solve problem they wouldn't get used period. RedHat being an evil member of Linux seems almost comical. Linux has won the war and yes RedHat has been a key member in winning the technology war. I fail to see how all distros who can do whatever they want continue to chosen RedHat solutions over and over again? They make developers lives better and arguably Linux better.

Canonical on the other hand continues to be a Linux community member that tries to compete with everyone else and doesn't contribute upstream as much as everyone else. I say it is good news now we can have less wasted work on different solutions. Why hasn't Canonical's projects caught on? They don't work as well or seen to not work as well as other solutions. Unity anyone?

PulseAudio has been a HUGE success that so many talk down due to the rocky start of the project and the personality of the developer (Who also created SystemD) Audio in Linux was a huge mess prior to Pulse Audio.

KVM - is the best virtual system bar none.

lvm - I don't really need to defend this project?

selinux - This was started by the NSA not RedHat

I never said they were evil. You misconstrue what I am saying.

I am just saying if RH wants something to become the dominant solution it will be, regardless. Doesn't matter if they started the project, or acquired it, or if they just think it's a good idea, or maybe it's just something a subset of their clients want (i.e selinux).

It's not about competition either. Canonical is a terrible example. They are tiny compared to RH in terms of presence in the community. Their efforts are basically safe to ignore because they are downstream of everyone else.

The issue at hand is just how much of the upstream that RH has a stranglehold on.

As I said. Sometimes it's good, sometimes it's bad but even if it's mostly good it doesn't mean that it's not happening.

systemd is a good thing (tm) - I recognize that and am grateful for it.

However.

In the beginning a lot of distros were "forced" to accept systemd because udev was merged into its codebase.

Systemd is great, but its group of devs are absolutely fucking terrible at public relations. Sometimes they make changes that upset users. Like the recent one that has (logind?) by default killing all user-created processes when the user logs out (this surprised people as it became a new default). Or the security incident before that where systemd made it possible for users to get access to framebuffer contents. Sometimes things happen.

It's just made worse when you go to the systemd group with your problem and they act like what they've done is correct and everybody should just live with it. Sometimes we're wrong, sometimes they're wrong. Poettering writes up these really long posts which are mostly good reads, but sometimes he calls us neckbeards who want to live in an unchanging, static past.

Great project, great code, great devs - but terrible attitudes [sometimes].

"Great code" -> I am sorry, but if the allegations are true it's not great. (Not saying every part of it is bad, I kinda like the idea of systemd-init-part, but I describe them as utterly inconsiderate to everyone else.)

Gigantic thread on the KillUserProcesses setting: https://lists.fedoraproject.org/archives/list/devel@lists.fe...

Dear deity...

https://lists.fedoraproject.org/archives/list/devel@lists.fe...

It was indeed logind.

* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#221

* https://news.ycombinator.com/item?id=11782364

The systemd developers' way of addressing that was to go and ask the people who wrote things like tmux to change tmux. The response of the tmux developers was to repeat the question asked and not answered 5 years ago.

* https://news.ycombinator.com/item?id=11798515

* https://news.ycombinator.com/item?id=11797075

The problem where the people who just switched to Ubuntu 16 are hitting problems with high-end database servers, middleware, containers, large builds, and so forth all running out of threads because of another systemd default that was switched by its developers, is still quietly on-going.

* https://news.ycombinator.com/item?id=11675129

> The problem where the people who just switched to Ubuntu 16 are hitting problems with high-end database servers, middleware, containers, large builds, and so forth all running out of threads because of another systemd default that was switched by its developers, is still quietly on-going.

That's evil. Thanks for pointing that out. Terrible to debug, poorly documented and funny side effects you don't immediately think off. That fork bomb reasoning for the change is also sketchy as if you have local privilege you can DoS the machine in a lot of other ways (cpuburn, filling the disk, hogging memory and causing swap of death). If you run a public SSH server you likely already used cgroups and other measures to prevent fork bombs.

I don't think it's really all that bad; several big, popular, widely-deployed distributions are using it and most people appear to be getting on just fine.

It's just that people against it are extremely vocal.

I do dislike the idea of binary logs, though.

I like binary logs. They are faster, which is not a bad thing if you have to grep them. And easy to filter thanks to a fix metadata interface, and so on.

journalctl could use some work, but it can just print JSON, and there's jq.

Maybe my dislike for binary logs is because I haven't yet learnt the tooling around them.

I'm familiar with dealing with text files in Linux/Unix land and have built up years of knowledge on doing so. I feel reluctant to throw that away.

People against it are extremely vocal because it is much harder to work around than previous stuff. Don't like PulseAudio? Use alsa directly is fine, I did in my Arch Linux box. Don't like Flash? HTML5 FTW. Don't like systemd? I have to go to FreeBSD altogether.

Because scope creep means more and more packages have systemd as a hard dependency.

And that is not a coincidence

> Well, it is definitely our intention to gently push the distributions in the same direction so that they stop supporting deviating solutions for these things where there's really no point at all in doing so.

> Due to that our plan is to enable all this by default in "make install". Packagers may then choose to disable it by doing an "rm" after the "make install", but we want to put the burden on the packagers, so that eventually we end up with the same base system on all distributions, and we put an end to senseless configuration differences between the distros for the really basic stuff.

> If a distro decides that for example the random seed save/restore is not good enough for it, then it's their own job to disable ours and plug in their own instead. Sooner or later they'll hopefully notice that it's not worth it and cross-distro unification is worth more.

https://lists.freedesktop.org/archives/systemd-devel/2010-Se...

"There is also concern that it forms a system of interlocked dependencies, thereby giving distribution maintainers little choice but to adopt systemd as more user-space software come to depend on its components" from relative wikipedia article (https://en.wikipedia.org/wiki/Systemd). This does not sound any good.

systemd is many things. It's a sensible init system, better in some ways than upstart and lightyears ahead of SysV init. Its native support for confining daemons' process tree using cgroups is generally a good idea.

But it's also a load of unrelated utilities like this one. Unfortunately if you get systemd as an init system, you generally get all this other stuff (unless you take steps to remove them, which in some cases is simple and in others is painful).

Some of these utilities might be a good idea, but they should be separate projects, not bundled.

As a daemontools fan, I'm frustrated that something in the daemontools family never became popular (process supervision, be it daemontools, upstart, systemd, etc. makes managing services so much nicer). But I do recognize the utility of using cgroups as part of this. Is there, or could there be, a "do one thing" utility that can launch a process in its own cgroup, such that it would fit in nicely in a daemontools-style run script?

There indeed could be. (-:

Hey, presto!

    jdebp % cat /var/sv/epmd/service/run
    #!/bin/nosh
    #Run file generated from services/epmd.service
    #Erlang Port Mapper service
    move-to-control-group epmd.service
    setuidgid rabbitmq
    userenv
    epmd
    jdebp %

Because it started small and OK. When distros made the decision to switch, it looked OK. It has proliferated into something else since then and none of the distros seems to be willing to take a step back.

Problem there may be that going back means picking up maintenance on code that has been abandoned for years.

There is a fork of Consolekit out there, Consolekit2, but they have to contend chasing logind's tail as most DEs have either stripped out their consolekit support, or it is suffering from severe bitrot.

Maybe because Red Hat pays the bills ?

Bingo. A full time programmer can churn out code and keep up with lists much better than someone that do so on their spare time.

Never mind that if you have several programmers on RH payroll on the same project, it is quite possible for them to use corporate channels to make decisions and then effectively dump that into the codebase over night.

My 2 cents: init script wasn't a enough pain in the ass for people in charge to search for alternatives but still a pain, and systemd was introduced to them by Red Hat manpower. It seems good enough so they went with it.

Actually, init script wasn't anyone's enough pain in the ass in Linux world save for djb. daemontools came out in 1997 and no one seemed to care. Systemd replaced those init scripts IMO only because they wrote all the replacement service files as well with the manpower at Red Hat's disposal. It's hard to match that from open source world.

Red Hat's marketing muscle to "embrace and extend".

How does this argument even make sense? Since when are Debian developers or Arch linux developers overly concerned with Red Hat marketing muscle?

RedHat controls development of other important Linux subsystems and introduced hard dependencies on systemd.

This might or might not be true. I would be inclined to agree more with it if the evidence from other distribution highlighted this argument.

I don't see Debian or Arch developers making that argument.

Are they hiding how much pressure from Red Hat they feel? Unlikely. Linux developers are happy to blog, tweet, and post to mailing lists about large and small things, but somehow a concerted push by a corporation makes them fall silent and accept SystemD?

Those things all happened, it's just been going on subtly over a period of years. A search for Gnome and systemd on HN should turn up some of the earlier complaints. The *BSD developers certainly made some noise.

I think it is pressure in the overt sense.

It is rather that RH can throw dollars and thus coder man hours at a problem while most other distros have to make do with volunteers (or can't field the amounts RH can).

Then again, there is a certain email from Poettering thats of interest.

https://lists.freedesktop.org/archives/systemd-devel/2010-Se...

An analogy with Google PlayServices is inevitable.

> "Google's strategy is clear. Play Services has system-level powers, but it's updatable. It's part of the Google apps package, so it's not open source. OEMs are not allowed to modify it, making it completely under Google's control. Play Services basically acts as a shim between the normal apps and the installed Android OS. Right now Play Services handles the Google Maps API, Google Account syncing, remote wipe, push messages, the Play Games back end, and many other duties. If you ever question the power of Google Play Services, try disabling it. Nearly every Google App on your device will break."

https://lwn.net/Articles/681758/

I don't understand why you are getting downvoted.

The absorption of udev and basically forced dependency on systemd from important desktop environment projects also controlled by RH is a very real reason why this happened.

Nothing prevented people from forking udev if they didn't want to take systemd.

And so they did

https://wiki.gentoo.org/wiki/Eudev

Forks and alternative /dev managers have to contend with GregKH and Sievers though...

http://www.landley.net/notes-2015.html#05-07-2015

Thanks for the great read. mdev is indeed nice alternative to udev monstruosity. It is somewhat supported in Gentoo https://wiki.gentoo.org/wiki/Mdev

Under a severe pressure from a vocal and extremely tribal minority, of course. There are no technical reasons to do it.

I don't know about other distros but let me remind you that ubuntu sometime ago switched from gnome desktop to Unity despite all the cries that the latter is just horrible.

But you can still run gnome on Ubuntu (I do), and Linux without a graphical interface at all.

True. Or you can switch to Mint. The think with systemd though is that you don't have this option anymore. Regardless of how bad idea you think it is - you are stuck with it (as it seems). I think that's on the core of arguments against it.

Without "Desktop Environment", not without graphical interface.

Huh? When did a console become a graphical interface?

Not a console. X Window System and window manager.

If you do not like unity, you can just use ubuntu-gnome like me. IMHO, Unity is horrible, but you have the choice to not use it. There is no need to complain.

Criticism does not equal complain. If I find something horrible I'll say so - that's feedback. By your way of thinking, since I don't have to use brainfuck (an intentionally horrible language) I should not mention that it is horrible. You just don't make sense other than patting youself on the back for being 'positive' downvoting the grumpy ones while letting bad ideas forward.

And? I don't see Canonical hog tying their DE to user space internals such that everyone else had to fork it or adopt it.

Why are people constantly trying to demonize Canonical?

Reply on news.ycombinator.com