Fill a room at the mall with Linux boxen with midrange GPUs and fiber internet and the sort of keyboards you can clean with pressurized water. Charge an entry fee and then sell pizza, cheetos, coffee, soda and beer. Open at 11AM and close at sunrise.

Then publish the public IPs used by the arcade-owned machines at each location in the chain and use different public IPs for the customer WiFi. No DRM nonsense, just a way to know you're playing with someone at the arcade where the management doesn't allow cheats on their machines.

One is security updates and bug fixes. These need to fix the problem with the smallest change to minimize the amount of possible breakage, because the code is already vulnerable/broken in production and needs to be updated right now. These are the updates stable gets.

The other is changes and additions. They're both more likely to break things and less important to move into production the same day they become public.

You don't have to wait until testing is released as stable to run it in your test environment. You can find out about the changes the next release will have immediately, in the test environment, and thereby have plenty of time to address any issues before those changes move into production.

That's not what it's about.

What it's about is, newer versions change things. A newer version of OpenSSH disables GSSAPI by default when an older version had it enabled. You don't want that as an automatic update because it will break in production for anyone who is actually using it. So instead the change goes into the testing release and the user discovers that in their test environment before rolling out the new release into production.

> On top of that, the backport model heavily discourages the kinds of refactorings and architectural cleanups that would address bugs systemically and encourage a whack-a-mole approach - because in the backport model, people want fixes they can backport.

They're not alternatives to each other. The stable release gets the backported patch, the next release gets the refactor.

But that's also why you want the stable release. The refactor is a larger change, so if it breaks something you want to find it in test rather than production.

It's definitely bad.

The thing to complain about is if the version in testing is ancient.

The bigger issue is that if you want to install or update system-wide packages, many of those will be used by privileged processes. Suppose you want to update /bin/sh. Even if the only permission you had is to write binaries, that'll get you root.

I think the idea is that languages like Python and JavaScript make it easier for humans to write the initial implementation, whereas the "hard" languages from the perspective of creating the minimum viable product are the ones that make it easier for humans to maintain the code, and this has historically been a major trade off.

Whereas if you have the AI write the initial implementation...

Some of the newer hardware is actually worse because the idle power consumption of PCs since around 2010 is determined in significant part by the low-load efficiency of the power supply. Brand new machines with the wrong power supply can use several times as much power at idle as ten year old machines with the right power supply. Annoyingly, power supply efficiency at idle is rarely documented so the only thing to do is measure it.

Mostly because the base Mini has Thunderbolt 4 which maxes out at 40Gbps. Anything with a PCIe 4.0 x16 slot will take a 100Gbps NIC. 100Gbps is around 10GBps (8 bits per byte plus encapsulation overhead). Desktop CPUs can do AES-GCM at 2.5GBps+ per core and have up to 16 cores and around 50GBps of memory bandwidth (dual channel DDR4-3200), so the NIC still seems like the bottleneck.

A bigger issue for enterprise hardware is that it's optimized for performance per watt under load, not idle power consumption. Running a mostly-idle rack server 24/7 can result in a pretty sizable electric bill. This also depends heavily on the model. Some will idle at ~50 watts, others at ~300, but both of these are significantly higher than a Raspberry Pi or an old laptop which for personal use will generally do the job.

Business class desktops are also a good alternative here. Many models have pretty reasonable idle power consumption (check this for yourself, I've seen 6W but also 60W) and then you get a couple of drive bays and PCIe slots and expandable RAM which you don't get from a Raspberry Pi.

But then the copper gets used for 10Gbps connections instead of fibre because it's what's already in the building.

If you chose PCs to begin with that come with fibre ethernet or put quality cards in the ones that matter then you could make fibre the default instead of copper. Until you have a number of devices like printers or VoIP phones or Raspberry Pis that have no need for 10Gbps or even 1Gbps connectivity, they just need a way to be plugged in at all. If you need to add $100+ in conversion expense to each of those devices, you're back to using copper by default.

The problem to be solved is that you want to be able to put fibre inside the walls of the building instead of copper. Running a new cable to the switch closet is the thing to be prevented.

But if the wall jacks are fibre then you need some economical way of hooking them up to every printer and single-purpose device with a network port. If you have to buy another $100+ switch just to get from fibre to copper even when there is only one device near that jack, people aren't going to go for that.

https://www.amazon.com/1000Mbps-Network-Performance-Gigabit-...

https://www.amazon.com/SALAN-Ethernet-Portable-Internet-Conv...

But it's not competing with those, it's competing with the copper port which is already built into most devices.

Another thing that would work is something like this (also $5.99), but with one of the ports as fibre:

https://www.amazon.com/Gigabit-Ethernet-Splitter-1000Mbps-In...

The point being you need some cheap way to plug in existing copper devices if you run fibre to the endpoints.

This plus $5 for a transceiver is pretty close at $15:

https://www.amazon.com/Gigabit-Ethernet-Converter-Auto-Negot...

But +$15 and an extra wall outlet per endpoint is still an inconvenience, and if a two-port device with its own power supply can be made for $15 then where is the PCIe/USB to fibre adapter for <$10?

What probably would is something like having PCIe and USB to 1Gbps fiber adapters that cost $5.