HN user

Vegemeister

25 karma
Posts0
Comments19
View on HN
No posts found.

Stop trying to blame capitalism for your failure to jump out of the pot when they put ads in Windows 8.

We very much do have options. I haven't had Windows on a personal machine since 2011.

A set of airpods + the Minimum Viable iPhone to configure the them to work as hearing aids is way cheaper than standalone hearing aids. Regulatory fetishism around "medical devices" is exactly what enabled hearing aids to become a racket and to remain one long after the relevant electronics became a mass-produced consumer product.

For example, your average CPU might look fine at 50%, but in truth you're using 200% for 500ms followed by 0% for 500ms, and when CPU is scarce your latency unexpectedly doubles.

That is exactly the behavior that cgroups' cpu.max has, except it'd have to be 50 ms instead of 500 with the default period.

The problem with cpu.max is that people want a "50%" CPU limit to make the kernel force-idle your threads in the same timeslice size you'd get with something else competing for the other 50% of the CPU, but that is not actually what cpu.max does. Perhaps that is what it should do, but unfortunately, the `echo $maxruntime_ns $period_ns >cpu.max` thing is UAPI. Although, I don't know if anyone would complain if one day the kernel started interpreting that as a rational fraction and ignoring the absolute values of the numbers.

This makes me really want to write a program that RDTSCs in a loop into an array, and then autocorr(diff()) the result. That'd probably expose all kinds of interesting things about scheduler timeslices, frequency scaling, and TSC granularity.

reverse-domain name

Why do people keep replicating this terrible design decision? It puts the lowest-entropy part of the name at the beginning, so that you have to parse (or type) the maximum number of characters before you get a unique specification. Try tab-completing a "flatpak run" command sometime.

I think it kind of has to do with kubernetes, in that kubernetes embeds assumptions in its design and UI about the existence of a kernel capability which is almost, but not quite, entirely unlike the cpu.max cgroup knob, and then tries to use cpu.max anyway. Leaving CPUs idle when threads are runnable is not normally a desirable thing for a scheduler to do, CPU usage is not measured in "number of cores", and a concurrency limit is about the least-energy-efficient way to pretend you have a slower chip than you really do.

There is a reason these particular users keep stepping on the same rake.

cpu.uclamp.max is a little closer to the mental model k8s is teaching people, but it violates the usage=n_cores model too, and most servers are using the performance governor anyway.

Clown if you want, but he's absolutely right. There is exactly one sentence in that entire damn thing that comes close to touching on the question of why ventilation is desirable, and it is:

Pleasant, healthy air to breathe is the most important food for human beings.

Seeing as "(leaky and scrapped) refrigerators are damaging the upper atmosphere, allowing ionizing UV to reach the ground and cancering the everyone," actually happened and AFAIK is disputed by almost nobody, it's not that implausible. Hormones in milk is more plausible still because hormones are known to do that kind of thing, but the main knock against the refrigerator idea is that we already have fairly strong protections against leaky fridges because of the ozone.

IIRC the issue is with cultures that leave rice out on the counter at room temperature, because of historical inertia from per-refrigeration times. In that case, it does support life like anything else moist and pH neutral.

But there is no problem if you follow good food safety practices -- everybody puts the lid back on the pot after they've served themselves, and any leftover goes in the fridge within 4 hours of cooking.

Only one measly paragraph on the obvious improvement, eliminating the microwaves. Instead, launch independent steerable mirror satellites of the most economically efficient size, and point them at the highest bidder.

No heavy transmitters or PV cells. No new ground-based infrastructure that has to be built before you can do anything useful.

Is there a way to do file-level encryption without leaking the number of files and their sizes? Because that seems much worse than any known problem with block-level encryption.

Meanwhile, the rich, in search of a more varied diet, bought, stole, wheedled, robbed, taxed, and ran off with appealing plants and animals, foodstuffs, and culinary techniques from wherever they could find them.

Yup, that's Jacobin!