I hope someone will create a Debian package for Immich. I’m running a bunch of services and they are all nicely organized with user foo, /var/lib/foo, journalctl -u foo, systemctl start foo, except for Immich which is the odd one out needing docker compose. The nix package shows it can be done but it would probably be a fair amount of work to translate to a Debian package.

I'll try to install in a short-ish while, and look into its installation in a detailed manner.

I may try to package it, and if it proves to be easy to maintain, I might file an ITP.

You could try setting it up as a Podman Quadlets, those hook into systemd so you can treat them like a normal service.

I have a few different types of content on my website and wanted to offer both individual feeds and a combined feed, so I was disappointed that nothing seems to support the category tag. I settled for prefixing the titles in the combined feed, e.g. "[Blog]" for blog posts.

I think the new async IO is great in simple examples like the one shown in the article. But I’m much less sure how well it will work for more complex I/O like you need in servers. I filed an issue about it here: https://github.com/ziglang/zig/issues/26056

It’s not the same situation because with async/await you end up with two versions of every function or library (see Rust’s std and crates like async_std, Node’s readFile and readFileSync). In Zig you always pass the “io” parameter to do I/O and you don’t have to duplicate everything.

Colors for 2 ways of doing IO vs colors for doing IO or not are so different that it’s confusing to call both of them “function coloring problem”. Only the former leads to having to duplicate everything (sync version and async version). If only the latter was a thing, no one would have coined the term and written the blog post.

IMO the problem was never about it actually doing IO or an async actions or whatever. It's about not being able to a call a async function from a sync function. Because in my experience you almost never wholesale move from sync to async everywhere. In fact I would consider that an extremely dangerous practice.

If everyone did that, lots of people would still die of preventable causes in poor countries. I think GiveWell does a good job of identifying areas of greatest need in public health around the world. I would stop trusting them if they turned out to be corrupt or started misdirecting funds to pet projects. I don’t think everyone has to donate this way as it’s very personal decision, nor does it automatically make someone a good person or justify immoral ways of earning money, but I think it’s a good thing to help the less fortunate who are far away and speak a different language.

I installed Jellyfin on my home server a few months ago but it’s already broken by upgrading to 10.11, and unusable until I restore 10.10 from backup or start over: https://github.com/jellyfin/jellyfin/issues/15027. There seem to be lots of other database migration bugs for this release and other ones.

Yeah, I've been afraid to upgrade because I've been following these updates. I'm going to wait until the dust settles a bit before upgrading because, as stated, I don't really enjoy larping as a sysadmin anymore.

I use Docker on Linux for this kind of thing (Jellyfin, Nextcloud and a few others) and updates are completely trouble free. I would never deploy complex "black box" apps like Jellyfin bare metal. That being said, I do run my email stack bare metal as I want fine control. Everything is hosted at home on my own hardware and I would never consider moving my computing to the "cloud."

In FreeBSD you typically install them in a jail.

Update: I just tried upgrading again (from 10.11.1 to 10.11.2) and it seems to have fixed things!

Would you ever really use that? That just shows how bad it is, IMO. Any time I want a sum type I want names, not hardcoded integers.

I wouldn't use it (in any language), but the claim was that it is impossible. It isn't.

I treat std::variant the same way I treat std::tuple, which is that I use them internally/privately and don't expose them as part of a public API.

If I want to expose a std::variant publicly then I take the effort to emulate Rust, which I think everyone agrees has an incredibly useful and elegant enum type so it looks like this:

    int main() {
      auto s1 = ConnectionState::Disconnected();
      auto s2 = ConnectionState::Connecting(3);
      auto s3 = ConnectionState::Connected("192.168.1.5", 8080);

      for (const auto& state : {s1, s2, s3}) {
        state.visit(
          [](Disconnected) {
            std::cout << "Disconnected\n";
          },
          [](int retries) {
            std::cout << "Connecting (" << retries << " retries)\n";
          },
          [](const IpAddress& ip) {
            std::cout << "Connected to " << ip.host << ":" << ip.port << "\n";
          });
      }
    }

To implement that I currently do need to write out boilerplate like below, but with C++26 I will be able to use the upcoming reflection feature to automatically implement the bulk of this code by reflecting on the std::variant directly:

    class ConnectionState : private std::variant<std::monostate, int, IpAddress> {
      public:
        static auto Disconnected() { return ConnectionState(std::monostate{}); }
        static auto Connecting(int retries) { return ConnectionState(retries); }
        static auto Connected(std::string host, uint16_t port) {
          return ConnectionState(IpAddress{std::move(host), port});
        }

        template <typename... Fs>
        decltype(auto) visit(Fs&&... fs) const {
          auto visitor = Overload{std::forward<Fs>(fs)...};
          return std::visit(visitor, *this);
        }

      private:
        using std::variant<std::monostate, int, IpAddress>::variant;
    };

    using Disconnected = std::monostate;

...

> For most "good enough" use cases, garbage collectors work fine and I wouldn't bother with a system's programming language at all.

It's not just about performance, it's about reusability. There is a huge amount of code written in languages like Java, JS, Go, and Python that cannot be reused in other contexts because they depend on heavy runtimes. A library written in Zig or Rust can be used almost anywhere, including on the web by compiling to wasm.

Another thing to watch out for with SVGs is how they appear in RSS readers or browser reader views. If you're using external SVG files then it should be fine. If you've optimized them by embedding into the HTML, then you need to be careful. If they rely on CSS rules in the page's CSS then it's not going to work well. For my website I try to make the SVGs self-sufficient by setting the viewBox, width, and height attributes, using a web safe font, and only relying on internal styles. You can still get some measure of light/dark mode support by setting fill or stroke to currentColor.

My advice, for web pages: always specify the <svg> width and height attributes, or the width and height properties in a style attribute, because if non-inline CSS doesn’t load (more common, for various reasons, than most people realise), the SVG will fill the available width. And you probably don’t want your 24×24 icon rendered at 1900×1900.

(For web apps, I feel I can soften a bit, as you’re more likely to be able to rely on styles. But I would still suggest having appropriate width/height attributes, even if you promptly override them by CSS.)

This, so much this. It is extremely annoying when I have a slow connection and I have to scroll down ages to get to the page content.

They appear to have “solved” the RSS problem by only providing one sentence of content with each entry in the RSS feed.