edinbruh

Is that the issues your project is solving?

That's exactly it, and also the fact that git doesn't follow symlinks. Just a word of warning, If you are still inexperienced I suggest you run my tool manually instead of automating it with git hooks, as it is inherently less secure. In the post I linked in the description you can see some of the precautions I took to make it more secure. Still, running it manually is fine.

Feel free to give some feedback if you start using the tool 🙂

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.

Say you want to store /etc/ufw/sysctl.conf which is owned by root:adm and has permission 644 in your repo, but also /etc/ntfy/server.yml which is owned by ntfy:ntfy with permissions 664. How do you keep track of this with gnu stow?

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).

It places you one year ago before they rebranded in rocq (obviously to stop the puns)

Ok, let me be more specific. Of course it delivers the audio, so you can technically say that i "works", that wasn't up to debate, you can deliver anything, actually. The problem is that it will never be viable. You shouldn't abuse the network, as it is a shared channel, when you use 2kbps to send your audio, no one else's can use it for messages, and viceversa, relaying many messages will limit your bandwidth.

You are trying to fit a square peg in a round hole, while instead there are tools designed for this purpose. It's kind of silly developing a roundabout way to send audio through meshtastic while every other amateur radio ecosystem is already designed for audio.

There is no way to make this work. As others told you, hex made it bigger, because hex is like equivalent to base16. Every digit in base64 is 6 bit, while in hex it's 4 bit. Raw bytes would be equivalent to base256.

You will not get a good result with this technology, it just can't handle the bandwidth, and will make it worse for everyone else by consuming their shared bandwidth.

Instead, try to look into midi and sound fonts, that might give you a more sustainable solution.

Converting binary to base64 makes the data 33% bigger, you should not do that when you have limited bandwidth

The Ali seller in question should be the official seeed store, so I should be fine