The Linux kernel is another example. The 2.5 development cycle (which led to the stable 2.6 series) was brutally long, and distros resorted to back-porting new features into their own kernels based on the stable 2.4 series that they provided to their users, creating all kinds of excitement. After 2.6.0 was released, Linus basically went nope, not gonna do that again.
And this is why I prefer a "hybrid" version scheme between CalVer & SemVer: A series number to allow LTS releases, a period, a hyphenated datestamp, optional "flag" letters "B" for breaking changes, "S" for security fixes, "F" for new features (more than one can be present, always in that order), and if more than one release is made on the same day the second & subsequent releases get a period followed by a release number starting from 1.
E.g. 3.2026-05-01FS for a first release of the day with a new feature & security fix to release series 3, 2.2026-05-01S backporting the security fix to release series 2 (LTS, say), 3.2026-05-02 for a "bug fixes & performance improvements" release, 3.2026-05-02S.1 for a security fix to the "bug fixes & performance improvements" release.
Like SemVer, this lets users know when there are breaking changes to an API or such, which releases contain security fixes, which releases have new features, and allows multiple simultaneous release versions for LTS support. Like CalVer it lets users know how recent a release is, and makes it pretty easy to figure out what the release schedule was historically (and likely still is) by comparing versions.
Are there any large projects that are older than 25 years that didn't go through that? The time based release thing as been recommended for about 25 years (can anyone get real data?), so newer projects may just be using it without knowing the pain, but for older projects it seems like they all went through it at least once.
$50M? Pfft. The regional health service provider over here has spent close to a billion € migrating to Epic over the past decade. The feedback has been so devastating they're apparently now considering starting over from scratch. Love seeing the consultants lighting my tax money on fire like that.
If GitHub flipped a switch and enabled IPv6 it would instantly break many of their customers who have configured IP based access controls [1]. If the customer's network supports IPv6, the traffic would switch, and if they haven't added their IPv6 addresses to the policy ... boom everything breaks.
This is a tricky problem; providers don't have an easy way to correlate addresses or update policies pro-actively. And customers hate it when things suddenly break no matter how well you go about it.
For every customer which has access controls configured based on IPv4 (sounds crazy enough already), GitHub would configure a trivial DENY ALL policy for IPv6. Problem solved.
Yes, exactly as they would now, when the access over IPv6 is entirely unavailable.
With that, the customers who don't use filtering by IPv4 would be able to use IPv6. Those who do use access control by IPv4 ranges would have time to sort out their IPv6 setup, without having anything broken at the moment when IPv6 is enabled.
No, if you have a dual-homed stack right now, and they only expose IPv4, you connect over IPv4, you don't attempt to connect over IPv6 and get connection denied.
That's rather the problem - there's no trivial way to mimic that policy transparently while enabling IPv6, because most stacks will default to using IPv6 if they're dual-homed and expose both, and won't fall back if IPv6 connects but gives an error. (Offhand, I think the best you could do would be to tell everyone that you're migrating to a new URI scheme to allow cloning, with IPv6 enabled, and that as part of that, you'll have to update your allow/deny rules, then, after a truly astonishingly long time and lots of nagging of anyone who never does it, make the old path an alias of the new one and let the last remaining people break.)
For comparison, latest commercial turbofans approach 6000h (they don't have a strict TBO limit AFAIU, overhauls are decided based on various inspections and measurements). At a typical airliner speed that's something like 3,000,000 miles.
> IMHO, electric is going to revolutionize farming. Diesel is expensive (a lot more lately). And farmers burn a lot of it. Electric motors are small, reliable, quiet, etc. They have loads of torque. And if you are a farmer, you have plenty of space to harvest your own electricity with solar panels and maybe a wind mill and some batteries. There is a growing amount of high end stuff available in this space but also very affordable low end stuff. And this technology can be very simple and tinker friendly. Buy some old EV batteries wire them up and you can make anything with wheels move. Including really old tractors, pickup trucks, etc. Anything from the largest mining trucks to the smallest lawn mower can already be powered by batteries. And everything in between. With battery cost dropping, there are very few obstacles that prevent adoption left. Mostly import tariffs in the US.
Yes. But maybe not a 1:1 of current petroleum-powered equipment with an equivalent electric one? Say, crop dusting aircraft are not being replaced by electric powered crop dusting aircraft, but by (electric powered) crop dusting drones.
Could something similar happen for, say, tractors? A tractor is of course an extremely versatile tool, and as long as there's a human driving it there's a tendency towards ever bigger tractors in order to minimize labor/ha. But big tractors are already a bit too big and expensive for many not-huge farms, ground compaction is a problem with large weight etc. Could we see these replaced by a fleet of electrical drones (drones as in autonomous, not necessarily flying) rather than "just" an electrical tractor? Of course, there's a certain minimum power required to pull a plow etc., so maybe not? Of course, autonomous fleets etc. goes a bit against the idea of DIY-fixable. Or does it? A different skill-set than wrenching on an old tractor, sure.
The MNT Reform classic discussed here was designed 6 years ago, but there’s nothing preventing an updated motherboard with better port selection from being created.
The MNT Reform Next that’s scheduled to be fulfilled this year has a much more modern port layout:
Why not? It's only an adapter away if you have something thst needs to connect to a usb-c female host port. And if you need more ports, which seems likely, you can get a usb hub which has ports of your preference.
5 hours with LiFePo4 and 8 hours with Li-ion since the battery system in the Reform Next should support both chemistries you can choose battery longevity or longer runtime and more frequent battery replacements.
reply