imoverclocked

Yup. There is no reason it has to be a ROM though. It can easily be a small flash device sitting on spi or something. Firmware sitting on an SD card is annoying for all the reasons already stated.

Well, for one, the dtbs don't belong with the shipped kernel. If a dtb exists, it should be shipped on the hardware (perhaps as part of firmware.) Right now, there is an intricate dance in some arm setups where:

The installed kernel has 200+ dtbs shipped with it and the boot loader has to be configured by some non-standard userspace glue to detect the correct dtb before rebooting. This glue doesn't exist everywhere and can be ad-hoc per-board or completely non-existent. IMHO, this leads to folks just not updating kernels.

One nice thing (in theory) about a dtb is that there is no code. Of course, there doesn't seem to be an established standard for finding that data so we are back to relying on specialized boot configuration and code anyway.

One place this all becomes glaringly bad is if you take an SD card and move it from one arm64 node to another; There is a good chance it won't boot. It's no wonder there are so many board-specific OS-images floating around instead of having arm64 installers that just work.

Also, a FDT is useless to most OS and remains primarily a Linux concept that has bled into other spheres (like U-Boot) so why would a manufacturer include it?

So ... what should we actually have? A standard on arm that doesn't depend on the triple of which (OS,board,bootloader) you are running. We should be able to just build an arm64 kernel (BSD/Linux/Windows/whatever...) and have a good chance that the thing just works. If that's done via UEFI, then so be it.

IMHO, given (waves hands) the current state of arm64 boards, arm64 support for Linux should look like:

1) Load a board-specific firmware to provide UEFI via EDK2/U-Boot/custom * This is likely on the board-manufacturer to provide and should be pre-loaded.

2) Run a generic arm64 installer.

Uboot contains a device tree which may or may not be in sync with your kernel device tree. Recent uboot supports efi which then muddies the water more.

When vendors ship a specific kernel, you are unlikely to get security updates in a timely fashion, if ever.

There should be no need for any of this in 2026.

Well, looking at the mess that is most arm/arm64 SBCs, I understand why it’s nice to have a standard interface that can run (eg) grub. Can UEFI be much smaller? Also yes.

The most useless review is the one where I am asked to review something on the day it is delivered.

It really depends on the shape of the tests and the shape of the language. Eg: Untyped languages often have tests that effectively implement a type system as software grows and the developer count grows. That seems like a waste…

Writing a good test or good set of tests does take effort but enforcing 100% coverage often pushes some folks to just run the code in any way possible within the test subsystem.

Sometimes the problem doesn’t get solved because it is lucrative to not solve it… not because it is too hard/costly to solve. Ie: some platforms don’t internally classify spam/bots/corruption/scams/etc as a problem. Often, the right amount of it increases engagement… and thus the perverse incentive perpetuates or amplifies the problem.

Think: corollary to Cunningham's Law.

> On top of that, the user's client can do any kind of algorithmic bot detection they want.

Bot traffic is sometimes detectable only at scale.

… and what about bot traffic? The current platforms are overrun by them but seemingly only by choice. A truly open platform would be a bot playground.

My methodology was not going to be a broad spectrum jamming device. I can see why you might hop onto that notion given my extremely abbreviated description. The signals I would have emitted would have been in line with existing analog signals… in a controlled environment. I’m not an RF guy but I’m also not ham-fisted, if you’ll excuse the pun :)

AFAICT, my larger point still stands.

Sort of.

When I first came into the tech space, I found myself with quad copters buzzing around my workspace. I had the intention of hacking the signals around me to dissuade folks from flying around my head while sitting at my desk. After walking into a radio shop, looking for a few key items, I chatted for a few minutes with the clerk. He immediately put me into his “you’re a jammer” box and was uninterested in any further conversation. He wasn’t wrong, but it’s ironic given that I was effectively counter-jamming to get work done… and maybe have a little fun hacking at the same time. Point being: some communities have such rigid rules around what a “good citizen” encompasses that they get lost in their own world.

I find myself more on the altruistic side, despite being far closer to a “computer hacker” than a ham.

> R1 & R2 are IPv6 only with no IPv4 anywhere on their interfaces (but carry IPv4 routes in their table)

… proceeds to traceroute with IPv4 addresses showing up for each router…

It’s neat but still requires IPv4 to be configured on the router? What am I missing?

It's amazing how easy it is to lie with numbers. This guy hyper-focused on one single metric to justify his current "career." His numbers are all about his direct contributions to a fund based on the continued degradation of people around him.

No, you aren't a quant. You are a drug dealer with an education.

> we all win

Do we all? Or does anyone with enough money to pay for Anthropic's IP, win? Nothing states that Anthropic/OpenAI/... have to share information they have generated. As the crunch for income becomes real, I doubt valuable things will remain free.

It's also how films have worked since the 1930s; We are coming up on a century of trailers at the beginning of films.