Become a fan of Slashdot on Facebook


Forgot your password?
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:Wait, let me get this straight... (Score 3, Funny) 54

I'm going to go downtown, park at the sturdy Bitcoin building, walk in past the colonades and marble lobby, right up to the sturdy oak desk of my local and well-respected Bitcoin representative and seek reassurance that his institution is sound, and that my deposits are safe, fully insured, and returning the advertised rate of interest.

Comment Re: Systemd! (Score 1) 364

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) 364

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) 364

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 Before anybody tries UBI I'd like to solve traps (Score 3, Insightful) 513

Before anybody tries UBI, I'd like to see trapless welfare. I don't know how bad this is in Canada, but the USA has a lot of "welfare traps". That's a situation where people remain on public assistance rather than work because their real income falls when they start working. We do so many stupid things such as labeling people "low income" and making them wait a long time for "low income housing". Then their "low income status" actually becomes an asset!

Fix that first, then get back to us.

Comment Re: Systemd! (Score 1) 364

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) 364

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

Nothing makes a person more productive than the last minute.