Hacker News Reader

Comment by jacquesm | Hacker News Reader

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.

View on HN

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.

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 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.

Reply on news.ycombinator.com