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.
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.
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?
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
> 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.
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#.
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).
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.
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.
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.
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.
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
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.
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.
>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.
This is peak FOSS, and I'm not even trying to be offensive about it.
You (and people like you) need to realize what makes Windows, Android, and iOS/MacOS successful: It's because they enable users to use computers as practical tools.
A FOSS phone must support Whatsapp because users are not going to use a FOSS phone to live and breathe FOSS, they use their phone for Whatsapp. Or Facebook. Or Mysterious Twitter X. Or Youtube. Or their banking application. Whatever; users are there to use their phone, not be their phone.
Users sincerely do not give a flying crap about FOSS or any other religious dogma unless it's Apple coming out with a new iPhone.
On that note, a FOSS phone probably doesn't have to support any actual telephony functionality. Most people nowadays fucking hate phone calls because 99.99999999999999999999% of them are junk.
> You (and people like you) need to realize what makes Windows, Android, and iOS/MacOS successful: It's because they enable users to use computers as practical tools.
What makes this cancer “successful” is the insane consumer exploitation that it enables, which motivates unfathomable amounts of money to be thrown at it to establish the monopolies. There’s no way out anymore and the entire society is suffering, except the venture capitalists who created this hell with cheap money due to decades of quantitative easing. Open your eyes at the tragedy around you instead of being so absorbed in your tech bro saviour complex.
>What makes this cancer “successful” is the insane consumer exploitation that it enables
>Open your eyes at the tragedy around you instead of being so absorbed in your tech bro saviour complex.
I'll fire those words right back at you, particularly the bit about being a tech bro saviour.
Computers are tools, tools that are practical will win mass adoption. FOSS as far as the zealots are concerned aren't even tools let alone practical, which is why they never win the mainstream audience.
Do you know why the Steam Deck has been successful where everything else prior to it failed? Because it is a practical tool, specifically to play games. Most of the customers buying it don't care what it runs so long as it plays games.
Concern yourself with making a better screwdriver, not whether the screwdriver is made from the finest libre materials.
This is a very naive view. Deployed capital fabricates adoption and the current state of consumer tech is a great case study for this. Rational demand in consumer markets is a fantasy.
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.
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.
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
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…
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.)
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...
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.
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.
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.
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.
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.
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.
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.
> 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?
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.
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 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.
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.
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’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.
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?
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.
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.
> 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.
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/).
"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/
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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...
> 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.
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.
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)
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.
> 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.
It’s even hard to find the uboot patches for clockworkpi hardware, and they open source almost everything.
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.
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.
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.
> 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.
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
> 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.
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.
My understanding as well that Nokia bet everything on Symbian.
[dead]
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.
They gave us a completely free version of Unix! What more do you want?! Do you even contribute to the FSF?
And they are still working on that.
"but they are still stuck 30"
What did I say?
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.
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.
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.
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 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.
>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.
This is peak FOSS, and I'm not even trying to be offensive about it.
You (and people like you) need to realize what makes Windows, Android, and iOS/MacOS successful: It's because they enable users to use computers as practical tools.
A FOSS phone must support Whatsapp because users are not going to use a FOSS phone to live and breathe FOSS, they use their phone for Whatsapp. Or Facebook. Or Mysterious Twitter X. Or Youtube. Or their banking application. Whatever; users are there to use their phone, not be their phone.
Users sincerely do not give a flying crap about FOSS or any other religious dogma unless it's Apple coming out with a new iPhone.
On that note, a FOSS phone probably doesn't have to support any actual telephony functionality. Most people nowadays fucking hate phone calls because 99.99999999999999999999% of them are junk.
Which is also why VMs on macOS, Windows and ChromeOS are the closest mainstream users will ever get from Year of Desktop GNU/Linux.
> You (and people like you) need to realize what makes Windows, Android, and iOS/MacOS successful: It's because they enable users to use computers as practical tools.
What makes this cancer “successful” is the insane consumer exploitation that it enables, which motivates unfathomable amounts of money to be thrown at it to establish the monopolies. There’s no way out anymore and the entire society is suffering, except the venture capitalists who created this hell with cheap money due to decades of quantitative easing. Open your eyes at the tragedy around you instead of being so absorbed in your tech bro saviour complex.
>What makes this cancer “successful” is the insane consumer exploitation that it enables
>Open your eyes at the tragedy around you instead of being so absorbed in your tech bro saviour complex.
I'll fire those words right back at you, particularly the bit about being a tech bro saviour.
Computers are tools, tools that are practical will win mass adoption. FOSS as far as the zealots are concerned aren't even tools let alone practical, which is why they never win the mainstream audience.
Do you know why the Steam Deck has been successful where everything else prior to it failed? Because it is a practical tool, specifically to play games. Most of the customers buying it don't care what it runs so long as it plays games.
Concern yourself with making a better screwdriver, not whether the screwdriver is made from the finest libre materials.
> tools that are practical will win mass adoption
This is a very naive view. Deployed capital fabricates adoption and the current state of consumer tech is a great case study for this. Rational demand in consumer markets is a fantasy.
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.
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
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
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.
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.)
Just the lack of.. the whole ecosystem adopting the restricted model and there being a properly specified and documented model in the first place.
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 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.
what would a banking app do that a bank website can't, exactly?
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
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.
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.
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.
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.
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 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.
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.
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.
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.
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’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.
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.
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.
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.
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.
> 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.
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/).
> 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.
It looks like it doesn't support android safetynet hardware attestation so banking apps etc won't work.
I'm fine with Android.
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.
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.
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...
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.
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.
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.
[dead]
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.
[dead]
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.
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
"I personally haven't been affected by this, so it's not a problem" is not a compelling argument.
If you only care about Android app compatibility but not safety net, try waydroid?