Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment Re: Systemd! (Score 1) 366

Dude, if like sjames you keep repeating that canard that Lennart 'keeps throwing bug reports back into your face', then I am fully warranted to assume you're just parroting talking points. Every case I've investigated it turned out that Lennart (or the other systemd team members) did no such thing. And simply repeating it makes you sound like a clueless hater. Don't do that if you don't want people to react with irritation. Stick to the facts.

And using systemd to manage user services instead of foisting it off to a dozen different desktop frameworks makes sense in principle. I just don't understand the interaction with system services as well as I should.

Lennart seems to "get" Unix just fine, the issue is that his solutions to its shortcomings are not to everyone's taste. The main problem I see, is that he is the only one actually doing the work to implement his solutions. It's not his fault most other people are happy to carp from the sidelines.

Comment Re: Systemd! (Score 1) 366

Look, SysV has worked for decades. It's creaky, but it works. If it has all the features you need, by all means stick to it. Clusters are usually a net of single-purpose machines, right? Because that would be a use case where systemd is overkill if you don't need its extra features.

As for the long-running jobs, I like the fact that by stowing them in their own scope they are recognisable as deliberately started long jobs, and not just badly-terminated processes. Thankfully I don't have to deal with end user jobs anymore, but I can see the design making sense.

The main problem I see right now is that systemd itself is mostly done, but people still have issues getting writing unit files right. Which results in weird startup issues occasionally. I managed to hang my laptop trying to add an autostarting emacs server to my user session. Which shouldn't influence system boot, IMO, but it did. I think I know what I did wrong, but I didn't have the time to really look at it. But that is a fair criticism: a badly written unit file can really mess up your service dependencies. But that is a hard problem to solve, and no other init mechanism has any decent solution either. Even SysV had ordering cycles.

Comment Re: Systemd! (Score 1) 366

With slices and scopes systemd directly interfaces with the cgroup mechanism in the kernel. The advantage is that with this mechanism you can fence off part of your session, or even a single process into its own environment, anything up to short of running it in a container (and then systemd can also manage containers). Resource usage can be limited on both the scope and the slice, and can be set for CPU, memory and I/O. The official documentation will provide more details.

We saw a part of that in the debate on the setting that kills all apps on session end. While I disagree with making that the default (at least for now), the idea that if you want something to keep running in the background you have to explicitly assign it to a background scope, so both the system and the sysadmin can see it's a background task and keep it constrained if necessary, is a good mechanism in my eyes.

I need that kind of fine-grained control in my work, and there are simply no alternatives that handle this as easily as systemd.

This, and event-based service handling is worth it for me. systemd feels a little overengineered to me, but since I haven't even seen half of what it cant do I am quite willing to entertain the thought that this is a mistaken impression on my side. Or it might be that it actually is overengineered.

It has faults; the event-based nature means that dependency cycles are hard to debug and can be frustrating; a number of units have timeouts that are far too long and make your system hang for ages if something goes wrong, and interrupting them is hard if not impossible. But I've dealt with SysV breakage too, professionally, and systemd's warts are certainly not worse.

So, it's not actually worse than SysV, and it brings some stuff to the table I like and need in daily work. And most of the objections are people blindly parroting echo chamber talk, and that is what pisses me off to no end: people pretending to be intelligent not being any better than Alex the Parrot.

Comment Re: Systemd! (Score 1) 366

But it is what you do. I merely like systemd better than SysV. If you characterise that as spreading empty hype and strongly advocating, that is a strawman of my position.

So unless you actually apologise and take that back, you can sod off. If you think insisting on the mere courtesy of a correct representation of my position is thin skin, then it is obvious you are not interested in facts and anything I say will be twisted to your position anyway.

In short, and redundantly: sod off.

Comment Re: Systemd! (Score 1) 366

Again, quote met where I am echoing empty hype. I was merely correcting your idiotic statement that hotplugging had nothing to do with servers, that's not echoing hype.

For the record: my use case for systemd is resource control, which it does a hell of a lot better than any of the alternatives, even if the interface is a bit too arcane to my tastes.

Comment Re: Systemd! (Score 1) 366

Yeah, you really are a fucking coward, aren't you? Quickly checking that box so you can sockpuppet your own thread.

As has been pointed out to you multiple times: Lennart was right, and Linus agrees. Using the overall debug variable was the correct way to go about it, and the real bug in systemd (overly verbose assertions) was acknowledged and fixed.

Slashdot Top Deals

Promising costs nothing, it's the delivering that kills you.

Working...