I was in the same place as you a few years ago - I liked swarm, and was a bit intimidated by kubernetes - so I’d encourage you to take a stab at kubernetes. Everything you like about swam kubernetes does better, and tools like k3s make it super simple to get set up. There _is& a learning curve, but I’d say it’s worth it. Swarm is more or less a dead end tech at this point, and there are a lot more resources about kubernetes out there.

The early twenties intermediate dev on my team was explaining the other week that if you remember a time before smartphones and broadband, you are old

I personally am familiar with 2 organisations with millions of dollars in annual revenue that deploy critical line of business applications like this in 2024

They are, but I think the question was more “does the increased speed of an SSD make a practical difference in user experience for immich specifically”

I suspect that the biggest difference would be running the Postgres DB on an SSD where the fast random access is going to make queries significantly faster (unless you have enough ram that Postgres can keep the entire DB in memory where it makes less of a difference).

Putting the actual image storage on SSD might improve latency slightly, but your hard drive is probably already faster than your internet connection so unless you’ve got lots of concurrent users or other things accessing the hard drive a bunch it’ll probably be fast enough.

These are all Reckons without data to back it up, so maybe do some testing

Debian. When I have time to mess about with server stuff, I want to be doing the thing I want to do rather than fixing whatever broke in the most recent set of updates

I’ve not heard any out-and-out horror stories, but I’ve got no first hand experience.

I’m planning on picking up 3x manufacturer recertified 18TB drives from SPD when money allows, but for now I’m running 6x ancient (minimum 4 years old) 3TB WD Reds in RAID 6. I keep a close eye on SMART stats, and can pick up a replacement within a day if something starts to look iffy. My plan is to treat the 18TBs the same; hard drives are consumables, they wear out over time, and you have to be ready to replace them when they do

Taking donations for a specific purpose (developing jellyfin core) then spending it on something else (donations to other related projects) is something donors and tax authorities generally frown on

Pretty much - I try and time it so the dumps happen ~an hour before restic runs, but it’s not super critical

pg_dumpall on a schedule, then restic to backup the dumps. I’m running Zalando Postgres in kubernetes so scheduled tasks and intercontainer networking is a bit simpler, but should be able to run a sidecar container in your compose file

If you figure it out, I know several companies that would be more than willing to drop 7 figures a year to license the tech from you

git-annex maybe?

Yeah, they are mostly designed for classification and inference tasks; given a piece of input data, decide which of these categories it belongs to - the sort of things you are going to want to do in near real time, where it isn’t really practical to ship off to a data centre somewhere for processing.

Dealing with this at the moment - in an org that’s been pretty lax at writing anything down about what and why as far as internal software goes, trying (with support from C-suite) to get people to actually write up any amount of detail in their requests is like pulling teeth.

I tend to take that position as well; if it’s not defined, I get to define it. If I ask for feedback or review and get silence, that means you approve.

That’s not how Neon works. Your install will upgrade itself once the team have finished rebuilding everything on top of 24.04 - it’s happening, but it takes a bit of time

https://blog.neon.kde.org/2024/05/09/kde-neon-rebasing-on-ubuntu-noble/

It’s coming. It takes a bit of work to make it happen

Seems pretty reasonable. At the end of the day people have to eat, so projects like this either trundle on as hobby-and-spare-time projects for a few years until people get bored and burnt out, or you find a way to make working on the project a paid gig for the core people

This is an “x-y question” - what are you actually trying to achieve?

Clearly you are concerned about… someone… knowing your home IP address - who, and why?

Removed by mod

Definitely interested - is the mainline situation any better than with ARM?

I’ve been bitten before with a device that “supports” a major distribution, but only if you install our custom pre-built image (good luck auditing what we’ve tweaked) and only with our special pre-built kernel that isn’t even an LTS version, and has a bunch of patches applied to support whatever weird peripherals we decided to throw on the board, and will get exactly 0 updates after the initial release.

Raspberry Pi gets around this by being big enough to get buy in from vendors (Ubuntu distributes a special kernel + firmware bundle), but support for all the other smaller knock offs seem shaky at best

As in, hardware RAID is a terrible idea and should never be used. Ever.

With hardware RAID, you are moving your single point of failure from your drive to your RAID controller - when the controller fails, and they fail more often then you would expect - you are fucked, your data is gone, nice try, play again some time. In theory you could swap the controller out, but in practice it’s a coin flip if that will actually work unless you can find exactly the same model controller with exactly the same firmware manufactured in the same production line while the moon was in the same phase and even then your odds are still only 2 in 3.

Do yourself a favour, look at an external disk shelf/DAS/drive enclosure that connects over SAS and do RAID in software. Hardware RAID made sense when CPUs were hewn from granite and had clock rates measures in tens of megahertz so offloading things to dedicated silicon made things faster, but that’s not been the case this century.