That’s silly. Cat will get on your keyboard anyway. The only real solution is to get heated floors. So my cat prefers sitting under my chair or desk and never gets on it.
People tend to want some separation between what's theirs and what's others. Other programs/scripts quite often put something into ~/.local/bin, so it's not yours actually, it's theirs.
I personally use both, each for different purposes.
I snapshot my entire home directory every hour (using btrfs+snapper), but I exclude ~/.local/ from the snapshots. So I use ~/.local/bin/ for third-party binaries, since there's no reason to back those up; and ~/bin/ for scripts that I wrote myself, since I definitely want to back those up.
This is a pretty idiosyncratic use though, so I'd be surprised if many other people treated both directories this way.
I prefer ~/bin/ for my scripts, links to specific commands, etc.
~/.local/bin is tedious to write, when I want to see directory content and - most important - I treat whole ~/.local/ as managed automatically by other services and volatile.
Personally I use ~/opt//bin where ~/opt is a ‘one stop shop’ containing various things, including a symlink to ~/local and directories or symlinks for things that don't play well with others (e.g. cargo, go), and an ~/opt/prefer/bin that goes at the start of PATH containing symlinks to resolve naming conflicts.
(Anything that modifies standard behaviour is not in PATH, but instead a shell function present only in interactive shells, so as not to break scripts.)
Unix lore: Early unix had two-letter names for most common names to make them easy to type on crappy terminals, but no one* letter command names because the easier were reserved for personal use.
I thought was for mixin externally provided systems like Homebrew, local is for machine or org-level customizations, and ~ is for user-level customizations.
/opt showed up as a place for packaged software, where each package (directory) has its own bin/, lib/, man/, and so on, to keep it self-contained rather than installing its files in the main hierarchy. ~/opt is just a per-user equivalent, analogous to /usr/local vs ~/.local.
The advantage of /opt is that multi-file software stays together. The disadvantage is that PATHs get long.
I haven’t tried C3 myself, but I happened to interact a lot with Christopher Lerno, Ginger Bill and multiple Zig maintainers before. Was great to learn that C3, Odin and Zig weren’t competing with each other but instead learn from each other and discuss various trade-offs they made when designing their languages. Generally was a very pleasant experience to learn from them on how and why they implemented building differently or what itch they were scratching when choosing or refusing to implement certain features.
Competing with each other would be trying to one-up each other feature-wise, whereas what I have witnessed was things like discussing trade-offs made in different languages and juggling around ideas on if some feature from language A would make sense in language B too.
"Head over heels" is actually a corruption of "heels over head".
It's one of those corruptions which flips the meaning (ironically, in this case!) on its head, or just becomes meaningless over time as it's reinterpreted (like "the exception that proves the rule" or "begs the question").
This is such a mediocre article. It provides plenty of valid reasons to consider avoiding UUID in databases, however, it doesn’t say what should be used should one want primary keys that are not easy to predict. The XOR alternative is too primitive and, well, whereas I get why should I consider avoiding UUID, then what should I use instead?
I switched to Helix a year ago and I’m very happy about it. I used to spend way too much of my free time configuring my editor and now that I can’t do that I use my free time to actually write some code!
Because people broadly understand that service dogs are a legally protected thing but not the exact details of the relevant laws, and this leads to interesting consequences when combined with increasing awareness of mental health in recent years. Probably in another decade the controversy will have settled somewhat.
Video editing is not as portable as coding, there ain't no git. It doesn't surprise me that they have to do that, I imagine it's simply speedier and comfier to connect to a desktop that already has the work in progress in the latest state instead of ensuring everything is synced on different devices one uses. I also imagine that beefy MBPs with M3 and upwards could handle 4K editing of Severance (or maybe 8K) and they'd edit on local machines, should it be actually more convenient than connecting to a remote desktop. It's a bit shameful to admit, but still something we have to deal with while having such crazy advances in technology.
In principle a good editing tool could use Git for the edit operations (mere kilobytes!) and use multi-resolution video that can be streamed and cached locally on demand.
When I got into projection design I tried using git to keep track of my VFX workspace. After typing `git init` I heard a sharp knock at my apartment door. I opened it to find an exhausted man shaking his head. He said one word, “No.” and then walked away.
Undeterred by this ominous warning, I proceeded to create the git repo anyway and my computer immediately exploded. I have since learned that this was actually the best possible outcome of this reckless action.
All jokes aside, it's too big of a pain in the ass to have that stuff version controlled. Those file formats weren't meant to be version controlled. If there's persistent Ctrl-Z that's good enough and that's the only thing non technical people expect to have. Software should be empathetic and the most empathetic way to have the project available everywhere is either give people a remote machine they can connect to or somehow share the same editor state across all machines without any extra steps.
Will it lock the GIL if you use thread executor with asyncio for a native c / ffi extension? If that’s the case, that would also add to benefits of asyncio.
reply