Live data from Hacker News

Systemd 252

github.com

251–260 of 317 posts

Re: Systemd 252

#251

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…

Don't we already have multiple, alternate systems that are significantly simpler? The primary reason why I don't use systemd at all, on any desktop or server I manage, is not that I think it isn't powerful or reliable but, I cannot fit it into my head. The scope and complexity of it goes beyond what I'm personally willing to invest into any one subsystem designed to regulate my operating system. I find that because I…

You don't have to fit anything in your head. I often find myself consulting the index at `man systemd.directives` to remember things: https://www.freedesktop.org/software/systemd/man/systemd.dir...

In lot of cases I've found systemd units much to actually be simpler and easier to maintain due to everything being in a simple declarative format. The old alternative is to have a lot of shell scripts that can get very complex, and to consult another few hundred man pages for various shell utilities...

Re: Systemd 252

#252

Earlier quoted context omitted.

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.

You mean the distros broke it by not toggling that option. As you can read from the parent comment here, that "convention" was also broken and causes issues in Debian. There's no solution here that isn't going to break something, that's why the best systemd can do is ship a toggle and tell the distros to figure it out.

Re: Systemd 252

#253
post #223

Earlier quoted context omitted.

http://www.islinuxaboutchoice.com/ >where to me, running Linux is about choice. Quote : "From: Adam Jackson To: Development discussions related to Fedora Subject: Linux is not about choice [was Re: Fedora too cutting edge?] Date: Wed, 09 Jan 2008 15:58:45 -0500 > Linux is about choice. If I could only have one thing this year, it would be to eliminate that meme from the collective consciousness. It is a disease. It s…

Hah, I knew somebody was going to post this and almost added a disclaimer. When I say Linux, I'm talking about Linux distributions. Not the bare kernel, not embedded Linux. If I choose to use Linux over macOS or Windows, the #1 reason is that it gives me greater choice. On the desktop, to choose different desktop environments, to customize it to a greater extent than what is possible on other platforms. (That even ap…

>But you can't choose your window decorations, themes, desktop panels independently anymore and get a somewhat matching look and feel. It's only Gnome island, KDE/Plasma island, and hacker-minimalist island.

Maybe take that as an indication those "spirits" are at odds and can't be reconciled? You can't have a system that's fully stable and predictable but also lets you swap out any component at a moment's notice to some unsupported third party thing. You either pick one or the other. In my opinion Linux has only ever been really worth it for companies willing to employ developers to work on it; you don't get any of that customization for free. At one point Linux companies were experimenting with things like desktop panels but then the market changed, they stopped and the money dried up. That's what happens.

Re: Systemd 252

#254

Earlier quoted context omitted.

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.

That would be the distro's problem, not systemd. Any of those utilities are going to be optional, the distro has to consciously enable them and ship them in a package for it to make it to you at all. A lot of commenters seem to misunderstand that systemd is not forcing distros to do anything. All they really do is provide a set of tools for distro maintainers to choose from.

Re: Systemd 252

#255
post #64

Earlier quoted context omitted.

I’m guessing you don’t mean setsid(2), but when you say “seat and/or session management,” what does that mean concretly? Why should init be involved instead of something under the user’s control?

How is systemd not under the user’s control? It is an init and service management system and long-running processes are services. Where else should it be managed? Systemd is the only component that knows whether you are logged in/out, whether you still have another seat open, etc. And its responsibility is to properly close resources, and not let unannounced processes to linger needlessly in the background.

init belongs to root. Only sysadmins can choose it (or not) and configure it, so only they should have reasons to interact with it or understand its UI.

Re: Systemd 252

#256

Earlier quoted context omitted.

It happened to Pulse after the project stopped being a moving target. Just look at the changelog of this systemd release.

Just because the project is moving, doesn't mean it's moving in the right direction. What I like about linux in general, is that there are lots of small tools, with a reduced and specific scope, that do their job well. Systemd seems to want to do and control everything.

I don't understand this comment. Systemd is a lot of small tools with a specific scope that do their job well.

Re: Systemd 252

#257
post #46

Earlier quoted context omitted.

There are solid technical reasons for systemd's binary logging. The nice thing about its binary log format is that it's organised by fields which are indexed for quicker searching and filtering. It's much easier and faster to analyse these logs than the traditional text-based ones. Also, having journald authenticate the process that is sending it log entries, and the log sealing capability, are two features that can…

Being able to boot a server with a 'live USB image'; mount root, and inspect the logs to see what happened are not possible when you got a binary blob for a log. When things have really fucked up, you need the 'ease of access that plain-text log files provides.

[deleted]

Re: Systemd 252

#258

Earlier quoted context omitted.

> There are many reasons to not like systemd and the creator, who incidently after leaving the GNU/Linux is now working for the same company that sought to destroy it, Microsoft. I only learned about that a few days ago, here on HN (some thread or some old comment). It is completely insane and gives lots of fuel to the systemd haters. I do run both Debian (systemd) and Devuan (a Debian fork with all the systemd stuff…

> and there should be Linux distros packaged without systemd. systemd should be an optional package on all distros. Shoving it down throats is one of the valid major criticisms. What should have happened instead is systemd was optional on Debian at setup and Debian was forked to include it by default. It is simply backwards that Debian needed to be forked for purity. Duvuan shouldn't need to exist, but it very much d…

>systemd should be an optional package on all distros.

Why? Should glibc also be optional? What about the Linux kernel? What about apt-get? You can technically replace those things but it's a ton of extra work, almost like shipping a completely different distro. At the end of the day, a distro decides what packages it wants to support and what it doesn't. The specific choice of supported packages is often what defines a distro and sets it apart from the rest. If they have limited manpower and choose to save themselves time by picking only one init, or libc, or desktop environment, or anything, that's their decision.

>but would any here really insist on forcing everyone else to use your methods and no others?

No. There are hundreds of Linux distributions to choose from, and anyone can make more distributions any time they want. No one is forced to do anything. Also, using Linux is optional to begin with.

>systemd, among other valid criticisms, is unmistakably fascist. For anyone but parent, don't just be thin-skinned and downvote my comment because you have allowed yourself to be insulted. Be courageous and disagree with me if you can. How is systemd not fascist?

You should stop and think a bit more before making these comments that you appear to be acknowledging as histrionic and insulting. By this definition BSD is also "fascist" due to only shipping BSD init, and the Linux kernel is "fascist" due to only shipping one set of drivers, and Devuan is also "fascist" for not supporting systemd...

Re: Systemd 252

#259

Earlier quoted context omitted.

Don't we already have multiple, alternate systems that are significantly simpler? The primary reason why I don't use systemd at all, on any desktop or server I manage, is not that I think it isn't powerful or reliable but, I cannot fit it into my head. The scope and complexity of it goes beyond what I'm personally willing to invest into any one subsystem designed to regulate my operating system. I find that because I…

You don't have to fit anything in your head. I often find myself consulting the index at `man systemd.directives` to remember things: https://www.freedesktop.org/software/systemd/man/systemd.dir... In lot of cases I've found systemd units much to actually be simpler and easier to maintain due to everything being in a simple declarative format. The old alternative is to have a lot of shell scripts that can get very co…

True. However, my objective is to internalise the tooling that routinely use, the scope of systemd is beyond what I need. Also, I find constantly looking up unique directives fatiguing and would rather use that energy elsewhere. I find working with the same general tooling results in faster & easier mental recall across a broader range problems that I tackle. Just my experience, no doubt different for others.

Re: Systemd 252

#260

I have long been an advocate against systemd for the typical reasons (overreaching responsibilities, lock-in, lack of choice, software assumption "it will be there", complexity, driven by large corporate interests [see lock-in], being modeled after launched, etc etc). I feel like the chickens are coming home to roost. That said, if one wants to use it, then use it. However, there are alternatives which I would love t…

Why s6 over other options? I've long considered switching from arch to something without systemd since I use almost zero systemd features but have not had time to discern which init system to use.
Post reply on HN