I outlined some differences that could make it worth it over just interface binding for some. Another is that it makes it impossible to accidentally have another application exit through the tunnel, leaking your identity, like a browser logged into gmail.com. You have to explicitly set the container as proxy in the browser for that to become possible. It also allows using a separate VPN connection, provider or region for the torrent client, while the desktop user is free to use a different VPN connection or none.

This is why the most foolproof solution I’ve found is to use a docker container that has VPN and torrent client built-in. It’ll have the networking configuration done by someone who knows better. The most popular ones, like this, would permit no internet access out of the container outside of the VPN host. Then it doesn’t matter whether the torrent client binds to a specific interface or not, or what its configuration is. It’s trapped, or sandboxed, and the only way out is via the VPN tunnel. Once you have setup one of these, you can also reuse it from other containers with other apps, like your Usenet client, or even outside of containers via the built-in HTTP proxy. I know there’s also a qBit based container but I haven’t read into it or used it so I can’t vouch for it. The Transmission-OpenVPN based one is rock solid. Have used it for many, many years.

Whatever the repo is setup with.

Nice. So this model is perfectly usable by lower end x86 machines.

I discovered that the Android app shows results a bit slower than the web. The request doesn’t reach Immich during the majority of the wait. I’m not sure why. When searching from the web app, the request is received by Immich immediately.

You could absolutely do that and be fucked too. However the point of the pattern I suggested isn’t to replace the return with an assignment. That is, the point isn’t to do the exact same implementation and then do result = something before returning it. Instead it’s to use the initialized result var to directly store your result throughout the function, at every place where you manipulate it. So in this case my suggestion is to not have psize at all. Instead start with int result = -1; and return result; and do all the things you do to psize except on result. Then there’s a higher chance you will return the right value. Not a guarantee. I’m not at all implying that “if they only did this one thing, they wouldn’t have fucked up like this, so stupid” I’m merely suggesting a style that can decrease the probability of this type of error, in my experience. I’m teaching my team to write in defensive ways so they can feel some confidence in what they wrote, even if they slept 2 hours the night before, and also understand it after another bad night. Cause that ends up happening, life happens and like OpenZFS we also can’t afford serious bugs in what we do.

Scary indeed.

This one could be helped by always using this pattern whenever you write a function that returns a value, in any language, along with no early returns:

int func(...) {
    int result = -1;
    ...
    return result;
}

I always start with writing my result default value, ideally indicating failure, and the return line. Then I implement the rest. We often don’t have the luxury of choosing the language we work with that has the features we like, but consistently enforced code style can help with a lot of problems. Anyone can make mistakes like the one in this bug regardless of experience so every little bit helps.

I’d argue no state has any shortage of money, not only PRC. Financial capital in fiat systems is factually unlimited. The ability to direct it in areas of public interest instead of private financial capital’s owners’ interest is what the PRC has over many others. The real limits are the real resources that are needed for that industry and a major one is highlighted in the article - the lack of expertise. But this exercise, along with investments in higher education and pushing boatloads of people through it are building that real resource.

Makes sense. They make startups, many startups fail for all the reasons highlighted. Some don’t. That’s the point of using competitive forces to create an industry when you don’t know how to do something well. They did it with their EV industry, among others. I think they’re finishing the competitive stage where many firms fail and entering the consolidation phase.

All-in, I wanted something on the order of 1MB for client app, server, all dependencies, everything.

Okay that’s gotta be radically different!

Well, you gotta start it somehow. You could rely on compose’es built-in service management which will restart containers upon system reboot if they were started with -d, and have the right restart policy. But you still have to start those at least once. How’d you do that? Unless you plan to start it manually, you have to use some service startup mechanism. That leads us to systemd unit. I have to write a systemd unit to do docker compose up -d. But then I’m splitting the service lifecycle management to two systems. If I want to stop it, I no longer can do that via systemd. I have to go find where the compose file is and issue docker compose down. Not great. Instead I’d write a stop line in my systemd unit so I can start/stop from a single place. But wait 🫷 that’s kinda what I’m doing isn’t it? Except if I start it with docker compose up without -d, I don’t need a separate stop line and systemd can directly monitor the process. As a result I get logs in journald too, and I can use systemd’s restart policies. Having the service managed by systemd also means I can use aystemd dependencies such as fs mounts, network availability, you name it. It’s way more powerful than compose’s restart policy. Finally, I like to clean up any data I haven’t explicitly intended to persist across service restarts so that I don’t end up in a situation where I’m debugging an issue that manifests itself because of some persisted piece of data I’m completely unaware of.

Let me know how the search performs once it’s done. Speed of search, subjective quality, etc.

Why start anew instead of forking or contributing to Jellyfin?

The problem is that Grok has been put in a position of authority on information. It’s expected to produce accurate information, not spit out what you ask it for, regardless of the factuality of information. So the expectation created for it by its owners is not the same as that for Google. You can’t expect most people to understand what LLM does because it doesn’t scale. The general public uses uses Twitter and most people get the information about the products they’re being sold and use by their manufacturer. So the issue here is with the manufacturer and their marketing.

I use a fixed tag. 😂 It’s more a simple way to update. Change the tag in SaltStack, apply config, service is restarted, new tag is pulled. If the tag doesn’t change, the pull is a noop.

Let me know how inference goes. I might recommend that to a friend with a similar CPU.

Yup. Everything is in one place and there’s no hardcoded paths outside of the work dir making it trivial to move across storage or even machines.

Because I clean everything up that’s not explicitly on disk on restart:

[Unit]
Description=Immich in Docker
After=docker.service 
Requires=docker.service

[Service]
TimeoutStartSec=0

WorkingDirectory=/opt/immich-docker

ExecStartPre=-/usr/bin/docker compose kill --remove-orphans
ExecStartPre=-/usr/bin/docker compose down --remove-orphans
ExecStartPre=-/usr/bin/docker compose rm -f -s -v
ExecStartPre=-/usr/bin/docker compose pull
ExecStart=/usr/bin/docker compose up

Restart=always
RestartSec=30

[Install]
WantedBy=multi-user.target

Did you run the Smart Search job?

That’s a Celeron right? I’d try a better AI model. Check this page for the list. You could try the heaviest one. It’ll take a long time to process your library but inference is faster. I don’t know how much faster it is. Maybe it would be fast enough to be usable. If not usable, choose a lighter model. There’s execution times in the table that I assume tell us how heavy the models are. Once you change a model, you have to let it rescan the library.

Yes, it depends on how you’re managing the service. If you’re using one of the common patterns via systemd, you may be cleaning up everything, including old volumes, like I do.

E: Also if you have any sort of lazy prune op running on a timer, it could blow it up at some point.