Live data from Hacker News

Systemd, 10 years later (2020)

blog.darknedgy.net

181–190 of 332 posts

Re: Systemd, 10 years later (2020)

#181
post #12

Earlier quoted context omitted.

it's kind of like locked bootloaders and pentalobe screwdrivers for organizing a unix system where most users were used to easy to inspect and modify scripts and single purpose programs . yes, it's still open source, but modifications and inspection are far more complicated creating a much higher barrier to entry. in the earlier days when it was still buggy, even linus himself was screaming about not being able to ea…

I have to hard disagree on this one. As someone who had half a foot in sysvinit, half in upstart, and half in systemd (don't try to do math with those numbers), sysvinit was always the hardest to use by wide margin. It was ridiculously complicated to get anything nontrivial to work. It was error prone, and the number of corner cases you had to think about was extreme. And the worst part was I kept having to relearn i…

[deleted]

Re: Systemd, 10 years later (2020)

#182
post #169

Earlier quoted context omitted.

And that is probably the motivation for this design philosophy of limiting options that Redhat and Freedesktop champion where more and more, simple, clean, turing complete solutions are replaced by a discrete list of simple options. But it does not change at all why I dislike it, and why I am annoyed by Freedesktop's pushing and insistence that many keep to these more custoizable solutions supposedly simply because t…

You have a misunderstanding of what Freedesktop is. Freedesktop is just a group of desktop developers that submit standards to each other, they don't really dictate anything. For that reason it tends to self-select for developers who are actively working on desktop environments, and the standards that tend to get submitted there are things that already have some level of adoption among open source desktops. You too c…

In theory it is that; in practice it has become a different face of Redhat because it's mostly Redhat developers that submit these standards there and the body is known to have a certain philosophy that is indeed exemplified by systemd.

They aren't particularly keen on hacking in how they design their software and standards and talking with them is frustrating to say the least.

Re: Systemd, 10 years later (2020)

#183
post #143

10 years and I still can't figure out how to view custom service logs, darn, so I redirect them into a logfile.txt in my .service files. Well, okay. I don't care how it works and didn't take part in condemning it back then either, and I think that probably it made something better (? not that I felt it), but from a pure sudo-user perspective it is a strange ini-based tech-ridden(?) launcher to me. I've managed small…

> 10 years and I still can't figure out how to view custom service logs

  journalctl -u custom-daemon.service
(you can usually leave out the ".service", but it helps disambiguate when you have different unit types under the same name)

Re: Systemd, 10 years later (2020)

#184
post #33

Earlier quoted context omitted.

On HN, reposts only count as dupes if the story has had significant attention in the last year or so. This is in the FAQ: https://news.ycombinator.com/newsfaq.html . (but also, it's true, people tend not to use HN search before posting)

Maybe there could be an auto search with a warning when posting a link? Saying "hey this has already been posted" and a summary of those rules. But you have probably thought of this already and didn't do it for a good reason. In this case I hadn't seen it before so it was news to me.

Trying to post a dupe often results in nothing being posted and the original submission being opened instead. I have no idea how accurate the thing that checks for dupes is, though, or on what criteria its decision is based.

Re: Systemd, 10 years later (2020)

#185
post #169

Earlier quoted context omitted.

You have a misunderstanding of what Freedesktop is. Freedesktop is just a group of desktop developers that submit standards to each other, they don't really dictate anything. For that reason it tends to self-select for developers who are actively working on desktop environments, and the standards that tend to get submitted there are things that already have some level of adoption among open source desktops. You too c…

In theory it is that; in practice it has become a different face of Redhat because it's mostly Redhat developers that submit these standards there and the body is known to have a certain philosophy that is indeed exemplified by systemd. They aren't particularly keen on hacking in how they design their software and standards and talking with them is frustrating to say the least.

I can't understand what you're talking about, I'm looking through the list of specifications and I don't see anything specific to Red Hat or systemd. I also see a lot of other names besides Red Hat people: https://specifications.freedesktop.org/

If Red Hat engineers submit something there it's because they think it's useful to the other desktop projects. It's just a collaborative space to put specs. If you have a spec of your own you can just create a new RFC. You don't need to persuade them to change how they design theirs, unless you intend to start working at Red Hat and start maintaining some of their software for them.

Re: Systemd, 10 years later (2020)

#186
I never became comfortable with neither the scope of systemd as a project, nor the ever expanding set of skills required to effectively use it. I was tempted to use the word mastering, but that would make the goal seem even more elusive, especially since with every new version one's knowledge would have to expand to cover its new features. 10 years later, it still looks to me like the project with a solution for everything in the IT industry, following trends, trying to cover all the bases. Always new things to learn, always the goalpost moving further and further.

Re: Systemd, 10 years later (2020)

#187
post #12

Earlier quoted context omitted.

it's kind of like locked bootloaders and pentalobe screwdrivers for organizing a unix system where most users were used to easy to inspect and modify scripts and single purpose programs . yes, it's still open source, but modifications and inspection are far more complicated creating a much higher barrier to entry. in the earlier days when it was still buggy, even linus himself was screaming about not being able to ea…

Right. I have a simple rule: don’t use a GNU/Linux system that uses systemd. It doesn’t respect the Unix philosophy. It’s trying to turn it into Windows. I’m waiting for Microsoft to buy Red Hat. Failing that, IBM.

I've been using various unices for thirty years this year. I have no respect for the 'unix philosophy'.

Re: Systemd, 10 years later (2020)

#188

Earlier quoted context omitted.

Maybe there could be an auto search with a warning when posting a link? Saying "hey this has already been posted" and a summary of those rules. But you have probably thought of this already and didn't do it for a good reason. In this case I hadn't seen it before so it was news to me.

Trying to post a dupe often results in nothing being posted and the original submission being opened instead. I have no idea how accurate the thing that checks for dupes is, though, or on what criteria its decision is based.

Oh ok I've only ever posted questions. I just assumed it didn't because I have seen a lot of dupes (also recent ones).

But I guess making it too wide would create false positives.

Re: Systemd, 10 years later (2020)

#189

Earlier quoted context omitted.

It reads like an over-eager developer read Design Patterns and then was tasked with writing a new init system for Linux.

I think the whole problem with systemd wasn't just about technology. The results were spectacular. Before systemd normal Linux boot times were well over a minute. After switching you could get below 10 seconds on the same hardware. And that is just one aspect. I think the core of the problem was somewhere between the style of introducing changes and the way how people communicated. After all, it speaks for itself tha…

SystemV init allows for init scripts to run in parallel, but that was rarely used. Most time spent was anyhow waiting for network (e.g. the MTA trying to resolve the hostname) and hardware initialization. Bourne shell isn't particularly fast, but ten years ago hardware used for typical Linux desktop/server systems was fast enough that it hardly mattered (it's used here for sequentially starting system processes, not number crunching). Not that it matters -- how often do you boot a desktop/server in a day? Performance mattered for VMs deployed in the cloud on request, but whether a full OS is the best choice for such services is a different topic ...

Re: Systemd, 10 years later (2020)

#190
post #20
post #2

It's not as bad as at first feared. Views here are along the usual lines; for many when there's an issue either it's something that's fixable inhouse (init scripts) or needs a support contract. Having said that, personally (old school) I lost 2 or 3 hours yesterday due to not realising systemd was changing things I changed for a reason.

>I lost 2 or 3 hours yesterday due to not realising systemd was changing things I changed for a reason. This is one of my go-to reasons when people ask me why systemd is bad. Once it overrode power settings I had configured in xfce-power-manager. Mainly I wanted the lid close to do nothing on AC power and to sleep on battery. It started sleeping for everything after an update once. I think in the end I couldn't figur…

I'm curious...what happened with the override or how did systemd modify its unit files?

Is it something like a forgiving parser going rogue in an edge case?

The only thing I could think of is a systemd default setting that was added to logind.conf or something similar...that's why I'm asking.

Post reply on HN