imoverclocked

It's nice to do this for more than just the direct economic costs. The generator doesn't have to run 24/7 since the batteries absorb the excess power produced by the generator. This means less fuel wasted as well as less noise produced. I used to have two small generators that I could run (and team, if needed) but adding a battery component meant being able to sleep at night without a combustion engine burning fuel all night long.

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.

Yes.

Is Apple tracking you here? Seems like you are using a free product which advertises its paid-variant. That's a far cry from targeted ads via tracking and profiling.

I just updated and see the same "ad" under New Document -> Choose a Theme.

Maybe unpopular take but ... this isn't just any ad. It's a link to another related product in the ecosystem. Discoverability has always been difficult and there are so many features that remain largely unknown to users because of it.

The title makes it seem like I can purchase an ad and have some kind of ill-fitting content jumping around the screen, trying really hard for my attention. Instead I see an upgrade path from what is free and widely available to a potentially better product. I see this with open source projects too.

Even still, this AppleTV only does up to 4k 60 fps. While getting long in the tooth (1000Base-T is 25+ years old! wow...) it's still enough for anything it is expected to do.

I’m not a gamer so I had to look this up. The Google AI answer for cloud gaming stated a stable 15-20Mbps connection as a requirement. Obviously latency matters in many scenarios but raw bandwidth might be overstated?

Any use for a faster port in this device? I use gig-e on my current 4K and it’s really nice to reduce latency (compared to WiFi) but I doubt 2.5G or 10G would be that useful… unless there were an SFP+ port where I could run fiber instead.

Except that states want their pound of flesh; California is definitely no exception.

There are entities that are federal registrations (eg: an aircraft with an "N-number" -- that N-number is federal) that individual states still try really hard to tax the same way as cars/trucks. Individual counties even take a stab at this.

It seems that the rules might be there for some benefit but mostly the rules help the state/county make income.

There are classes of virus that are hard to detect. One is a compiler virus that passes itself from compiler to compiler. You only get rid of the vector by bootstrapping from 0.

I'm not arguing either perspective but being 59 and out of money looks very different than being 80 and out of money. If you have built up capital and that's how you make your living, you become very dependent on that capital.

I've known people who believed they would never live past 20. I've also known people who want to live to 200. The difference in mentality between the two as well as the different approach to life is large. IMHO, the difference is directly comparable to working for what you need for the day/week vs saving for when you are 80.

Frankly, if you had just enough money to simply retire, would you risk it on employing folks who drink themselves to death, wreck expensive equipment, take responsibility for as little as possible and generally don't care about your bottom line? ... or would you retire?

That's useful if you run a Debian-packaged kernel.

Searching around, the best I have found so far for vanilla kernels is: https://linuxcvetracker.com

It does require a little clicking around to get all the info I want though. Time to pull out curl+awk! :)

Is there a way to know if a particular vanilla kernel has a particular CVE addressed? Unhelpfully, the ChangeLog-* only seems to contain sporadic references to CVEs.

I don’t think it’s that unique. Social learning is documented in a wide range of species.

https://en.wikipedia.org/wiki/Social_learning_in_animals

If you have enough friends, you can learn the lesson.