Linux Development Experience on Android

How Termux and further products can shape the future.

Dec 22, 2023

This post covers two complementary yet different topics.

The first one is the geek in me having fun. It is about Linux, the Linux Way, development setups, Android phones and tablets, and, overall, about how to use Termux in a fun and exciting way.

The second topic is about the value this approach unlocks. It’s closer to the topics of self-contained systems, information security, and even Web3. I envision the world where Android shifts the paradigm of how we think of software, as Linux did twenty years ago.

As you choose which parts to skim through, just keep in mind a quiet and soothing call to action from yours truly. So far I was fortunate to meet just a few people who are interested in both facets of the story. So, if you found both interesting, or can think of someone who might, it would be fun to chat about it some time. In a Zoom room or over a ${BEVERAGE} of your or that person’s choice.

Intro

Let me first share a few quick pieces of back story to set the table.

First is that I started writing this post two weeks before my ARM-powered laptop arrived. All my life I wrote code on desktops and laptops. My short affairs with MacBooks started with their first white Intel model back in 2006, and ended far before M1. And my experience of coding on a PalmPC or a tablet would total a few hours max.

Thus, now is literally the first time for the developer in me to live on a non-x86_64 architecture.

Sure thing, I have been cross-compiling for various architectures far before becoming a professional developer. Heck, I even wrote a C compiler for AVR-s back in high school. Fun times! But it was never a proper relationship. Much as I disliked x86 and then x64, there was never a good option to part ways with it. That is, until now.

The second piece of back story is that my open source framework, C5T/Current, is something we want to keep as cross-platform as possible. I do have a habit of building it and running all the tests on Windows once or twice a year. And I praise Windows as a development platform precisely because it’s not a *nix system.

Historically, I just view CL.exe as the most advanced non-gcc and non-clang compiler. Also, not being a PowerShell expert, I always viewed Windows as a “point and click” system, with manual builds & runs. When it comes to macOS, of course, Current is built and run by Github actions on multiple platforms including Apple.

The final piece of the back story is that I view changing laptops as an opportunity to have a fresh start. I reflect on what else I can automate and streamline to make migrating the next time even easier.

In particular, I love the idea of having the dotfiles cleaned up and in one place.

It’s not that much fun to “test” the set of dotfiles by trying out various OSes in VirtualBox or in Docker. There’s something materially different in trying out the setup on a different device. Call it irrational, but I firmly view our life experiences as most illogical (tm), and thus cherish this geeky trait of mine when it comes to occasionally setting aside some time to play with the new tech.

This draws Android into the picture.

Full disclosure: I am careful with Apple for a long time, but have given in since. My main phone is an iPhone, and I am a big fan of AirPods. With this being said, I never liked MacBooks and iPads. Besides, since I travel a lot, having a spare Android phone, if only as a mobile hotspot for an international SIM card, became second nature to me. Especially when the company that is kind enough to be paying me wants some app installed. No way I’m compromising my personal iPhone with that, right?

This slowly evolved into carrying a Galaxy S7+ tablet along. It’s irreplaceable when it comes to solving Cracking the Cryptic puzzles over lunch.

And this tablet effectively has the same ARM architecture as the laptop I am now finishing this post from.

Internalizing this, it’s only natural the geeky part of me lit up to try it out for real.

In fact, one of the reasons I chose that Samsung tablet was to see if I can do parts of my work routine directly on it. Zoom calls, for example. And I did try using a USB-C-into-everything back then, and was quite impressed with what DEX can make a Samsung device do with an external monitor, keyboard, and mouse.

Hey, LineageOS folks, are you taking notes?

Moreover, with laptops and tablets converging, I always thought Android may well have a future as a “desktop” OS. It’s an open core system with fully open source options. It has good hardware support of what one can choose from. There’s no shortage of good devices.

Personally, I also like how Android is far more focused on smooth UX, compared to both Windows and Linux.

And I like Android’s approach to isolation between apps. Qubes OS, which runs (Linux) applications within different Xen virtual machines, is a great idea. I myself remember configuring Skype to always run as a dedicated Linux user many years ago, upon reading up that its EULA indeed allows the application to use my machine “for its own needs”. And I use the Web version of Telegram on my laptop, because I am not comfortable installing a closed-source app.

On Android, at least as I view the ecosystem, these issues are non-existent. Apps really do not have access to more than we give them to. And uninstalling an apk is quite a clean process, at least compared to uninstalling an Ubuntu package.

Besides, battery life. I know macOS notifies offending background apps to cut down on doing their CPU-intensive work. Linux is far away from it. On my laptop, I routinely find the Slack (Electron) app, or Chromium itself, eating up a lot of CPU for no good reason whatsoever. In fact, had there been a clean way to run a mobile-native version of Slack or Gmail or AirBnb on my laptop, I’d have been using them on my laptop for a long time!

I even experimented with running a virtual Android and opening a “rootless” visual session into it on a per-app basis. Telegram was quite fun to run this way. But it’s not smooth enough to my taste, so the whole enterprise all in all was just a weekend exercise.

To summarize: while I don’t like Chromebooks, it is always in the back of my mind that the world does not have to revolve around desktop OSes. And, sorry in advance the BSD folks, Android is a solid number two OS, after Linux, which I can see myself living inside, for a non-insignificant share of my keyboard-equipped screen time.

Tech

Termux

As a good friend of mine put it succinctly circa 2005: “The OS wars are over, Dima. Today they boil down to which OS you prefer to emulate within another one.”

And Termux is, in a nutshell, a way to get *nix experience from an Android device.

Full disclosure: I have tried several other apps before Termux. The closest second would be UserLAnd. If you’re curious, try these two at least.

At the end of the day, Termux pleases my inner geek quite a bit. The app itself is as Linux-way as it gets.

Ultimately, and quite quickly, I’ve got to the “REPL-loop” setup to:

If desired, uninstall the existing Termux. That’s a sub-second operation from the UI. A one-liner with adb. Also, this step is optional.
Install a fresh Termux. Tap on an .apk straight in mobile Chrome’s downloads, or from the Termux Github page. This aso is a line-liner with adb. Nice trick: -r will re-install the package, rendering the previous optional uninstall step redundant =)
Open Termux on the device. It needs to set up itself. To “install bootstrap packages”, as Termux itself says. This is a ~one-second operation. Besides, one has to enable notifications for it; somehow this popup emerged unconditionally on the first launch of Termux.
Run one “single”, albeit long, command to configure this “fresh” Termux. Long tap, paste, “press” the virtual “Enter”, wait. This can take a few minutes. Fully unsupervised though.

Myself, like a good boy, I was playing around without adb first. Just a week later, when installing LineageOS on a cheap phone that arrived together with my ARM laptop, I’ve realized the process is even more Linux way with adb as part of the loop.

All the steps are well-documented and reproducible. If you prefer code to text, head straight to the README.

Automation

So far so good. What is there left to automate, you ask?

Quite a few things, as it turns out. Testing the dotfiles (and YouCompleteMe!) was just the beginning.

Ultimately, I want to be able to connect to my Android device from my laptop, via SSH.

The “beauty” of running an SSH server on a keyboardless device is that you really want to minimize the number of keystrokes on the keyboard other than the one your laptop has. Trust me, even typing out the IP address for the SSH command on the device is a remarkably unpleasant experience.

And, as you will quickly see, at a certain point we’d need ssh -R 8022:localhost:8022 ${HOST_IP}. Pure torture.

Sure thing, I am not typing this in by hand on every single “REPL” iteration. And my “host IP” is changing, since this research spans multiple AirBnb and hotel wifis in several countries!

But first things first. Why would an ssh tunnel even be required? Besides, even if it is, can’t I just type in this Android device’s IP address on the proper keyboard, to have the SSH request go in the right direction?

Oh, glad you asked. Fasten your seatbelt.

First, connecting into the Android device requires the “full network access” permission. Not that I am particularly uncomfortable with this, although, of course, “the tighter the better” is a good heuristic when it comes to security.

The real problem is more prosaic. This very permission for full network access has to be enabled manually, in Android’s settings. Ironically:

When it comes to notifications, Termux asks for them right away.
When it comes to storage, Termux has a wonderful termux-setup-storage built-in command, to get to the Android-native popup to ask the user to “let this app access your photos”, at no time.
Had there been a similar way to get to the “full network access” one, this post may have been shorter. But alas. In fact, unlike “access the photos”, full network access is buried into “advanced” settings, which is another unnecessary manual tap.

Besides, if there is a clean way to a tighter setup, why not use it?

Then there is another challenge. Even If you enable inbound network connections on the Android device, and even if you are comfortable with typing in the IP address of the Android device to connect to from your laptop, the “Linux username“ of a particular Termux incarnation would be different.

I am no Linux expert. But creating a new user is not something that is easy, or even doable, on a non-rooted Android device.

And I badly wanted to not have to root the device! In fact, I want the ultimate setup to not even require the Developer Mode, and this is exactly what happened at the end!

So, your whoami username inside Termux would be some u0_42. Or u0_145. Or u0_416. And reinstalling the app changes this number.

~~There~~ ~~must~~ ~~be a way to alias some custom user name on the sshd level. I spent about fifteen minutes looking in this direction, but then decided to take the road less traveled, and more fun.~~

Thankfully, the Termux folks are accepting incoming ssh connections with any username. Otherwise, the problem would have been a bit more difficult.

In any case, “pairing” the devices is where reverse SSH tunneling comes in handy. Having the Android device initiate the connection eliminates the need for it to have full network access. After all, it’s the Android device that initiates the connection, not someone “calling into” it.

Long story short, I’ve added the tmx user on my laptop, and ssh -NR works like a charm. Once the Android device has established the connection to the laptop, from the laptop itself, ssh -p 8022 whatever@localhost does the job.

Yes, I should mention Termux uses port 8022 for SSH. It’s a good number. I’ve kept it.

One to Zero

There is just one piece of the puzzle left.

How does the automated setup of a freshly installed Termux know at which address should my laptop be found?

I’ve experimented with netstat on Android. I even tried iterating over local IP addresses. But that’s quite ugly.

Maybe some standard discovery technique could be used. Hostnames exist for as long as computers do, after all, and ARP is older than me.

But again, this is not my area of expertise. I am not a systems administrator after all. I bomb interview on Linux internals (would love to paste the link here, but we didn’t release that episode, possibly because I curse more than it is acceptable while explaining exec() and fork() from the “first principles” of distributed architecture). So, to put it mildly, low-level networking is not my strength.

So I thought to myself: there has to be a SysDesign-grade solution! And oh boy I found a fun one.

The core idea stems from my desire to find a way to “send data” “into” the Android device in the most non-invasive way possible, with no extra permissions to enable, and with no “connection” established whatsoever.

One idea I liked right away is to leverage the fact that the vast majority of Android devices have cameras. And cameras can parse QR codes. And Termux, when granted the respective permission, can access the photos taken by the device.

So the original plan was as follows:

Generate a QR code on the laptop. It would encode the means to connect to this laptop. Originally I wanted to include some passcode-protected private key in that code too, but eventually I dropped this idea in favor of “ just” encoding, in a secure way, the IP address of the laptop on the local network.
Take a picture of this QR code using Android’s standard camera app. No need to get fancy. Just use any camera app and have that picture stored on the device.
The Termux startup script would then look through the few most recently taken photos and analyze the QR codes it finds in them. And, for every “connect to me” code deciphered, it will attempt to open the tunnel.

Fast-forward, this wonderful plan failed spectacularly in the way I least imagined.

There is no reliable way to quickly parse the QR code via a command-line tool!

The evil trick played at me was time of day. When I started the experiment, it was a fine Sunday afternoon, and everything was bright. By the time I was ready to call it done, it was already dark. And, as it got darker, zbarimg refused to parse QR codes!

Even the most trivial ones, such as “Hello!”.

What’s worse is that I wanted to analyze the last few photos taken by the device. But if it’s a dark photo in which zbarimg does not detect the QR code, it may well run for quite some time before declaring defeat. In fact, I’ve observed dozens of seconds per run!

And somehow there is no simple way to tell it to quickly run the basic detection checks only, and then stop. And other command-line tools for parsing QR codes from JPEGs are not better.

I even wrote a script, which I’m quite proud of, to have my laptop’s Linux terminal display the QR code in full “color”. That is, in full black and white, see for yourself. Still no luck.

What was most frustrating is that Android’s native camera app was perfectly able to parse QR codes with far more entropy in them. But zbarimg refused to accept even the one with the bare IPv4 address.

Well, it was getting late. And I wanted to have this done. So I found a way to leverage Android’s native ways to parse this damn QR code.

TL;DR: Have that code point to an HTTP route via localhost. On the device, from Termux, spin up an HTTP server on that port. And do the opening the tunnel magic from the implementation of this “endpoint”. Which will be triggered by opening this particular “page”, which is “hosted” on the very Android device.

Then run a one-liner on the “host” Linux. It will show a nice QR code, straight in the terminal. This QR code encodes how the device can establish the server SSH tunnel to this cost. Point Android’s camera to this QR code. The camera app will parse it as a localhost HTTP route. Tap on this “link” and open it. Voila. Done. The SSH tunnel is open.

One last step that I did not complete — and probably should! — is to have the “host” Linux to report, from the same one-liner script, that the tunnel was indeed open successfully from an Android device. In fact, this should be an ephemeral one-time-use-only code, and there should be a timeout. Alas, I am having fun here, not building a product.

All in all, this works miracles. Including zsh, and screen, and even YouCompleteMe (!) vim-completion works for Python and JavaScript and C++ (!!) right on the device (!!!).

I’m coding C++ in an “Android IDE”. With code completion. Natively. Ain’t this cool?

Termux also does surprisingly well with keeping the connection open as the app is closed.

Here’s the code. Have at it as you wish. It’s not up to my standard of “should work in one click”, but it’s quite close. Besides, if you do decide to dig deeper, you probably are interested enough in following the steps one by one.

Last but not least: OpenSSL. The message passed through with the QR code is encrypted. Granted, for this particular experiment, the password is stored in plain text, and so is the private key of the Android system installed into Termux. This is the POC though. The important part is that this setup puts together all the pieces needed to lock down this setup quite a bit, as long as the only thing “shipped” is a self-contained apk of the fully configured app.

Further Geeking

I talk more about future product work in the next, less technical, part of the post. For low-level notes check out the last section of the README of the respective repo.

To complete the geeky part, I can totally envision such a custom-built apk to not just be the above setup plus my private key. It can also contain a complete build environment, with the cache pre-built, for a particular project or several of them.

Within itself, this apk also has the credentials to git-push code changes under some semi-ephemeral Github user account, to a somewhat randomly named “dima-purple-monkey-dishwasher” branch.

The pull request creation part can be done later, from a different device, and even by a different person. From within the apk, one just works on the code, literally from the second right after installing it. The expected BAU pattern is to work by ssh-ing into this Android box from one’s own laptop / Chromebook, although coding directly on this Android device is also possible. Every time a local commit is pushed into a certain local repo, as long as the device is online, this commit is forwarded to the right remote.

The very Android device is then fungible. And the very upstream repo can be proprietary, since Android supports VPNs natively. No hard connection to GitHub pe se, although I would imagine first experiments to be Github-centric.

Another geeky idea: for non-Github workflows, have the Android device act as a sidecar and run Phabricator on it. So that the code review experience, via localhost, is both interactive and lightning fast.

Personally, I’m quite fond of the idea that for a project worked on by multiple people there are nightly, or even hourly, self-contained apk builds of this code + build cache + zsh + a preconfigured vim-based IDE. This way, the step of getting one’s (new) device ready to begin development is literally one tap on the apk to install. And the Github action to build this API should share it via a create a QR code as well.

Besides, even though I don’t like Chromebooks, the idea of the “compute device” being separate from my “thin client” is something I ponder on for years now.

It’s a tad too unorthodox to carry a passively-cooled Raspberry Pi with a connected power bank in my backpack. But if it’s just a full-size tablet that I’m happily using to read books and watch movies on the plane regardless, the idea begins to make a lot more sense.

Value

Tech is fun. What is even more fun is having it work to help advance our humankind.

The value unlocked by the above experiments is in making Android devices first class citizens when it comes to business processes. Work with documents, spreadsheets, task trackers, and all the way to the code and accessing production systems — all of the above can be powered by an Android device.

And I am talking about both the user-facing client side and the server-side backend where the data resides.

One can work on this Android device natively. Tablets are good enough, and many have keyboards these days. A lot of work can be done from a phone too. For more demanding tasks, such as coding, this Android device supports the setup with a keyboard, mouse, and a proper screen.

Or one could use their thin client to access the work environment on the Android device. A cheap Chromebook would do.

My long view for the future includes having entire backends of various systems deployed fully on a bunch of lightweight phone-grade devices around the globe.

And today Android phones are a great proxy for those devices as of today. They are relatively cheap and very cost-effective when it comes to CPU & network. They are already produced en masse and are only getting cheaper and more powerful. And they have decent kernel-level software, specifically, applications isolation, hardware support, and VPN as part of the core system.

As of today, you probably won’t want your company to “host” its chat or email data on a bunch of randomly located cheap Android phones. What about your git repositories, your wikis, your documents and spreadsheets, your task trackers? These are lightweight. They don’t need to store much data. Unlike chats, access patterns to the data they operate with do not suffer from an extra second of latency.

Android phones are single-digit hundreds of dollars. Traffic is almost free these days. If you want security, third-party VPN providers offer external IP addresses for single-digit dollars per month. That’s literally pocket change if the alternative is to acquire a license for several enterprise-scale tools.

This sounds too good to be true. And nonetheless true it is. For a mid-sized company, a “self-hosted” solution, the backend of which runs on several Android devices scattered around the globe, can easily run the show. Such a solution would be both cheaper and more secure. Even if you throw in VPN costs into the picture.

Product

Consider a company with dozens of employees and hundreds of augmented staff. This company is interested in saving costs and keepings its data secure.

The first bullet point alone is good enough to consider not paying Google or Microsoft a ~hundred dollars annually per seat. But, realistically, mature self-hosted solutions are also not cheap these days, and they require maintenance by onsite staff. So, the first point by itself highlights a market niche.

The second point, taken seriously, is about having data safety guarantees at least at the level that large companies offer today, while making sure no big player can peek into your data. This requires a decentralized setup that does not depend solely on a single vendor, both for end-user software and for the servers that host the data.

After spending several dozen hours playing with various Android devices, I can confidently say that it is very much possible to have:

The server-side code run on a swarm of relatively cheap devices scattered around the globe,
The user-facing apps, which connect to this “swarm” securely, shipped as Android apps, and
A smooth work experience, on any Android device and/or from one’s preferred phone / laptop / tablet which would connect to your company’s “swarm network” via a small company-provided Android.

A non-tech way to internalize the above is to think of a powerful “authenticator app with benefits”.

Most of us have used a Google / Microsoft / Salesforce / OKTA Authenticator app. It’s the one whose purpose is to generate OTP codes, six digits each.

Some of those apps have useful features, such as sparing their users the need to copy-paste the code, as the very presence of the unlocked phone in the vicinity is good enough. Some also have enterprise-friendly features, such as adding or removing access tokens remotely (good) or watching when and from where the users are requesting authentication (less good).

Taking it to the next level, imagine this “smart authenticator” does more than guard access. To explain it in non-techy terms, imagine it connecting your device to a “corporate” VPN, so that you can begin using the services that are otherwise inaccessible. That’s exactly how it works, except this app does not “connect” you to a virtual private network where those services are hosted. Instead, this “smart authenticator” app becomes the backend provider for those apps.

The very apps are likely the very same apps you already have installed. To continue with the Google Drive analogy, your device may well already have an app to manage those docs and spreadsheets. It’s just that some of those docs and spreadsheets are only accessible once the “smart VPN” is up and running on your device.

Non-tech-savvy users would not even understand the difference. Except, they will most definitely experience a far lower end-user latency =) because, effectively, they are no longer talking to “the server”, since their own device is part of the mesh that represents the storage + compute “backend layer” for these particular docs and spreadsheets.

I can see the synergy for a “soft lock-in”, similar to what Linux did to the world of servers.

On the one hand, the very system is fully open core. The “smart authenticator” app is 100% open and 100% free. As for the “swarm”, the servers also are open source, so that one can easily augment them with their own company’s public key. A lone enthusiast can set this up, including running this “swarm” server-side code on multiple devices, even with the VPN configuration as needed.

On the other hand, since no real company wants to depend on a sole enthusiast, an ecosystem of consultants and consulting firms emerges.

A lone enthusiast can run everything by themselves. For a secure large-scale setup though, it would be nice to have the “docs” and “tasks” apps offer enterprise-grade experience. This would mostly apply to backup, access journaling, and audit/compliance. I can also envision some whitelabeled app with user-facing features tailored to the business processes of a particular company.

And these custom-shipped and/or whitelabeled apps can run for $0.99 per user per month.

Much like during the golden age of the Internet twenty years ago, for our lone enthusiast, setting up this very “corporate-grade” setup will be a matter of a few hours of relatively straightforward work. Which was exactly the case when Apache Web Server and then nginx were taking off, when everybody wanted to have their own homepage and their own webmaster.

Today, decades later, the market has converged, and most of the money made “via” this software is captured by large players, mostly cloud providers. For the first dozen years though, a lot of people have been making a living by offering their “webmaster” services to larger businesses. And this is the model worth reproducing.

I would even say this is the model worth returning to, although the question of how long-lived it can be remains unanswered.

On the other hand, the model described above befriends two huge worlds. The world of enthusiasts, the purists who would love to work day and night for reasonable pay, perfecting the craft that powers the above. And the world of venture capital, since, while the entire system remains open core at heart, there are plenty of enterprise-grade pockets where the total addressable market is huge, and where the right product is straightforward to scale with the right executive team.

That’s the path I would love to see the Web3/decentralization community to take, by the way. Not ICOs and NFTs and shitcoins we’ve been seeing recently. And not the “worldwide” smart contracts with ever-decreasing but still high “global ledger” fees. And not staying in the gray area, dangerously flirting with regulators who are making it increasingly difficult to make progress.

Instead, I envision Web3 as the set of tools as widespread and broadly viewed as the Common Good as Apache was at the dawn of the “Web one” era. With serious business™ gradually taking note and, over time, relying more and more on decentralized solutions. Knowing full well that the solution is cost-effective and resilient, that their data is safe, and that the ecosystem of enterprise-grade support is always available, for a modest fee.

I would also argue that, looking back, helping “David” developers make Apache (and Linux!) better and paying “David” webmasters their salaries has lifted more people out of poverty, and saved more trees and polar bears compared to the “Goliath” ecosystem of online services and cloud providers that we live with today.

If interest rates stay high and money remains expensive, I can see the world where more and more companies want to break free from vendor lock-ins. And having an open core, open stack solution, running which costs single-digit hundreds of dollars per month for an entire company, sounds like a big win to me.

First Light

To end this part on a constructive note, there is a clear definition for a minimum viable product to kick-start the above. We need one SMB-friendly app that is fully, end-to-end, runnable in a decentralized fashion. My first instinct was to suggest Google Docs, but the more I think about it the more Spreadsheets make more sense.

So, the app is effectively a poor man’s Airtable, polished to the degree that a lone developer can spin up its server side on several Android phones for storage & compute, and generate downloadable apk-s, so that whoever installs this app gains access to the “cloud storage” of these “Airtables”.

The user-facing side of the app is venture-worthy, since the network effect is there, and there is no shortage of enthusiasts who have built the POCs of “smart tables for Web3 and iPhone/Android”. It would not be difficult to persuade one of them to cooperate on the frontend-backend protocol, so that their powerful user-facing control is put on the tracks where the network effect helps it take off.

The backend decentralized storage & compute part is a non-profit, financed in part from the venture-backed user-facing side. The motto is open discussion, open protocols, and open implementations. My SysDesign Meetup crowd would be a perfect fit to kickstart this.

For the record, a service hosting git repositories in a decentralized way, offering Phabricator as the code review tool, is a problem of comparable complexity on the storage side. It’s just too nerdy and does not sell, so Airtable it is, for the MVP to present to the public.

I, for one, would be happy to live in a world where joining a mature organization, hosted on the above ideas, would be as simple as sharing my public key with the hiring manager. We already have this with Git repositories, although the upstreams are mostly centralized these days. Time to expand this greatly, both in the direction of covering far more than the codebase and of making the storage truly decentralized.

Last but not least. I contemplated whether this thought is worth including in the post, and could not convince myself to cut it. There are lessons we can learn from the Web3 community, and one learning that I personally find valuable comes from the conservative Bitcoin community. One of the foundational principles of this community is that anyone with an average PC can dedicate part of this computer’s CPU and Internet bandwidth and become a node in the Bitcoin blockchain. This makes the system fundamentally egalitarian, as mining farms are well aware that the average Joe and Jane will forever remain first class citizens of the network. This is Bitcoin’s utmost Democratic hedge against a large force attempting to take it over, and this hedge is working well so far.

A very similar statement can be made about the above idea, and it will be a stronger statement. Just replace the average PC by a cheap Android phone. There are and there will be plenty, and each and every of then can be put to good use. And replace the global blockchain, where every transaction competes with every other transaction, with a small, company-wise source-of-truth, where the consensus problem is far more manageable.

An average PC is worth a few hundred dollars today. An average cheap Android phone is worth a few dozen dollars.

Let’s make it easy for three geeks in three different parts of the world to spend ~$50 each on such a phone, plug them into a shared network, and begin working on their own Airtables and stuff in no time.

Some day some three geeks will start a company that will become a multi-billion dollar one. If, as they scale, instead of moving their operations to the cloud they choose to buy thirty more ~$50 phones to ensure their company’s data is safe and secure, then we’ve done something right.

Afterthoughts

After spending some time with Android, both as an engineer and as an evangelist, I am very comfortable saying that the Android ecosystem is underrated.

Not necessarily as the platform for end-user devices. Let the users vote with their dollars there. Apple has a lion market share, and this is not the market that welcomes disruptors.

I am talking decentralized server-side Android here.

Android may well be the operating system we need today to take over the world. Not because it was developing rapidly. But because other players have not been innovative enough for a while now, and the window is opening up.

As someone who uses Linux all the time, I can not hide my continued frustration of how slowly it is improving these days. As we speak, Windows is, quite literally, becoming a better day-to-day laptop operating system than Ubuntu.

Similarly, on the server side, Linux is dominating the market of data centers. If data centers are the future, not much will change.

But if decentralization starts taking off, Android is just the right-fit OS. Much like Linux was the right-fit OS when the Internet was about to kick into high gear.

No one but enthusiasts used to run Linux on their desktops. But backends of the systems your average Joe and Jane used were increasingly powered by Linux. And then development work moved to Linux. And then there was no way back.

Dima Korolev

Discussion about this post