We need Linux OSes and phones to catch up to really break free from this duopoly. Only when there is enough traction, essential infrastructure like banks will start supporting Oses like that. It's a chicken and egg kind of problem.
I think that the main problem is that android has a lot of weird modifications that are not consistent with the rest of linux distros. The user data is suddenly in /data instead of /home, theres no package manager, no systemd (for better or worse), and there's hella lotta security gotchas, for example call recording is impossible without root as far as I know. I'm not saying that Android is not hackable, but it's a different type of hackability than desktop linux, you have to learn it all over again and in my opinion it's much harder to master than desktop linux.
I've been on ubports for 3 years and while it also has some weird caveats like read only rootfs, no working package manager (due to read-only fs. however ubports has pretty cool support for lxc containers where you can use apt). Due to chronic lack of time I haven't been able to sit down on my phone to play with it a bit (for example id like to install waydroid), but it seems a lot easier than android. For example, while there isn't an app for call recording, some guy worked around it by writing a systemd user service as a workaround[1]. This is exactly the type of thing I'm thinking about when talking "linux phone".
For me as a linux user, the difference if ubports was a human, I'd think that perhaps they were sick, whereas if android was a human, i'd shoot them in the face :)
If your criterium for choosing an OS is tinkering and hackability freedom to do modify almost anything to your liking (even if it will compeltely break your system or poke extra security holes in), then desktop Linux OSes ported to mobile might indeed be a good option.
If your goal is security and privacy (which go hand in hand), mobile OSes are clearly the best solution.
Anyway Android is still a Linux OS. The only requirement to be a Linux OS technically is to ship a Linux kernel. Adhering to freedesktop specifications like the FHS, using systemd, using GNU userspace software, etc. isn't necessary.
On Android you can install software by installing directly from APK files or you can use application stores which are package manager, they help you install software and if there are dependencies they can also install the dependencies if they support that.
Call recording is possible on multiple Android OSes, it's possible on stock PixelOS and GrapheneOS, I'm not sure about others but normally it's just part of the Dialer app. You don't need root at all for that.
Yeah, just need to decide where to start the fork. The larger problem is radio firmware. FCC regs were the initial excuse, for wifi and Bluetooth too, but we need to open up the source for all of these and allocate money for enforcement if we are truly worried people are going to start adding wifi channels etc. Open firmware phone radios would let you do things like truly turning off the radio when wifi was present, no gps ping even.
You’re not wrong. The thing that bothers me is that AOSP is being developed behind close doors and controlled by a single company which wields way too much power and control over our daily lives, and which has a track record of abusing that power.
They for sure control the direction of the development but it's not really that problematic given that things downstream projects take issue with can just be removed from the source and things they want can be added.
The portions of SailfishOS specific to it including the user interface and application layer are nearly entirely closed source, unlike the open source Android Open Source Project (AOSP). SailfishOS has far worse privacy, security, functionality and usability than the Android Open Source Project. It isn't possible to make a fork improving it due to it not being open source like AOSP.
You can run desktop apps on GrapheneOS including on a desktop monitor via the desktop mode with free form windows. There's support for non-native apps via hardware-based virtualization. These features are experimental but already work pretty well.
There's a new Jolla Phone in pre-marketing phase right now (almost 9000 phones have been pre-ordered so far). First device deliveries are scheduled for this summer and this should easily be the new benchmark for officially supported SailfishOS devices.
The situation with Sony Xperia devices is not great, the best experience is still on the X10III (from 2021 I think) and there are significant issues with the support of 10 IV and V generation devices (a free beta release is available for those as well).
It seems that recently there has been quite a lot of buzz in the Sailfish community compared to the past few years. In the public repos there are some interesting contributions like xdg-shell support for Lipstick, which looks set to enable compiling many previously unavailable Linux apps natively if that will actually be integrated in an upcoming OS version.
Jolla mishandled the funds they got for the tablets, it went bankrupt and bought up by a company connected to the Russian state. Jolla lied a lot during these events and tried to hide what happened, and I don't think that's an acceptable thing to do when the main selling point of your product is privacy and trust. AFAIK they recently got bankrupted again and bought by the original owners, but it's hard to rebuild trust.
This is just a frontend. It uses Cranelift as the backend. It's missing some fairly basic language features like bitfields and variadic functions. And if I'm reading the documentation right, it requires all the source code to be in a single file...
Look at what those compilers are capable of compiling and to which targets, and compare it to what this compiler can do. Those are wonderful, and I have nothing but respect for them, but they aren't going to be compiling the Linux kernel.
A genuinely impressive effort, but alas, still missing some pretty critical features (const, floating point, bools, inline, anonymous structs in function args).
In modern Qt you don't write UI in C++ anymore - you do that in QML. It is far simpler to create amazing pixel perfect UIs with drooling-inducing animations in QML. I wrote a blog post that talks a bit about this[1].
This is not because of Qt - it is due to some (most) Qt developers not caring enough. I created my Qt app feel native both on macOS and Windows[1]. It did require a lot of tuning - but those are things I'll reuse across other apps.
BTW thanks for Daino! I'm working on assembling a set of tools to easily build and manage a personal knowledge base locally. I was worried I would have to build every piece myself, specially for note taking, so I was really glad to find Daino!
Oh that's awesome to hear! I have been playing with the idea of creating a desktop environment. Don't know if necessarily using i3wm but it's good to have your library if I do (:
reply