Please create an account to participate in the Slashdot moderation system

 



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:This is retarded conservatism to help 'coal' (Score 1) 465

You're right, you said "super capacitor plates" which is not entirely the same thing, but the same principle still applies: For high tech applications, purity is critical, and mineral coal is not pure.

Do you ever abstain from trying to torpedo a discussion you're losing by calling the other person a retard?
=Smidge=

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:This is retarded conservatism to help 'coal' (Score 1) 465

Yes, they CAN do it, but there is no reason to do it.

And mineral coal is not that "close" - it contains a lot of impurities (eg heavy metals, sulfur) which makes it unsuitable for water filtration and battery electrodes in your list of examples.

We don't need coal anymore. When - not if - all the coal is gone, we have it covered.
=Smidge=

Comment Re:This is retarded conservatism to help 'coal' (Score 2) 465

Activated CHARcoal, which is not made from mined coal but from organic matter than is run through a gassifier to remove all the volatile compounds and leave the carbon.

You do not need mineral coal for this. There are vanishingly few things that require mineral coal these days.
=Smidge=

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 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.

Slashdot Top Deals

A list is only as strong as its weakest link. -- Don Knuth

Working...