If you build a linked list in C, and put the pointer to the next entry as the first element in your struct, then you only need a single variable (and two comparisons) to do sorted insertion into the list.
ace
joined 2 years ago
Steve Rogers might have America's Ass, but Mothman has the Buns of Steel.
Here's a .jxl JPEG-XL upload I did on Lemmy three days ago;
https://lemmy.ananace.dev/pictrs/image/ad4e745e-0135-4cc3-889c-052600828d82.jxl
The built-in Firefox support is only activated for unstable builds, so you can't enable it on stable unless you manually enable it during compile-time.
Why is it .jpg and not .jxl? That's the registered extension for JPEG-XL.
People really have no love for JPEG-XL - though to be fair that's mainly Google's fault at the moment.
Haven't really used any proper JMAP clients - since the setup is broken anyway, so mainly just curl.
You could also just run IMAP/JMAP/SMTP as separate components, I can't see any place in the Stalwart documentation - or in the Docker image itself - where monolith is the only option.
I haven't tested the setup myself yet, but me and another root are planning on testing a setup of Stalwart to replace a semi-broken IMAP/JMAP setup for a computer club, keeping the SMTP as is.
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.
This looks really odd in relation to other fediverse software; Why
/magicand required to be on the root of the domain? Why hard-require routing the domain part of the user ID when.well-known/webfingerexists? Why is there aX-Open-Web-Authheader which the spec only describes as "its purpose is unclear from the code"?So many questions.
I definitely like the idea of distributed sign-in, Solid did a decent work of that many years ago after all. This particular proposal just looks rather odd.