

This, make a partition thats a few gigs smaller than the drive, add the partitions to the storage pool instead of the raw drives.


This, make a partition thats a few gigs smaller than the drive, add the partitions to the storage pool instead of the raw drives.


Don’t think about drives in terms of reliability. Consider them a consumable in your storage system. The storage system should insulate you from the exact drives. Run a ZFS mirror or RAIDz2. Swap drives when they fail. The exact brand and model shouldn’t matter.


As always the social infrastructure (community, user base) is much more important for the success and use value of a piece of software than the exact technology used to make it (lang, framework, helper tools).


The upgrade was pretty trivial from 2.7.5. Minimal changes in the docker compose file if your was up-to-date on 2.7.5. Mostly version changes. No changes needed to .env other than going to v3.


Ahahaha, nice. Loosely reminds me of how we looked at implementing share-to-app (when that was a novel thing) in a mobile OS circa 2011 and we looked at how iOS did it. It was a list of hardcoded targets - Facebook, Twitter. No pluggability no nothing. Our product team was like - if no pluggability is good enough for Apple, it’s good enough for us!


What is it, restricted access? Am an Android user since 2008 and never had an iOS device so I’m clueless.


Wait for 3.0.3 and then the emergency 3.0.4. 😅


That’s probably coming too. This is the first preview of the feature.


Sounds like you should self-host Nextcloud with Tasks and Tasks.org on your phone. 😄


Upgrade guide from Immich v2 - https://immich.app/blog/v3-migration.


zpool create and docker compose up to you too!
RAIDz2 for 5.5TB with 2-disk redundancy.
All of a sudden USB becomes important. 😅


Coud probably be done. Find publicly shared Immich albums -> sync to Google Photos -> share publicly -> write the public Google Photos URL to the metadata of the Immich album.
Another could be an insulated public facing Immich instance that gets publicly shared albums pushed to it, the same way as with the other scheme. No reverse access to the private Immich instance. Then if that gets hacked, only those photos leak, attacker can’t get their hands on other server data. Assuming it’s really well isolated. A public VPS would probably be best for this.


It is but it requires public internet access to the Immich instance, or everyone involved being on our VPN. Reusing someone else’s publicly facing service to share photos from a private Immich instance is a clever workaround.
Time to setup an arr stack.


I think self-hosting has the expectation of the ability to self-host for indefinite period of time. E.g. I can run Jellyfin 10.10 for as long as I have the hardware and willingness to run it. A proprietary piece of software, say Plex, could technically allow that too, but that’s much less likely. Since I can’t see its source code, I can’t know if there’s a time bomb that stops it from working at some future date. Or an update/remote procedure I don’t know about that asks me to pay $750 at some point to continue using it. Which could preclude me from being able to continue self-hosting it. Is the ability to self-host indefinitely an expectation everyone shares? Probably not. Probably worth thinking about in this context though.


8.0.24


Have I not seen this because I’m using a fixed tag from sometime in 2024?
This reminds me it’s probably a good idea to setup a local container registry along with the services I run so I can keep access to the images long-term.


Are you using the All-in-One docker setup?
Folks who’ve used Linkwarden and archivebox, which do you prefer? Is one a superset of the other?