ubertaco

I think you misspelled "perps"

>University of Michigan professor Jenny Radesky, a pediatrician who has extensively researched screen use among children, said problems can arise when tablets are allowed to serve as a “child’s always-available buddy, meaning it is taken everywhere to help manage the child’s behavior, calm them down, or keep them quiet.”

Yeah, that's the crux of the problem. The goal of parenting is not to keep your kids quiet and calm. That's nice to have, and as someone with a toddler myself I get the desire for it sometimes.

The goal of parenting is to raise a healthy human being. Managing kids as problems to be solved instead caring for them as people to be nourished (not just physically with food, but emotionally and mentally) hardcore misses the mark on a fundamental level, in ways that harm your child directly and society more generally (since it's common for children to internalize and repeat their parents' patterns of behavior).

You're thinking of "South America" (parse as "South America + n", or "from South America").

So what I'm hearing is that when it comes to cheap, clean, consumer-empowering energy, the USA tends to regulate, not innovate.

I've used libraries before, where I call the API surface that they expose based on method names and parameter types, without reading all the source. Generally those libraries don't implement my software's entire problem domain area; they tend to implement things like "CSV parser" or "HTTP server". The important code, that I'm actively reading and writing, tends to be the code around those library calls.

This is different from building a product, which you only interact with via UI buttons/CLI/etc, without reading any code to understand how it conceptualizes that product's problem domain area.

People do that latter thing, and we call them "users", not "developers".

If you believe like some guys do that you can just point a camera at any painting in the world and replicate it, what is the point of painters again?

(i.e. the ability to copy existing things does not obsolete the need to be able to make new things)

>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.

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.

To quote a comment I saw either here on HN or on Lobsters (can't remember which):

>A vibe-coded password manager? Sign me up!

Yeah, if only the government didn't regulate that pesky

checks notes

workplace safety, then for-profit companies could be free to act for the good of all, like they always do!

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.