The driver runs in the kernel, distrobox still uses the host kernel as it is container based so no, you can not run two different drivers on host and in distrobox. That wouldn’t even work in a VM though unless you have a second GPU you pass through to the VM. How do you imagine one piece of hardware to be simultaneously controlled by two different drivers?
So this one guy maintains a mobile OS and a browser and an openwrt fork? That seems like too much work for one person and too few people to have issues with lack of donations if he actually does pull it off.
I doubt most of the companies tracking people with their phone even bother trying to get at that data since finding your identity is so easy when there is some tracking in almost every app.
Does sqlite read-only access still work when the disk is full? Would be bad if your history tool prevented shell access when you need to delete something if your disk fills up. Also not sure how fsynced access might slow down debugging of I/O starvation issues (when you want your shell to run from memory mostly).
Syncing shell history between machines seems like an incredibly bad idea considering how many commands are specific to one host and not having all the commands from other hosts in the history makes it so much easier to find them again in the history. Maybe I am thinking about this too much from a cross-platform and server viewpoint though.
Your fdisk output shows a single partition of type ee which according to en.wikipedia.org/wiki/GUID_Partition_Table is the type for the protective MBR partition shown by MBR tools when looking at GPT partition tables.
Try using gdisk -l instead of show the GPT partition table.
I don’t use Terraform but from my understanding Terraform is more for “what kind of server hardware/VM/container/… do I want” and less “which configuration do I want on that server/VM/container/…”
Seems familiar. Did you by any chance also not update the copy of grub in your EFI system partition since you installed it? Then you need to do that and afterwards everything works fine again.
While you are at it add a netboot.xyz EFI entry to fix that kind of stuff without a USB stick or your own network boot server.
What you want sounds like you need something CRIU based where the whole processes are saved and restored. Not sure that is worth it though as it would be rather inflexible if you want the slightest changes in the application state.
I was more thinking about things like governments that decide that every implementation of something must be certified to be used, e.g. with wireless technologies. Not so much implementation as specification or legal compliance barriers to open source basically.
You raise a good point though, financial barriers such as per user pricing that are hard to implement for software distributed for free would be quite similar.
Maybe your could also add organisations (companies, government agencies, NGOs,…) that create standards in such a way that the standard is hard or impossible to implement in open source implementations?
RHEL and other extremly long term support distros that have a significant user base because they hold back a lot of software features, network protocol features and moves to new dependencies that are required to work on the oldest and the newest supported distro for any given upstream software project.
Also, any time I have to learn something about a quirk in a version of software in use there it is basically wasted life time because the knowledge is already outdated by the time I obtain it.