Summary of my comment: the study showed that the AI tool in question was an effective tool for the task, nothing more.

I didn’t read this particular article, but I recently read a different one about the same study. I also clicked into the study itself and read the abstract and everything else that was freely available. The study was paywalled, but as far as I could tell:

• Performance immediately displayed a sustained increase of 24% relative to baseline while using the AI tool in question
• Immediately after the tool was taken away (after using it for three months), performance was 20% lower than the baseline
• The study did not check to see what level performance returned to after three months without it, nor when it returned to baseline levels
• The study also did not compare performance drops after returning from a three month vacation
• The study did not compare performance drops when losing access to other tools

This outcome is expected if given a tool that simplifies a process and then losing access to it. If I were writing code in Notepad and using _v2, _v3, etc for versioning, was then given an IDE and git for three months, then had to go back to my old ways with Notepad, I’d expect to be less effective than I had been. I’ve been relying on syntax highlighting, so I’m going to be paying less attention to the specific monochrome text than I used to. I’ll have fallen out of practice from using the version naming techniques that I used to use. All of the stuff that I did to make up for having worse tooling, I’m out of practice with.

But that doesn’t mean that I should use worse tools.

I still wouldn’t call a car an “investment” or anything, but 100% agreed. The whole “cars lose 50% of their value when you drive off the lot” thing might have been true before the Cash for Clunkers program, but it isn’t anymore. Or maybe it’s true if you’re trying to trade-in the vehicle.

If I wanted to buy the (fairly popular) car I’ve been driving for over 6 years with the same mileage, it’d cost me over 2/3rds what it cost new When I bought it, new cars were less expensive than used cars (i.e., like less than two years old with less than 25k miles) thanks to how much better the interest rates were on the loans. A couple years later, I was getting offers for more than I paid for it. And none of that is a unique experience.

In fact, Redot has had 13 releases since the project started late last year.

With an absolutely massive number of commits since then.

An absolutely massive number of commits that were originally made to Godot, sure. Redot has 118 more commits than Godot as of the time of this writing (76,344 vs 76,266). That’s not even 1 original commit per day.

I genuinely don’t understand why people here are taking it so hard that I wish the Immich devs were using semver.

Because you didn’t say that; you said “Breaking changes in a point release? Not cool” and later “I’m basing this off the guidelines at semver.org.”

I’m paraphrasing your comments from memory, to be clear, so apologies if I misquoted you.

It certainly felt to me like you were assuming that this project was using semver and was not following it well, not that you wouldn’t want to use a project that receives this many breaking changes / that doesn’t follow semver. Those complaints both make a lot more sense to me - and I’ve seen many people say similar things about Immich in the past. In fact, it’s a big part of why I haven’t migrated from Photoprism to Immich myself - in this regard they’re complete opposites.

I don’t think there’s any room to argue that announcing a 1.x with a change the developers say is a breaking change, which is what Immich have done, fits within the semver.org guidelines.

That wasn’t the argument.

Following semver is optional. If a project doesn’t explicitly state it is following semver, it shouldn’t be assumed that it is. With regard to Immich in particular, a cursory review of their documentation makes it clear that they are not following semver. Literally, go to https://immich.app/ and read the text at the very top of the page:

⚠️ The project is under very active development. Expect bugs and changes.

Go to the repo and you’ll see the README, which states at the very top:

• ⚠️ The project is under very activedevelopment.
• ⚠️ Expect bugs and breaking changes.

If you can read that, see that they’re on major version 1 with a minor version over 100, and you still think they’re using semver, then that’s on you.

The devs have stated they won’t be using semver until they consider Immich production ready, and that moving to a 1.x version from 0.x was a mistake made some time ago. If you want to think about it as though it is semver, consider the major version to still be 0. See https://github.com/immich-app/immich/discussions/5086#discussioncomment-7593227 for example.

As this project is clearly not following semver, the semver guidelines aren’t applicable and haven’t been violated.

I don’t think there’s any room to argue

Even if semver were applicable, in this case, I would still disagree. The text from semver.org states:

8. Major version X (X.y.z | X > 0) MUST be incremented if any backward incompatible changes are introduced to the public API.

It doesn’t state that any backward incompatible changes, period, require a major version increase, only changes to the public API. I would personally argue that the deployment configuration is part of the public API, but not all project owners agree with me. Even if they do agree, they might say that this was not a documented deployment configuration and thus not part of the public API, and that it therefore doesn’t necessitate an increase to the major version, but as they knew that people were using that configuration, anyway, they included a note about a potentially breaking change as a courtesy to those users.

Immich isn’t a library (the main use case for semver is dependencies that will be pulled into other projects) and as far as I know they don’t state that they use semver.

There have been so many places in front end web dev that used the abbreviation “a11y” without defining it (or explaining the 11) that for years I assumed it was just the name of a particular library that had gotten Kleenexed.

(To be clear, I’m using “Kleenexed” as a verb here to mean “genericized explosively, as if a sneeze.”)

It didn’t help to look at the code, either. “Okay cool, so all this does is add a bunch of random extra tags to the DOM? Doesn’t seem super useful but okay, I guess there’s probably some tool out there that depends on them but we probably don’t use it.”

I’m lucky enough to be able to budget for things I want. If it’s in the budget, no justification is required. If it’s in the budget but expensive, then I just have to figure out if I want it more than the other things I want (or will want) that I won’t be able to afford as a result.

I hate how much I agree with you in principle and how ugly it looks in practice. With doubled periods, at least - different marks don’t trigger that same reaction. For example, a question mark inside, followed by a period or comma outside feels right.

It’s not grammatically incorrect to end a sentence with a preposition. It’s a common misconception that it is a rule, basically because one guy argued in favor of it back in the 1600s and had some support for formal writing in the 1700s. But it’s never been a broad rule, and even in formal contexts it’s not a rule in any current, reputable style or usage guides (so far as I know, at least).

Some more info on the topic: https://www.merriam-webster.com/grammar/prepositions-ending-a-sentence-with

When did Democrats have a supermajority in both the House and the Senate?

Okay, and? What nontechnical user cares enough to use it specifically when they could use Microsoft Office, Google Docs, Polaris Office, MobiOffice, WPS Office, Collabora, etc., instead?

But do nontechnical users care about the “missing” features? A lot of nontechnical users prefer simpler apps.

There is a version of Blender that was made for Android. It’s quite old, though. But if you’re competent enough with Blender that you’ve memorized all its keyboard shortcuts and workflows, you’re likely technical enough to get it working via Termux. But if not, Nomad Sculpt (on both iOS and Android), SpaceDraw (Android only), and several other apps can serve the same purposes.

Not sure why you listed video editing software and two different specific video editors, but Android and iOS both have Lumafusion. I’m sure there are other decent editors but I haven’t used them because Lumafusion is great. iPads do have DaVinci Resolve, though, for what that’s worth. If you care about using a FOSS video editor then you should care enough to install it via Termux. But let’s be real, most nontechnical users are probably happy using CapCut.

DJ software - Cross DJ is free. There are other alternatives. And there are web based DJ software apps like YouDJ.

The products currently on the marketplace have architectures that are far more sophisticated than just an LLM. Even something as simple as “Deep Research,” which both Anthropic and Claude have available, is using multiple interconnected systems to provide a single response.

Consider Agentic AI, like Claude Code, where they’re using tools, analyzing the results of those tools, iterating, possibly calling out to MCP servers to do other things, etc… The tools allow them to do things like read or modify files in the working directory, execute programs (i.e., your linter, installing dependencies, running your app), querying against your app itself, and so on.

And of course note that the single “Claude” box in that diagram has an architecture that’s more sophisticated than just being an LLM. At minimum, consumer facing LLMs generally have a supervisor that censors problematic inputs and outputs; this doesn’t make the system more competent but the same concept can be applied to any other sort of transparent wrapper.

It seems to me that we already have consumer systems that are doing what you described, and we’re already working on enhancing their architectures further.

OnlyOffice is available on Android already.

“any linux app” - I don’t think any nontechnical users want GParted on their Android phones, and it wouldn’t work anyway.

Android has its own games, same as iOS. Nontechnical users are way more likely to want Windows games than Linux games anyway.

Wine used to be developed natively for Android but they stopped a few years back. You can still download it at winehq though. I think Box64 with wine is a decent option?

Overall the thing I’m confused about is why you think Google or any major Android phone manufacturer have a motivation to make native Linux apps more accessible. Google certainly doesn’t want to make it easier for you to use the better versions of their competitors’ apps. Google is moving further away from Linux, not closer. Providing a usable, good enough desktop experience that’s still Android underneath makes far more sense for them.

Fortunately, like I said earlier, there are workarounds to get access to those Linux apps.

The thing that is more likely to change is for the creators of Android apps to build apps that function better when used in a phone-as-desktop format. And even if they don’t, there are enough competent web apps out there that just being able to use your browser full screen on a monitor solves 90% of people’s actual use cases - and probably over 95% when you include the other apps that have decent desktop experiences that can be run alongside them.

The Steam Deck approach is much closer to what you seem to want. The Steam Deck is an actually competent Linux machine that has a Valve-supported compatibility layer in Proton for running non-Linux games. It plugs into a USB-C hub connected to a monitor, mouse, and keyboard just fine, can install any Linux app, etc… It’s completely usable handheld as well. But it isn’t a phone, and even though it’s quite portable, it’s not “stick into your pocket” portable.

I don’t expect a major manufacturer to make a Linux phone any time soon, and I don’t think the Linux phones that are out already have - or will have in the next 5 years - a smooth enough experience to convince any nontechnical user to switch.

There are mobile versions for all of those?

What are the gaps in functionality for nontechnical people? And “apps that exist on Linux but not Android” doesn’t count, because such people are unlikely to have ever even used a Linux desktop in the first place. The improvement that matters won’t be Linux apps; it’ll be Android apps that are more usable in desktop mode.

That said, what are the issues with the apps that are currently available?

If a user installed Chrome, an office suite (whether that be Google Docs, Sheets, and Slides, the Microsoft equivalent, or something else), an email client, and other commonly available apps, what tasks would they be unable to complete, if any?

Are these, or other commonly used apps, substantially less usable than on desktop? If so, how so?

Can’t you just use GNURoot Debian and XServer SDL to get a Linux desktop env on any Android phone?

There’s an xda-developers guide on this and the two apps are still in the Google Play Store, so I assume it’s still feasible.

I’m not sure how well it plays with DeX and other similar solutions, though.

That’s assuming the apps aren’t capable enough to handle being used on a desktop on their own, of course. What sorts of gaps did you see, and in which sorts of apps?

This is already a thing

Samsung DeX was the first big one but there are a bunch of competing ones that do similar things now.

What’s been stopping them?