I personally use ~/.bin for my own symlinks, though I also use the user-specific installation instead of the system-wide one.
I wouldn't guarantee that any automation handles ~/.local/bin or ~/.bin either, that would depend entirely on the distribution. In my case I've added both to PATH manually.
Flatpak already creates executable wrappers for all applications as part of regular installs, though they're by default named as the full package name.
For when inkscape has been installed into the system-wide Flatpak installation, you could simply symlink it like; ln -s /var/lib/flatpak/exports/bin/org.inkscape.Inkscape /usr/local/bin/inkscape
For the user-local installation, the exported runnable is in ~/.local/share/flatpak/exports/bin instead.
The official binhost project has been an experimental thing until now, I've personally been using it for the year on multiple machines, but it's not been something that you can just enable. And it's definitely not been something that's come pre-prepared in the stage 3.
Reading the Dockerfile in their repo, it's simply a clean debian:slim with four compiled rust binaries placed into it. There's no services, no supervisord, nothing except the mail server binaries themselves.
Flatpak uses OSTree - a git-like system for storing and transferring binary data (commonly referred to as 'blobs'), and that system works by addressing such blobs by hashes of their content, using Linux hardlinks (multiple inodes all referring to the same disk blocks) to refer to the same data everywhere it's used.
So basically, whenever Flatpak tells OSTree to download something, it will only ever store only copy of that same object (.so-file, binary, font, etc), regardless of how many times it's used by applications across the install.
Note that this only happens internally in the OSTree repo - i.e. /var/lib/flatpak or ~/.local/share/flatpak, so if you have multiple separate Flatpak installations on your system then they can't automagically de-duplicate data between each other.
A lot of that data doesn't actually exist, ostree hardlinks data blobs internally, so the actual size on disk is much smaller than most disk usage tools will show.
Valve did purchase the for-profit MoltenVK layer and had it open-sourced under the Khronos umbrella, so they've already been happy to provide people a Vulkan-on-Metal solution for those who want to support Apple without an entirely separate rendering engine.
Probably not what you're looking for, but I'm going to note that Turris make some great OpenWRT routers.
Currently running theTurris Omnia, and using both Wireguard and Yggdrasil through it.
It could be that running the game at full speed causes some lock contention that doesn't happen when slowed down by the log stream.
Or it could also be that under normal gameplay your system spins down the harddrive to save power due to a lack of accesses, which would cause slowdowns and choppiness when the game suddenly needs to load something - also something which would be helped by running the log in the background.
For testing the second point, I'd suggest running something like this in the background while playing; (i.e. generating some constant load)
while true; do
uptime > $HOME/workaround-test
sleep 1
done
Not really, WSL seems like it was mainly supposed to stop people leaping ship to be able to develop Node without the horribly painful Windows JS experience. And wouldn't you know it, Microsoft has been making their own JavaScript language in Typescript.
Definitely the third / middle left, but the bottom right definitely gets second place to me.
Not a major fan of too abstract art, and those are just both so serene.
People love to complain about CMake, often with valid complaints as well. But it - to this day - remains the only build system where I'll actually trust a project when they say they are cross-platform.
Being the Windows maintainer for OpenMW, it used to be absolute hell back a decade and half ago when an indirect dependency changed - and used something like SCons or Premake while claiming to be "cross-platform", used to be that I had to write my own build solutions for Windows since it was all hardcoded against Linux paths and libraries.
CMake might not be the coolest, most hip, build system, but it delivers on actually letting you build your software regardless of platform. So it remains my go-to for whenever I need to actually build something that's supposed to be used.
For personal things I still often hack together a couple of Makefiles though, it's just a lot faster to do.
Ananace @ ace @lemmy.ananace.dev Posts 46Comments 166Joined 2 yr. ago
Why is it
.jpgand not.jxl? That's the registered extension for JPEG-XL.