mfukar

Sure, but what you're claiming is that air bags are missing based on never having seen them operate.

I don't make policy. Policy, however, involves risk management. If deficient plants have been operated successfully for this long, the implication to me is that their operators have proven responsible enough to handle it.

I'm not sure what that means. Are you pointing out a severe deficiency that makes their whole operational record somehow moot?

That would be getting causality backwards.

It's alarmist criticism of politics, and not of actual fact. It'd be difficult to find a single study supporting the headline with facts.

> FWIW I think nuclear is good in principle, but neither states nor companies have proven responsible enough to handle it.

So the currently operating nuclear plants that have gone without incident are dismissed? Why so?

> Also, proprietary desktop software is still usually "protected" by just a serial number :D

Not really; there's a lot of sophisticated DRM going around at least since the 70's..

I have a family of 6. I often divide a cake by 6. If my number system makes it more convenient to divide by 8, that doesn't really change my workload.

The article is completely irrelevant to floating-point math. I guess even Scientific American has to attract clicks.

I don't think it's as subtle as it is incoherent. I've yet to see a single article putting together the harm of DRM in terms tangible to a layman.

> download to your own heart's content in the safety of your own home

Nein.

The only thing? What about computer software?

Maybe you meant to type 'the only thing I care about'.

What constitutes the "low-hanging fruit" changes constantly. I suspect that trying to quantify them at any given point in time is as infeasible as it is useless.

The answers to the question "what is there to gain?" are fairly obvious, don't you think?

That's a naive solution to a tiny problem.

Those problems are already solved by async I/O in platforms other than Linux.

So a scenario where the key is long-lived, but the process communicating is transient? I suppose that makes sense, although I struggle to imagine the use case.

In what scenario is it an advantage to be able to encrypt/decrypt data with a certain key, but not know the key directly?

So...maybe...consolidate the process of executing hundreds of little things?

How tiny do the steps in this thought process need to be? We can go on all night.

I can't help but think if a one-time initialisation cost is bogging a process down, there are bigger problems than that initialisation cost.

My naive first reaction would be: because something up the stack is Linux-specific (or X-, or Y-specific).

It's not exactly consistent. Different rows for different services (sometimes different for the same type of units), an inconsistent amount of logs included (maybe), the status is not reported consistently, whatever. It's mildly helpful for visual inspection, and that's it.

systemd has a few nice ideas, and it might be alright for whatever your use case is. I'm working on a product which uses it as its init system, and it's an endless source of problems. Its flaws are deep and unfortunately pervasive.

The dirty secret in software development: most think they write efficient software, but very few know what to compare it to and how.

Some would even argue that you can't meaningfully criticise a system without experience in it.

Why would it? The parent comment had already pointed out Andrea's fix.

It's 2017 and we still don't have a single decent bitmap terminal.

I don't track people (any longer) and I don't check their DNT preference. Shame is not an incentive for me - or any website code - to do so.

We should have moved away from privacy-theater by now.

> I can see how it fills a gap

What gap is that? I can't see anything I wouldn't find in existing tools.

If all it offers is a prettifier, I'd rather it were just that.

Good question - sounds like you have a paper to write.