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.
Plus - the medical ones are horrible to use with an iPhone - barely enough volume for watching media - and music has absolutely no bass... (plus, they regularly "forget" their bluetooth sync connections...)
Money is an artifice used to track the payment of taxes. It happens to be useful for tracking other kinds of scarcity, especially with people you do not know, so societies in which the use of money is imposed tend to move the rest of their economic relationships over to it. In other words, Bitcoin is not valuable because it is scarce, it is valuable because you can pay data ransoms to cybercriminals with it. If, tomorrow, every ransomware vendor demanded payment in POGS or Beanie Babies, you'd see the value of those skyrocket as every IT professional went and hoarded them.
Satoshi Nakamoto saw the state, with it's coercive taxation and central banking, and thought the answer was to make decentralized money you couldn't shut down. Hence, Bitcoin and it's millions of forks. The problem is that Bitcoin's valuations are based on the same coercive taxation, just carried out by the illegitimate criminal underworld rather than the legitimate state. That's not liberty, that's just changing who wears the jackboots.
That is an interesting perspective, but it doesn't actually change my point, which is that if you want to build a distributed system that cannot be shut down, you have to be willing to collaborate with distributed system that cannot be shut down enjoyers.
Libertarians call themselves that, that doesn't mean that they're inherently the primary defenders of liberty.
Much like how the difference between Republicans and Democrats aren't an argument over whether the United States is better run as a Republic or a Democracy.
No memeing necessary - most vocal and visible (eg mainstream or platformed) libertarians are…a lot, and not in a good way. I’m sure it’s very similar in nuance to democrat and republican - the faces and voices in the media aren’t necessarily representative of the average people who use the same labels.
>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.
Yes, in that scenario of 500ms of 200% CPU for a request / response type workload, 50% of responses will have an extra 25ms response time tacked on as the system is sleeping during the remaining portion of each scheduling period.
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.
If you mention tab-completing, if starting with the detailest component it wonʼt work at all because of context search problems. If you press something like "alice<Tab>", in deepest-first order it will have to search the whole tree which could contain millions of entities. Worse than, some subtrees may be dynamically loaded during the completion request.
To mitigate senseless tree top listing, IDEs propose a bunch of means like context-related hints or unpacking forms like "o.e.t" to "org.example.test".
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.
I’m clowning because OP seems to be mostly dedicated to whining.
To your point, the original post requested information specific to European standards where AC is not common. I don't care to spend time solving internet stranger’s problems but Minergie would be a good place to start because they presumably didn’t fabricate their standards. A curious, motivated person could track down whatever they’ve published, which is most likely in German.
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.
I've visited the App Store world, and my experience was that, weighted by how often packages appear in search results, the median is charitably described as "potentially unwanted", and honestly described as malware.
