• 8 Posts
  • 77 Comments
Joined 3 years ago
cake
Cake day: February 1st, 2023

help-circle


  • Mainly two reasons, one about architecture, and one about vendors

    In the PC world, the entire ecosystem is designed to be modular, and people expect to be able to put windows/Linux on any pc and have it work despite the manufacturer. The kernel just wakes up on one of the cores, figures out the CPU, wakes the rest of the cores, and from there it figures out the rest of the computer. By contrast arm systems are tightly integrated, each SoC is unique and there’s no way to figure out the rest of the system, the kernel wakes up on one of the cores, reads out what SoC this is, and mostly has to already know the chip and any additional hardware connected to it.

    But, sure, there are only so many SoCs (kinda), and displays, cameras, and touchscreens are mostly similar, you are bound to find a way to tell the kernel what hardware is running on and have it work, right? Except a lot of phone hardware is proprietary (duh) and requires bespoke proprietary drivers, google pretends to encourage vendors to submit their drivers upstream, but this doesn’t really happen. Now, if you are familiar with running external drivers on Linux, you probably know how picky the kernel is in what to load, but android’s kernel is specifically modified to be less picky, to allow vendors more slack. Mind you, the API is not more stable, the kernel is just less picky.

    Bonus: running Linux on arm laptops is indeed proving kind of a challenge (nothing impossible, but resources are limited), that’s because they are built like a mobile phone.











  • Yes, that was one of the tools I considered before making this. I do not remember the precise detail on why, but much like gnu stow is only good for versioning user dotfiles and not system config. Etckeeper is good for storing either your system config files or user’s dotfiles, but not both at the same time. copicat doesn’t care what you use it for because you explicitly tell it all the locations and permissions that you want.


  • Yeah, it’s cool, people are mostly looking for something like your usecase. I got suggested stow or stow-like tools a lot when exploring this. And when they understood what I wanted, they just suggested ansible… Which would work when starting from scratch, but wasn’t right for me. I made copicat mostly because I am actually using it, and then decided to make it public because really I didn’t find anything like it.



  • That is a good question. I have considered using gnu stow before building this. But there’s a couple of problems with that.

    Git doesn’t follow symlinks, it stores them as links in the repo, so your only option is to keep the files in the repo, and symlink from the config file location to the repo. This is fine for user config files (like from your .config folder), but if you want to keep system config files (like those from /etc) then the git process needs to run as root to modify those files, because symlinked files share permissions and ownership. And even then, git will always create everything as root because it only tracks permission bits, not ownership, so you will need to constantly fix up ownership of your files.

    With this tool instead you explicitly tell it the ownership and permission of files, and it takes care of that for you (it still needs root permissions of course).