111–120 of 491 posts
Signal doesn't currently support them or allow third party clients to connect to its servers
Openmoko failed for so much more than financial reasons. It's been a while since I've thought of that fiasco, but my memories: * The leadership was terrible. They had no clue what it took to make a mass market product. They just assumed that they would sell hardware and a community would provide a working operating system and apps magically. * The hardware was buggy. There was one issue that if you let the battery dr…
From the same era, I had Nokia's N770, N810 and N900. All three were based on Linux, and they were great. I also had the Palm Pre and Pre 2, both of which were based on Linux (and apps were made with HTML, CSS, and JS in 2009!), and those were also great.
I've still got an N770, N810, 3x N900s and an N950 developer device that I run battery maintenance on every 4 or 5 months.
Had a Pre 2, and still have an HP Veer. Making modifications to the system to customize or change things was so easy and straight forward, I really miss this; though building LineageOS / AOSP for supported devices kinda fills this niche for me now.
The Android platform represents an enormous amount of work that encompasses a more secure base kernel, an unparalleled selection of applications designed for mobile usage and written in a memory-safe language, fantastic sandboxing and user privacy features leagues ahead of any desktop operating system, and great diversity in the hardware market.
While it's apparent that Android has significant downsides - de facto proprietary drivers, an environment of mostly closed-source applications, some Big G integration, and a general lack of long-term updates occasionally countering the work put into security (thanks, chip manufacturers: https://news.ycombinator.com/item?id=26593274), these are problems that can be solved. It doesn't make sense to throw the baby out with the bathwater.
Closed-source applications are more a moral problem than a security one thanks to Android's sandboxing, and a vibrant ecosystem of high-quality free-and-open-source Android applications (https://f-droid.org - Amaze, Notally, QKSMS, and Tasks are some of my favorites) makes them all but optional. Google's presence in the AOSP codebase is rather limited (mostly around notifications) and taken out altogether by custom ROMs like Lineage and GrapheneOS. Proprietary drivers remain as Android's biggest problem, perhaps alongside the manufacturers that ship locked-down phones with bloatware (looking at you, Samsung).
Why go the desktop-Linux-to-mobile route when you could fork Android, write drivers for the Pinephone / Librem 5, punch a hole to the base system for privileged applications, and have the best of both worlds with an order of magnitude less effort?
I don't understand the desire for a Linux phone as so described in the article as a daily driver. The Android platform represents an enormous amount of work that encompasses a more secure base kernel, an unparalleled selection of applications designed for mobile usage and written in a memory-safe language, fantastic sandboxing and user privacy features leagues ahead of any desktop operating system, and great diversit…
I'm not even against proprietary apps (just against proprietary drivers of course), it's just that transforming Android to make it behave normally is just more and more work every year.
Some people (including myself) would prefer to have the same system they have on their desktop on their phone, with the added bonus of having convergence.
Shielding Android from the rest of the system as a "compatibility layer" just to run some apps or drivers makes tons of sens.
Though I love Linux, it's not because it's Linux - I just want to live the one device life. If IPhones could run MacOS on external monitors, I'd buy an iPhone.
Alternatively, a web-based OS (with desktop linux on a hub) would be awesome if all my apps were available as web apps - but they are not so I'd still need a mobile OS and a desktop OS for the usbc hub life.
Earlier quoted context omitted.
Android apps are becoming more and more dependent on the closed source blobs that Google ships with Android devices, so some apps might not work without them. Although microG exists, it isn't perfect and some apps still won't run with it. A Linux phone can forgo Google's userspace libraries for Android, and if they're really needed, Android can just run in a container like with Anbox. Instead, it can ship with the ty…
Your comment doesn't describe any benefit for users. Maybe a benefit for some developers who consider ideological technology choices a benefit. But users gain nothing.
I don't understand the desire for a Linux phone as so described in the article as a daily driver. The Android platform represents an enormous amount of work that encompasses a more secure base kernel, an unparalleled selection of applications designed for mobile usage and written in a memory-safe language, fantastic sandboxing and user privacy features leagues ahead of any desktop operating system, and great diversit…
Because Android is Google's own property, it's not like a standard Linux distribution by any stretch of imagination. I'm not even against proprietary apps (just against proprietary drivers of course), it's just that transforming Android to make it behave normally is just more and more work every year. Some people (including myself) would prefer to have the same system they have on their desktop on their phone, with t…
In that respect I really like how I can run Windows games on Linux via Proton and Steam; an otherwise good game can ship with all kinds of crap (like having their own launchers stuck in the system tray), but when I'm done the whole Wine-sandbox collapses and I'm back in a Linux desktop that does what I want. Something like that for the host of proprietary apps you are nowadays hard-pressed to avoid (I manage now, but it is not a tenable position) would be welcome. Ideally you could do all sorts of privacy preserving stuff at the sandbox layer.
Am I missing something? Every Android phone is running Linux.
The core parts of Android that make it usable on mobile devices like power management and scheduling [1] aren't in the mainline Linux kernel last I checked. This is about getting Linux to the point where you can choose between an Arch, Ubuntu, debian, etc. distro for your phone. [1] https://lwn.net/Articles/706374/
Does Termux count? It may be containered within an application package, but it's running off the host kernel and it uses the debian package manager.
https://i.imgur.com/WIT2VjW.png
I find that, when it comes to Android, people try really hard to make exceptions for what qualifies as "Linux" that do not exist as goalposts for other distributions or forms of Linux that are generally accepted under the Linux umbrella.
I'd say it's as much as Linux as anything else that uses the base kernel and is reduced (for space reasons) or modified (for hardware support)... DDWRT comes to mind.
When you have a base kernel for a device, running a "proper" distribution isn't much further behind. I was able to install Ubuntu on top of the stock kernel of one of my oldest Chromebook devices, the Acer C710. That's how I started using Linux full time. Does that not count? Because you can do that on Android devices, too.
It's Linux. Carving out exceptions and drawing arbitrary lines and qualifiers doesn't really get anyone anywhere. In the end it's a very specialized Linux kernel for that hardware running often proprietary blobs, but when it comes down to it:
Yes, you an install distros on top of the kernel on the device[1],
And yes, I'd argue Android itself is a distro.
The only thing Android really lacks is a universal installer. IMHO, we can thank Qualcomm for that situation we're in.
Of course not. Nobody wants to run that on their phone except a tiny few. Android isn’t the same, but even then nobody knowingly wants to run Android.
Nobody, eh? Not one person?
