Hacker News Reader

Comment by evanosaurus | Hacker News Reader

A number of developers from RedHat were once very involved in the project. However, these developers had a very arrogant attitude towards Docker: They wanted docker changed so that it would follow their design ideas for RHEL and systemd. They often made pull requests with poorly written and undocumented code and then they became very agressive when those pull requests were not accepted, saying "we need this change we will ship a patched version of Docker and cause you problems on RHEL if you don't make this change in master." They were arogant and agressive, when at the same time, they had the choice of working with the Docker developers and writting quality code that could actually be merged.

THIS. It was both amusing and sad to watch this happen time and time again. My favorite is what happened (or, rather, didn't happen) around CoW filesystems and how they decided to just use a FUSE-based one instead.

View on HN

Upvoted because every opportunity for me to vote against RedHat's insistence on the nightmare that is systemd is a good opportunity.

Stop breaking Linux's usefulness as a server OS in a misguided attempt to make it a desktop OS. (see: systemd, networkmanager, etc)

Why do you think that systemd is not useful on a server OS?

I don't want to start this discussion but it largely comes down to taste. Some people don't want to run dbus or have no use for journald. If you put your daemons into runit you can have a small and lean image without dbus.

Personally I loathe network manager in RHEL7 but that's not a systemd problem.

I understand that there are people who don't have a use for journald. It strikes me as odd to look at journald's feature set and conclude that this is being driven primarily by desktop support to the exclusion of servers, though.

Frankly i suspect journald is one bother backing the other.

The basic concepts journald is built on is lifted straight out of a doctorate thesis written by Lennart Poettering's brother.

Thinking about i don't think systemd really have a goal. It seems to be a hodgepodge of Poettering itch scratching, Gnome/Fedora/Freedesktop NIH-ing, and a bunch of "because we can" sub-projects.

If you don't like systemd in general that's one thing, but to claim that systemd only benefits desktops is just wrong. I'm just tired of the "systemd only goal is boot speed" argument. Too many people want to join the crowd and get their old-school linux user credentials by bashing systemd without understanding or acknowledging the benefits.

sysvinit maintainers must love systemd. Before systemd came along there were lots of complaints about what a terrible hack sysvinit is. Now it's a paragon of simplicity and stability without having actually changed any..

Yes, wouldn't a server want to depend on the DESKTOP BUS?

Ok, snarky, yes. Still want to know the answer :)

Also, why is it that the ONLY alternative ever mentioned is sysvinit? Systemd is not the 2nd init system ever invented, nor even the 4th or 5th. There are simpler alternatives.

Binary log files? Don't even get me started.

You think if it wasn't for systemd your server wouldn't need dbus? You wouldn't be running docker on that server either..

If I had a dollar for every time a systemd supporter compared it to upstart without provocation, I'd have exactly zero dollars.

If I had a dollar for every time a systemd supporter reminded us that we need systemd because runsv was a terrible hack, on the other hand...

As a neutral party, one thing I'll say about systemd is at least they understand what a dependency is. I still haven't figured out why the upstart people think it's a good idea for a service to magically start just because its dependencies are fulfilled. Maybe they think system services are like proteins or something.

Someone tell that to RedHat. They consider the network "up" once the device gets link, not when the system gets an IP address. Even in environments without spanning tree, this is a problem due to massive parallelization -- spawning 30 processes 5ms after the network is "up" but doesn't have an IP from DHCP yet.

The solution? Put a sleep 7 in there, thus making the entire process slower than the previous solution.

Wow, that's disgusting.

That's wrong. Read about it at https://wiki.freedesktop.org/www/Software/systemd/NetworkTar...

So either I use systemd's sleep or my sleep, but either way it's broken out of the box. Great job!

EDIT: RHEL/CentOS only supports NetworkManager for this. Which sucks if you don't want to run NetworkManager (for a litany of reasons).

$ yum whatprovides "*/systemd-networkd-wait-online.service" No matches found

It's because every argument I've seen against systemd is by people who think systemd betrays the Unix philosophy and think we should go back to sysvinit (see rconti above). Upstart had a lot of problems, and the only good technical arguments I've seen in its favor are better compatibility with other kernels. Please point me to a good "Upstart is better than systemd" technical article.

> think we should go back to sysvinit (see rconti above).

Except he didn't. Another good example of the straw man arguments I was talking about. Hating systemd doesn't automatically make you a sysvinit fan.

>Upstart had a lot of problems

The fact that you didn't mention one of them demonstrates just how much you know about this (nothing).

Another good example of the level of technical detail I see in comments from systemd haters, thanks.

You know, the funny thing is I never exactly considered myself a systemd supporter. I just get tired of the comments from people bashing systemd which are almost always emotional and political rather than technical in nature. Maybe there's good technical arguments for some other system but they get drowned out by the "systemd is a nightmare with zero benefit that was written to make linux a desktop OS" comments..

It's not the best architected system of all time but it's hardly a nightmare. Too monolithic though, and they like to violate the UNIX philosophy.

It wasn't really any better than upstart either, which is why I was mad about seeing ubuntu rip it out in order to replace it with systemd.

The main thing that concerns me most is that systemd is now dominant on virtually every linux platform and without competition it is going to stagnate.

Upstart wasn't perfect but it was decent and it was competition, it worked well for ubuntu and it would have been a better choice for debian (unfortunately the vote was split 50/50 and the tiebreaker guy decided on systemd).

It could well be. I don't have the technical understanding or time to invest in order to make a technical criticism. But I've been fighting it for a year or two, and it hasn't started making more sense yet!

Because it does nothing that anyone in my organization has ever asked for, nor does it do anything that anyone in any organization I've ever worked for has asked for, in 20 years of working on Linux systems.

I've never heard of any problems it solves other than things described in abstract terms that might make sense to a developer but that makes no sense to Operations/DevOps teams.

Nobody likes learning something new for zero benefit. I keep trying, though. But the more I am forced to learn about it, the more arcane it gets. It's not a learning curve, as far as I can tell. It's a learning wall with no payoff. It makes everything we do more difficult, the commands make no sense, and it brings no tangible benefit. It's change for change's sake. It reminds me of DJB's insistence on making logs in hex "just because".

Just a simple example. Why is it "systemctl list-unit-files"? What the hell are unit files? How is this in any way logical? Why is this an argument and not a flag? Why is it that I can use a systemctl command, and it tells me to use the -l flag to view non-ellipsized output, but then when I use the flag, it gives me an arcane error that tells me nothing about what happened? It's the tip of the iceberg in an endless string of junk that simply doesn't make any sense or work properly.

So, I like to vote against it whenever I can, because supporters like to keep insisting that it's the way of the future, and implying anyone who hates it is a luddite.

> Why is it "systemctl list-unit-files"? What the hell are unit files? How is this in any way logical?

I suggest you read systemd.unit(5), which begins as follows:

"A unit configuration file encodes information about a service, a socket, a device, a mount point, an automount point, a swap file or partition, a start-up target, a watched file system path, a timer controlled and supervised by systemd(1), a temporary system state snapshot, a resource management slice or a group of externally created processes."

> Why is this an argument and not a flag?

Multi-use programs with a good CLI accept the argument(s) determining what they do positionally rather than as flags. Flags should be used for options that somehow modify the behaviour of the command.

> Why is it that I can use a systemctl command, and it tells me to use the -l flag to view non-ellipsized output, but then when I use the flag, it gives me an arcane error that tells me nothing about what happened?

I don't know what you mean. For me, 'systemctl list-units -l' works fine.

It's hard to argue with someone who claims that systemd has zero benefit.

You claim unit files are confusing. Let's say we took a Windows programmer who was a sophomore in CS but didn't have any Unix or Linux experience, show him both systems. Explain how runlevels are handled in systemd vs sysvinit. Show him a systemd unit file vs the equivalent bash script. Explain how systemd tracks the process tree vs sysvinit pid file hack. You spent five minutes trying to figure out systemctl and declared it terrible. It probably took you more than 5 minutes to find /etc/init.d your first time

Perhaps. My complaint is that systemd has not started making any more sense in the year(s) I've been wrestling with it. And it hasn't given me any benefit yet.

To most of us, it's change for change's sake, which makes life worse due to the learning curve. If it made life easier for the average end user or the average sysadmin, it would have more defenders.

Why on earth would you think Redhat, of all companies, wants Linux to become a desktop OS? They literally make all of their revenue on Linux server deployments.

Red Hat does not use a FUSE based file system. It's LVM Thin-p based....

ouch, like i was not already suspicious of RH activity.

Their threat sounds almost Microsoft. I have run into various claims where companies were worried they had to bend to MS wishes, or MS would start shipping a clone product.

Sounds like Microsoft from 15-20 years ago, not in the past decade.

Reply on news.ycombinator.com