ebiederm

Thank you for posting this.

I had heard LLMs were finding a lot of bugs very quickly and now I can see what that looks like from a user perspective.

Hooray! A static test fire caught a problem.

Crap! There was a serious latent problem for the test fire to find.

Plus pretty blantant plagiarism.

In addition to capabilities, which implemented the principle of least privilege (and keep untrusted code sandboxed by default) there is a need for binary verification.

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.

My reasing of the study is children with significant gut issues and diagnosed with autism see a significant reduction in symptoms when the gut issues are treated.

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.

The notification happen when the fix was shipped. That people would prefer to been spoon fed only serious security issues is understandable, but not realistic.

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?

For everyone getting into the details about how all of this should work please look at RFC7084: Basic Requirements for IPv6 Customer Edge Routers

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.

Language design benefits from parser generators that can point out ambiguities and verify a language is easy to parse.

But it happens successfully.

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.

It is not breaking userspace if there are no programs in userspace that care.

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.

Chuck Moore of Forth fame.

When Wirth talks about modules and abstraction I believe he was talking about what was known as the software crisis. In particular the observation that as programs size increases the number of possible interactions of program components grows quadratically.

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.

Message-ID is a requirement for Usenet where it came from.

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.

My EV is absolutely terrible range wise at cold weather. It is EPA rated at 220miles of range. I only see that when the temperature is at or above 80F.

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.

Having moved between states and taken a lot of drivers tests. I can say the exact rules are something that vary between states and over time. Including how it was taught.

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.

Does the 2026 Nissan Leaf meet your criteria for a dumb car?

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 appreciate that I am not the only one seeing the connection between property based testing and proofs.

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.

I don't know if this is realistic but as a general rule if I was contracting with someone so that my business would have higher reliability, I would ask for a service level agreement with a agreed upon amount the vendor will pay you for every unit of time there service is not up.

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

Thanks. That helps put things into perspective.

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.

Obstructing traffic is also against the law.

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.

Odd.

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.

There is an aspect of the history of Forth and C I have been trying to wrap my head around.

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?

CLU implemeted abstract data types. What we commonly call generics today.

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.

In the basic block with arguments variation there is no going in and out of SSA.

I prefer the Oort cloud colonization plan. Since Oort clouds stretch so far out they touch between the stars.

Once the problem of living on a comet has been solved, you get something like the Polynesian islanders. People would move from one commet to the next. One generation at a time, for more living space and more resources.

I wonder what people in a generation ship would do when they arrive at a star and discover the comets of the star system are already inhabited.

I am not up to speed on these new algorithms. I still remember there was a light weight cryptography algorithm a few years ago championed by the NSA that had a subtle (possibly deliberate) flaw in it.

When dealing with cryptography it is always necessary to remember cryptography is developed and operates in an adversarial environment.

Since when has following the advice of a customer service agent been using technology incorrectly?

It might not be the sole responsibility of the customer service agent, but it is certainly their fault for giving bad advice.

It is completely reasonable to rely on the public statements of a company.

That said unless a someone at the company steps up, this seems like an issue for something like small claims court.

The Motorola Moto G series has both.

I just bought their 2025 model for that reason.

Funny

The situation RISC OS dates to the beginning of ARM and still lives but is 32bit only and in assembly. They have been getting sponsorship for small improvements.

32bit Arm is going away.

They are looking for the resources for a 64bit port.

That seems like an entirely reasonable ask. I don't know if enough people are interested but it seems entirely reasonable to ask.