

For my computer science internship I just dodged a drone-shaped bullet… I’m working on abstract verification of access policies instead


For my computer science internship I just dodged a drone-shaped bullet… I’m working on abstract verification of access policies instead
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).
How do we know what the trees looked like? I thought they got buried and crumbled into carbon or something


ISO/OSI is a neatly separated model mostly used on theory.
In practice, actual network stacks are often modeled after a simpler model that is called TCP/IP. Which despite the name is not actually TCP specific.
Here’s the general description and correspondence to ISO/OSI:
Or, you can just not care about how the actual software stack is separated, and continue to use the most complete model, knowing that everyone will understand what you when you say “layer 2/3/4” anyway.
Plus, some could say that the TCP/IP model is equally unfit because the Linux network subsystem doesn’t care about layers.
Edit: I hope the formatting of that table isn’t broken on your client, because it is on mine


It places you one year ago before they rebranded in rocq (obviously to stop the puns)
Then, the year of the freebsd desktop came many years ago when apple released MacOS
Ok, but what’s the situation in this one?


What disconnecting problem?


My system should be fully updated, I will try an Xbox 360 cabled controller


That’s a flattering thought, but I think that kind of improvement is a pipedream.
The os shenanigans might be the reason tho


You are correct, it also lacks a decorative groove that the “one” one has near the top.
I think the “series” d-pad is the best modern d-pad, especially since Nintendo forgot how to make them just before releasing the Wii u. I’d say on par with classic Nintendo d-pads, maybe a bit less comfortable for platformers though.
On the other hand, the 360 d-pad is the worst most horrible piece of crap ever devised.


I am seeing higher latency even plugged via cable though, even if less so


No, kde on amd
Noooooo 😭
It’s not the kind of validation I do tho 🤓😉