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

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.

Actually it supports multiple user accounts with ability to switch among them, each application runs under its own process account, it has multiple ways to execute background processes, it uses OS IPC among several kinds of workflows, since Treble each device driver runs in its own process, it is possible to request a wake lock, Android Things was a headless version of it,....

Looking at Inferno and replacing Limbo with Java/Kotlin, it could be made to work.

How much it would add over any UNIX clone + Java/Kotlin? Maybe a safer userspace.

Would it be worth the trouble? Probably not.

>It is essentially a single-process OS, only the running app gets all the resources it needs.

Does the vast majority of people do more than one thing on their computer at a time?

As far as I'm concerned, Android not taking the desktop by storm (and ushering in the Year of the Linux Desktop) is because Google seemingly just isn't interested.

Windows is at its most vulnerable state in its entire history, and it's steadily losing ground to MacOS as things stand. Google and Android could absolutely wipe the desktop market if they could be convinced.

> Does the vast majority of people do more than one thing on their computer at a time?

Absolutely. Just looking at my wife, an office worker. Even when not working with whichever of 5 huge Excel files she has open, she is talking on Teams while working in a permanently open Outlook. Add a variety of internal sites which she constantly peruses. She just cannot have each single application taking the whole screen at a time.

Even if we ignore that most people who work on PC use multiple applications at the same time, at least in my experience also most office workers use at least 2 displays, plus the in-built laptop screen. Not sure if Android can handle 3 screens with each showing at least 2 applications by average.

Currently visible for me are 9 applications on 3 screens. Sure, I could minimize or close some of them (Keepass is not that important all the time), but I appreciate the convenience of having a lot of space.

This is the quote from the post you're responding to:

> 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...None of those things you'd want in a server OS.

That is obviously referring to _servers_.

> Does the vast majority of people do more than one thing on their computer at a time?

The vast majority of people are not running servers. In fact, I'd assume the majority of people do their computing on either iOS or Android.

Really the question of why "there no major push towards Android for Servers and Desktops?" is mixing two very different issues that should be discussed separately.

>Does the vast majority of people do more than one thing on their computer at a time?

Yes? A browser, chat client, and music player in addition to whatever program they use to do their job.

Because it's a Goggle surveillance abomination?

I mean, you're serveer isn't walking into retail stores, so why would Goggle want to track that?

The primary purpose of android is a user data harvesting platform. I'm already dismissing large numbers of modern cars because of this.

I did see a job posting recently for some company running "headless Android" and I was super confused. Like trying to hammer a screw.

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.

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

Honestly, this seems like the "right" answer here. While I haven't used NixOS, I've actually described OCI containers a bit like installing apps on Android in the past - each has all of the dependencies bundled, a common API to interact with all of them, things like port configuration or just setting environment variables as well as storage with a unified mechanism, including even resource limits!

Docker, Docker Compose, Docker Swarm, Hashicorp Nomad and Kubernetes (including K0s, K3s etc.), as well as more recent efforts like Podman all feel like a step in this direction, depending on what your exact needs are and how much complexity you can deal with.

> 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 already run almost all of my own software in containers and so far it's amazing - I don't even care too much whether the node itself is running Ubuntu, CentOS/Rocky Linux, or even something like Alpine Linux on the server directly (which some might actually consider, because of the simplicity and lightweight nature).

Throw in Ansible or something like that for making sure that the configuration is similar across all of the nodes (or groups of nodes) that you want and there's surprisingly little to worry about in the long term.

Edit: though maybe I'm only able to say this because building OCI containers (say, with Docker) is actually easy, to the point where I build everything apart from databases myself, like dev images for Java/.NET/Node/Python/Ruby/PHP and the resulting software etc.

> or even something like Alpine Linux on the server directly (which some might actually consider, because of the simplicity and lightweight nature).

You are going to eventually run into the same issue most people trying to use Alpine Linux just because of simplicity and being lightweight run: musl is not a completely ABI-compatible seamless replacement to glibc and might cause issue with statically linked binaries, and other annoying issues you won't foresee.

Had this "pleasure" in the past in one of my infrastructure-heavy positions.

> You are going to eventually run into the same issue most people trying to use Alpine Linux just because of simplicity and being lightweight run: musl is not a completely ABI-compatible seamless replacement to glibc and might cause issue with statically linked binaries, and other annoying issues you won't foresee.

Well, if all you need is the server to run Docker/Podman, SSH and some other limited amount of packages, it shouldn't be too bad. Of course, there are also horror stories of Alpine resulting in way worse performance in select use cases: https://github.com/docker-library/python/issues/509 and there's the fact that Alpine might be popular inside of containers, but way less so outside.

Also, because of the short EOL cycle, I personally ditched Debian on servers (and Alpine in containers) myself for Ubuntu everywhere: https://blog.kronis.dev/articles/using-ubuntu-as-the-base-fo... A bit of a polarizing move (though RPM distros aren't much better at the moment), but it seems to have worked out for me in the end.

Doesn't mean that someone can't try, though, maybe their use case is suitable for Alpine.

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 ?

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.

From what I read somewhere, recent versions of ChromeOS allow you to run Android Apps. My Chromebook is too ancient to test.

Yes, not even that recent it's been a feature for years

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.

I've used Linux exclusively on desktop for about 10 years, and used it on lots of embedded controllers.

When you use Linux the "classic" way, where you let the package manager do shared dependencies, large and complex suff often breaks. You can't install half the software out there because it was made for a different version of some library than the one the system has.

On servers, it seems the main way around that is just to build against old stable OS versions.

When you use it with flatpaks or snaps, stuff sometimes breaks too, or is missing features, or has performance trouble.

I don't know anyone who uses Linux on the desktop and has everything just work with zero tinkering and maintenance, unless they are just using simple unixy software.

When you have 10-50 large apps with 100 dependencies each, every year you will probably have a few that break.

I feel like you need to take another look at Linux. None of these problems are really a thing in modern deployments. The whole point of containers is that you really just install a core CentOS, and then roll up all dependencies within the image definitions.

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

I don't see flatpak getting the flak that snaps do. Personally I fall in the camp of "snaps bad; flatpak all right". There's no shortage of posts and comments expanding on this stance.

> These are extremely unpopular on HN.

idk.

HN just mainly complains about some implementation details.

Like flathub applications often not being sandboxed, yet.

Or Canonical forcing certain update strategies and similar on snap users.

Yes. I am in the support-snap-flatpack camp, and was really surprised by HN hatred towards it.

Well they are new and different, what more can you expect from the crowd here?

(Only slightly joking).

They have their issues, that's for sure (e.g. flatpack's broken for a long time sandboxing model, snap doing weird things with mounts, the backend being closed source) but honestly they solve so many issues with desktop/client facing software they're a no brainer.

A closed source backend means it shouldn't be used. I would say there is more than enough history in the software world that explains to you why this is the case, even if it is just kind of convenient right in this instant.

The main problem with Snap is that it is user hostile (forced auto updates) and propertiary to some degree. Canonical is just up to some no good.

Containerization in general is aatter of taste.

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

No matter what OS underlies it the problems are not simple. No matter how simple the easy case is made, the complex case will stay garbage. When faced with a choice, a sysadmin that might be woken up at 5AM will pick something a bit harder to set up that's at least still recognisable and debuggable at 5AM. So we have linux, something infinitely more accessible and introspective than android.

I mean automtated driving cars is not simple either. It's not stopping people from trying.

Isn't that what people use cloud/k8s/docker for?

Edit: thinking about it, running something as a Cloudflare worker is basically this. You even get a K/V store. It's just that there isn't an "app store" for these for individuals .. for essentially market reasons (in almost all cases, you're better off using someone else's service than spinning up your own)

OP is talking about having a mechanism / Operating system for servers to easily deploy and manage. Atleast, that's what I understood from the original post. How does k8s help me deploy say a blog ? It's just too technical and geeky. If this was "Android", I just download some blog app, click and install. Don't have to worry about updates either.

Docker compose wraps the app and db in a few lines of config: https://github.com/docker/awesome-compose/tree/master/offici... the extra config is for networking / db connections - you don't get those on Android because you don't run network services on it.

K8s can do the same thing, but has more options.

You can do exactly that with a Wordpress Docker container: install and run the container, it might even spin up a database for you if part of a docker-compose or you just rely on SQLite. The technical geeky aspect comes into making your blog available to the wider web through naming, you need to configure DNS, and serve requests.

I don't see how an Android app that you can "click and install" would help to configure your DNS entries.

I think in a few years at least some self hosting will have moved to things like cloudflare tunnels and ngrok, and domains and certificates will be a "Only if I'm getting paid to deal with it" kind of thing.

Maybe to reduce latency there will be hosting services that have the tunnel proxy in the same data center as your VPS, and include the service and the subdomain with your account.

Sandstorm was an attempt to do this, but there isn't much demand. Why install WordPress when wordpress.com will run it for you as a service?

As you sad, it was an attempt. We need more attempts.

Install on what, though? Why is this preferable for the target user to just using a SaaS?

privacy, data sovereignty , data ownership ?

Would you host your email in china or say srilanka ? I prefer hosting stuff in my country .

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?

a lot of things

but also for a lot of use-cases a lot of things would be missing, be very bothersome

and most important a lot of the things you have left are semi use-less as they are all specific to one instance of hardware

but modern server applications are always spread across hardware (even if it's virtual hardware)

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

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.

I see the walled gardens and restrictions as fairly separate from Android itself.

Most of the worst of it isn't Android at all, it's all just Play Store related, but other app stores don't need those restrictions.

I could see something like F-Droid, but with a cloud or local portal to be able to install things remotely on headless servers.

I'm not sure what the extra administrative burden is, Android is designed for as little administration as possible, I'm not sure if it's explicitly documented anywhere, but they seem to have a philosophy of "You should never have to configure one thing to get some other thing to work, everything should either be one size fits all or automatic".

Admin burden is lack of docs and tooling to maintain stuff. You need to introspect and debug things and measure performance, manage logs, networking,etc... and there needs to be a pool of potential people that can do that job of maintaining it.

If you have an ngnix apk, it might need to talk to a php and mysql apk and a bunch of other apks and each of them have configs and require management. Essentially, my problem is that you would need to port everything servers now are doing to it but to what benefit? It makes more sense to import features you like in android/dalvik to gnu/linux. Less work/burden.

Well, if you were really doing things in a fully "Androidish" way, you wouldn't just be straight porting PHP into an APK.

You'd probably have a DatabaseProvider interface that your MySQL would implement, that would have all the stuff to auto-configure that interaction, and the SQL app would probably include its own backups and related admin stuff.

If you were really going all the way, PHP and nginx probably wouldn't be a thing, you'd just be writing apps in straight Dart and putting your content as markdown files or something, to stay consistent and not add any extra layers of frameworks that aren't closely managed by the OS.

But yeah, I agree, if you just straight ported existing architecture to Android you probably wouldn't get much benefit.

> chromeos is sort of like that and GKE nodes use it to run k8s stuff

I'm not sure where you got that impression, but the default OS for GKE is Container-Optimized OS[1]. It's a Linux distribution maintained by Google for the purpose of running containers. I don't think ChromeOS is an option you can select for your nodes.

[1]: https://cloud.google.com/container-optimized-os/docs

You don't select it. Just create a pod/workload and ssh to the compute node and see. It's based in chromeos but not the exact chromeos on chromebooks.

Ah, you are correct. It's based on Chromium OS, which is the open source base for Chrome OS. I somehow missed it, but it's also mentioned on the page I linked.

On a server without a GUI, Android would basically be JVM running on Linux.

Except no package manager, none od the typical gnu/linux utils and a custom kernel.

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.

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.

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

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.

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/

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.

Because it's a Goggle surveillance abomination?

I mean, you're serveer isn't walking into retail stores, so why would Goggle want to track that?

The primary purpose of android is a user data harvesting platform. I'm already dismissing large numbers of modern cars because of this.

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.

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.

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.

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