A check that a whatever is downloaded cannot exceed it's capabilities.

Part of the challenge is that hardware tried and has failed to be trustworthy in implementing security boundaries. The failure appears to be because a misalignment of incentives.

I think the premise of a capability based operating system can help a lot, but for something to work in the long term the incentives need to aligned.

Which leads me to wonder if for some of these children is the root cause just gut issues.

If all they have figured out how to so is treat significant gut issues that sounds very promising.

A large percentage of kernel fixes have the potential to be similarly bad. For some the potential isn't even realized until after the fix has shipped.

Ever stable release GregKH says you must upgrade now, because there is something security relevant in there. This happens at least once a week.

As for shared hosting providers it is my sense that there is always at least one local privilege escalation available to miscreants. Making shared hosting only safe if there is a certain amount of trust.

I remember bugs that were similarly bad from my university days 30+ years ago. Has anything substantially changed?

https://www.rfc-editor.org/rfc/rfc7084

It describes in detail what a home router needs to be doing to make all of this work seamlessly.

Things work so well that half the world has working IPv6 already.

Openwrt pretty much implements all of this out of the box.

If you are struggling with IPv6 I recommend reading up on where it is at today and figuring out how whatever makes your network special can be done using IPv6 with no fuss.

Personally I have moved several times changing ISPs in the process and my IPv6 setup involving multiple LANs on my home network has just continued to work. IPv6 renumbering events just work seamlessly and completely automatically.

Historically the only practical hold up to IPv6 adoption has been the ISPs not rolling it out to their customers.

The code base is Xorg rather than Xfree86 because of one such fork.

Gcc went through the egcs fork.

OpenOffice became LibreOffice in a fork.

When leadership of a project fails to keep the volunteers behind them such forks happen.

If you have a program that cares please report it.

The evidence is that no one has had a program that cares since 2016. A decade of holding on to dead code seems enough.

Modules in particular and good abstractions in general make the number of interactions between components tractible.

The N^2 component interaction problem is real and it continues to cause problems.

Even with our best solutions there is room for improvement.

Last I paid attention there was a culture that had developed around the administration of CISCO routers because things that should be unrelated affecting each other is a real world problem for the administrators of those routers.

Any time something changes in siftware and something unrelated is affected this general problem is making it's appearance.

There is also a long term tension between abstractions and entire system simplicity. The wrong abstract or an abstraction poorly implemented can make things worse.

It is a requirement for being able to reply to messages and in general for email threading.

Message-ID is a requirement to archive email.

Practically every email client has included Message-ID since dial-up internet was fast and fashionable.

Given all of the above I am amazed more places don't drop email without a Message-ID.

Not including a Message-ID seems to be saying you don't want replies and you don't want your message to be archived. That seems very shady to me.

Most of the winter it tells me I can only do between 100 and 120 miles. It is definitely half the EPA range with climate controls disabled at 0F. (Ask me how I know).

I love driving it in the winter. I don't have a pressing need to go long distances, so that is not a current concern. Not having to stand outside in the bitter cold to fuel up in absolutely awesome.

There are EVs on the market that do much, much better than mine in cool weather and I now know what to look for.

To really penetrate the midwest it will take a car that can realistically do a road trip to Florida from say Duluth, MN or Michigan's UP in the winter.

Because not only do folks in the midwest drive long distances without a second thought, they sometimes do it in the cold of winter so they can get a break from the snow.

So yes still getting 90% of the range at -40C does sound attractive.

My first drivers test was yield to the right. Later it was fifo order of who made it to the stop.

My running interpretation is fifo order with yielding to the right in case of ambiguity.

All it's connected features appear to come from Android Auto or Apple Car Play. AKA from a connection to your phone.

I like the looks of it because it appears to be a serious EV unlike too many which are just some company getting their toes wet.

I will quibble a little with their characterization of proofs as being more computationally impractical.

Proof verification is cheap. On a good day it is as cheap as type checking. Type checking being a kind of proof verification. That said writing proofs can be tricky.

I am still figuring out what writing proofs requires. Anything beyond what your type system can express currently requires a different set of tools (Rocq, Lean, etc) than writing asserts and ordinary programs. Plus writing proofs tends to have lots of mundane details that can be tedious to write.

So while I agree proofs seem impractical. I won't agree the reason is computational cost.

At least then your pain is their pain, and they are incentivesed to prevent problems and fix them quickly.

I looked and today Swift Forth from Forth Inc, has some version of a compiler that generates not horrible code so I expect the 10x slowdown compared to C is a thing of the past.

Something I had pounded into me when I drove too slowly and cautiously during my first driving test, and failed.

Those Waymos weren't moving which is a pretty egregious example of obstructing traffic.

An old rule of thumb is every time a service expands by an order of magnitude there are new problems to solve. I suspect and hope this is just Waymo getting to one of those points with new problems to solve, and they will find a way to more graciously handle this in the future.

Using Openwrt which pretty much all home routers are built on, all I have to do is tell my router which offset to give my subnets from the prefix and it does the rest.

Both for subdividing up the prefix from the ISP and my ULA prefix I use for internal devices.

I have changed ISPs I think 3 times with no ill effects. Plus it works when my ISP occasionally gives me a new prefix.

The only tweaking I had to do was when I went from an ISP that game me a /48 to one that only gave me a /56. I had been greedy and was handing a /56 to my internal router. I changed that to a /60 and updates it's expectations about which subnets it could hand out and all was good.

But I expect two layers of home routers without NAT is a bit of an exception.

The early B compiler was reported to generate threaded code (like Forth). The threaded code was abandoned fairly early in the port to the PDP11 from the PDP7 as it was deemed to slow to write an operating system in.

At which point unix and C lost a very interesting size optimization. With the net result that Forth was more portable and portable between machines circa 1970 and Unix had to wait until circa 1975 with UnixV6.

I have been trying to go back through the history to see if I could understand why threaded code was deemed too slow. Today the most part of executables is code that is not run often and would probably benefit from a smaller representation (less memory and cache space making the system faster overall). So this is a practical question even today.

I found a copy of unix for the PDP7. Reproduced from old printouts typed in. If I have read the assembly correctly the B compiler was not using an efficient form of threaded code at all.

The PDP7 is an interesting machine. It's cells were 18 bits wide. The adress bus was 12bits wide. Which meant there was room for an opcode and a full address in every cell.

As I read the B compiler it was using a form of token threading with everything packed into a single 18 bit cell. The basic operations of B were tokens and an if token encoded with a full address in the cell. Every token had to be decoded via a jump table, the address of the target code was then plugged into a jump instruction which was immediately run.

Given the width of the cells, I wonder what the conclusions about performance of B would have been if subroutine threading or a similar technique using jmp instructions would have been.

Does anyone know if Forth suffers measurably in inner loops from have to call words that perform basic operations?

Is this where a Forth programmer would be accustomed to write the inner loop in assembly to avoid the performance penalty?

The Liskov substitute principle in that context pretty much falls out naturally. As the entire point is to substitute in types into your generic data structure.