In the EU, lights have to be sold with a mandatory energy efficiency label. A lesser-known component of this is that this label includes a link to a standardised datasheet, which includes things like flicker metrics, CRI, chromaticity, and a measurement of the spectrum.

It doesn't fully quantify the light, but it's good enough to distinguish trash or even passable lights from actually good ones.

There's software where the continued existence of a diligent community around that project is necessary (web browsers, OS drivers, security-critical software...), but there's also software where I don't need any of that and I'm grateful for the chance to ignore any community around it and keep using the software anyway. Sometimes ideas just aren't compatible, and that's fine, forking allows us to part amicably.

I wish I could "just fork" most social problems. As FLOSS developers, we have the great luxury of being able to fork, and all we lose is the community, other people's considerations for our preferences. But for social problems, the people are the point, so "forking" alone wouldn't accomplish anything, not to mention physical limitations that make forking e.g. a country impossible.

The way I read it, they probably have Ethernet on their gaming desktop PC, just not on a second device to run a local speed test.

It matters in that it opens up competition and allows fully-open designs, which should keep prices low and products available, but you're right that having fully-open state-of-the-art chips is unlikely to happen any time soon.

They're great, because you can use all standard ARM tooling, including CMSIS-DAP dongles for debugging.

That's not clear to me: Will they do fewer releases, or will they have the same quarterly release cadence as now, just with only every second release open source?

I would assume the Q1 and Q3 quarterly releases are going away altogether.

They are not.

You seem to think an SSG is some burden that people put up with due to sunk cost fallacy, but I don't see why.

The Markdown-to-templated-HTML pipeline code is the same whether it runs on each request or on content changes, so why not choose the one that's more efficient? Serving static HTML also means that the actually important part of my personal webpage (almost) never breaks when I'm not looking.

"Markdown-to-templated-HTML" is only 1 part of a website.

SSGs force people into particular ways of doing all the other parts of a website by depending on external stuff. This is often contrary to long term reliability, but nobody associates those challenges with the SSG that forced the external dependencies.

It becomes a sunk cost fallacy because people do what Jeff has done, they switch to an SSG in the promise of an easier website and proudly proclaim they're doing things the new best way. But they do the easy SSG bit (the content rendering) and then they create a TODO with all the compromised options for interactivity.

When they've got to a feature complete comparison, they've got a lot more dependencies and a lot less control/ownership, which inevitably leads to future frustrations.

The end destination for most nerdy personal website is a hand crafted minimal server with minimal to no dependencies.

Vega GPUs should be very well supported, especially for basic desktop stuff, since Ryzen mobile CPUs shipped with Vega cores for many years after the dedicated GPU line.

Yeah, I had one of these, but I suspect that the hardware is quite different.

> I can have a both a firewall and a NAT. The two layers are better than one because at least my address is shouldn't be routable even if I failed to configure my firewall correctly.

That's not true. When you configure just NAT (with e.g. nftables on Linux), the NATed devices are still reachable from the outside, you just have to add an entry to your routing table to reach that internal address space using the router.

"Just add an entry to your routing table" ... it's virtually impossible to do that for RFC-1918 addresses across the internet. It will be filtered at the ISP border or an upstream. Is it theoretically possible? Yes. Is it an actual risk? Probably not.

Well, if you're other customer of the ISP on the same network, then that may get more interesting... (or inside VPS provider's network)

I think Linux is the better choice for replacing the entire userland. From what I've seen, the BSDs don't have such an accessible userspace/kernelspace split. With some effort, on Linux you could probably just run an exe as your init.