Hacker News Reader

> Ironically, just after posting that I came across this, which I think proves why my concern is warranted: https://news.ycombinator.com/item?id=45169657

> Debian isn't immune to this, but it's much harder for such an attack to be successful when dependencies aren't constantly changing.

Immich is more immune to this issue because they wait 5 days before raising PRs to bump dependencies, which is a good practice https://github.com/immich-app/.github/blob/main/renovate-con...

OK, more maybe, but that is nothing next to Debian, where a huge Debian userbase settles on a single set of versions for all dependencies for a year (usually more) at a time.

I would expect an operating system and a single application have a different approach to dependency management.

Debian is both an operating system and a distribution of single applications. Its (excellent) dependency management applies to both. It doesn't have a software supply chain problem because it takes dependency management seriously.

I've been keeping my eye on Immich for a while and keep waiting for a stable release to try it out, but that hasn't happened yet. I'm also dreading having to setup proper backups if I were to switch to this over Google photos. My current solution is to backup critical homelab things to Google Drive automatically but I'd want a proper off-site backup if I were going to self host all my photos.

I quite like their backup story. Immich has one folder that you need to backup. It stores file and dump of db that immich does on schedule. I don’t care that much about db dump but backuping photos os very easy

So you use Google Photos and backup to Google Drive? Sorry to say, but if Google ever decides to deactivate your account (which can and will happen for any reason, real or imagined), you lose everything.

A stable release is only a couple months out. Maybe do a Takeout until then, and put it in S3 Glacier, or similar?

To be fair, there’s a massive banner on their front page warning users it’s in beta. Until they settle on a proper release it’ll continue to be a bit chaotic. All software development is like that.

This looks like one of those projects that will never settle and have a stable slower release cycle.

I don’t think so. They are steadily approaching their defined and published goals for stable release. I’m guessing it will come this year.

v0.46.4_p3

This looks like a project that’s under heavy development (it is) responsibly keeping up with dependencies. This gives me more confidence, not less.

To be honest, a decent image server that can be the root server for a CDN and do the right things with modern web formats is something that should be standard and built in by now, with nobody needing to build and install their own.

That said, this is far better than my own non-existent image server.

For me a measure of quality is the rendered HTML code, which should use all the content sectioning elements and not be bloated with gazillions of divs and classes. This software is well off the pace in this regard.

Why is docker compose a red flag? That feels like a benefit to me.

100% -- firs time I have seen providing a docker compose file is a sign of weakness.

Yeah... I'm not sure that I've ever seen a complex app with multiple, separate service/database requirements (redis, pg, etc) packaged in a Linux distro repository... but I could be wrong.

controversial but docker compose is for development and demos. for prod give me a binary, a config file / systemd unit file, and tell me how to configure external dependencies and let me decide how to manage them.

and if you're serious, k8s config. otherwise don't waste my time.

But this is for running on an old PC in your closet next to your router. Not serving 40k concurrent users. I would not even consider trying to scale it past a dozen family members. And anytime I run an upgrade or config change I just do it in prod.

You can get all that information from a compose file.

Waste your time? You know what would waste my time? Building out my own deployment of Redis/Postgres, all the dependencies, systemd services, ML server, and backup solutions (yes, the compose takes regular DB backups for you) and then keeping it all updated manually, just to host photos on my local network for my family of 4. Do you think making your life needlessly difficult is a feature? Then read the docs and deploy to a K8s cluster. Nothing is preventing you from doing that.

It's not a problem that Docker Compose can be used and a configuration is provided. What's an indicator of a dependency problem is when it's the only way to deploy the software. If, instead, they could say "all required dependencies ship in Debian at a sufficient version to meet our requirements" then that would be ideal (Debian isn't a hard requirement for me, but I use it as an example since it sets a bar similar to the one I want software I deploy to meet). Or even just "nearly all dependencies except this one" would be much better.

You want to run it in docker and manage it with some tool. I use dockge and click the upgrade button every couple of days / weeks (when the app or website tells me). that's it.

Immich is an excellent piece of software, I have switch all my photo needs from over 25 years to it. It will mature and it actually already is. Don't hold yourself back with such practicalities.

Are there any/many applications that require a configured database (like PostgreSQL) and Redis/Valkey in Debian's package manager at all?

Also, Docker-compose is pretty great in terms of getting complex applications up and running.

so you find it too immichure? <jk>