Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Systemd 252

github.com

Post reply on HN
Print view View original

161–170 of 317 posts

Re: Systemd 252

#161

Post by WastingMyTime89 »

lakomen wrote: post #86
stevefan1999 wrote: post #71

I just never get why people always flame on systemd. Sure, it's kinda bloated in the sense that it is "battery included" just like Python, but the intention to have a stable init with great system and service management is very good from both a DevOps and Sysadmin perspective. It is at least much better than writing your adhoc init.d script that may not guarantee to run on other Linux distros.

The arrogance of Lennart has something to do with it. The way he tends to disregard real bugs as not a bug, since he and his production are perfect and always right. Numerous cases of that. Then the security aspect of a jack of all trades process running as one that controls every other process. Reading logs after a panic and rebooting to check them is a pain in the ass without journald on the chrooting system, readi…

> Numerous cases of that.

Like when? Because I have interacted with projects where Lennart is part of the admin team and from where I stand it’s all in your head.

Both bugs and security are taken seriously.

> The above doesn't represent my personal opinion, it's a representation of what reasons people might have.

I admire the courage you display in standing for your opinion.

Re: Systemd 252

#162

Post by ciupicri »

gorgoiler wrote: post #65

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…

From the logind.conf man page [1]:

> KillUserProcesses=

> Takes a boolean argument. Configures whether the processes of a user should be killed when the user logs out. If true, the scope unit corresponding to the session and all processes inside that scope will be terminated. If false, the scope is "abandoned", see systemd.scope(5), and processes are not killed. Defaults to "no", but see the options KillOnlyUsers= and KillExcludeUsers= below.

> In addition to session processes, user process may run under the user manager unit user@.service. Depending on the linger settings, this may allow users to run processes independent of their login sessions. See the description of enable-linger in loginctl(1).

> Note that setting KillUserProcesses=yes will break tools like screen(1) and tmux(1), unless they are moved out of the session scope. See example in systemd-run(1).

[1]: https://www.freedesktop.org/software/systemd/man/logind.conf...

Re: Systemd 252

#163

Post by Xylakant »

blueflow wrote: post #116
biorach wrote: post #101

Earlier quoted context omitted.

were you able to install this without using sudo?

In the contest you had root access for a limited amount of time, but you can also do it via a user unit.

But then you should only get the users account as shell, so while this is a neat trick, being able to gain persistent root if you are already root is not that hard.

Re: Systemd 252

#164

Post by blueflow »

Xylakant wrote: post #163
blueflow wrote: post #116

Earlier quoted context omitted.

In the contest you had root access for a limited amount of time, but you can also do it via a user unit.

But then you should only get the users account as shell, so while this is a neat trick, being able to gain persistent root if you are already root is not that hard.

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.

Re: Systemd 252

#165

Post by dark-star »

gorgoiler wrote: post #65

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…

Wait, what French naming?

Re: Systemd 252

#166

Post by VLM »

stevefan1999 wrote: post #71

I just never get why people always flame on systemd. Sure, it's kinda bloated in the sense that it is "battery included" just like Python, but the intention to have a stable init with great system and service management is very good from both a DevOps and Sysadmin perspective. It is at least much better than writing your adhoc init.d script that may not guarantee to run on other Linux distros.

Systemd is a somewhat successful non-unix operating system, marketed to people who want a unix-like operating system using force. This isn't what anyone wants but you'll go along or they'll unleash a hell of sophistry about how this is "really" what everyone wants even if its the opposite, made up stories about the opponents, or only bad people don't want what we want and you don't want to be tagged as one of the bad people so you're gonna say you officially love systemd, correct?

It would be like going to the EV car dealership and being told the best modern EV they sell is a diesel pickup truck and they will unleash sophistry hell on anyone who doesn't go along with their meme that the best modern EV is obviously a diesel pickup truck but pointing that out in public is doubleplus ungood badthink.

Ironically, for a non-unix-like operating system, its not that bad and works some of the time, although not as well as a unix-like OS would work for someone who's engineering criteria is a unix-like OS. Most people would be technically better off with a unix-like OS than a systemd based OS, but thats not what the corporate marketing department is selling, so we all love systemd, uh huh.

Re: Systemd 252

#167

Post by cptnapalm »

stevefan1999 wrote: post #71

I just never get why people always flame on systemd. Sure, it's kinda bloated in the sense that it is "battery included" just like Python, but the intention to have a stable init with great system and service management is very good from both a DevOps and Sysadmin perspective. It is at least much better than writing your adhoc init.d script that may not guarantee to run on other Linux distros.

While systemd does have many good features, it also has failed to turn computers off on various systems and distros. I repeat: failed to turn computers off. This wouldn't be acceptable in beta quality software. But it's systemd and for whatever reason gets a free pass on failure to do incredibly basic things.

Re: Systemd 252

#168

Post by LeSaucy »

dsr_ wrote: post #145
captainmuon wrote: post #97

About removing support for what they call split-usr and unmerged-usr: Why does a init system and daemon manager even need suppport for a certain directory layout, shouldn't it be agnostic? Having a separate usr-space saved my bacon in the past a couple of times. The thing I dislike most about Systemd is that it leads to homogenisation, where to me, running Linux is about choice.

I believe that the end goal of systemd is to end Linux distributions as anything other than a flavor. This will not work completely, but it may work well enough that non-systemd linux will be considered an unusual eccentricity.

One could make the argument we are already there.

Re: Systemd 252

#169

Post by WastingMyTime89 »

kaba0 wrote: post #54
plaguepilled wrote: post #6

Earlier quoted context omitted.

I would say it really depends on the context! Some reasons systemd is bad: - Its a "big" for small docker containers (which is part of why a lot of people like Alpine Linux). - It produces binary logs, which might not work with your workflow and is a kind of vendor lock-in if you don't script a binary-to-text script. - the binaries are all a lot bigger in terms if SLOC and in terms of storage space than the solutions…

> It produces binary logs, which might not work with your workflow and is a kind of vendor lock-in if you don't script a binary-to-text script I never really understood this point — it’s not some proprietary format that has to be reverse engineered, you quite literally has both encrypt and decrypt source code available for every single version it has been released. You can also just pipe the binary output through the…

It’s even more difficult to understand when you consider than text files are themselves binary logs and given how many encoding they can have they are not even trivial ones.

People should just call systemd logs structured rather than binary because that’s what they are. Sure it means you need a shim if you want to view them as plain text but it’s not like we are talking about some unfathomable complexity here.

Re: Systemd 252

#170

Post by WastingMyTime89 »

denton-scratch wrote: post #157
panick21_ wrote: post #33

Earlier quoted context omitted.

You can easily have it not produce binary logs. Other software depending on Systemd isn't really Systemd responsibility. Its not systemd fault that almost nobody uses OpenRC.

> You can easily have it not produce binary logs. How do you do that? If you want non-binary logs, you can have journald tee log records to rsyslog; but the canonical log is still the binary log. Have I missed something?

What does canonical log even means here?

Systemd will produce logs in its own structured representation and write them straight away as plain text in the logger of your choice. For all intent and purpose, you now have text logs.

Post reply on HN