Live data from Hacker News

Systemd 252

github.com

241–250 of 317 posts

Re: Systemd 252

#241

It feels like the time is ripe for something simpler and more modern to replace* systemd. The timing of this release coincides with me being bitten with yet another bug** on the weekend. How long until “Systemd: The Good Parts”? *The most trivial new name would be système which would at least be in keeping with the French naming. **In Debian stable if you create a new user, ssh in as that user, logout, then delete th…

> It feels like the time is ripe for something simpler and more modern to replace* systemd. Well then do what Poettering did and write it. It's threads like this why I am eternally grateful that Linux kernel uses a merit driven approach and not concessus driven one.

> Well then do what Poettering did and write it.

This is such a superficial and ignorant take I'm having hard time forcing myself to believe it was written in good faith.

Dozens of alternatives already exist. The problem isn't writing, problem is having politicial power Poettering had. (ie. He was employed by Red Hat and had close connections with other Freedesktop developers.)

Re: Systemd 252

#242
post #37

Earlier quoted context omitted.

>thought that systemd was generally hated? If it was generally hated there would be a lot more support for the distros that don't have systemd. There isn't. Except for alpine, all of them are extremely niche, half of them are dead, the other half barely have enough people to stick around for a release a year. Even alpine is kinda niche, it's mostly used as a way to make lightweight docker containers, rather than as a…

I think that is an overstatement. I use systemd but there is legitimate criticism and even a questionable conflict of interest in the creator now working for the competition. People working against the best interest of the community is a real threat that shouldn't simply be ignored. However, so far systemd has worked out alright for me so I can't complain too much but the documentation is still lacking in certain are…

> creator now working for the competition

Microsoft hasn't been the competition for while. They might not be "part of the team", but they definitely have more to win by linux being alive than dead. I'd put them more along the lines of IBM or Oracle, huge corps trying to somewhat discreetly steer linux in a path that suits them.

Re: Systemd 252

#243
post #200

Earlier quoted context omitted.

Ahhh, thanks. Now you mention it, wasn’t there some major scandal about this when it first shipped?

There were a lot of noises made about it, yes, because people had been "nohup"ing things for decades, and using stuff like screen and tmux to keep sessions going over poor connections. All of a sudden, without much warning, someone made the decision to kill all user processes on logout. It broke a lot of folks workflow.

One would be tempted to say that deleting a user and logging out are definitely different operations with expected different outcomes.

Re: Systemd 252

#244

It feels like the time is ripe for something simpler and more modern to replace* systemd. The timing of this release coincides with me being bitten with yet another bug** on the weekend. How long until “Systemd: The Good Parts”? *The most trivial new name would be système which would at least be in keeping with the French naming. **In Debian stable if you create a new user, ssh in as that user, logout, then delete th…

> It feels like the time is ripe for something simpler and more modern to replace* systemd. Well then do what Poettering did and write it. It's threads like this why I am eternally grateful that Linux kernel uses a merit driven approach and not concessus driven one.

Ubuntu had the alternative software called Upstart.

It was killed because of the Red Had power behind Systemd.

Technically, I don't know which one is better, but politically, Systemd was a power move by Red Hat.

Re: Systemd 252

#245

Earlier quoted context omitted.

> It feels like the time is ripe for something simpler and more modern to replace* systemd. Well then do what Poettering did and write it. It's threads like this why I am eternally grateful that Linux kernel uses a merit driven approach and not concessus driven one.

> Well then do what Poettering did and write it. This is such a superficial and ignorant take I'm having hard time forcing myself to believe it was written in good faith. Dozens of alternatives already exist. The problem isn't writing, problem is having politicial power Poettering had. (ie. He was employed by Red Hat and had close connections with other Freedesktop developers.)

That isn't "political power" it's called knowing your audience and knowing what they want. The audience here is Linux distribution upstreams who also participate in Freedesktop. The other alternatives had ample time to talk to these people and copy the features of systemd and improve on them but they refuse to do it. They seem more interested in building for their own niche use cases and ignoring everyone else. That's a fine decision, but it's their decision. They can't say it's anyone else's fault.

Edit: If those other developers were really serious about trying to replace systemd they would be going around to every distro maintainer they can possibly find and asking them what systemd is doing badly and what they'd like to see in a better project. Then they'd have to think really hard about whether it's easier to fix those issues just by contributing to systemd, or whether a full replacement is warranted. Every now and then I see comments about writing replacements in Golang or Rust or some other memory safe language but there's no other interesting ideas there to warrant a rewrite. Maybe you do all this and conclude there are no major complaints from the big systemd users, and that's just how it is.

Re: Systemd 252

#246

Earlier quoted context omitted.

It was part of the contest that your enemy team is not able to detect and remove your backdoor. The obscurity of systemd sockets was my winning move.

systemd doesn't bind to random ports without being told to. if the blue team didn't stop and say "why is anything listening on port %d", they're a trash blue team.

Clearly you have not used systemd and friends much.

It is an ecosystem of daemons that does a lot of things, some of which are guaranteed to surprise you. The specifics of which will vary between releases.

I could easily see some random systemd utility binding a non standard port without anyone taking notice.

Re: Systemd 252

#247

Earlier quoted context omitted.

Ahhh, thanks. Now you mention it, wasn’t there some major scandal about this when it first shipped?

The "scandal" was the exact opposite of your complaint. People where SSHing in, starting a screen/tmux, disconnecting and complaining about the process being killed.

Not really an exact opposite. There was a preexisting convention for how to intentionally keep a process running after logout, which systemd broke. That's quite different from a case of a background process the user did not explicitly ask to be started in the first place, let alone flag to keep running after logout.

Re: Systemd 252

#248
post #244

Earlier quoted context omitted.

> It feels like the time is ripe for something simpler and more modern to replace* systemd. Well then do what Poettering did and write it. It's threads like this why I am eternally grateful that Linux kernel uses a merit driven approach and not concessus driven one.

Ubuntu had the alternative software called Upstart. It was killed because of the Red Had power behind Systemd. Technically, I don't know which one is better, but politically, Systemd was a power move by Red Hat.

>It was killed because of the Red Had power behind Systemd.

That is an absurd, untrue conspiracy theory. Whoever told you that should be ashamed. The author of Upstart said that it died because of a restrictive CLA. Read the thread linked here for an explanation: https://news.ycombinator.com/item?id=27176807

To quote the relevant parts:

>I entirely agree with Kay and +Greg Kroah-Hartman that it was the CLA that caused systemd to be written instead of Upstart.

>But I don't need that self-affirmation anyway :) I wrote Upstart, I got paid for it, I moved on to do other things, something else came along and replaced it. If Upstart hadn't been under the CLA, and systemd hadn't've happened, all my code would have long since been rewritten by now anyway.

Re: Systemd 252

#249

Earlier quoted context omitted.

> It feels like the time is ripe for something simpler and more modern to replace* systemd. Well then do what Poettering did and write it. It's threads like this why I am eternally grateful that Linux kernel uses a merit driven approach and not concessus driven one.

Yeah, but Redhat has been slowly getting control of more of the infrastructure. Want to make your own? Well even if you make something backwards compatible with Gnome or udev, get popular and they will probably find some way to break your compatibility. You end up needing to fork all the projects that Redhat has gotten their tentacles around.

That's a pretty negative way to make an innocuous statement: that it's expensive to make an OS. You can't expect Red Hat (or any other Linux company) to maintain backwards compatibility forever for every single possible project they've ever had an employee contribute to. They'll maintain some as long as their customers pay to support it for that long, but even that ends after a while. Yes, if you don't want to pay them for it, then you get to spend the immense amount of time and money needed to fork it; because shipping a full commercial operating system with millions of lines of code is a complex task with a lot of interlocking parts and no one wants to do it for free. It makes no sense to single out complaints towards random projects for this.

Re: Systemd 252

#250
post #213
post #114

Earlier quoted context omitted.

You can run virtually any Windows application on top of Systemd already via Wine. Unless you have some particular attachment to the NT kernel, there near zero reasons to use Windows today.

If only that were true. "Virtually any Windows application" is a fantasy I'm afraid, many important applications run poorly or not at all on Linux. Then there's the "particular attachment to the NT kernel" caused by driver support for $HARDWARE - there's tons of niche hardware that just can't be driven from Linux. If you use a computer for actual industrial work , you will hit one of these problems very quickly.

> there's tons of niche hardware that just can't be driven from Linux.

Linux developers can often do wonders, but they still do not have a crystal ball. If that hardware is niche+closed+expensive I don't see how they can produce working drivers or software. Manufacturers not releasing documentation are the problem, not Linux, or BSD or any other non supported OS.

Post reply on HN