For thin clients?

It’s Cannonical. They prefer implementing everything themselves fast, rather than developing a more sustainable project with the rest of the community over a longer timescale. When they do that, there will be very little buy-in from the wider community.

Others could technically implement another snap store for their own distro, but they’d have to build a lot of the backend that Cannonical didn’t release. It’s easier to use Flatpak or AppImage or whatever rather than hitch themselves onto Cannonicals’s homegrown solution that might get abandoned down the line like Mir or Ubuntu Touch.

It’s Cannonical. They prefer implementing everything themselves fast, rather than developing a more sustainable project with the rest of the community over a longer timescale. It makes sense that when they do that, there will be very little buy-in from the wider community. Much like Unity and Mir.

As you say - why would others put time into the less supported system? Better alternatives exist. If Canonical want their own software ecosystem, they’ll have to maintain it themselves. Which, based on Mir and Ubuntu Touch, they don’t have a good track record of.

I don’t know why you’re getting downvoted. It makes perfect sense that Cannonical made it’s own proprietary package ecosystem and while technically anyone can build their own snap store, ain’t nobody got time for that.

curl shit | sudo bash is just so convenient.

Why use separate partitions over subvolumes within btrfs?

Except PGP is a substring of the ‘technically correct’ term. It’s like someone saying you’re playing on your Nintendo - “Um, actually it’s a Nintendo 64.”

You fraud.

----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEETYf5hKIig5JX/jalu9uZGunHyUIFAmaB8YEACgkQu9uZGunH
yUKi7Q/+OJPzHWfGPtzk53KnMJ3GC8KQGEUCzKkSKmE0ugdI9h1Lj4SkvHpKWECK
Y1GxNujMPRM/aAS2M97AEbtYolenWzgYmO1wt131/hEG4tk+iYeB2Sfyvngbg5KI
y4D7mqpcVWYSf6S13vUX8VuyKeTxK6xdkp95E0wPVLfJwx5o5nH0njLXxeW0IblY
URLonem/yuBrJ6Ny3XX9+sKRKcdI9tOqhMhTxPcQySXcTx1pAG7YE7G5UqTbJxis
wy7LbYZB5Yy0FO3CtRIkA+cclG4y2RMM9M9buHzXTWCyDuoQao68yEVh4OdqwH1U
5AUnqdve5SiwygF/vc50Ila6VjJ4hyz1qVQnjqqD96p7CSVzVudLDDZMQZ8WvqLh
qaFr51xJvH6p6/CP1ji4HHucbJf6BhtSqc8ID9KFfaXxjfZHiUtgsVDYMV0e7u9v
lhcDH/3kmw/JImX25qsEsBeQyzOJsBvxOYD3lZrwSY9+7KNGVQstFrEvCuVPHr72
BQJPIhg3+9g6m36+9Uhs1N6b8G9DsZ6OgnNqr9dGturUg6CtRsLSpqoZq0FT9cLA
tnFTJDaXgx1DZnsLGDSoQQYjZ3vS+YYZ8jG86KGLFyXVK+uSssvorm9YR1/GGOy7
suaxro72An+MxCczF5TIR9n3gisKvcwa8ZbdoaGd9cigyzWlYg8=
=EgZm
----END PGP SIGNATURE-----

Well at that point, just don’t install any kernel mode EDR software at all.

NixOS can be set up for impermanence where all config is recreated every boot and nothing persists besides the nix store. There’s helpers for ephemeral home also, so you can have something like TailsOS. I’m sure you could do that with other distros but you’d need absolute discipline to have everything the machine needs provisioned at boot.

I think having an A partition and a B partition (I’m assuming that’s how SteamOS works) wouldn’t help in this case. If the A partition downloaded the definition file, crashed and failed to reboot; the bootloader could failover to the B partition - which would then download the definition file, crash and fail to reboot. It would have to keep rolling back to a last known good snapshot until the update got withdrawn.

You could have an ephemeral set up that wipes /var and /etc and recreates them every boot. I don’t think these EDR tools would like that very much though.

Yeah, you’d need to snapshot their data directory and roll that back. The previous kernel module may well have had the bug already, just not a malformed config file to trip it.

Also, if the driver booted ok, but then panicked soon after, would that count as a bad boot? The description seems to indicate the boot counters get reset as soon as a boot succeeds.

I’d have thought the cloud side would be pretty easy to script over. Presumably the images aren’t encrypted from the host filesystem so just ensure each VM is off, mount its image, delete the offending files, unmount the image and start the VM back up. Check it works for a few test machines then let it rip on the whole fleet.

The switches do suck but they can usually be revived with contact cleaner. If you open the mouse you can spray around the switch plunger or better yet, pop off the top half of the switch case and spray the contact directly. That completely cleared up the double click on my G402 and even revived an old MX510 that was missing clicks.

Because then it would be 'a;imodo not qazimodo.

Wherefore art thou Gnomeo?

I can see that, but surely there wouldn’t be much difference matching the first 4bits (0x2XXX, 0xfXXX) vs the first 16 (0x0001)?
0:: is presumably all for loopback-type stuff, but I don’t see a reason not to use 1:: through 1fff:: and they would be much easier to type/remember/validate for public DNS servers which are needed before name resolution is available.

Why start at 0x2001 though? Why not 0x0001? Then we could have addresses like 1:1:1::1 or 1:2:3::4.

2606:4700:4700::1111

Hmm, maybe Google is easier:
2001:4860:4860::8888

Quad9 is 2620:fe::fe or 2620:fe::9

I don’t understand why they can’t get better addresses than that. Like surely 1::1 would be valid?

Edit: So IANA only control addresses 2001:: and up and there are quite a few IETF reservations within that. I don’t know why they picked such a high number to start at. Everything else seems IETF reserved with a little space allocated for special purposes (link-local, multicast, etc.).

I’m using ATmega micros, on my Lily58. If I remember correctly, the default QMK behaviour was to use the USB to select which half was the master and what side it was on. That would work on RP2040 boards just as well so that may be what the provided firmware does.

I would suggest you just flash them both then see what they do. If they are swapped, try connecting the USB to the other half. If that works then you don’t have a problem. There’s no risk of damaging them and the RP2040 is pretty easy to reflash.

I wasn’t satisfied with that method and set QMK to store the sides in eeprom so I could use the same firmware but connect to either one. I’m not sure if the 2040 has a separate non-volatile memory so you’ll likely need a different method. I think a GPIO can be grounded to set the side but the Lily58 doesn’t do this. You could add a bodge wire if you want this but you have to customise QMK to use that method.