throw0101c
As someone in HPC: people never delete stuff. It can stick around forever, and so if more bits are generated, there are more bits that people don't want to delete "just in case". Depending on the organization, quota enforcement can be tighter or looser.
HSM is fairly popular in the HPC space for this reason:
* https://en.wikipedia.org/wiki/Hierarchical_storage_managemen...
Your newest/hottest bits are on NVMe, anything older than (e.g.) 3 months gets move to SSD, anything older than that to spinning rust HDDs, and then to tape.
There are several file systems where this happens in the background: the file still shows up at /path/for/stuff/foo.txt but the contents are shuffled about behind the scenes.
The drives are a fairly fixed CapEx: once they're purchased they don't cost must/anything to run. You may replace them every few years with newer tech for higher capacities of course.
Libraries last even longer, and can stick around for a decade or more once purchased.
One difference: the longer your money is in a casino, the more likely you are to lose it; while the longer your money is in the stock market (especially in a total market index fund), the more likely you are to win:
* https://awealthofcommonsense.com/2023/05/the-stock-market-is...
After five years, you're up 90% of the time. Buy and hold for fifteen years, and you're up 100% of the time.
In a casino the house generally wins eventually, in the stock market you do.
This brings to mind a recent article from a Toronto newspaper: we recently had municipal elections, and the article noted that most city councillors are home/land owners, but in the new council there are now a few renters as well:
> With the election victory Monday night that saw her become the councillor for Parkdale—High Park, the longtime tenant advocate has taken one giant step toward altering the economic makeup of city hall. Before the election, Toronto had no councillors confirmed to be a renter like McNally, and now it will have three. She told the Star she wanted to bring that perspective to the fight against Toronto’s affordability crisis.
* https://www.thestar.com/news/gta/city-hall/half-of-toronto-r...
I like Michael Pollan's advice from 200:
* https://en.wikipedia.org/wiki/In_Defense_of_Food
When shopping for food try to stick to the edges of the store and avoid the middle aisles with the 'shelf stable' products; look at ingredient lists and lean towards things that have (~)five or fewer listed; if there are a bunch of ingredients / chemicals with terms you cannot pronounce it's probably not that great.
A couple more Middle East wars from Republicans and the resulting gas prices will help push electrification forward. semi-/s
Ubuntu managed to release the updated 26LTS kernel on October 28, but the other LTSes have been sitting around since 26 or 28, so I'm wondering why they haven't been moved to "security" or "updates" in the several days since.
Especially since their page on it mentions October 15
* https://ubuntu.com/security/CVE-2026-98432
and Debian released a couple of weeks ago.
The versions are mentioned in this page:
* https://ubuntu.com/security/CVE-2026-98432
I'm wondering if the CVE in question is not mentioned because it was embargoed so they did not want to accidentally leak things while the kernel went through the (public?) QA workflow. Perhaps the Changelog will be amended at some point to have the CVE?
Which only came out a few months ago, and which only recently released its .1, so the do-release-upgrade message only recently appeared for most people.
I'd be interested to know how many folks have changed their current production over to 26TLS in the last six months. I'm guessing not a lot.
So yes, there is a newer LTS, but what is its current market share as compared to 24 TLS (or even 22LTS)?
Ubuntu releases its LTSes in even years, and Debian does its releases in odd years:
* https://en.wikipedia.org/wiki/Debian_release_version_history...
And Ubuntu 24.04 LTS is using 6.8.
Ubuntu releases a new version every six months, but an LTS — which is probably what most people run in production — only every two years. Debian releases come out every two years.
So if you only run Ubuntu LTS, the release cadence is the same as Debian.
* https://launchpad.net/ubuntu/+source/linux
You can pull them down with a "-t" added to your apt-get (but will not appear by default).
26LTS had the new kernel go to the updates/security repos on October 28.
Until it becomes harder, or even impossible, to root the hardware, as even the guide states:
> DO NOT UPDATE TO WebOS 26 firmware released after 2026-10-10 like 43.21.84 (see the firmware list). Public root method got patched and this firmware currently cannot be rooted. If you will connect your TV to the internet to root it, first turn off autoupdate.
* https://tv.slada.sk/guides/rooting-guide
So if people continue to buy 'subsidized' TVs, companies will continue to produce them.
There needs to be an unsubsidized-by-ads option and people need to purchase it to show The Market™ that there exists demand for such a product. But the problem seems to be that all the current offerings are ads-based.
It's not about "what 'normal' humans want", it's about what can even be built.
It's currently hard to build decentralized anything now, and it'd be nice to open things up to see what creative things (if any) people could come up with if the network allowed for more peer-to-peer connections.
Construction: "two-bys" are used, with 16/19.2/24" offsets for studs and such (though the building code has millimetre equivalents).
IPv6 solves this by making it easy for everyone to get their own 200::/3 address so that when two companies get together they have completely different /48s (or whatever).
> […] but then the same could be said of IPv4 where adding entropy to 10.X.X.0 is the usual recommended way of doing things.
There has never been a recommendation to add entropy to 10/8 addresses. At least I have never heard of such a thing. Can you provide a citation for this (alleged) recommendation? Is there an RFC of some kind?
CGNAT works for you? Do you play video games at all? Because there are all sorts of people for which it doesn't.
The fact that you may be fortunate enough to get a publicly-accessible IPv4 address on your WAN interface does not mean everyone else is. This type of attitude seems to be akin to "I gots mine."
Because just about all applications are currently architected in such a manner.
When Skype first came out many moons ago it allowed peer-to-peer connections with clients, but a lot of clients were behind NAT (especially ones that could not do PCP or UPnP), so Skype had to come up with the notion of "super nodes" that could do relaying.
Protocols like STUN/TURN/ICE/etc had to be developed to deal with all of this blocking of traffic.
If clients could know their 'real' addresses and allow things like PCP (which is often needed for (e.g.) video games), then perhaps there could me less strictly consuming and more collaborating.
There is no easy way to transition from IPv4 to any kind of IPng; see my other comment:
Unless there's a merger/acquisition and the two companies both use 10.0.0.0.
Most home networks use 192.168, and so you can't use that in corporate environments, because the WFH people who VPN in could then have routing snags between local and remote locations.
Also, in your VPN software be sure to perhaps not use 172 addresses (like my previous job did), as some of those ranges are used by Docker by default, and so you can cause issues for developers.
But other than that IPv4 RFC 1918 is not complicated at all…
* https://en.wikipedia.org/wiki/Metrication_in_Australia
It's going to take decades, mostly waiting for the non-metric folks to die off probably and the raised-on-metric folks to grow up, but if you don't start you'll never finish.
† Can Aussie HNer confirm?
The protocol chosen for IPng, SIPP, did actually have "only" 64 bits, but this was deemed not enough as folks did not want to have to worry about running out again (amongst other reasons), and so tweaked it to have a fixed 128 bits:
* https://datatracker.ietf.org/doc/html/rfc1752
SIPP originally was variable-length capable, but it was decided fixed-length was better (e.g., for hardware like ASICs).
> Wouldn't have been a problem if they hadn't given every square millimeter of the planet 100 billion addresses.
For the record: IPv6 gives 10¹⁷ addresses per mm²; in terms of volume, 10⁸ IPv6 addresses per mm³ throughout the Earth.
Google sees 70-80% from some countries:
* https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...
Or octal:
* https://networkingtoolbox.net/ip-address-convertor/represent...
On the surface of the Earth [land+water], there are 8.4 IPv4 addresses per km². Not counting the oceans, that would be 28 IPv4 addresses per km² land.
IPv6 gives 10¹⁷ addresses per mm² (yes, square millimetre).
In terms of volume, 10⁸ IPv6 addresses per mm³ throughout the Earth.
A second way of thinking about it:
* Stars in the Milky Way: 400 Billion
* Galaxies in the universe: 2 Trillion
* So (4x10¹¹)x(2x10¹²) = 8x10²³ stars in the universe.
* Size of IPv6 address space: 3.4x10³⁸
* Find the ratio between addresses and stars: 3.4x10³⁸ / 8x10²³
IPv6 offers about 430 trillion times more addresses than estimated stars in the universe. From Tom Coffee's presentation "An Enterprise IPv6 Address Planning Case-Study":
As does DNS.
"A" records are fixed at 32 bits, so you have to add a new record type and update all DNS software, plus user-space API/library code and data structures to ask for and store the new record type.
Just like IPv6.
There is no "just" adding more addresses: whatever scheme anyone comes up with is the same amount of work as IPv6.
There is no "just" extending the address length:
So it's a matter of mathematical and physical fact that to expand
the address size, you must change the protocol, and that means
[three] things immediately:
You have to change the version number.
You have to add new code to handle the new version.
[…]
You need a coexistence technique so that updated systems,
with the new protocol, can connect to old systems that know
nothing of the new protocol.
Two minutes of thought show that this third requirement has only
two solutions:
(3A) Dual stack, in which the new machines speak both
the old (IPv4) and new (IPng) protocol.
(3B) Translation, in which something translates addresses
between the old and new protocols.
* https://datatracker.ietf.org/doc/html/rfc1671
> Keeps all the nice parts of IPv4, doesn’t require everyone to switch to an entirely new system, backwards compatible with existing hardware/software. Problem solved.
You have to ship new code to every 'network element' to support your "IPv4+" plan. Just like with IPv6.
You also have to update DNS to create new resource record types ("A" is hard-coded to 32-bits) to support the new longer addresses, and have all user-land code start asking for, using, and understanding the new record replies. Just like with IPv6. (A lot of legacy code did not have room in data structures for multiple reply types: sure you'd get the "A" but unless you updated the code to get the "A+" address (for "IPv4+" addresses) you could never get to the longer with address… just like IPv6 needed code updates to recognize AAAA, otherwise you were A-only.)
You need to update socket APIs to hold new data structures for longer addresses so your app can tell the kernel to send packets to the new addresses. Just like with IPv6. In any 'address extension' plan the legacy code cannot use the new address space; you have to:
* update the IP stack (like with IPv6)
* tell applications about new DNS records (like IPv6)
* set up translation layers for legacy-only code that cannot be update to reach IPv4+-only destination (like IPv6 with DNS64/NAT64, CLAT, etc)
You're updating the exact same code paths in both the "IPv4+" and IPv6 scenarios: dual-stack, DNS, socket address structures, dealing with legacy-only code that is never touched to deal with the larger address space.
"Just adding more bits" means updating a whole bunch of code (routers, firewalls, DNS, APIs, userland, etc) to handle the new data structures. There is no "just": it's the same work for IPv6 as with any other idea.
Creating an IPng was always going to be complicated:
So it's a matter of mathematical and physical fact that to expand
the address size, you must change the protocol, and that means
[three] things immediately:
You have to change the version number.
You have to add new code to handle the new version.
[…]
You need a coexistence technique so that updated systems,
with the new protocol, can connect to old systems that know
nothing of the new protocol.
Two minutes of thought show that this third requirement has only
two solutions:
(3A) Dual stack, in which the new machines speak both
the old (IPv4) and new (IPng) protocol.
(3B) Translation, in which something translates addresses
between the old and new protocols.
* https://datatracker.ietf.org/doc/html/rfc1671
For anyone curious as to the decision-making process, here are the criteria for what the IETF was looking for in an IPng:
* https://datatracker.ietf.org/doc/html/rfc1726
Here are the candidates that were floating around at the time, and the reason why the winner was chosen:
How many Chrome tabs do you have open?