Exactly. It's not like backup certificate have validity starting at a future date.
1,024 karma · joined July 3, 2016
For electricity-to-heat conversion, heap pumps are indeed much more efficient relative to resistive heating, yes. About 4 times more efficient.
In absolute terms, though - that is still only 50% of "Carnot cycle" efficiency.
https://en.wikipedia.org/wiki/Coefficient_of_performance
Similarly, heat-to-electricity conversion is about 50% efficient in best case:
https://en.wikipedia.org/wiki/Thermal_efficiency
So, in your scenario (heat->electricity conversion, then transmission, then electricity->heat conversion), overall efficiency is going to be 50% * 50% = 25%, assuming no transmission losses and state-of-art conversion on both ends.
25% efficiency (a.k.a. 75% losses) is pretty generous budget to work with. I guess one can cover a small town or a city's district with heat pipes and come on top in terms of efficiency.
But going with larger structures probably means aggregation (fewer of them are built, and further apart). Assuming homes to be heated are staying where they are, that requires longer pipes. Which are harder to insulate. Because geometry.
Isn't that the unfortunate status quo? At least hard requirement for JS, that is.
Google's homepage started requiring this recently. Linux kernel's git, openwrt, esp32.com, and many many others now require it too, via dreaded "Making sure you're not a bot" thing:
https://news.ycombinator.com/item?id=44962529
If anything, github is (thankfully) behind the curve here - at least some basics do work without JS.
Memory/RAM. See also:
Processing was/is graphics-centered, so that's where Arduino's term "sketch" come from, if you ever wondered.
https://en.wikipedia.org/wiki/File:Processing_screen_shot.pn...
...except current peak in demand is mostly driven by build-out of AI capacity.
Both inference and training workloads are often bottlenecked on RAM speed, and trying to shoehorn older/slower memory tech there would require non-trivial amount of R&D to go into widening memory bus on CPU/GPU/NPUs, which is unlikely to happen - those are in very high demand already.
That being said, system designer might choose higher cut-off point, since:
1) charge/discharge curve is S-shaped. There is very little energy in that last few millivolts;
2) battery (protection) circuit, and/or battery itself probably have some small leakage current. However minuscule, over months/years on a shelf, even some nano-amps of leakage will add up. If you want device to survive that, you have to factor this in, so that rest cell voltage still stays above safety threshold even after storage.
Also, "Li-ion" is quite a wide category. Don't use arbitrary voltage as a fast rule. Look up datasheet, or characterize actual cell you use. For some[2], disconnecting at 3.6V would mean leaving 50% of capacity unused. For other[3], that would be a reasonable, if somewhat conservative threshold.
[1] https://docs.rs-online.com/080b/A700000007848112.pdf
[2] https://www.murata.com/-/media/webrenewal/products/batteries...
[3] https://ntrs.nasa.gov/api/citations/20140005830/downloads/20... (page 4)
Netfilter is plenty fast, when configured sensibly. You'd probably want script to populate a "hash:net" ipset instead, and have just one iptables rule:
-A INPUT \
-m set --match-set geoblock \
-j DROP
That estimate is way to high. More like 90 eurocents (~$1) for the whole thing, assembled. That's retail price:
Ubuntu 25.10's rust "coreutils" multicall binary: 10828088 bytes on disk, 7396 KB in RAM while doing "sleep".
Alpine 3.22's GNU "coreutils" multicall binary: 1057280 bytes on disk, 2320 KB in RAM while doing "sleep".
And size. About 10x increase both on disk and in memory
$ stat -c '%s %n' {/opt/fil,}/bin/bash
15299472 /opt/fil/bin/bash
1446024 /bin/bash
$ ps -eo rss,cmd | grep /bash
34772 /opt/fil/bin/bash
4256 /bin/bashI guess GP meant "containers" broadly, including things like pipx, venv, or uv. Those are, effectively, required since PEP 668:
https://stackoverflow.com/questions/75608323/how-do-i-solve-...
RGMII uses 4-bit bus, so that would be 250M state transitions per second.
Clock signal is 125MHz, yes. But data is sent/sampled at both edges (DDR), so PIO state machine has to be clocked at 250MHz.
That's still reachable with mild overclocking, I guess?
There are some heady boundary-layer effects and temperature/temp-conductivity gradient physics involved here. For simplicity sake, consider a plastic [1] bag full to the brim with water, held over open flame. Will bag melt (oxidize, erode)?
[1] polyethylene melts around 120-ish °C and ignites around 220-350 °C (sources vary)
Or you mean it'll catch fire? Also not a concern. That is supposed to happen at a temperature well above anything useful for cooking.
rw,nosuid,nodev,noexec,size=5120kBut you're right - if dataset is exhaustive and finite, and model is large enough to preserve it perfectly - such overfitted model would work just fine, even if it's unlikely to be a particularly efficient way to build it.
Also, most 1Gbit/s and faster routers have hardware-accelerated packet forwarding, aka "flow offloading", aka "hardware NAT", where forwarded packets mostly don't touch software at all.
Some routers even have internal "CPU" port of packet core with significantly slower line rate than that of external ports'. So traffic that terminates/originates at the router is necessarily quite a bit slower, regardless of possibly extra-beefy processor, and efficient software. Not really a problem since that traffic would normally be limited to UI, software updates, ARP/NDP/DHCP, and occasional first packet of a forwarded network connection.
By the way, delving into obscure and hardware-specific kernel code, sometimes yields quite interesting generally-applicable problems. For example, @dougg3 did an (excellent!) series of articles about his work on bringing mainline kernel support to "Chumby 8", a somewhat obscure, but historically significant piece of hardware, and as a side-quest he stumbled into this:
https://www.downtowndougbrown.com/2024/04/why-is-my-cpu-usag...
...which is applicable to quite a few other machines.
A lot other servers will not play ball here. Your self-hosted mail server, if it lacks IPv4, will not get inbound from mailgun, mailjet, github; neither will it be able to send outbound to cisco/iphmx, as well as about 90% of small servers from what I see in my logs.
Better yet! (one-line) shell prompt is always available and has some nifty integrations via <Ctrl+X>. For example, one has a bunch of files visually tagged (selected) on current panel, and wants to tar them up as "/tmp/foo.tgz". Well...
tar czf /tmp/foo.tgz <Ctrl+X><T>But don't brush off "special status" of NPM here. It is unique in that JS being language of both front-end and back-end, it is much easier for the crooks to sneak in malware that will end up running in visitor's browser and affect them directly. And that makes it a uniquely more attractive target.
Surely, open firmware could skip that and boot faster - if vendor would allow an escape hatch from the "secure boot" hell. But why would they expend effort on something 99.9% of users don't care about, and give up free ads in the process, too?
apt install musl