rentar42

It doesn’t exist.

Wait. Again?

I was answering under the assumption/the context of of “Amazon wants to release an Android-based OS that doesn’t contact any of Googles services”.

So, when I said “easy enough to remove” that was relative to releasing any commercial OS based on AOSP, as in: this will be one of the smallest tasks involved in this whole venture.

They will need an (at least semi-automated) way to keep up with changes from upstream and still apply their own code-changes on top of that anyway and once that is set up, a small set of 10-ish 3-line patches is not a lot of effort. For an individual getting started and trying to keep that all up to do date individually it’s a bit more of an effort, granted.

The list you linked is very interesting, but I suspect that much of that isn’t in AOSP, my suspicion is that at most the things up to and excluding the Updater even exist in AOSP.

Yes, but those minor traces are easy enough to remove, especially if you don’t care about being “ceritified” by Google (i.e. are not planning to run the Google services).

Not to diminish what Valve has achieved there (it’s an amazing PC/console hybrid, love mine).

But a smooth experience without any hitches is much easier to achieve when your hardware variation basically boils down to “how big is the SSD”. The fact that all Steamdecks run the same hardware helps keep things simple.

I guess that’s also the reason why they are not (yet?) pushing the new SteamOS as a general-purpose distribution for everyone to use. Doing that would/will require much more manpower.

Not OP, but as someone using Ubuntu LTS releases on several systems, I can answer my reason: Having the latest & greatest release of all software available is neat, but sometimes the stability of knowing “nothing on my system changes in any significant way until I ask it to upgrade to the next LTS” is just more valuable.

My primary example is my work laptop: I use a fairly fixed set of tools and for the few places where I need up-to-date ones I can install them manually (they are often proprietary and/or not-quite established tools that aren’t available in most distros anyway).

A similar situation exists on my primary homelab server: it’s running Debian because all the “services” are running in docker containers anyway, so the primary job of the OS is to do its job and stay out of my way. Upgrading various system components at essentially random times runs counter to that goal.

Woah … metacity brought back memories. Initially my reaction (comming from Sawfish/Sawmill) was “what? you mean I can’t script my window manager with LISP?!?”, but eventually its simplicity grew on me.

Free Ubuntu CDs were awesome back then. “What do you mean I can just order 10 and pay nothing, not even shipping and just give them away?!?”

Definitely beat having to order packs of Debian releases, because Internet was slow and CD burners were expensive.

How do you feel about Microsoft now owning GitHub ;-)

Just a little addition: the majority of things that people associate with Linux as per your first item are actually shared by many/most Unix-like OS and are defined via the various POSIX standards.

That’s not to say that Linux doesn’t have it’s own peculiarities, but they are fewer than many people think.

Screen prints (printed?)
Suddenly the Dungeon collapses!! - You die.. when the master process died unexpectedly.

Yes. Everyone can just release a tweaked Android version and Google can’t really stop them.

But if you plan to ship Google services (including the play store, which effectively makes a device an “Android device” in many users eyes) then you will have to be able to pass Googles verification suite.

That’s already the case today and adding new requirements to that in new Android versions happens all the time.