I think having a solid/stable virtualization layer is very helpful. Whether that’s Proxmox, Incus, or something else, it’s a matter of taste.
You can then put NixOS, Guix, Debian, Arch, whatever on top.
I think having a solid/stable virtualization layer is very helpful. Whether that’s Proxmox, Incus, or something else, it’s a matter of taste.
You can then put NixOS, Guix, Debian, Arch, whatever on top.


That’s what I use too. Coupled with soju it’s an easier experience for me. And they are both in Debian 13!
I like Pop, but note that Gnome has a few extensions that implement tiling (I use PaperWM). I believe KDE also has some tiling support.
Certainly, many of the hardcore tiling environments are too bare and require significant effort to get to a usable state (esp. on laptops, where you want wireless network applets), and it’s unfortunate that it is no longer so easy to mix and match components (e.g. I used to run xmonad on top of Mate).
Having said that, I’ll have another go with the beta!
Is it an option? Can’t find it. (But GitHub is confusing and I’m old, so maybe there’s something?)


Hah, no worries. I think it’s just an unusual use case and… well, I recognized it because I’m obsessed with PiKVM lately and those things!
I’m not superknowledgeable on USB, but Linux has features to do this; they are called “gadgets” in this list:
https://docs.kernel.org/usb/index.html
I have used this to turn a RPI Zero into a virtual USB drive with these scripts: https://github.com/alexpdp7/rpi-zero-usb-iso/
Likely by searching the Internet for USB gadgets you might find good explanations about requirements. I know there are unexpected difficulties- I’m using a Pi Zero instead of a nicer Pi because… nicer Pis can draw too much power over USB and bork what they’re connected to. So be careful.


If this needs to be “hardware” level, I saw https://openterface.com/ recently. The PiKVM-style projects are also a bit adjacent to this.
But now with the end of Windows 10 looming, I need to upgrade a family member’s computer to Linux.
Why?
Did they ask for Linux? Do you have authority over them?
So this needs to be something that both is not going to break on its own (e.g. while doing automatic updates) and also won’t be accidentally broken by the users. … There’s no way I’m going to be able to handle long-distance tech support if things break more than once in a blue moon.
Issues appear. I would be more focused on setting up remote access than choosing a distro.
I’d choose something LTS that has been around for a while (Debian, Ubuntu, RHEL-derivatives, SuSE if there’s a freely-available LTS, etc.).
If you are not against the use of Google products, ChromeOS devices are about the best well-designed low maintenance operating systems. (Not Flex, a ChromeOS device.) But you would be sacrificing Firefox and LibreOffice, which might not be an option. (And technically, it’s running a Linux kernel, if I remember correctly.)


https://dgross.ca/blog/linux-home-server-auto-sleep did the rounds lately.
But you’ll need another system to always be on to handle this.
In many cases, you can “fake” this in other means. For example, I had Remmina configured to run a script to send a WOL packet and wait before connecting via remote desktop to a computer.
I dunno, I still have a soft spot for Proxmox. I want ZFS, so it’s about the only game in town with support.
(TrueNAS Scale looks good, but it would increase too much my Hetzner costs, because of their requirement of having a dedicated root pool. And I don’t want an LTS distro that supports root-on-ZFS “oficially”. That narrows the field quite a bit.)
(For work and for my workstations, I’m very pleased with Incus on top of Debian… but that’s because I don’t need ZFS on those.)
Ah, sucks :(
I’m looking forward to see where Incus OS goes, or TrueNAS Scale. Honestly, I was very tempted to automate a procedure to take a Proxmox ZFS install and replace the Proxmox bits with Incus bits :) Incus + ZFS as an appliance would be nice. I kinda don’t want to think about the underlying OS.
It’s on backports :D
(I’m actually running it from the Zabbly repos.)
I like to live on the edge of time and therefore have the feeling that debian based distros (although being very stable) are too “old” for my liking.
Nowadays, with Flatpaks, so many software providing binaries, etc. this does not matter so much. If you want, you can even use something like Distrobox to have containers for tools using whatever bleeding edge distro you want, but still have a solid stable underpinning.
Debian also has more stuff than you would expect in backports. The main sticking point is yes, you’ll be stuck in Debian 12’s KDE until 13 comes out. But that might be sufficient for you?
(You could also use Debian Testing, which is basically a rolling release. But I’d consider stable first.)


My crazy idea is: write software so that Flatpaks can run on Windows and macOS. Plus, make high-quality Flatpak-building templates available for as many programming languages, UI toolkits, etc. as possible.
Because everything that Flatpaks provide is OSS, making shims for Windows and macOS compatibility would be tedious, but doable.
Same with crosscompiling Flatpaks, compared to the difficulties of crosscompiling for Windows or macOS from any other OS, multiplatform Flatpaks should be doable to crosscompile.
So this would lead to a world where a very convenient way to package for Windows and macOS… is creating a Flatpak that works on Linux!
I’m still a huge fan of Ventoy, but lately I have been finding more and more issues with it.
So I decided to investigate using a Raspberry Pi Zero with a USB adapter to create a virtual drive:
It’s very wonky and manual at the moment, but I have managed to boot all Linux ISOs successfully so far. Unfortunately, I think only ISOhybrid works OOB, so Windows ISO do not work. I have found some scripts to take Windows ISO and make them ISOhybrid, but haven’t gotten around to doing that yet.
I think it should be doable to package this nicely.
You don’t need to rebuild your server from scratch to use Ansible or any other configuration management tool. It helps, though, because then you can ensure you can rebuild from scratch in a fully automatic way.
You can start putting small things in control with Ansible; next time you want to make a change, do it through Ansible. If you stop making manual changes, you’ll already get some benefit- like being able to put your Ansible manifests in version control.
(I still use Puppet for configuration files, installing packages, etc. It just does some stuff better than Ansible. Still, Puppet is harder to learn, and Ansible can be more than enough. Plus, there’s stuff that Ansible can do that Puppet can’t do.)
Dotfiles are a completely separate problem, tackle them separately. Don’t use Ansible for that, use a dotfile-specific tool.