As a tech community, we should really rally around a libre/free mobile OS and soon. Being beholden to corporations for our operating systems is antithetical to freedom.
It's so much harder to do on mobile, for multiple reasons:
- Hardware is not very modular (mainly because of size constraints), meaning you have to purpose-build libre hardware if you can't/don't want to run on tech-giant devices (you can right now if you're forking Android; you probably won't be able to once it's replaced with Fuschia).
- Developers' needs have always been a bastion for keeping desktop OSes flexible and open. No matter how closed-down software gets, someone somewhere has to be able to muck with it so as to build and improve it in the first place. This doesn't apply to mobile OSes; people don't use them for development.
Not that it's impossible for these things to be overcome, but it's a much steeper uphill battle.
Also, perhaps even more importantly, you'd be starting from scratch in terms of app ecosystem, which is even more important today (and especially on mobile) than it used to be in the PC era. You could get some mileage out of the web- but first you'd have to build or port a browser. Chromium certainly won't target your open OS, and with its 75% market share, it now strongarms the direction that web standards take. And many app makers don't even have mobile web apps these days (or their web apps are crippled versions of their "real apps"). Good luck getting Slack and Favor, or your bank, to build apps for your new OS. Or even Dropbox and Evernote. Forget about Netflix and YouTube.
Maybe you're okay with going back to the iPhone 1.0 days where a smartphone was just for phone calls, texting, email, a calendar, listening to music, looking up directions, and searching the web. But while you might get an mp3 player app, many people no longer own copies of their music and you won't get Pandora or Spotify. You certainly won't have a decent maps app - maps are one of the most heavily monopolized core features of today's phones, mainly because of the sheer size of the task of mapping the world. OpenStreetMap exists, but it's honestly not very good.
You start to see the problem.
I used an Android fork for about a year without any Google services before I gave up. I was able to grab a few crucial apps from APKMirror, but not many. I tried using OsmAnd for maps; it was awful. I once bought a pair of headphones I literally couldn't use without the app - available only on the App Store and Play Store. I used web apps to fill in some of the gaps; they were spotty and many were ugly and/or slow and/or didn't hook into APIs like push notifications. At least I had a fully up-to-date Chrome fork to use as my browser.
Maybe after the death of Android there would be greater momentum behind building and sustaining this kind of ecosystem. That would help bolster not only app development, but possibly even the value of the open web, and maybe even the contributions to (and therefore quality of) things like OpenStreetMap. It's hard to say.
So your complaints are that you couldn't use your preferred commercial services on an open platform. But if you zoom out to Smartphone Global Scale, the vast majority of people don't use those services anyhow. Netflix has 155 million total subscribers globally, which means it doesn't have about 3,745 million other Internet users.
Smartphones are far, far more about communication and collaboration than passive content consumption. 'Functioning' in our digital society isn't about everyone individually watching the same movies on a 5" screen on the bus. Most people use their phones as a glossier smartphone with navigation capability and that's just fine.
"the vast majority of people don't use those services anyhow."
You use Netflix as a stand-in for all "commercial services". The majority of smartphone users in the world may not have Netflix on their phones, but the majority of Americans - the largest market by value - do. And more importantly, I guarantee you that the vast majority of smartphone users worldwide regularly use Facebook and/or WhatsApp. Those are commercial services. I personally have trouble staying in the loop at work without Slack on my phone. That's a commercial service. Plenty of mobile, commercial services are truly essential to modern life. Singling out Netflix is a straw-man.
> The majority of smartphone users in the world may not have Netflix on their phones, but the majority of Americans - the largest market by value - do.
Maybe Americans are the largest market by value. Are they larger than the sum of all other markets, though? Will they be in 5 years? What about 10?
Regarding WhatsApp and Facebook, let's just remind ourselves they did not exist ~10 years ago. Any argument based on their size should only serve to remind us that such a dramatic change is possible over a period of 10 years.
For those curious, what I ended up doing was switching to an iPhone. I decided that my boycott of Google was mainly about privacy, not openness, and I resigned to the fact that I'd rather be able to fully function within our digital society than have openness in my phone (I still use Linux on my desktop). I've been happy with my decision; but for what it's worth I'd still try out a mature, truly open mobile OS if one ever surfaced.
> Also, perhaps even more importantly, you'd be starting from scratch in terms of app ecosystem
The "app ecosystem" on a free mobile OS would be shared with the "ecosystem" of free PC apps. Chromium does target, e.g. Debian GNU/Linux, as do quite a few proprietary apps relying on Flatpack. There's no reason why we shouldn't be able to piggiback on this work for the mobile platform. Yes, UI is different, but not that different. Modern Linux apps already come with a touch-friendly UI, for example.
Assuming the free mobile OS was Linux-based. And if it's going to be, I don't see why one wouldn't just start with an Android OSP fork. Even if Google stopped maintaining the latter, it's a huge head start compared to the alternative.
That said, because of the way Google APIs have extended their tentacles into non-Google Android apps, many of them cease to function without Google Services installed. So you'd still have most of the app ecosystem problem.
AOSP is way too fragmented. An "app" dating back to, e.g. Android 2.3 (not that long ago), or even as late as Android 4.0 will not even build in a form suitable for a present-day version of AOSP - you have to go and rewrite the code yourself, there is no backward compatibility that reaches that far. Linux platforms are truly mature and can easily run code dating back to the 1980s. Add to that the pointless overhead caused by Dalvik/ART (especially wrt. RAM use - quite critical on a system with no swap space whatsoever!), and the gratuitous differences with widespread Linux kernel and userspace standards. Starting from scratch on a better base is short-term pain for long-term gain.
Though you can just do both. Support both Android apps as well as New Better Thing and then all new apps use the new thing but the existing apps let you hit the ground running.
Almost all hardware is NDA. Even the Raspberry Pi has a lot of it's mobile-oriented chips like the VC GPU under a lot of NDA restrictions and binary blobs. There's basically Qualcomm, Samsung, and Huawei as the only companies making cellular modems and basebands, nearly all of which is closed source.
Linux was started by a student and brought into the limelight by volunteers. While the current development is largely paid for by corporations the essence of the thing is still the same, Linux-the-kernel is free software and can be forked by anyone who so pleases. If those corporations all were to loose interest, go bankrupt or suddenly decide they want to change Linux into a DRM-infested monster which only listens to its corporate master it would be a simple thing to fork the thing and ditch the corporate version. What would be less simple is the answer to the question who would pay for future development and how drivers would be written if and when hardware manufacturers started acting up but it would not be impossible to go that way. OpenBSD is a good example of a system which is developed without too much corporate funding, the concept has been tried and tested and is known to work.
This theoretical situation is precisely the one Android is in. The only difference is that Google is the only corporate stakeholder, so as they lose interest in various open-source Android components, those components simply die. Maybe the answer is to get more corporations invested in AOSP.
A big difference is that development of Android is done behind closed doors, whereas for Linux you can observe what is happening in public (discussions on the mailing lists for example). This means that it's essentially impossible to follow or contribute to Android development in a meaningful way. This is also reflected in the fact that there are open issues in Android with almost no reaction from any developer for years.
A large portion of the components needed to boot (not to mention use) android have always been closed. This is absolutely not the case for Linux. You can boot a totally free kernel on most PCs and don't really even need much userspace (busybox and whatever app you want to run (provided it doesn't need X11) is usually enough)
Furthermore, android really wasn't built to be easy for individuals to work on. Compare compiling and modifying Linux to compiling and modifying android. I've done the first but I don't think I've ever even finished downloading the source (tens to hundreds of gigabytes) to even start with the second.
Those components are presumably hardware drivers, right? In which case they're kept closed-source by the OEMs, and in which case you'd face the same problem whether you're putting Android on top of them or not. The solution in either case is to develop open source drivers. This is true regardless of whether you start with Android or go back to the Linux kernel and start over.
On modern Linux the drivers are part of the kernel which puts them under the GPL, legally obligating the release of their source code. On android the graphics drivers are part of userspace which lets the authors get around this.
Okay, but all that means is there aren't currently open source drivers for Android because we haven't needed them. Presumably the Linux kernel doesn't already have drivers for Android hardware (and if it did, presumably they could be ported to Android proper), so they'd have to be written either way. The point is moot.
> there aren't currently open source drivers for Android because we haven't needed them.
People don’t need anything, most of them just suck it up and deal with it. On Android this means throwing out phones and getting new ones every few years.
PostmarketOS is the closest I've seen to the right idea for sustainability and openness: mainline Linux kernel, no closed drivers, and a userland that lets various current and future environments be layered (and can run the existing wealth of GNU/Linux software immediately, modulo the small touchscreens).
A word of warning is that still developer-only, not ready for real use. (Even my Replicant devices are much more functional than my PostmarketOS ones, at the moment, but PostmarketOS is a much better idea.)
While I get this desire I have a hard time imagining ever using a free/open OS of any kind, mobile or otherwise. Mobile OSs and platforms tend to prioritize things that are unimportant for most users’ day to day use and thus suffer accordingly. They make good thought experiments or are great for the areas they’re optimized for (see *nix), but not for day to day use.
1) Pixels move to Fuchsia, native apps are in Dart/Flutter, compatibility layer for Android. Fuchsia becomes a distinguishing feature of Googles hardware, and allows Google to differentiate vs Android competitors.
2) Google continues to support Android, but only as it affects their business interests (as a funnel for search).
3) Google migrates some service level functionality away from Android and Pixels become a first-class citizen in Google's ecosystem.
In my mind, Fuchsia is a direct result of Google's newfound interest in hardware (as a business). I imagine the following:
- Google sees voice (and maybe AR) as the next frontier, which is actually an existential threat for them--they are harder to monetize via ads.
- Google decides to start making hardware (for profit), to monetize their services (a la Apple). That is, their Voice Assistant is now differentiated from Android, and to use that service, you have to buy their hardware. Now, they don't need to make money on ads for voice searches.
- Google will continue to roll out more ML-driven services that are exclusive to their hardware, and eventually, exclusive to Fuchsia. This will allow them to both a) further differentiate their hardware from other Android manufacturers, b) better monetize their services (effectively through HW purchases), and c) steal market share of the most valuable customers from Apple.
This isn't an official statement from Google. If you're interested in Android's OS update story (keywords: Project Treble, APEX [0], GenericSystemImages [1]), then the thread [2] has some interesting pointers.
They've never made an official statement or confirmation of what Fuchsia is intended to be used for, if anything. An Android OS dev making this statement is, in fact, significant news.
AlexandraSalvaterra's github page shows that she is not a member of the Github Google organization. So I don't believe she is an Android OS Dev working for Google, or that this should be considered an official statement.
The articles that she linked to were old ones which have a note saying that Google denied that the speculations were true. And herself said in a later tweet that she was "putting things together" and that "5 years is a long time".
And also, "Also, do keep in mind how Google sometimes randomly kills projects, and starts new ones, nothing is set in stone with Google."[1]
You're right, it was bizarre to say the least. The entire thread is full of well-sourced, accurate info, and then this tweet was thrown in, then immediately after it was accurately disclaimed.
Anyone who works at a BigCo knows there's no way in hell anyone's made a decision about something 5 years out. There's a lot of risky dev between here and there
I think they meant to suggest Fuchsia could replace the Linux kernel in that timeframe
I mean, I know you're suggesting the claim has no merit because the poster doesn't know what they're talking about; but you know, even if the poster were a genius with intimate knowledge of the project, a claim like this is bogus.
If somebody with a modicum of common sense and software experience says some software of this kind of complexity that they're working on "can" be good enough in 5 years that basically means: it's a herculean task, and they have no clue whatsoever as to how long it's actually going to take. Also, they probably don't really know what they're really trying to do, only general aims, not actually how they're achievable.
There's no way in hell anybody can plan something that novel and hugely complex, with that many people involved in an ecosystem that's constantly changing not to mention a business that's not known for its long term perseverance, with any kind of accuracy for 1 year. 5 years is a complete joke.
Who knows - it might happen. It might in just 1 year. Or maybe 50. Or more likely, never. But I cannot believe that estimate to have any kind of sane grounding.
The only way they're actually going to follow through on a schedule that long term is by giving up on scope and quality, which is to say - sure, something will be delivered, but perhaps nothing resembling today's expectations.
I don't believe she works at Google. Someone correct me if I'm wrong.
Edit more: From my research she is someone who has legitimately worked on an Android OS derivative, but it was at another company (Sky TV?). So she's both an Android OS Dev and a non-Google employee. Her source for Android's EOL is the articles she links in the twitter conversation.
She has done nothing wrong but many people seem to have misinterpreted this as a Googler saying Android is EOL.
She doesn't work at Google, she "know[s] a lot of people from Google and/or OEMs" [0]. I'm going to have to file this under "my uncle who works at Nintendo".
She is in the wide sense of the term: she has made some contributions to AOSP. But only Google has actual knowledge of the future of their OS, and she doesn't work for them.
Fuchsia is permissively licensed. I swear, copyleft people have the weirdest definition of freedom. How does using a license that lets you do anything with the code, including using it to compete commercially with Google, automatically indicate some nefarious plan to lock down the new platform? If they wanted to do that, why would they release Fuchsia under a permissive license in the first place?
The main difference is that copyleft currently requires some components of all new phones to be released as open source. With a permissive license, many Android vendors will not release anything open source. So you might have a much harder time figuring out how to flash the OS on them or get the drivers to work with them. Obviously some manufacturers will probably still do so, but they won't be required to as they are now.
Which is to say Fuchsia may not be closed source, but a lot of devices built on it probably will be.
Yeah- this is the only reason there's any openness at all in the mobile space right now. Android forks couldn't exist at all - much less postmarketOS - if the underlying hardware and drivers weren't open and available.
A lot of bootloading / unlocking has been figured out by reverse engineering closed systems. It turns out Google is one of the few ones providing easy tools to do this on nexus / pixel phones, even though they didn't have to.
They still provide the binary drivers/firmware from upstream because there's no replacement for those.
People are concerned a copyfree license will enable Google and manufactures to lock down the platform. Why do so many people have trouble understanding this kind of thing and have to turn the debate into an argument about the definition of the word "freedom"?
Most people don’t run software they built from source code on their phone. If what they’ve done with proprietary Android additions is any indication, you’ll have no idea what you’re really running on your Fuchsia device.
One big feature Fuchsia has over Linux is stable kernel driver ABI. It is reasonable to predict that while Android kernel drivers are open by necessity, Fuchsia kernel drivers will be closed unlike Fuchsia kernel itself.
Isn’t only the kernel and the OS permissively licensed? There’s nothing stopping Google and others from making all of the non-OS features closed source.
The nice thing about copyleft is that it’s infectious.
GPLv2 for a kernel isn't super infectious because your entire userspace can be proprietary. And you can also ship proprietary kernel modules as long as you make sure there's a minimim of logical separation. And even if you don't it hasn't been tested if the kernel plus a bundled kernel modue constitutes a derived work.
So you now basically have full control and can make nigh arbitrary modifications to both user and kernel space while only having to show the source of the kernel itself. Not super powerful in practice. Pretty deal for the kernel devs though.
Google Play Services is already closed-source and that’s where the tracking happens. The fact that the base OS is technically open source is usually irrelevant if you have any proprietary Google junk on top of it. But your baseband is allowing you to be tracked too (regardless of the software on the application processor), so it’s hardly possible (certainly not easy) to have any privacy with a cell phone in your possession.
This is lunacy. Nothing is going to replace Android but the next version of Android, for the same reason why Microsoft will forever continue developing Windows: there are (hunrders of?) billions of lines of code written for it, and: 1. Users just want to run their software, 2. Developers just want to sell their software, and nobody is going to give a shit about principled OS design or whatever. If Google doesn't understand this, they're about to learn a hard, and expensive, lesson.
Google has already made Android apps run on Chrome OS, and I think are at least planning to do with Fuchsia. Which is to say, Google could kill the Android OS as long as they preserve the Android app platform.
See also: Windows has actually replaced their Win32 app model with UWP which is nearly a whole different app platform, but they still support Win32 apps and have made it increasingly easier to deploy Win32 apps on UWP-based platforms.
The main hold up to new development being UWP is the lack of compatibility with Windows 7, which is going out of support in January. Enterprises will most all have switched by then, and it will be considered pretty safe to develop ew software with UWP over legacy APIs.
1. The large body of win32 code already written, maybe exceeds the quantity of future UWP apps.
2. The quality gap between what you can write with new and old stuff.
Maybe they have closed 2, I stopped paying attention a few years ago. But last I knew there was a bit of a chicken-egg problem where nothing substantial was being written with the new thing, thus no means for it to be validated and improve.
Also there is the general problem that 21st century Microsoft cannot compete with Windows NT. Can a new UI framework from Microsoft ever outdo the old stuff? Debatable. There have been several attempts.
I actually looked at UWP a couple of years back. To my shock and amazement, at the time the C++ API did not contain anything that would allow you to resize bitmaps. You could resize them for display, no problem, but there was nothing like Core Image available. How this is possible in this day and age on the world's premier desktop OS, I don't know.
AFAIK a UWP app can use Windows Imaging Components (WIC) for that task, which is a COM API introduced around the Vista era. Part of the great nebulousness of defining UWP is that they can retroactively say a particular Win32 API is "modern" enough to fit.
Microsoft never did and never will "replace" anything with anything. They'll just minimally rearrange the barnacles on the ship to make space for new barnacles. Their customers rely on being able to run software they purchased 20 years ago in some cases.
And I personally haven't seen anybody use Android apps on ChromeOS.
What if "the next version of Android" will run all those old .APKs on something that isn't Linux? To someone working on the OS level of present day Android this will be "not Android anymore", to everybody else it will be just another iteration, perhaps worth a little brand refresh. There's no conflict beyond semantics.
Don't see how that will work, given that a lot of the more desirable apps use native API and their developers have no desire whatsoever to put in more work to adopt yet another Google OS, in addition to Anrdoid. See e.g. what happened to Windows Mobile. Excellent OS (better than Anrdoid in terms of UX IMO), but failed to get traction with devs.
It's not like all Android phones will just cease to exist when Fuchsia comes out. So even if this is done near flawlessly (chances of which are slim given how different Fuchsia promises to be), Google would be expanding the already insane Android testing matrix for devs.
If BlackBerry cam figure out how to run Android apps on BBOS 10 (which is QNX under the hood) I'm sure Google can get the Android runtime working on Fuchsia.
I don't see how Fuchsia can pull this off without having at least compatibility with existing Android apps.
Even if they do: I could see a ton of smartphone brands continuing to maintain it for their own smart phones (the Chinese have been big on that front!) or even making their own OS like Samsung with their Tizen OS.
All they need to do is offer the legacy API in addition to the new one, and write an internal translation layer. Obviously, that legacy API is at huge risk of being deprecated, so you should expect it to be considering. Any app out there that isn't rewritten for the new API will eventually stop working, just like most of Google's products. I am sure they would enjoy seeing this 'cleansing' of less-popular and niche apps.
Fuchsia is just a kernel, if Google reimplements the Android stack on top of it as a replacement for Linux, the only apps that would be impacted would be those few that use NDK native code.
Well I'm not aware of any nonprofit phone development cooperatives so without Google driving it is is likely to become less popular but there will probably also be other corporations that continue to develop an ecosystem for it. There are still OS/2 derivatives being developed. I'm also just saying people will continue to use it and something along the lines of LineageOS will be even more important for people to be able to use their existing phones. For most people who continuously discard their phones after a few years to get the latest greatest it may end up being supplanted by whatever fuschia based phones are developed. I'm convinced that fuschia is partially driven by a desire to escape the GPL so with a MIT based licensed manufacturers won't even need to pretend to release the source code for their hackish drivers and kernel mods.
This explanation ignores the incredibly valid technical reason for why Google is working on Fuschia.
Android uses a monolithic kernel via Linux, and as a result has weaknesses that have surfaced over time due to ecosystem and compatibility bloat. Long story short: Android upgrades are often dependent on the manufacturer distributing updates that account for their unique devices. And that's both difficult to manage and shortens the lives of the phones people use. Hence why so many Android phones stop getting updated after only a couple of years. (Apple doesn't have this problem because it controls the ecosystem of devices.)
Fuschia, on the other hand, is based on a microkernel, which simplifies the stack, making it easier to push the phone's underlying operating system to a newer version while allowing the complexities that come with there being dozens of phones (and laptops and tablets) to support. Everything is a service in a microkernel. Given the complexity of having to support so many different kinds of devices in the current ecosystem, moving everything to a service makes a lot of sense as it would remove the compatibility complications.
Google taking its mobile operating systems and pushing them into a monolithic kernel, licensing concerns aside, helps solve a big ecosystem problem that has only grown for Android over the years. It limits functionality in older phones and when developers fail to support these devices, it creates unnecessary electronic waste.
This approach would conceivably separate the underlying OS from vendor support. That is something a widely used mobile OS would benefit from.
This is only one aspect, admittedly crucial as ecosystem management is a leading motive. But there are many other technical advances. One aspect is rampant bloat in today's apps, as each often duplicates a significant part of the OS.
In Fuchsia apps are collaborative by nature as the OS itself manages the user. Apps get to fill slots in story lines and so can be a seamless part of a bigger task, which can involve online resources. Along with a better user experience, app sizes might well go down 80%.
If successfully executed, it represents a paradigm shift reminiscent of the transition from DOS to Windows: it becomes much easier to realize a engaging and satisfying user experience.
The reason is more that the binary blobs that make every modern phone work couldn't be updated to the kernel ABIs every time they changed. The whole point is to make it easier to deploy new hardware with custom bits.
> ... Fuschia OS (i'm sure i probably butchered the name)
This is an excellent reason why Google shouldn't ditch the name "Android". It's easy to pronounce and globally recognized. Every time I see the word "fuschia" I have to think "wait how is it pronounced again?"
I don't care if they change the OS under the hood, but if anybody in Google is planning to sell a "Fuschia-based phone", they're pissing on their own brand.
According to Wikipedia total Alphabet assets are around $232B, and Xiaomi's are around $21.6B (ie. ~10% of Google's total net worth). Xiaomi was founded in 2010. Google was founded in 1998.
it was only half sarcasm (and thanks for not firing at me for being overly laconic in my previous comment)
I feel going back to very tech light, very local might be a very plausible future. Maybe phones but not as a platform for life through digital pipe metaphor
different and deeper education, more trustworthy next door social tissue, slower pace
Haha no problem, I figured there was more to it than just that ;)
I do agree with you that we would be better off with less tech, but it would be hard for me at least since I love it so much. Although I do stay away from social media (unless you count the occasional HN post) which I think does more bad than good.
