Ask HN: Why is there no major push towards Android for Servers and Desktops?

1. There are no steam deck games, because most don't want to write for two different systems 2. Android apks are like deb, rpm, ... but they contain most of their dependencies by themselfs. On fact they use an seperation maintained by selinux (prohibits access to resources they don't have permissions to) and seperate users. some deb packages can do exactly this process of setring up the software and connect to the database out of the box.

It sounds like you are talking about snap or flatpak. These are extremely unpopular on HN.

You maybe on to something here but do remember that ChromeOS was released by Google in addition to Android to cater for the laptop and low end desktop market.

Friend, android on servers sounds like a nightmare.

But, chromeos is sort of like that and GKE nodes use it to run k8s stuff. I can see it being used to run containers like that, although with much disdain.

I can see an android inspired thing but android with it's app stores and rather peculiar administrative burden would make a bad fit imho.

Fyi: there are android laptops and desktops but nobody likes them.

I mean, I hate android but I hate all populat mobile OSes compared to desktop and server variants because of UI , walled garden and severe restrictions.

[dead]

I really don't want Android on my server, very hard to audit, made with manufacturers in mind and not device owners, it's not fit for the purpose.

I'd like the opposite actually, a push to standardize Android into a proper Linux distribution and not the Frankenstein that it became.

Your arguments make sense however consider the following:

We don't change anything. Management likes this because we don't incur extra costs developing, training, deploying, advertising, and using this new paradigm.

On top of that, you're asking devs and sysadmins to entirely change the way they're doing things. Maybe the returns are actually worth it, but either your idea has very little market penetration and why would anyone spend the time to learn it, or it does (how?) And you're training yourself on an entirely new system with no connection to the old one, effectively learning your entire job again.

To put it simply, the reason we're not doing it is that we're not changing things at all, for the most part.

Your comment on complex deployment reminded me of https://git.cloudron.io/cloudron/box#cloudron - "Web applications like email, contacts, blog, chat are the backbone of the modern internet. Yet, we live in a world where hosting these essential applications is a complex task."

What you are saying is so true. I don't understand why no standardization work is being done to make server deployments simpler with high reliability. We have some takes like cloudron, sandstorm, yunohost but nothing is "mainstream".

Steam deck is linux based but, objectively, was built and has a purpose of running stuff, made for windows. It has benefit of Photon, that was built on top of Wine, the tool with *very* long history of building windows compatibility layer.

No. Android is very unreliable and crashes often. It's a terrible platform.

Keep in mind, that little stability it does have is for mobile loads not server loads.

It is insecure and most of the security is applied by a poor mans implementation of containers. The rest is done through appstore scanning, restrictions and limitations on who can publish an app.

I know we love to reinvent the wheel here but come on. Dead simple Linux is too programmable, does too many things, so we have to layer Android on top of it so we can do fewer things and then it's magically okay? This must be a joke.

That sounds like shoehorning Android into a place it does not fit in. It is essentially a single-process OS, only the running app gets all the resources it needs. It is an UI-focused OS, nobody is using Android without an UI. It is a single-user OS. It does not provide a consistent computational capacity since things get put to sleep as fast as possible.

None of those things you'd want in a server OS.

> Why is the Steam Deck Linux based while Android hardly has any decent games?

This is entirely a market issue; you can port Unity games provided you can adapt to the weaker GPU, but you have to deal with the small screen and touch controls. Plus people have got used to everything being free on Android, so the really big money makers left have to be gatcha-monetized.

> On Android you don't need all kinds of containerization nonsense with 100MB packages for even the tiniest things.

Have you looked at some Android package sizes lately? They all bundle their dependencies.

You should check the app sizes on Android - I've got very few under 100MB and that's exactly because they ship all the needed dependencies with them. That's how you avoid the issues during upgrades both on the phones and servers.

The phone apps don't use the exact same system for it, but essentially they're fully isolated in a similar way containers would be. The only difference is what is provided by the system and what by the app.

Flatpak can also shift the GUI into the base layer, so for example on Fedora Silverlight you can have a barebones system which uses a shared gui layer for most installed apps. (CoreOS is a similar idea, but for the server side)

> It's not hard to imagine extending that model to cover things like databases

Databases are not interchangeable beyond trivial examples. But a plugin system like that exists - odbc.

> when the app can just say "Hey, I need to make a database, I can use ...

This can be already solved with either full system configuration (Nixos) or containers (docker-compose does pretty much that). Those are sane and structured as well and they're available now.

If you want to go one layer higher (lower?), you can build a similar environment with AWS cloudformation - they can provide you with app containers or isolated functions, ready databases, all the connections in between.

> Apps use things far slower than Dart and Kotlin and Android API calls all the time.

Yes, but on the phone your app may just take slightly longer. On the server side a common case taking longer means everyone else waiting a bit longer and the whole thing translates to more money spent on infra. Those are different failure cases / requirements.

> Why are we not managing our web apps by uploading a single APK file and a settings.ini with the permissions we want to give it?

Many of us are doing basically that. The APKs are container images / static binaries / other kind of packages though. My whole server is one Nixos configuration file for many services and packages for example. Some older systems won't change overnight, but for new stuff you have all the possibilities you want, available right now.

Probably the closest to "just put some blocks together" you can get now are the iot fleet management services OSes like balena and others.

I'm very puzzled by the lack of Android desktops. Most users (not high-end users) would rather use the same OS and apps on all their devices, and Android is perfectly OK for content consumption, Office-type work, social and comms, light games...

There were a few very early attempts at Android laptops, but as for tablets (only worse), w/o any support from Google (Playstore category, guidelines...) those floundered.

I blame mostly ChromeOS, preferred by Google because it fixed the NIH issue and because why build one good ecosystem when you can build an OK one AND a bad one ? I'm still making "Android desktops" from TV boxes for the elderly around me. Android's support for standard webcams and other USB devices is a boon. It only really needs an LTS version, and some devices/apps guidelines and vetting. Not sexy enough for Googleheads, I guess ?

One major part of your point is the desire for OCAPS (object-capability system), I think.

Others mentioned ChromeOS but I think the Google effort in this direction lies in Fuchsia today. The Zircon kernel is quite different from Linux from what I can tell, but given enough effort and time (not necessarily by Google) may become a viable target for server workloads.

https://en.wikipedia.org/wiki/Fuchsia_(operating_system)

https://fuchsia.dev/

Hmm if Google would announce tomorrow a server oriented Android variant, would you jump on it or wonder when they will cancel it?

If you remove the UI from an Android app, what's left that's android specific?

I get the remark, it's certainly an interesting line of thought. In a way, this model reminds me of Ubuntu Core [0], although Ubuntu Core is more freedom loving than Android, but that is not your point obviously.

Somehow I feel uncomfortable with the suggestions you make, but I find it hard to articulate. Somehow this does not sound like an attractive model, it sounds very "involved". Let me try to articulate why.

I think a lot of the Android tooling sound new-ish, but actually I find it to be old-world in the server space. We have been moving more and more into declarative infra-as-code paradigms: Spin up a multitude of servers from a single text file that declares the final state of the entire architecture. Think Docker compose, Kubernetes/Terraform, Ansible, Chef/Puppet, Nix(OS).

In a world where your servers/configs live in Git, where is the advantage for something as involved as Android, which in the end is just a Linux kernel with some APIs on top (and a privacy invading proprietary layer, again, not your point I guess)?

[0] https://ubuntu.com/core

You don't need to push android for desktop a lot of non-technical/non-power users will just use larger tablet and be fine with it.

Wrt. to servers Android is fundamentally designed to run phone applications in all of it's fine tuning, optimizations and internal design. You really don't want to run that as a base for servers (same for iOs). Not even considering that Android is missing tons of functionality server software uses all the time.

> On Android, we have a really nice design pattern where the OS pretty much provides everything, and stuff you might want to swap out can be done with a service provider app of some type.

same for Linux which most servers run on, just often easier and more flexible then on android and without a lot of phone use-case specific overhead android comes with

> On servers, we have a nightmare tangle of Microservices and crap.

this is fully unrelated to the operating system, you have microservices not because operating systems succ, you have them for stuff like auto scaling, fault isolation, replaceable components etc. _across many hardware nodes_ potentially distributed across all the world.

> It's just... so much more sane and structured.

no, it really isn't

> Why is the Steam Deck Linux based while Android hardly has any decent games?

Because google is clamping down control on android.

Because Android isn't that good for games.

Because it's just easier for valve to make windows games run on desktop Linux then on android.

Because the app stores market dynamics make it hard for many kinds games to be profitable. Android has a tone of game, just many crap idle clickers and stuff like that, because that still sells well enough.

I mean consider this: Google itself did more then just one time try to find a way to get ride of android and replace it with something else, better working. They just failed because it wasn't pragmatically possible wrt. the existing ecosystem.

EDIT: Also a lot companies don't really run desktop/server Linux, they put a application into a contain which can be hosted on Linux, and might contain many parts of a server Linux for convenience reasons, but logically it's more like directly running only their application on a linux kernel then anything else. If you want nice abstractions about how this servers can interact, something which in general is seen more as infrastructure ten OS tasks, you would need something like a distributed web OS or infrastructure abstraction layer, i.e. not Android (they do exist with varying degree of success).

EDIT2: Yes the current state of cloud computing is pretty bad, but really trying to put Android in there wouldn't help at all IMHO.

Your assumptions about Linux are either all made up, or are based in working with some VERY incompetent people.

Most of what you refer to is Android is the UI stuff built on top of a slimmed down Linux Kernel.

On desktop because the UI is not suitable for it, and most of the apps would not work as well as their desktop counterparts. Server because background apps get starved of resources, put to sleep, and then killed. And you don't want that to happen to your database.

Phones may have "very high reliability" (although I don't even agree that this is true, IME apps crash constantly, on my somewhat older phone, even the camera app crashes sometimes) - but that's because they only have a single user.

Try that with having to serve hundreds or thousands of users all over the world so that responses come back in a reasonable amount of time.

There's things being done today in backend development that are probably overcomplicated, but Android is certainly not going to be the solution. And if your use case is really simple (e.g. personal hobby project and you're the only user), you can also just run some program from a single VPS, that's certainly very easy to do (and can be automated with all sorts of tools).

For anyone new to backend development, I would anyway recommend to ignore docker and microservices and other such things at the beginning and just try to get a program to run on a single server (and having it being accessible from outside). All the other technologies build on top of this, and they exist for various reasons to make things more maintainable/scalable/secure, but they're not essential, in a strict sense, to backend development.

Android with a keyboard is terrible. I've tried my TV (where the remote is already in effect a keyboard with cursor keys enter, and escape) and my Astro Slide.

In both there are many issues - the tab index is often weird, some parts of the UI may be inaccessible at all, some widgets don't even have a different colour when they are highlighted.

Some apps start in portrait mode by default, so you without a 3rd party app they are sideways.

Even without that it's sometimes random which way round apps will start.

Android is a disaster using the UI this way.

I'm gonna assume "Android" here is a word meaning a centrally developed and somewhat more planned OS platform, not literally Android itself.

The main reason there's no such OS is because developers by and large will not pay for software if they could use something free instead. That's it, that's the only reason. Once there were quite a few such server operating systems, e.g. Solaris and Windows Server, but they've all been crushed by Linux because Linux costs nothing and that is overwhelmingly the most important criteria for developers. See also the massive Red Hat drama lately. Note that they'll happily fork over a lot if the alternatives also cost money, which is why everything commercial for devs takes the form of services not software because they'd have to pay for servers anyway so once you've crossed that bridge why not pay for expensive fancy servers in the form of cloud services too. But a generic OS platform you could use anywhere? Devs won't go for it unfortunately. They'd rather chew devops glass than do that. It's not entirely irrational. There's safety in numbers and Linux's complexity = job security and career advancement, after all.

OK so what would an "Android for servers" actually look like? The big problem with defining this is that Android gets a lot of its simplicity from not caring about scalability. It's scoped to a very specific set of use cases which don't involve processing much data. The moment you talk about a server OS, are you even talking about one machine anymore? Or something more like Kubernetes where the "OS" is lots of computers fused together. Is your server platform meant to power a 10,000 machine cluster or is it focused on single machines? You talk about uploading .apks to the server which suggests you're after something more single-user focused, which is a lot simpler to do but again there's no demand because people would rather just create accounts on the 10k machine cluster and share all their data (despite what the EU thinks nobody cares about data privacy, convenience wins every time).

So yeah - summing up, there could be something way more sane, more structured, simpler, more consumer-like in its usability. But whoever tried to create such a thing would go bankrupt because nobody would buy it. You may not like it and find it a nightmare but for better or worse devops is a job and companies would rather grow their empire by hiring people to do it than pay a third party for easy to use software that means they don't have to.

it's for phones.

there are much better servers and desktops. using android for these makes me feel sick.