We need a real GNU/Linux (not Android) smartphone ecosystem | Hacker News Reader

We need a real GNU/Linux (not Android) smartphone ecosystem

old.reddit.com

199 pointsneelc223 comments

As much as we laugh at IBM and Intel nowadays and praise the success of ARM, the x86-based IBM PC ecosystem with standardized BIOS that maintains compatibility for decades is such a blessing, a huge breakthrough that we don't even notice anymore because we're so used to it.

Before that the OS development was tightly coupled to hardware development. Booting an existing OS on a new device even with the same CPU required prior patching, configuration and re-implementation of the floppy drive driver. And it wasn't seen as odd because that's the way it was.

I don't think the problem is a lack of OS enthusiasts, we probably have more of them than at the time Linux was born. The problem is they're fighting an uphill battle against a swarm of slightly different CPUs and device trees and uncooperative vendors that do anything they can to lock the device.

A lucky accident that IBM failed to prevent, they didn't want to have such a market, Compaq made it possible, with a clever way to prevent it legally.

It is very puzzling. We have a plethora of brands from chinese, korean, european and american companies to kickstarter-funded projects to reskinned odm designs in developing markets,- all vying and clawing at each other to stand out in an oversaturated market with more cameras, more pixels, more features like AI, and filters and what-not. Yet not one of these companies think to release a phone that proffers to give the best rooting experience or Lineage OS compatibility - or better yet, comes with LineageOS out-of-the-box.

I think one of the main reasons is that many apps such as banking or drm-protected apps, which are usually only offered through the official app stores, will refuse to work on a rooted or custom imaged phone. You'd have to go through youtube tutorials and have to download the software through third-party mirrors, and that's not a feature that will sell phones.

Another reason is that giving users the option to root and unlock is possible only after ditching whatever agremeent is in place with Google. So, no Play support for this vendor at all means no sales to normal markets.

Going deeper in conspiracy theories, Google would drop Qualcomm/Mediatek from the ecosystem if they'll ever allow a single SoC licensee to do such phone.

> Yet not one of these companies think to release a phone that proffers to give the best rooting experience or Lineage OS compatibility - or better yet, comes with LineageOS out-of-the-box.

How profitable do you think this would be?

I reckon at least as profitable (probably more) as every other forgettable model in the currently oversaturated market all trying to target the same segment in the race to the bottom. We don't care about cameras or games or ai. We are happy with last years specs (or older). The after-sales-support, maintenance, updates can be offloaded to the community. Sales will probably be online and not in brick-and-mortar stores since it would be difficult to market to regular people. So Marketing budget can be minimal. Just do a couple of talks at foss events. It might not be the kind of phone that gets Marques BrownLee excited but the FOSS community (which still has clout and influence among tech-elites) will be more than happy to do the evangelism for a phone that is 100% open-source and doesn't spy on you. Since sales are online it could be a kick-starter or pre-orders in batches. So 100% cash upfront before production. It could even be the halo phone for the next phone unicorn startup (ala OnePlus).

So, basically the Librem 5?

Yeah. Basically a Librem 5 with the useability of Android.

Nothing stops you from running Android on a Librem 5 if that's what you desire.

I believe Fairphone used to ship models with LineageOS out of the box—their new models optionally ship /e/OS, which I'm not familiair with but seems similar on the surface.

I think OnePlus one comes the closest. It came with Cyanogen OS out of the box (a version of Cyanogen od, predecessor to the LineageOS)

The devices ship with a kernel that can use them. Is there anything we can do to make it easier to extract whatever device tree or other information from the compiled kernel it ships with, so it can be used with any other Linux kernel?

You can use the downstream kernel directly via Droidian (a Mobian-derived GSI image). But otherwise the downstream kernels and device trees tend to be useless from an upstream development perspective - too hacked together and not maintainable in practice. Your proposed approach can be used however to extract existing firmware blobs (that will run unchanged no matter what the booting OS), and Mobian is pursuing that approach.

Device tree is a file in /boot that can be decompiled. The missing artifact is open-source driver code.

What stops someone from decompiling the closed source driver into barely legible "source code" and then grafting that onto a generic kernel so it can run on the device? It wouldn't be pretty but it would probably be a faster way to get running on the device than having to write a complete reverse-engineered driver from scratch before you can even boot, and then you have a starting point for writing an open source driver that doesn't suck as much.

Could some change be made to the kernel to make that process easier? Do we need better tools to make it more practical?

> decompiling

https://law.stackexchange.com/questions/101689/can-you-legal...

  If you look at a decompiled code and are influenced in how you write your code by the decompiled code, this is probably a "derivative work" of the original program and not just "reverse engineering" from the way that the computer program works. Copyright for software protects the decompiled code that is written, as a literary work, and anything derived from that decompiled code is also protected..

  [clean-room reverse engineering] One group examines the source to write the specs and rundown. Another to make the code again, with no people from group 1 taking to them but for the spec sheet

> do we need better tools to make it more practical?

Good question, perhaps others can comment. The challenge is likely economics, not tooling.

This is GPL code so decompiling isn't necessary or the problem.

Accepting over the wall low quality code and having a submitter for it who may know nothing about it makes it difficult to work any of this low quality code into the mainline kernel via its resource starved processes.

Isn't that precisely what the GPL is for? Are all these vendors violating the license?

Possible, but sometimes vendor code isn't acceptable for upstream, even when public. Some vendors ship binaries with EULA restrictions to customers, who choose not to exercise their GPL rights.

A modern approach to working around the GPL is to move functions from open drivers to closed firmware.

> uphill battle against a swarm of slightly different CPUs and device trees

Economic incentives for "differentiation", e.g. device tree with upstream Linux and uboot support for feature A, but non-upstream uboot blob enables feature A+B.

The Samsung s5 had a noticeable difference in camera quality between stock and AOSP.

One issue between then and now is that there’s a hell of a lot more people now that are aware what transpired then and what steps to take to prevent or sabotage a burgeoning clone market.

I wonder why google hasn't mandated some open standard like BIOS for all new arm based phones/tablet/smart-device that have the playstore and google services. I can't see it doing anything harmful to them and would make the whole ecosystem easier to develop for and may even make spread and make arm based laptops/desktop/servers more standardized which would be useful for data centers and such. it would probably help with the whole shitty driver situation on arm platforms. I honestly don't see a downside for anyone if everyone is having to do it which mandating it for android would essentially insure.

With the vendor/system split introduced by project Treble in Android, it should be easier than ever to build your own system against a rich set of hardware abstractions, that work on a wide range of devices. Assuming you are ok with still running a very thick slice of the stack as proprietary vendor image.

Yes you can run a GSI (and project Droidian does that) but then you're dependent on a downstream kernel and Android-ish early boot environment, that will likely lead to pointless incompatibilities compared to a fully-upstreamed approach.

Upstream doesn't care about clang and Rust as much as Google does, so that isn't ever going to happen as much as people vouch for it.

The biggest hurdle to getting AOSP-kernel features into the upstream kernel is not clang or Rust, it's cleaning up hacked-together kernel code in a way that makes it long-term acceptable to upstream maintainers. (And getting rid of userspace blobs for things like graphics.) Always has been for as long as AOSP was a thing.

It’s even hard to find the uboot patches for clockworkpi hardware, and they open source almost everything.

well, it was fun while it lasted at least.

now with apple and arm pushing for an alternative platform via emulation at first, we are heading for a fragmented mess yet again.

Nokia had a chance for greatness around 2010 with Maemo and Meego. And either by stupidity or malice they ruined that. It was the right moment to have a chance, the smartphone game was still starting up, Nokia was still very influential in that arena, and the 2 devices it made (the N900 and N9) were great in their own way, for what was around that time.

But between their own internal sectors still betting on Symbian, not being open enough and the mole that Microsoft introduced with Elop that opportunity was lost.

From there on there was Sailfish (that never managed to get enough adoption), Ubuntu Touch and Firefox OS among others, but no big vendors backing.

And the opportunity moment was already passed, as the de facto platforms for mobile development were iOS and Android, not even Microsoft was successful pushing their own platform there. All the killer apps are already released for those platforms, trying something new won't give the essentials to communicate with others and participate in society as of today.

N900 was my first smartphone and still miss the feeling of having a proper Linux box in my pocket. Unfortunately didn't buy the n9 as it was clear it was dead in the water by the time it came out.

Based on my contacts at Nokia it was simply underfunding, believing that symbian would remain dominant in developing countries and seeing the meamo/meego line as a distracting and expensive side project as well as internal competition which people sought to sabotage internally. Some ex-Nokia people blogged quite extensively on it.

Holy f---ing s--t! Did you just reboot your web server through an SSH pipe with your cellphone?!?

The N900 was phenomenal for its time. One of the best smartphones ever made. If you just wanted to use it as a smartphone you could but if you wanted to dig deeper it was such a versatile and capable device.

I still use Sailfish OS, but it's becoming more frustrating with more and more things locked into proprietary apps (which are only available for android and ios) with no option to do things over a web interface. Just the other day I had to leave a laundromat because they only accepted payment via their mobile app.

Nokia may have had an opportunity; however, you may not remember history, but the iPhone 1 was a game changer, and one thing that Android did right was to immediately adapt to the new form factor. Android won its place in the duopoly because it was and still is technically excellent, it adapted faster, and because it was immediately available to use by phone makers, borrowing many good lessons from Windows.

The truth is, there was no more room left for a no. 3. The writing was on the wall for those able to see, Nokia's alternatives were out, much like Blackberry, regardless of what they did.

I, too, was unhappy with Nokia's move to producing Windows Phones. But Microsoft, compared to other companies, knows how to build operating systems and create developer ecosystems around them. If Microsoft failed, IMO, Nokia did not stand a chance.

Nokia had a device on the market, the 770, before iPhone 1 release, and launched a successor, the 800 around the same time. However, for internal political reasons the devices didn’t have a GSM chip. The 800 was comparable to the iPhone: the touchscreen was much worse, but had a keyboard and could multitask.

So, from the technical standpoint they could have adapted much faster. However, the Maemo team didn’t stand a chance against allpowerful Symbian internally. The team was tiny (50ish people on the software side if I recall correctly?), wasn’t given neither the resources nor the goahead to try and build the smartphone on the platform.

It took years for the executive to realize Symbian’s not going to cut it and devote more resources to Maemo. Finally, with the launch of N900 Nokia two years later had a capable horse in the race.

It promptly went to kneecap it by announcing, in the same announcement speech that introduced the N900, that the platform is obsolete and the new version will use a different platform (qt instead of gtk, rh instead of deb, etc etc). It was the worst ever act of self sabotage I have ever seen and to this day I don’t believe it wasn’t a malicious act by some executives, nobody could be that stupid.

Anyways, Nokia proceeded to rewrite the entire platform, tied up with Intel in the process, and just wasted time until Elop told everyone to jump off.

In 2007-2008 Nokia stood a fighting chance, but internal power struggles, short sightedness and politics killed it.

(when I say Nokia I mean the smartphone division)

The N800 was actually before the iPhone too, I know since I had it. This meant I wasn't as impressed by the IPhone as others, but I failed to appreciate the strength of the iPhone too. N800 had a resistive screen and a pen. It had a quite cumbersome interface and was more fragile. Also, it wasn't a phone. But I used it like I use my smartphone today.

The LG Prada was the real game changer, the iPhone was just a knock-off.

As ex-Nokia, it was a game changer in the US market where Symbian didn't had much luck in the market.

Symbian development community wasn't that happy with Windows on Nokia phones, that is why most pivoted into Android and iOS.

Nokia was mostly an anti-Microsot culture shop when I joined in 2004, we had HP-UX, Solaris, Red-Hat Linux and Symbian. Windows was only used as thin client.

Android was fortunate to recruit Matias Duarte with experience from Danger Sidekick and Palm WebOS.

Only thing to add that it was funny how Blackberry didn't get for years that the browser is so important in the phones. Others missed that as well, everyone was doing the stupid half-browser thing. Of course they did as a normal browser needed a level up from their hardwares to be a PC leauge player.

This would have maybe delayed the inevitable though for some years anyway, just sayin.

Blackberry did eventually get their act together, but it was too late. There was a Blackberry KEY2 phone based on Android, with a valiant effort to sandbox Android/Google with Blackberry security policy controls. That phone belongs in a museum of adversarial interoperability, alongside Godzilla/Kong memes.

We need more devices with runtime competition between tech titans. Some is visible on iOS with Apple v. Facebook on ad targeting and contact databases.

Blackberry was primarily a corporate vendor, their phones were geared for email and Exchange server support, not end users, and their corporate users presumably weren't surfing the internet on their phones regularly. By the time of the iPhone, these features were available to the consumer market as well and it was no longer a unique advantage for them.

> All the killer apps are already released for those platforms, trying something new won't give the essentials to communicate with others and participate in society as of today.

I don't know about that. What's left are the things the existing platforms won't give you.

Example: uBlock, but for apps. Runs the app in a container and blocks network requests to tracking servers, or otherwise modifies the app to remove misfeatures. Think: Game Genie for social media apps.

The problem is you don't just need the killer app, you also need all of the existing apps, and hardware to run it on. So the real problem is you need your new system to be able to do that, but simultaneously be able to run common Android apps on common Android hardware.

For those who don't know, DuckDuckGo provides an app tracking blocker for Android that implements itself as an on-device pseudo-VPN and blocks known tracking services. No containerization/sandboxing, but it's a start.

https://spreadprivacy.com/introducing-app-tracking-protectio...

I switched from Android to iphone a few months ago because I'm an idiot, and I was really disappointed to find there's apparently no way to set up an ssh tunnel in to my server so I can go to localhost:3000 and check out dagster from my iphone.

10+ years ago I had an HTC touch pro 2 with Lineage OS and I miss it dearly. Amazing hardware keyboard, linux in my pocket, no BS. And that phone originally ran Windows Mobile, funny enough.

You can do it, just need third party app

Seems like it’s limited to ten minutes max in background by iOS

Even the N8 was comparable to the android I have today after 14 years. Full touch screen, great battery life, excellent camera quality, great maps, regular OS updates, ran all the software it had smoothly and could be programmed in C++ with Qt Creator.

Then Microsoft came and ruined the N series by making nokia release some broken version of the OS (code named anna and then bella) so that people would buy Lumia. After a couple of months, there was no more application store. What terrible blunder that was.

Now imagine the Symbian community, with its anti Windows CE/Pocket PC bias, shortly after doing the whole set of transitions with Caride, Qt Creator, PIPS, being told that after all that transition work, they had to throw everything away and code for Windows Phone 7 with Silverlight and XNA in C#.

Naturally most went elsewhere.

> Nokia had a chance for greatness around 2010 with Maemo and Meego. And either by stupidity or malice they ruined that. It was the right moment to have a chance, the smartphone game was still starting up, Nokia was still very influential in that arena, and the 2 devices it made (the N900 and N9) were great in their own way, for what was around that time.

Meego, Maemo was really early experimentation IMHO. WebOS and Tizen were two worthy contenders, but both of them went to die in enterprise institutions that have no understanding how to create a product. HP absolutely smashed WebOS, and Samsung in its usual ultra hostile fashion destroyed any open source potential Tizen had. HP, Samsung, and Oracle is where Open Source goes to die.

WebOS was absolutely amazing. The Palm Pre on the other hand felt like plastic trash. I was young enough when it came out that I was dependent on my parents to buy and pay for my phone still and I dragged my dad to a Sprint store at 5:00am to make sure we were first in line to get one so they didn't sell out. When we got there I figured I must have the wrong date because we were the entire line.

I used that Pre until the plastic shell started falling apart and by then the writing was on the wall that it wasn't going to be the next big thing for phones and I regretfully bought my first Android phone with my own hard earned money.

There was also Bada OS, Samsung's attempt to cut the dependency on Android. I was actually running a device with 1.0, and it was surprisingly usable. The investment in building a development community was also there. They released lots of documentation and the SDK. Sadly, they followed with a 2.0 that really wanted to feel like Android (but wasn't).

They obviously didn't want to put all their eggs into one basket and kept releasing Android phones in parallel. Eventually, Bada died a silent death, although some of it probably found its way to Tizen.

Palm/HP WebOS descendant lives as open-source based on OpenEmbedded, shipped on LG TVs.

https://www.webosose.org/

And much saner than using Android based TVs.

My understanding as well that Nokia bet everything on Symbian.

Wanna buy my N900? I don't miss using it. Especially its abysmal GPS, abysmal video recording, resistive touchscreen, terrible manual calendar sync setup, no choice of map software, etc. etc. Good riddance. That proper keyboard alone couldn't make up for everything else.

The mobile ecosystem is basically the world Stallman and his comrades-in-arms wanted to prevent.

It did't come to reality on the PC, but sneaked in through the backdoor with the advent of mobile devices.

I have little hope that this can be undone, but we need to be prepared to nip these tendencies in the bud for the next paradigm shift.

It is coming, PC Clones only happened due to IBM not being able to legally prevent it taking off.

It is no accident that the laptops as desktop replacement are just as vertically integrated, most people not using laptops have NUCs and game consoles, and custom built PC towers are seldom seen outside hardcore PC gamers.

Working with all major systems I have to say I don't have the feeling that the commercial OS is getting any better. If anything they are getting worse.

What is getting better are the likes of KDE. Where a good decade ago running Linux still was a pain where it didn't work, nowadays it mostly just works, the System UIs are more usable, more customizable and in many cases better than any of the commercial OS for a while now (and yes, that includes MacOS).

Android is a pain in the rear, IOS similarily so.

I just returned a NUC, because no matter what I tried, the UEFI bios and the collection of distributions I tried didn't come to terms.

And that's one of the strongest criticisms of Stallman's Free Software. Instead of providing alternatives, they are just against them.

Of course they tried to provide alternatives, but they are still stuck 30 years behind, they haven't gotten to phones yet. During Covid they had issues getting videoconferences to work.

> they haven't gotten to phones yet

Huh? I've been happily using several GNU/Linux phones as my daily drivers for the past 16 years.

FSF also supported Replicant, which isn't something I'm personally interested in but it's there.

Which devices and distros?

They gave us a completely free version of Unix! What more do you want?! Do you even contribute to the FSF?

AT&T did that in first place, without the impediment to sell Bell Labs research and the Lions book, UNIX would never had been available for free to start with.

And they are still working on that.

"but they are still stuck 30"

What did I say?

FSF's position is restrictive in the sense that it limits the choices you have. On non-mobile, while a lot of people agree with FSF's point of view, in practice they have to make exceptions.

(There's the urban legend that you're always breaking some law even when you try your best not to; probably you're also always running some opaque firmware blob even when you try your best not to).

I don't see mobile users making any compromise like this, unless a gigantic scandal happens.

It’s happening (albeit slowly?)

Librem 5 PinePhone and its Pro variant FuriLabs FLX1

Mobian UBPorts PostMarket OS And all the other distributions.

Still what’s really lacking is some kind of critical mass that can’t be ignored. Many many services even in real life are locked behind an iOS/play store wall (even sometimes with no alternative outside needing a smartphone).

We’re not completely locked in yet so there’s still time…

This. I try to collect all that happens weekly in the space at https://linmob.net

Thank you for doing this. Added RSS feed.

Something I think people in tech sometimes don’t realize is that the complexity of modern software generally requires a lot of money to be thrown at it to get meaningful amounts of stuff done, and that money is getting thrown at open source by the giants, who may have whole teams dedicated to advancing it. That means they’re the ones directing the R&D and advancing the state of the art, so your little indie/hobby/crowdfunded/grassroots thing isn’t going to be able to keep up, probably. Call me cynical, but that’s just what I seem to see right now.

That's because you treat a FOSS project with a commercial mentality.

Remember the first post Torvalds made for the kernel?

He didn't say "I'm doing a project to compete as fast as I can with commercial UNIX machine so please help"

He sid this: "I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu)"

And it became huge. By chance.

A FOSS phone doesn't have to support Whatsapp. It should be open, fun to tinker with, modular and, maybe, with enough logic to handle carrier signal and SMS.

Even if it's not successful, the code and schematics will still live somewhere on the Internet, ready for anyone to create a weird steampunk phone.

Most people that want a Linux phone don't care about freedom of tech. They just want some portable Unix workstation with all the comfort of a commercial phone.

Which it's not wrong by itself. But demanding Open Source to create another "commercial-like but gratis" it's already a bad attitude to start with

> A FOSS phone doesn't have to support Whatsapp.

What apps does it have to support, in your opinion? A computer in my pocket is useful for a lot of things, but central to its usefulness is communication. it can choose to not support all possible modes of communication, but it needs to at least support some of them, in order for there to be any adoption.

A browser that provides PWAs if you are looking for a smart phone. An opensource app store alternative. That's how I imagine the bare minimum, but I'm not the biggest smart phone user.

Matrix. Then you can have a Raspberry Pi homeserver that bridges to Whatsapp and other things.

I mean, you can already run the Linux kernel on a phone and shell in, which is why I think of a “Linux phone” as meaning a Linux based phone that’s actually usable, as opposed to a fringe hobby device…

I think you are missing the point.

It will support whatever forms of communication the author wants it to. I know it’s hard to believe, but mass adoption isn’t the end goal of many FOSS projects.

You are commenting in a thread titled "We need a real GNU/Linux (not Android) smartphone ecosystem", mass adoption is the foremost goal.

First of all I really wish people would stop conflating nonfree open source and free software. They are as different as night and day.

Second of all, you are agreeing with me that independent software can’t compete with massive corpo sponsored projects.

All I’m saying is an indie phone isn’t going to be able to compete on the same level as devices that have billions of dollars of R&D poured into them, and people have this fantasy where the socialism of the commons will give them magic toys (after all look how successful open source projects have been!) without thinking about how all the expert hours are going to get devoted to these things, of even throwing a couple of bucks anyone’s way themselves to fund it.

Crowdsourcing can work (Ubuntu phone got $12.7 million public commitment but fell short of the goal so got nothing) but even then it’s on a whole other scale.

I've given up on ever expecting an open source phone. Apple likely spends more money developing just the keyboard than these OSS companies have to spend on the entire phone, software and hardware. There is just no way they can release something that's even usable, let alone competitive.

Did have an unexpected win in the form of the Steam Deck though. Never thought I'd have a powerful hand held, desktop linux gaming machine at an affordable price. Back in the day I was following the Dragonbox Pyra project and really liked the idea, but couldn't justify spending so much on a device that couldn't really do anything.

Yeah, but Steam Deck is a perfect example of corporate funded semi-open-source winning. It could literally never have happened without spending millions of dollars on FTEs, not to mention getting the hardware side right. That’s EXACTLY what I’m talking about! Nobody who doesn’t have a giant stack of cash is going to come disrupt le heckin’ market with a great UNIX phone.

The closest we got there in the phone market was Purism's Librem 5. That project funded tons of development, both upstream in various projects all over the stack and in original work like Phosh that later went on to live its own life - and of course all the vertical integration that went into PureOS. It significantly pushed the ecosystem forward and produced a working device that let me finally migrate away from N900 and that I'm still happily using as my daily driver. OTOH, it went way over the crowdfunded budget, caught enormous delays (including, but not limited to, COVID supply chain collapse) and almost killed the company...

Contrast that to the PinePhones, which were done cheaply in a "throw some hardware at the community and let them figure things out" fashion. This approach had both upsides and downsides, but ultimately I think it showed us that this community is still way too small to be able to sustain a project of such complexity on its own. There's still a lot to be done in this space and without Purism's investments things move much slower than they did a few years ago (though fortunately they still do move).

(disclosure: I'm one of the developers who were paid for that work)

I think in general the idea that open source means tons of crowdsourced free labor is both very misleading and very much oversold by people who do make money on it (I have also been paid to work on free software and done my fair share of shamelessly pimping free and libre software as a giant pool of free labor) (but I’m referring more to giant corporations that exploit community software)

It is a giant pool of free labor, but it's an uncontrollable pool which will go in whatever direction it wants to and doesn't care about what you would like it to do ;)

Why can’t Facebook spearhead such a project? Zuck has always complained about closed ecosystems not allowing them to release cool features. Google forbids android OEMs from developing devices for other mobile stack. So we really have two hurdles.

No we really don't.

What we actually need is to do all over again what has been done for the last 30 years on computers: developing and reverse engineering open source versions of the various drivers for mobile devices' hardware. Without them you will be forced to pray for ABI compatibility at every update and you will never get to know your actual hardware

As an analogy: I use Sway but it doesn’t stop me from running GTK apps. I could use Gnome as my desktop software — a giant GTK app for running other GTK apps — but I don’t have to.

Job scheduling, URL handling, settings daemons… we have standard tools for doing this as well on a Linux system. Somehow they remain only very loosely bound together and different bits can be omitted or swapped for alternatives.

With Android / AOSP, are the components bound tightly together? I suppose the acid test would be: can I run Google maps APK on my Linux desktop as an app showing in a native window, or do I have to run an entire android emulator which has to take over a portion of my screen (and provide separate versions of all its own system services) to run one app?

If a WINE-for-Android like thing exists, then I’d be very happy to run a standard Linux system on my phone and have it boot into an Android launcher that could run Android apps, but also be able to do anything else I wanted to do with a bare Linux system.

Steamdeck from Valve does exactly this and it’s very good. The stock behaviour is to boot into their launcher (SteamOS) but if you sang you can toggle to a KDE desktop, get a shell in a terminal emulator, and hack away on what is just a regular PC.

I think you're looking for waydroid? AFAIK it does in fact have most of an android system bundled into it and it doesn't do rootless windows (Android apps are rendered into a single window that contains an entire Android UI), but it absolutely works. Funny enough, I use it on my laptop because Anki has dependency problems on my system but the F-Droid version is fine.

>it doesn't do rootless windows (Android apps are rendered into a single window that contains an entire Android UI)

If you launch individual Android programs via `waydroid app intent ...`, they render as separate windows in the parent compositor. The single window for the entire Android UI is what you get if you run `waydroid show-full-ui`.

It's better to use the single window mode though. Splitting to separate windows is hacky and is never going to be 100% reliable unless completely reimplemented at a different layer.

I'm using Waydroid on my phone sometimes, and frankly, single window mode is all you need anyway.

Oh! Thank you, I will have to try that. Here I just got it working and stopped reading docs... oops...

Note that the .desktop files that waydroid generates by default for each installed Android application already do that.

We already have it, and it's called Sailfish OS (https://sailfishos.org/ and https://en.wikipedia.org/wiki/Sailfish_OS)

The paid version even comes with Android App Support - the 'killer feature' that allows a Sailfish device to run full Android apps in a sandbox (https://jolla.com/appsupport).

Some people will inevitably moan that it's proprietary, but that's just the UI layer; the rest is wide open, familiar Linux. I can SSH into my device without any fancy workarounds, and it works almost identically to a desktop machine.

(Besides, how else is a company meant to survive in the super-competitive mobile device market? The OS is cheap. Android App Support is awesome. Pay up and be grateful!)

The UX is simple and consistent, WAY superior to iOS and Android.

Most importantly, it has an ecosystem: the Jolla app store, a comprehensive SDK, and an alternative open source app repository (https://openrepos.net/).

It looks like it doesn't support android safetynet hardware attestation so banking apps etc won't work.

> Pay up and be grateful!)

Website says it's only sold in EU. How is that verified?

"We currently sell in European Union, UK, Norway and Switzerland.

Please be welcome to use our software anywhere in the world, however due to our limited resources we can only support the noted regions." https://shop.jolla.com/

It isn't. You can just use a VPN.

No we don't, because it would be UNIX command line and X11 on our phones, as proven by multiple attempts to GNU/Linux phones since OpenMoko.

For all their flaws, iOS, Android, ChromeOS, and the gone Blackberry, Windows Phone, Symbian, actually rethought the whole programming stack, using modern programming languages, and UI/UX.

And security, don't forget that. Proper app isolation on Linux is still very tricky, with many competing approaches in Apparmor/Selinux/Snap/Flatpak/Docker, all complicated to set up and use. The consequence is that in practice a 2048 game has unlimited access to the files in my /home folder.

On the other hand, Android has a very solid permission and isolation system. This is why I don't want GNU/Linux on my phone; I would rather have a proper FOSS Android.

The Android approach is among the most "complicated to set up and use" (since it's based on SELinux under the hood) but the OEM does that for you. There's no reason why Linux distros couldn't do the same thing using Flatpak and/or bubblewrap. (Plus AppArmor for extra hardening where sensible.)

Linux distros already do that thing. Distros like PureOS, SteamOS and Fedora Silverblue focus on Flatpak as app distribution model.

The thing is, nobody restricts you from ignoring that model and doing stuff the old way if you feel like it, which is in contrast to Android.

Just the lack of.. the whole ecosystem adopting the restricted model and there being a properly specified and documented model in the first place.

The unforgivable part for me was Google prohibiting Android forks in their vendor licensing agreements for their add-on software.

It was a deeply cynical way of doing an end-run around the GPL, and I've held them in utter contempt ever since.

We need real FOSS Android. I wish people would start building from there.

There's a lot of building going on. Waydroid builds their own highly specialized Android derivative. As does Replicant, Calyx, Graphene, /e/foundation, Lineage, microg, and probably lots more in the Foss space alone.

What do you want that LineageOS (plus F-Droid) doesn't do?

Banking apps come to mind.

This is the only reason my phone's not running Lineage. I need those apps mainly for 2fa (some banks don't give me any alternative) or for one or two with no web app.

It feels like a total artificial duopoly, you only get to use your essential service on android or ios.

No other "real FOSS Android" is going to pass SafetyNet either, though

what would a banking app do that a bank website can't, exactly?

Many bank websites require bank apps or hardware tokens to login.

IIRC some finance apps either don't have web sites that can perform financial transaction, or are lacking a number of features of the mobile app. Cash App and Venmo used to be some of the worst offenders, but have improved in recent times.

Google et al pour billions annually into making android a first-class and dominant mobile OS. I think the FOSS community should leverage that and focus on liberating Android instead of trying to reinvent the wheel.

It's impossible because of hardware attestation. Until something is done for that (and "legal" seems the only way), there is no solution

GrapheneOS is attempting to pursue the "legal" way: https://news.ycombinator.com/item?id=41119047

I'm aware, I'm really rooting for them

Android Virtualization Framework with pKVM on Pixel 7+ can technically allow unmodified Linux VMs to run in parallel with "official" VMs that pass hardware attestation. This feature is not yet exposed to end-users.

The point is that apps you need to run will only do so in the "official" VMs that pass hardware attestation and will intentionally fail in the unmodified Linux VMs.

If a banking app or DRM-encumbered streaming app can run in the official attested VM, what would be the benefit of running such closed apps in unmodified Linux VMs?

If banks and streaming vendors don't trust unmodified VMs, why would open-source Linux VMs trust closed apps with binary blobs?

One benefit of running open-source Linux VMs is access to the vast corpus of mature open-source software applications packaged by Debian, Fedora, etc.

> what would be the benefit of running such closed apps in unmodified Linux VMs?

That you wouldn't need the official attested VM anymore.

> why would open-source Linux VMs trust closed apps with binary blobs?

The point is that with an open-source Linux VM, the user could decide what to trust instead of some megacorp deciding for everyone.

> vast corpus of mature open-source software applications

The problem is that there's a lot of proprietary apps that are both (1) necessary for a lot of real-world things, e.g., the SeatGeek app for tickets to shows, and (2) not replaceable with FOSS because the company will ban you if you connect to their API with a third-party client.

> That you wouldn't need the official attested VM anymore.

As hardware, sensor and cellular radio standards continue to evolve, someone has to pay for timely development of bare-metal software to drive new hardware. Today, that is the vendor providing the "official attested VM" and drivers. If Arm can reach x86 levels of backward compatibility and stable interfaces, it may be possible to extend the lifetime of mobile devices with OSS bare-metal drivers. It has taken many years to achieve this on relatively open x86 PCs. Even Arm SBCs still struggle, see the efforts of Armbian. Mobile devices are less open and more complex.

> proprietary apps ... not replaceable with FOSS because the company will ban you if you connect to their API with a third-party client.

Regulations and technology are evolving in the direction of more control, not less. Customers will need to find forms of collective and competitive action to influence vendor policy in sensible directions, because it will be increasingly expensive to bypass. Try to support vendors who use technology responsibly in service of their customers. Encourage OSS competition where feasible.

Is SeatGeek a great example? The web site seems to work fine on my phone.

For one show I went to, I needed the app to be able to get in the door, because I had no option to print the tickets, have them mailed to me, or pick them up at will call, and the web site didn't let me see what they needed to scan.

my bank websites work fine on my phone, too. i don’t run anyone's apps any longer as corpos just take the chance to add invasive data harvesting, location tracking, etc.

> my bank websites work fine on my phone, too.

But don't they disable some features if you don't use the app, e.g., mobile check deposit?

Google is clamping on that freedom by providing ways to detect when you run unauthorized/liberated software (i.e. root or custom ROM)

Your banking app is not going to work on Linux either. If Android is fundamentally broken then fork it. My point is, it seem smarter/easier to take Android and make it more linux-like than to take Linux and make it more Android-like. All the work is already done and paid for. Sailing with the wind vs sailing against the wind.

edit : Unless the goal is also to benefit the linux desktop ecosystem (the whole convergence meme)

This is why it's so worrying that browsers are getting the same treatment. Attestation/WEI will bring this to the desktop (and mobile browser for that matter) and you'll have to use Chrome or an approved Chrome reskin (every other browser, basically) for most things.

> you'll have to use Chrome

That isn't sufficient. You'll also need to use an OS which provides "acceptable" hardware attestation capabilities (as defined by Google) required to verify that the copy of Chrome is legitimate (otherwise this could be spoofed). In practice that most likely means your options are limited to: Windows 11, macOS with System Integrity Protection enabled, Chrome OS, stock Android with Google services installed as system apps, iOS.

Google's first attempt at bringing attestation to the web, WEI, was shot down by hackers, but it won't be the last. Please continue to fight against this.

Honest question - how? I run Linux, Firefox, etc. but I don't know what else I can do to help restore a healthy ecosystem. Run for office with the pirate party?

Crypto, piracy, and anything else you can do to protect yourself from the institutions that caused the these problems in the first place. The actual problem needs a societal/cultural solution though, not a technological one.

> Your banking app is not going to work on Linux either

Why is that? I can use my bank through Linux via a web browser without issue. Logging in more frequently is a hassle but not a bad trade IMO.

The native app won't work though. The problem alluded to by grandparent comment and in linked-article.

My bank doesn't even have a web portal, it's app-only. This is remarkably common in the UK, birthplace of Monzo, Revolut and Starling.

Then change from the bank equivalent to MVNO into a real bank with a website.

Presumably this is about apps which are required for authentication, even in the browser version.

> If Android is fundamentally broken then fork it. My point is, it seem smarter/easier to take Android and make it more linux-like than to take Linux and make it more Android-like.

That's what LineageOS (née CyanogenMod) tries to do, and what this leads to in practice is force them to depend on a heap of proprietary code (downstream kernels and userspace blobs). Outside of that, the work that's "done" on the AOSP/LineageOS UI layers and supporting software/"apps" is relatively easy to port over to Desktop Linux - the GNOME Mobile UX is actually making great progress from that POV. So I'm quite skeptical about your proposed approach.

> Your banking app is not going to work on Linux either.

I think the idea is that no amount of forking Android is going to produce something different enough to entice developers to port their apps to it, but maybe if an entirely new Linux-based mobile platform kicks off, there's a chance?

If you have to consult `developer.android.com` (a Google-owned domain) to develop for your "totally not Android" platform, it may be difficult to avoid the temptation to do as the documentation recommends and simply embrace proprietary Google services and hardware attestation and whatnot. After all, 99% of users have those things and it's just these several weird forks that don't?

I highly doubt devs are interested in developing apps for such a niche mobile OS outside of hacker circles.

Windows Phone failed because even paying devs for apps couldn't entice them to do so.

I think what these people are looking for, really, is an alternative to the Android/iOS duopoly that provides more control and less tracking, not necessarily Linux (yes, I know the title of the post is "we need GNU/Linux"). Companies like Framework prove that there's a nontrivial number of people looking for devices like this.

Windows Phone was around during the time that carrying a smartphone on your person at all times was optional, and we didn't have critical government and banking services being delivered exclusively through apps that only work on Google Android and Apple iOS. I suspect that if Windows Phone had survived, and managed to keep even a tiny fraction of the market share, these apps would nonetheless be forced to support it because they would have to account for at least some of their customers using it.

We already had not one, but multiple. They lost to android. I imagine there were multiple reasons, really, but one of them seems pretty basic: simple SDKs. Even when there was no Android apps, making one was easier, than making... whatever. Now, when there are thousands (maybe millions? I have no idea) Android apps, I don't really see anything else catching on. To be fair, now there is this react-native approach, but still, all these permission frameworks, drivers, really necessary apps nobody will port and everybody needs...

We already have it, but people aren't willing to use it. Using a real libre system will always be a little harder than using a nice and polished billionaire funded walled garden. For obvious reasons. People just aren't willing to sacrifice even a little bit of comfort for the freedom, so products like Librem or PinePhone get mostly just complaints, comparison with Apple, and current users are ridiculed as nerds or weirdos. We will never have freedom as long as this is the prevailing culture. It's up to us, the customers, the commenters.

The title and the fact that it's posted on reddit gives a real "someone needs to do something, but it's not gonna be me." vibe.

Google AVF/pKVM will allow unmodified Linux VMs on Pixel 7+. GrapheneOS has shipped early plumbing support, not yet exposed to users.

That's exactly what I was going to mention. I'm waiting for android 15 to be released and for people to test hardware acceleration support. If the overheating problems are fixed, I'll get myself a pixel 9 XL (for the bigger battery) and use it as my laptop daily driver replacement.

If performance is any good (fingers crossed for something close to the latest raspberry pi) then it's the perfect machine: usb C displayport, it fits in your pocket, can run proper Linux, fallback to Android for steam Link until valve releases an ARM version of steam. It'll be perfect.

For actual laptop form factor usage, I'll connect the xreal glasses to get a big display and I'll use the pixel as a keyboard and trackpad, or an external keyboard and the pixel as a trackpad.

Can't wait for people to test android 15.

They reenabled display port output on the Pixel line?

June 2024, https://news.ycombinator.com/item?id=40650087

All hail Big G in our Temple of Tensor. Amen.

In comparison, Apple shipped a hypervisor 2 years ago, then removed it because users were running VMs. 2024 M4 iPads have silicon support for nested virtualization, but Apple prevents users from running VMs.

At least Google has upstreamed pKVM to the Linux kernel. Since Pixel Tablet can run GrapheneOS, there's a path to running unmodified Linux VMs as open-source pKVM support matures.

It's sad that customers have to settle, but non-zero Google table scraps > zero Apple VM slices.

We need mandatory FLOSS and mandatory open-hardware with the obligation for all commercial products to be design and built openly from start to allow a community to form and switching marketing from mass advertisement to community flaws of interests. Essentially OEMs instead of being advertisement driven with brands like religions they should evolve toward being innovation-branded.

That's would create a much better and knowledgeable world BUT it means having entrepreneurs in chief and managers and technicians aside ate the same level, "high output managers" do really dislike that.

So far, we can't even get Samsung to have their FOSS kernel stuff published in a buildable and usable form - its basically impossible to build their recent kernels with their recent toolchains without finding out that some obscure config option was skipped or that some file didn't survived the pre-release purge or that it requires some obscure Linux distribution to run on. And if you get it to build, chances that it will boot are slim. (Good luck finding out if there's a working UART somewhere on chip pins and it's not hidden behind hypervisor and fuses)

I know, but IF we mandate openness from the start with a public development process this could not exists or the company does not respect the law, if we do not, we will never get much usable things, "open source enterprise" and "open core" are nowadays common ways to profit from FLOSS being not FLOSS at all while formally respecting the license.

The problem to arrive at the laws is how many know enough to understand why we should and we must have such law, because if for most it's not even clear what is something you own vs something you can use via a proprietary remote service...

Physical ownership is a clear concept for most, digital ownership for most is a mystery... That's the damn issue.

As much as I like the concept, I'm not sure Linux phone is a good idea. Desktop Linux is not particularly prone to spyware scanning the filesystem and uploading it mainly because they mainly use free software from package repositories that are vetted by maintainers. If Linux phones are used like Android or iOS phones are used today (downloading random binaries, often to interact with real world things you can't opt out of, with distribution controlled by a corporation not too worried about your privacy), it would be a privacy nightmare.

In my mind part of the "Linux Phone" package is moving primarily to a package repo software distribution solution. You can slap an App Store-esque frontend on it, but the software you're installing is (by default) from a curated list of supported open source packages, not random binaries from untrustworthy parties. Of course, this mentality is losing support even on desktop Linux with the move to Snaps/Flatpacks/AppImages/etc, which is a real shame.

The gnu/linux userspace has absolutely no security whatsoever. It’s a real shame how trivial it is to have even an npm install potentially do literally anything.

Android has an actual, sane, rethought security model that has a good track record in protecting millions of non-tech-savvy people.

To be clear, this security model is bolted on top of the kernel and uses SELinux under the hood. It's not some magic thing, it can certainly be replicated and even improved.

Android has a security model that protects the OS from applications and applications from users. A sane security model would put the user in control.

That is true. A good way to remove the second part is to gain root.

If you run your npm install in a properly set up container (and at some point in the future, Flatpak will set this up for you), it isn't going to do much. Yes, I'm well aware that containers should still be tought of as "not a real security boundary" given the amount of remaining attack surface, but even then the Android approach is not very different.

Well... yeah, don't do that. I mean this seriously, not facetiously; when I say I want a Linux phone what I mean is I want a phone that runs Debian or whatever (on bare metal, with good quality of experience, and with a mainline kernel) and where I install software out of the official repos using apt (or whatever).

(Also plenty of people on desktop Linux do `curl | sh`, and some of us are getting most of our Android apps out of F-Droid; I'm not sure the distinction runs quite the way you're suggesting.)

You can have a pinephone, and it will work fine for like 2 hours, warming like hell, and having you wait for minutes for an app to open. That’s where the linux userspace is. Maybe we should take a look at android and simply re-use the multi-million dollars spent on actually making a working mobile OS?

While my experience with PinePhone has been significantly better (sounds like you may have had a faulty unit), we have working close-to-mainline ports for a few Qualcomm-powered phones (e.g., Xiaomi Poco F1, OnePlus 6(t), Google Pixel 3a, ...) in OSes like postmarketOS or Mobian. Turns out these work a lot better - having phones build with components for phones makes a significant difference.

I didn’t mean to “shit” on the project, I did buy it as a means to both support it and to toy around with it - and yeah, the “free hardware” (which is arguably a bit naive and marketing-y goal) definitely doesn’t help create a device fit for everyday use, but I’m afraid the userspace is just not even ready to tackle the complexity, and I don’t see it happening anytime soon.

Android has a proper security, IPC model, the whole userspace has a focus on battery-saving, apps are made in a way to be suspend-able, etc. “GNU/Linux” is living in the past where C-posix binary goes brr is considered safe and enough, and I just don’t think that’s the case.

I don't understand what any of your comment has to do with this thread, which is about security models and application sources.

That said,

> You can have a pinephone, and it will work fine for like 2 hours, warming like hell, and having you wait for minutes for an app to open. That’s where the linux userspace is.

No, that's where the pinephone hardware is. I mean, also it sounds like maybe you have a defective unit because mine doesn't do what you're describing, but this is like judging Android by the cheapest phone I can buy, which is also agonizingly slow. If you don't use a device built out of really old+cheap parts, ex. postmarketos is perfectly fine.

> but this is like judging Android by the cheapest phone I can buy, which is also agonizingly slow

Nope, even running android on the same pinephone hardware results in a smooth system - it’s almost like google has been spending dollar billions on fixing and developing stuff that won’t magically appear in a userspace stuck in unix times. The kernel did get some upstreaming, that’s why linux laptops are remotely portable.

But for a mobile device you need a used space that understand the resource-constrained environment and are good citizens. This makes a huge difference in an age where racing-to-suspend is the way to conserve battery.

Just because Android can bypass PinePhone's underpowered GPU when doing some of the animations doesn't mean the whole system gets significantly smoother. There's nothing preventing phoc or KWin from doing the same, aside of its relatively low priority on development roadmaps as other devices don't suffer so much from it.

We do have one. I guess not many people even here know about it since it doesn't have a multi-million ad campaign around it. I've been messing around with a few distros on my Pinephone. The base Pinephone is much too weak to be used as a daily driver, but maybe the Pro is better. There are distros like Ubuntu Touch and Arch Linux Mobile. There are specific phone DEs like Phosh and (KDE) Plasma Mobile. Hardware compatibility is low, but you can at least check them out in a VM on your desktop. The best part is that you can run any software that works on ARM desktop Linux, so "app" compatibility isn't even a worry. Whether the software is usable in that form factor and resolution is another factor though.

https://wiki.pine64.org/index.php?title=PinePhone_Software_R...

> The base Pinephone is much too weak to be used as a daily driver, but maybe the Pro is better.

Both Librem 5 and PinePhone Pro are much faster than the original PinePhone, although PinePhone Pro is still relatively immature when it comes to software support.

I’d like a portable device with good battery that would run free software, mostly for privacy reasons. Anything with a good battery could do, GNU/Linux would not be strictly necessary. Running TOR or a VPN over Wifi and a browser and fast enough to stream a YouTube video at 720p is all I need.

I wonder what would be the closest hardware today that could do it. Smartphone or small tablet form factor would do just fine for me.

Gaming handheld would give you that. There are also old Intel-Atom based tablet PC's that are quite cheap on the second-hand market, and work well with Linux. Smartphone/palmtop form factor would be harder though.

The problem with open mobile phones is neither the phone hardware or software. The main problem is the damn cellular network carriers.

Until some government agency gets serious about forcing the cellular carriers to actually allow phones on their network without having to go through the anal violation that is "certification" for their network, the open mobile phone ecosystem will continue to suck.

It was the governments that require that certification, and for good reasons.

We can play this “wild west hacker” whatever, but rules are a necessity for a working society, one can’t just start driving on the other side of the road, and neither would we be ahead with random frequencies getting emitted everywhere.

Why would the government ever force carriers to accept uncertified devices? So they can emit interference on cellular frequency bands? So they can violate SAR limits and burn people?

The devices would still be subject to FCC certification just like your WiFi chipsets are.

Beyond that, the people developing chipsets generally have better tests for compliance than the carriers, themselves. You should be able to drop one of those chipsets in your phone, plug in a SIM, and get on with life. However, the carriers make you spend a couple of megabucks of bribes and then they will deign to allow your phone on their oh-so-fragile network.

Effectively, the current cellular carriers are acting exactly like Bell System prior to the Hush-A-Phone lawsuit: https://en.wikipedia.org/wiki/Hush-A-Phone_Corp._v._United_S...

How do you build such a thing when it doesn’t exist on PCs in the first place? In order to build an ecosystem you need cross compatible applications as well as some kind of strongly supported and strongly emphasized programming interface.

In the opposite direction, would Android make a decent Linux desktop if it got a little more polish for this use case? What about it's code quality? Is it a mess or is it on par with GNOME + Wayland + whatever?

That's basically a Chromebook, which can run both Android apps and Linux apps.

Last decade's definition of "power user" is "being able to type on physical keyboard and have more than 1 window open at a time", and Android caters to that; it would not even remotely be decent, though it'll likely eat just a bit more battery and cpu than a pure XFCE running without compositing.

Yeah, let's make desktops unusable toys as well

In what way is it “an unusable toy”?

How can you see it any differently?

You need an "app" for everything, they can hardly interact with each other, they can get killed at any time, and without rooting (which is subverting how the system is meant to be used) all sorts of things are crippled (from filesystem access, to using a firewall, to freaking setting a different volume for every app).

And the limitations increase with every Android release

They have a proper, standard, high-level way of interacting with each other, literally the whole OS is built around than. Read up on android services, intents, etc. It is eons better than dbus-ing and writing to random files all over my home dir is that linux desktops do.

Killing stuff from time to time is literally an advantage for a system - look at the battery life of a linux desktop or a pinephone. You have to make apps ready for a possible suspension, otherwise they just keep on draining the battery. Besides, services can be called from an active activity, or binded by one and then they will not be killed under normal circumstances.

I don’t want a random app to read my browser caches/ssh keys, etc, but if you like any random repo you download having access to your personal files, you do you.

I do know Android development.

Intents are only standardized for a few categories, they're slow (you routinely have to wait for the app chooser to load and scroll to the app you want) and not scriptable.

And the calling app can very well be killed by the loading of the called one.

> Killing stuff from time to time is literally an advantage for a system

Killing stuff that I want to have running is literally maddening. Ever wanted to have music in the background, and to not have the player killed at random times? Or, to have files moved in the background (with the painfully slow SAF) without them getting randomly corrupted? Or any other thing you'd need to go on while you check out something else?

> You have to make apps ready for a possible suspension

After 15 years the apps that do that reliably, whatever they're doing, are still exceedingly rare; not surprisingly, since software has never been developed in that way, doing it would require constant writing to the persistent storage, and even Android itself provides few facilities to make it more feasible. And even when that's done correctly, getting back to the saved state often takes time.

> I don’t want a random app to read my browser caches/ssh keys

I want a specific app to read my browser cache/ssh keys or any other file if I need it to. And yes, I'd like to limit an app's access to what it needs, but on Android it's either all (shared storage) or nothing. File providers? Yeah, except that it requires the app that has the file to offer them, and very few do.

And one app I'd like to allow access to everything is a backup app; but no, to protect me Google requires me to upload everything to its servers (for what it even allows to be backup up).

And thankfully I can't use SD cards in any meaningful way, to protect me from myself.

For Android security means protecting the apps from the phone's owner, rather than the other way around

How are intents not scriptable? I have an app that can literally call any other intent, but I can even write a bash/python script and run it from Termux to execute whatever I want. Look up the `am` executable.

Re the “killing stuff” paragraph sounds like a memory size issue - frankly, in that case killing something is a better option than desktop linux’s tendency to just freeze the hell up. Just for reference, on a modern low-end samsung I had no such experience.

After 15 years: android’s activity life cycle doesn’t make them constantly save stuff — there is a pause and stop lifecycle events that are appropriate places for saves to happen. Android will attempt to gracefully stop applications, unlike desktop linux’s oom killers. And this model works exceedingly well, you just don’t even notice it, only when it occasionally couldn’t clear enough memory and has to resort to killing.

I haven’t tried doing backups recently, I believe that it is not as streamlined as it should.

That's ONE intent, and not even between two apps...

Have you ever had to pipe more than two applications to operate on something (image, video, whatever)? Or actually, more than one, since in your solution one app is am, or your intent-calling app?

> Re the “killing stuff” paragraph sounds like a memory size issue

Whatever it is, how about asking what to do, instead of assuming that users only care about the foreground app? (I risk smashing my monitor every time I read that in the documentation)

> And this model works exceedingly well, you just don’t even notice it

Nope, I notice it all the time, since apps are more likely to get killed than let to gracefully stop, in my experience.

I heard that the latest Samsung One UI versions behave better, though

> look at the battery life of a linux desktop or a pinephone

Desktops generally don't have a battery. My laptops have perfectly good battery running assorted Linux distros. The pinephone sucks but mostly for hardware reasons; I suspect you would find Android on that hardware to also suck.

> I don’t want a random app to read my browser caches/ssh keys, etc, but if you like any random repo you download having access to your personal files, you do you.

If you must download random untrusted code and execute it, then you should run it inside bubblewrap/firejail/docker.

> I suspect you would find Android on that hardware to also suck

Not at all, android is smooth as butter on even significantly worse hardware.

> if you must download random untrusted code and execute it, then you should run it inside bubblewrap/firejail/docker

There is no if, this is the case for everyone, and thus the default should be sandboxed. Plus, a sandbox should have appropriate channels to communicate with other sandboxes, otherwise you are not ahead even a bit. Just think about a memory unsafe program like a PDF reader opening an untrusted file. It is already ripe for executing arbitrary code, no need for compiling stuff.

Kernel land is almost entirely Linux. Just without open-source drivers for some freakish reason.

Userland is as different from desktop Linux as you can possibly get.

> Just without open-source drivers for some freakish reason

Because manufacturers buy random parts from other suppliers, who may or may not own the source code, and they often legally simply can’t share forward that code.

Nope, it is a custom Linux kernel with goodies that aren't available upstream like first level support for clang, several Rust modules (no need to argue with anti-Rust kernel folks), all security features turned on, and a micro-kernel like driver subsystem, supporting Java, C++ and Rust.

There is sailfish OS. And it runs quite a few Android apps too.

Any recommendations for modern-ish devices which run Sailfish?

Can the "free trial" be used indefinitely if you don't need Android app support?

Yes, the free version can be used indefinitely.

The latest device you can use with full support is Sony Xperia 10 III, released in 2021. There have been no further releases; the project never really took off and unfortunately it seems that the OS is slowly dying. The Finnish company behind it, Jolla, had a joint project with Russia (Aurora OS), which I believe provided a good chunk of the funds via Rostelecom. With the war everything changed, and in 2021 they had to cut ties entirely with Russia for many reasons: embargos, and many people rightfully not wanting anything to do with "a Russian OS" on their phone. The company had to be "restructured" in 2023.

No, we need an alternative smartphone ecosystem like a hole in the head. Android won, and AOSP is free software. There is no reason to undertake the Herculean task of writing a new mobile userspace core. You might as well write a new kernel while you're at it. What would be the point? What are you going to do better than AOSP? A 5% more efficient binder?

At Google HQ, there is a veritable mountain of skulls of Android competitor projects. Please notice the skulls before doing something that will almost certainly add your project to the pile.

I'm fine with Android.

Is this a parody post?

No, its something i strongly agree with. The phone ecosystem is a locked in disaster. If phone hardware was required to support some standard like x86 computers do we could turn all this apple amd android crap ibto something that actually respects privacy

Every vendor that is not Apple already supports Android. Even the ones that don’t want to have the GSuit built in, and some of them care about privacy, while some don’t. A smartphone is comprised of more than one cpu, and there are proprietary chipsets with closed firmware all the way to battery. This is a much different world than x86 PC with pre EFI BIOS, when you could flash everything (except cpu?)

What do you expect to be able to achieve with just the word “Linux” added to the mix? Can you build new 5G drivers for Linux as well? Smartphone market is moving pretty fast, the hardware is nearly disposable, and the consumer doesn’t even know what an OS is.

GNU/Linux smartphone, that is competitive? Good luck with that.

The firmware side of things is a different can of worms that also affects X86. That's not he ask I was making (although it is a good second phase). I just want phones to be more like X86 in that I can install whatever I want to them and have a more standardized interface than the current wild west situation so that it's easy to bring on new devices. It would be nice if the hardware vendors were not actively blocking installing my own operating system as well (in addition to the technical non standard issue).

Why do you think I care about competitive or commercial viability? I just want the behemoth pushing apple and android crap to be forced to make their devices easier to boot an alternative and leave the rest to us to figure out and see what interesting things can be done.

If you don’t care about competitive smartphones, why do you care about smartphones or phones at all?

It's not about making a competitive linux smartphone, it's about making the hardware ecosystem more conducive to software competition by making it easy for people to run their own software on their own hardware.

It's a solved problem for ARM platforms with standards like SBSA. Thankfully, a few ARM notebooks implement ACPI, UEFI and whatnot that makes standardizing boot images easy instead of requiring bespoke images for every model.

Then i guess all that is really needed is legislation to force manufacturers to stop being a bunch of dickheads locking down the devices they sell?

Is this a parody question?

We don't need a non-android ecosystem. The compatibility is nice. The security features are nice.

What we need is more devices that allow unlocking the bootloader and rewriting the keys.

Sadly that isn’t really enough today - since many applications will refuse to function if SafetyNet fails because you have some non-standard image running.

There's likely a statement in Play Services ToS for vendors to do all things possible to prevent bootloader unlock/relock flow from happening - reasoning from the fact that yellow AVB state is non-existent outside Pixel devices. Maybe it goes as far as for SoC vendors, as well. So far, outside of Huawei, no top tier hardware vendor ever decided that denying Play functionality to their users would be profitable - also all Mediatek based devices are basically licensed by mediatek afair, so there's no chance of, say, Vivo/Realme suddenly deciding to ditch Play and do bootloader relocking.

Also the possibility of postmarket devices running non-bloated OS is a loss for a vendor since it both reduces the appeal of whatever next "+1% cpu +1% battery" lineup update (and its a bad idea to sell 200k "good device model 1" rather than 100k "bad device model 1" and "bad device model 2", because PR/stocks/whatever) and increases the possibility of having users dissatisfied with the brand name because battery/flash degradation is still a thing.

That's not a problem and not getting fixed by diverging farther than android. To date none of my apps have required that, including my banking app. Even so, loss of some financial apps is a small price compared to loss of social and dating apps, public transit and health apps, and more.

iNaturalist publishes an open source android app to complement their very functional website, and honestly I would give up all of GNU for that one app.

Maybe this is less of a thing outside the UK but the banking apps absolutely is a problem for me. I have banks that only have apps, no websites, or require the app for 3ds that will refuse to open with safetynet failing. It's not even just safetynet, at least one of them has it's own seperate tests to stop it working.

This is the only reason for me (and presumably a fair few others) not to be using Lineage, I can do without google wallet etc but I can't do without access to my own bank accounts

Then vote with your wallet and switch to a bank that isn't so hostile to its paying customers.

Banks are fungible.

That sucks but yeah that is not my experience in the US. Not sure what 3ds is, some kind of identity or MFA service?

All of my banks have functional websites.

"I personally haven't been affected by this, so it's not a problem" is not a compelling argument.

"I personally haven't been affected despite using the capabilities of the system extensively, so its not a dealbreaker" isn't?

Sure, that follows and I agree that most people probably won't find it to be a dealbreaker. But your OP said it wasn't a problem in general. I would advise against ignoring it and treating it as a non-issue because more and more apps are adopting attestation. There is absolutely no guarantee that the apps you depend upon won't just suddenly start requiring attestation (and old versions likely will stop working, as forced updates have become very popular on Android).

If you're asking what the solution is, I'm not sure, but sticking your head in the sand isn't a great way to handle it. GrapheneOS thinks that suing Google might be the way to go: https://news.ycombinator.com/item?id=41119047

If you only care about Android app compatibility but not safety net, try waydroid?

Waydroid was really slow last time I tried it, and most apps I tried did not work well or at all.

I don't perceive Waydroid as slow on my Librem 5 at all, and apps tend to work well within it (playing some ad-riddled games from Play Store on a GNU/Linux phone, out of curiosity to see whether they'll work, was an interesting experience) - with the exception of remote attestation and peripheral access, which, of course, greatly limits the possible use cases.

The former isn't really something that could be fixed, but for the latter I've just had NLnet's funding accepted for a project that's about better integration of Waydroid with the host OS, so hopefully I'll be able to make some progress in this area in the coming months. My personal goal is to be able to download a local public transport app and be able to buy a ticket, which includes scanning an in-vehicle QR code, without much fuss.

Reply on news.ycombinator.com