>Why would you want this? What's the point of the server if you mirror deletes?
Sharing and backups, with the phone serving as the "source of truth" and the server as a replica that is more accessible to a partner/friend/etc than the contents of your phone's filesystem.
Sometimes, certain processes strongly predict bad outcomes, though.
If someone told me to choose between two barbecue restaurants, where one used an wood-fired smoker and the other used a microwave, my reaction wouldn't be "you really shouldn't judge based on just the process." The microwave is a sufficient indicator of low quality.
Vibecoding (as distinct from using AI as a resource while writing better code yourself) is the microwave: fast, hands-off, low-effort, low-quality.
The one caveat here is that, because Apple only really allows certain apps the privilege of running in the background without being interrupted or killed, I could never get the iOS version of Immich to reliably sync photos without having to manually open it and leave the app open until sync finished.
This was a few years ago, and was one of several "iOS breaks our crucial workflows" problems that motivated switching our last device over to Android, so the situation might be better now...but I've never had that problem with the Android client, so I know it's not an Immich problem.
You don’t need to run your app in the background. You can register your app as some extension to handle photo backups/cloud storage and you just setup a request to upload to a particular url when a new photo is added, iOS will background those requests and retry them and what not.
I read their "why use our fork" page, and it's very obviously AI-written, which causes me to distrust it.
As a happy Immich self-hoster, I'm not excited by the idea of switching to a fork written by folks who can't even be bothered to write their "why this fork exists" explanation themselves. It inspires very low confidence both in the quality of the many additions (because of the vibecoding) and the long-term sustainability of the project (because of the lack of any effort, and because vibe-coded one-offs tend to die faster than labors of love).
Buried at the very bottom of the wall of slop text on their "why our fork" page is this very last "FAQ" question:
>Why fork at all instead of upstreaming features?
>Several Gallery-exclusive features (Shared Spaces, Pet Detection, contextual filters) were either declined upstream, considered out of scope, or required architectural changes that wouldn't have fit Immich's roadmap. Forking lets us experiment without slowing down the upstream team — and rebasing means we never lose touch with their progress.
There's no mention there of "our vibe-coded implementations of these features were declined by upstream because we vibecoded them"; instead, they frame it as "upstream doesn't want these features for their users", with a dash of "upstream has made bad design decisions" (particularly the note about how upstream Immich "required architectural changes").
That's more than a little disingenuous on "Noodle Gallery's" part.
You’re reading that into it. That is not what it says.
So far the Noodle communications feel considered, professional and friendly (that’s what a Claude sub buys you), while the Immich communication is just “vibe coded”.
Okay - is the code bad? Are you collaborating to improve it? The answer appears to be no, for reasons hopefully better considered than “vibe coded”.
Coincidentally, Salesforce just laid off the senior engineering lead on their shared login service team who 2 months ago was describing the practices his team follows to keep 99.95% uptime on that shared login service (this guy: https://www.linkedin.com/posts/patricktprice_engineeringmana...)
Layoffs are usually short-term money-savers at long-term cost, but hot damn this is the shortest short term I've ever seen.
Nobody has said that, so you're arguing against a strawman. The parent poster made the argument that there's too much government regulation such that it causes fatigue and ignoring the rules, not that there should be zero.
Probably depends on how you came to the opposite conclusion; if peer-reviewed research showed that outcome, it'd probably be a lot easier than if it was just "I turned out fine."
I've read comments that sound just like yours from consparicists any time another study disproves links between vaccines and autism. You might consider whether the reason the opposite view isn't well-regarded is because it's disproven.
We're commenting on a site run by a Silicon Valley tech start-up accelerator. "Move fast and break things" is the accelerationist way, even if the "things" they break are a stable, functioning social order. As long as you IPO and cash out along the way, you can wreck everyone else's lives just fine, in the minds of this sort.
Sharing and backups, with the phone serving as the "source of truth" and the server as a replica that is more accessible to a partner/friend/etc than the contents of your phone's filesystem.
reply