I've been using touchscreen laptops for more than a decade now. It's been really useful when working on mobile stuff and occasionally handy in some games or when sketching something, but other than that - it just stays unused.
Yeah, but what's more likely to happen is that when you look inside the code you see thousands of lines of code of a handrolled parser and when you ask "why would you write your own rather than use some existing one here?" you only get silence in return.
I don't really generate big chunks of code, but in general I found AI outputs to be quite sensible. It knows what the main modules are and uses them, I've not seen any as egregious as making a JSON parser from scratch without a need.
Maybe not a JSON parser in particular, but I've already seen a fair share of MRs that contained many thousands of lines that no human would have ever written without stopping to ask "do I really need to do it?". LLMs aren't bothered.
> In this post, I use the term "Free Software" to mean software licensed with Copyleft licenses, and to explicitly differentiate it from permissively-licensed "Open Source" software (which is what the Free Software Foundation and Co. also do).
That's not what "FSF and Co." do at all. I'd expect someone writing an article about whether Free Software failed or not to understand that if they want to be considered seriously.
I don't think it's a proper filter, looks like just a tag that needs to be manually applied to the game somewhere. I can tell it's not showing some FLOSS games with correctly filled out license metadata.
I used to use e17 on my daily driver phone. Illume was a nice UI, but you (or your distro) did have to find a good revision to not have it crash indeed :)
My distro was Slackware, prior to any sort of package management, so, yeah, things would crash, but IIRC, Enlightenment, as much as I loved the use, look and feel, just crashed way too often.
I'm pretty sure both Librem 5 and PinePhone can use VoLTE in the US. The former you can even buy together with a MVNO service that's just guaranteed to work.
I forgot about the Librem. I originally used the PinePhone 5 years ago and had to switch to a OP6 because the PinePhone was unbearably slow. It looks like Mobian and PostmarketOS both support VoLTE on the PinePhone now which is good.
BTW, isn't VoLTE on devices like OP6 pretty much a solved thing by now as well? These devices with no discrete modem had to configure all the IMS services manually over undocumented QMI interfaces (as opposed to a documented AT command than then makes the discrete modem do the same thing internally), but I believe that has been figured out some time ago already.
When I ran the OP6 5 years ago on PostmarketOS it wasn't working. I had a PR open with the devs and we tried to figure it out but lost steam. It looks like someone on Reddit got it working two years ago:
So yeah, 5 years ago it wasn't so critical to have it yet, and by the time it became critical it also became supported. Perhaps that's why you keep reading articles that don't mention it :)
Agreed. I assume aftermarket Linux support for Android devices with out-of-the-box unlockable bootloaders (including the OP6/6T) is the most likely path to viable daily-driver "Linux phones" in the future, and it's strange how the linked article doesn't seem to mention this at all.
Yes, I probably should have addressed that in my article, but my primary focus was on whether Linux phones can grow from being a miniscule niche for nerds like me to being a real alternative for normal people to Android and iOS phones. I would guesstimate that around 10,000 Linux phones were sold in 2025, which represented 0.0008% of the global smartphone market that year. The question I was asking is whether we can get to 0.1% or even 1% of the market. Rereading the article, I see that I wasn't very good about explaining the focus of the article. There was so much technical stuff to cover, and I got a little lost in all that.
If you look through the list of recommended devices for Nura (formerly postmarketOS), the only one that has full software support for all the hardware is the Librem 5, and the second best supported phone is the PinePhone.
The rest of the phones are dated Android devices which all have significant functions that don't work correctly. The processor with the best support is the Snapdragon 845 from 2018 in the OnePlus 6/6T, POCO F1 and SHIFT6mq, and all of those devices have issues that a geek like me can accept (like downloading code from github and manually compiling to get a partially functional camera), but it isn’t really an option for ordinary people.
I think that it is very important that there are native Linux phone manufacturers, totally independent on Google, and thus also independent on Android and Android Open Source Project (AOSP), or Android kernels in any way.
A cash flow is essential to sustain a Linux mobile ecosystem. And in the Linux world the sell goes often once. Just when selling the device itself. But software has to be maintained, and people have to be paid. Therefore, I highly recommend to buy a native Linux hardware device, independent on Android, if you want to support mobile Linux, and have the financial means.
There are options to donate to different mobile Linux projects as well though. Only a small donation can already make a difference, especially if many people are providing such support.
It is hopeful to see how different Linux phone software projects, and Linux phone competitors in a way are all working together to further a truly free operating system. The phone market is large enough for native Linux phones to exist next to each other. So not Linux as an aftermarket, but Linux native phones that support the whole mobile Linux world. And yes, also there is place for aftermarket Linux support, but I doubt if this would be enough in the long run.
I am the administrator of the system on my phone. It's the same OS as what I've been using on my PCs for decades, so it's very familiar. It's fully scriptable in whatever language I wish to use, so I can easily adjust its behavior. I can use sandboxes when I need them and ignore them when I don't. Its software components are replaceable and patchable - if something bothers me, I can write a patch, compile a patched package, install it and even send a merge request upstream right on the phone itself without using any other device - regardless of whether it's about desktop environment behavior, cellular middleware or a kernel driver. I can freely modify the system to my liking without being punished for it. I never have to wrestle with the system whenever I want to keep something running in the background.
It just feels like my little personal computer. No Android device ever felt this way to me. I don't want to feel like a guest confined to a sandbox within a computing device I'm supposed to own.
If you have selinux then you may not be "absolute God either", and arguably it's never necessary to have that much control. I would much prefer to have sane security boundaries so something blowing up won't bring everything down with it.
And there are quite a few devices with unlockable bootloaders so you can feel to hack whatever you want with AOSPs.
I had to build a patched Android image in the past, so no thanks, it's definitely not something I would want to do in my spare time just to tinker. It's a system that's designed to be user-hostile; you can fight it if you want, but why would I do that if I can just keep using GNU/Linux instead?
But then a modern fiberglass car is more complex than a 60s steel truck. The latter eats more gas, but if they two get in an accident the truck is all that's left and those practically illiterate can readily fix the components of it as needed, no dealer specific gadgets and lock-in, you can even bore out new holes mounting in different engines if they can move the steel on wheels.
>something blowing up won't bring everything down with it.
If you aren't be reckless about backing things up and being safe, this makes absolutely no sense.
Anytime things "blow up" its because you did something, updated something, ran something, it doesn't just happen or have scripts that will trigger shit for no reason (microsoft updates anyone?).
As for "bring everything down with it" that is because you don't actually know how to fix it, but with enough experience, or if you torture yourself with non-FHS compliant/non-systemd/Nixos or GUIX, you figure it out eventually and figure out how not to cause problems, you know like getting over the electron apps to do functionality easier as a script or justfile command or insisting on a broken IDE that is a dumpster because its extension store has a lot of possible options that are mostly non-functional.
But you do you.
EDIT: And AOSP still depends on Google being so kind as to allow for it, there is no guarantee that continues forever. But that's my low time preference talking, don't mind me.
reply