https://lwn.net/Articles/718267/ / https://news.ycombinator.com/item?id=14002386
EDIT: This just got downvoted to 0, unsure why...
Now it is deprecated, but according to the roadmap it will be gone from the SDK with release 16.
With Fuchsia, Google has a clean slate and can choose to have 'write-once' drivers with a stable driver interface across kernel/version upgrades.
Which makes it easier to write proprietary drivers.
> And most likely not supporting future kernel versions.
Huh?
If Fuschia provides a stable driver interface, then it would mean that my 5-year-old phone doesn't need to also use a 5-year-old kernel to interface with its closed-source drivers. It'd be a big win, overall.
The Free Software initiative requires bravery and confidence. The idea is that if you establish a large enough base of viral software, people will eventually have no choice but to become a part, or be put at great disadvantage. And it worked. Linux is everywhere. The only places it didn't work, are the places we were too cowardly to press the advantage.
Stallman was right. You cannot compromise. Once you start paying the Dane-geld, you'll never get rid of the Dane.
Maybe because you called Android "a slightly less terrible Windows Mobile 6".
Also: "Please resist commenting about being downvoted. It never does any good, and it makes boring reading." https://news.ycombinator.com/newsguidelines.html
Okay, that's entirely fair. I guess I've gotten too caught up in the fragmentation and vulnerability hype.
I think I was underexaggerating when I said "slightly" as well - Android is a remarkably decent system by and large.
> Also: "Please resist commenting about being downvoted. It never does any good, and it makes boring reading." https://news.ycombinator.com/newsguidelines.html*
This... woops, I picked that behavior up from others here. Now I know to link to this page instead. Thanks very much.
And I thought I'd I'd gone over the guidelines page a while back, too...
The thing is that fixing security bugs in old Androids just isn't that hard. I'm not talking about making Samsung upgrade their Galaxy S3 (a five year old phone) to Nougat (which also isn't that hard, Cyanogenmod (before it was LineageOS) did it, and the hardest part (back porting kernel features) is done by a very small team IIRC), but fixing bugs shouldn't be so much work.
The issue is that there is almost zero benefit for Samsung to bother.
So how will Fuchsia help?
Maybe now Google will contractually obligate companies using Play services to upgrade for X years?
How long will X be?
Based on Google's own history, I doubt it's going to be longer than 2 years since "flagship release".
Now this made sense when you got free phones every two years, so must people just upgraded then (why not?) But now that you actually lay out $800 on a flagship phone, people are holding on too their phones for much longer (and there's not much of a reason to upgrade, unless you're playing heavy games, SGS3 is perfect).
But we may actually lose something: If Samsung/Qualcomm can close source their kernel, it's going to be tough to build your own "Fuchsia." So even if you're an expert and shop smartly, you'll still be at the mercy of your phone manufacturer (see Motorola and their promise).
Looking at it that way, Google have little incentive to rock their own boat.
There's also some interesting ponderation to be had considering why Android BSP propagation/vendor branding works the way it does in light of the above. Absolute device control (aka a flagship device) is likely only an option for Google (and Microsoft, thinking about it!) because of the competition; in fact now I wonder how fine the line is that Apple's skating (although I imagine the competition is what keeps them going as well).
In any case, I see Fuchsia as Google's equivalent of Microsoft Singularity. I'm trying to figure out what kind of point they're making by developing it in the open; they've likely gone through a hundred similar initiatives internally, as did/have Microsoft. Although now I think about it, Google do seem to have some practical business/real-world targets to hit with this (IoT is the likeliest actual hit) so maybe they're just publicizing it for that reason.
Regarding the openness of the kernel, all I can do is hope like mad that the kernel generally stays open on production devices (in "end-user" mode), or that there's some sort of developer option (and hardware, if necessary) available. And I can only hope like mad that Google figured out and appreciate the massive value of an open device, and don't do anything monumentally stupid. Fuchsia has an open repository, at least, which is a very nice start.
Pretty sure one of the effects will be total inability to port Linux drivers to the platform in order to install different operating systems. Not saying that this is easy today, but still some degree of compatibility allows the creation of jailrooted environments. A 100% OSS alternative to iOS and Android sadly won't be here anytime soon, surely not from the big players.
Also, Fuchsia will never be an distribution or branded OS on it's own. It might replace the Linux kernel is some bigger operating systems. Could replace Linux in android or chrome but I doubt it'll be fully new standalone OS.
I just downvoted you because you complained about being downvoted.
Write your comment and live with it - don't interrupt the discussion to meta-discuss the scoring system.
I'm operating under the assumption that Apple is more privacy friendly than Google under pretty much any circumstance.
I've done the Cyanogen + F-Droid thing and it's just miserably inconvenient, and none of the "proprietary" alternative app stores have any sort of catalog to write home about.
I'm curious as to why...?
Apple is primarily (not solely) a hardware / product company, so the financial incentives are different.
There's also a stronger history of Apple fighting for user privacy against government requests, etc.
http://www.metafilter.com/95152/Userdriven-discontent#325604...
Yep, I am fun at parties.
Is there ? AFAIK Google has been pretty pro-active in giving as little data to the governments as it legally can.
Or maybe I have been influenced by the PR Google has been doing about this for years.
Biggest annoyance of Android are the millions of permissions which every app asks for and which allow perfect fingerpinting. Phone number, all device accounts, wifi access names, mac adress are some examples. I know that one can switch off those permissions with newer Android versions but thia is too much hassle for me.
And my second gripe with Android is the slow browser: Android's Chrome is much slower than iOS' Safari. Safari is as fast as Chrome on my Macbook.
Third and biggest bummer: the updates on Android.
Android is in general and as an OS quite good.
I prefer to install everything with F-Droid failing that I use a Play viewer called Yalp that downloads apk's from the Play Store. The only app I ran into that fails to load is Hangouts (I use that for work). While Facebook Messenger shows an error when loading it doesn't crash when using it. Yalp will ask for your Google credentials, but I also saw that it also has a fake account mechanism.
My only other complaint is that by default the ROM comes with a couple non-free apps like Br0Zip that is quite obnoxious and you can't uninstall. I could re-flash my device and remove the app, but that's just annoying. If anyone from LineageOS is reading this please remove this ridiculous app.
Honestly though I'm just happy that I'm running an OS that's open source at it's core and that I have access to an app store that exclusively hosts open source applications. It even warns when apps promote non-free software (like Yalp).
PS: I'm not saying you're wrong, but that I've had quite a pleasant experience.
Is there a way currently to install baremetal Linux on a phone without emulating it? A small Linux, usb microphone and VoIP would get me 90% there.
If anything the open source community is a lot better in supporting large numbers of devices than closed source has ever been. Witness the incredible hardware support in your average linux kernel. The only reason they're a bit behind the times is because hardware manufacturers are loath to open up their specifications to open source implementers.
> The fact that I can pick up a PC from the nineties and install an up to date Linux
See, that's exactly the reason why this works.
1) One volunteer spearheads the development effort towards keeping phone/tablet/device X supported. 2) Various other people draw on the 90% base work already done by Lead #1, add their own wrappers, tweaks, etc, such that the community on the whole appears to be vibrant and bustling around development for device X. 3) Lead #1 eventually stops supporting the project because he gets a newer device. 4) None of the developer's behind Lead #1's forks have sufficient technical knowledge to continue the base development without him, and all of their forks stop updating as well. 5) Community on the whole for Device X fizzles out.
I've seen it happen multiple times on XDA-developers forums. That dozens/hundreds/thousands of people are using an AOSP-based ROM on a device does not mean that the community necessarily has the technical knowledge to continue it without someone to steward the project. The volunteer leads do an incredible job, but at the end of the day, they usually only last as long as the device is the lead's daily driver--after that, they usually stop.
Not entirely true. The mobile hardware ecosystem is vastly more diverse than the PC ecosystem.
For starters, there was never any cloneable, de facto standard (a la IBM) thus everyone started from divergent designs.
Add in the limitations that PCs never had to deal with (miniaturization, power, cellular radio integration) and you rapidly get each company integrating things as quickly as possible so they can get a product to market.
And honestly, there's not much reason support clean code underneath the hood. 99% of your customers will never flash a custom ROM, much less change the OS. If your stuff works, and you've got the time for a rewrite for the next model, full steam ahead with business as usual.
Unless the SoC drivers are mainlined, you won't be able to upgrade your kernel on such a device. This is precisely the same issue with Android where people mistakenly blame Google instead of Qualcomm (driver authors) for the lack of Android upgrades.
Does this also apply to iOS devices?
With Android you have the Linux kernel team providing the mainline kernel, the SoC team providing the drivers, and Google providing the rest of the OS.
If the SoC team don't care about mainlining their drivers then those devices will only ever support the kernels that the SoC vendor releases packages for.
If Google wants to move Android along to a newer kernel and the SoC vendor isn't playing ball it comes down to hacks that may be acceptable in a community ROM but I wouldn't want to support in a commercial device.
Great point about how PC hardware can always be expected to be generic enoughthat we can just install Linux on it and not have too much trouble, yet there is no equivalent for phones, but there really needs to be.
http://lineageos.org/ https://microg.org/ https://f-droid.org/
[1]: You can use the QR code here to avoid typing the URL into F-droid: https://github.com/microg/android_packages_apps_GmsCore/wiki...
I feel like this isn't a solution for the planned obsolescence inherent in mobile devices though. Every release after Google officially drops support (and provides their own image) gets exponentially harder. The amount of things moving out of AOSP and into Play services grows every month too.
My dream would be an android "distribution", that doesn't rely on some murky "update by getting a new image somewhere if you're lucky enough that someone built one for your device". WOuld work more like a linux distribution (packages and updating) and is generic over a variety of phones. Challenge is probably how to handle drivers.
You're able to build an image yourself from their source if you'd like slightly more comfort, and can run it without gapps if you're privacy or software freedom conscious.
I'd love to see it, but considering how long it took desktop Linux distibutions to run semi-reliably on most PCs which have far fewer hardware differences and important components without even partially reverse engineered specifications, I'm very suspicious this is a feasible way forward.
LineageOS (http://lineageos.org/) has OTA updates with UI: https://1.f.ix.de/scale/geometry/710x500/q75/imgs/71/2/1/3/6...
So your dream has already came true :)
If you're buying a new device, then yes, certainly you should shop for one that's supported on LineageOS or OmniROM, or whatever. But one of the uses of custom ROMs has been extending the life of older devices, and that ecosystem is very spotty.
What you're describing is similar to the situation with mobile devices, only to a lesser degree. Turns out, making an OS run on hardware is challenging and under-appreciated work, and continuing to gloss over the complexity of it doesn't do solving the problem of open-source OSes any favors.
Since there isn't an inexhaustible well of free labor to throw at other peoples hardware there will always be some hardware that either doesn't work right or doesn't work right out of the box because it requires fix foo that is only available in version bar that is the very latest that hasn't made its way into the stable version yet. If you run a bleeding edge distro you may find that you have the needed version of bar but they broke something else!
The solution is to buy hardware with the OS you intend to run in mind. If you are just curious about whether linux might be useful to you the easiest thing in the world to do is try it out either via live usb or virtual machine. If indeed you would like to run linux and it doesn't work with your existing hardware just buy with Linux in mind when you get your next machine.
Instead of asking whether linux can meet the impossible standard of running flawlessly on any pos you happen to throw at it ask whether there exists a reasonable range of hardware that meets your needs and expectations.
If you approach it that way you will most likely be satisfied.
The exception I regularly hit is raspberry pi, but in that specific case I (a) don't actually expect anything to really "just work" out of the box (the whole point of the platform is to hack around on it) and (b) I'm not trying to use it as my primary development / work / games / day-to-day environment.
The idea to build an OS for every device simply doesn't scale.
On the other hand it has potential for even more 'closed source'-ness on the handset manufacturer side of Android. And maybe even for other industries, once its market share rises.
Much more info on wikipedia - https://en.wikipedia.org/wiki/LineageOS
Wow
The website and everything else is still new and very much work in progress. I guess their main focus was getting up the core infrastructure before making a cute website.
The lineage site is pretty garbage. It tells you nothing about it, and had I not been following the Cyanogen news, I'd have no idea what it is. It's literally impossible to figure out what it is from any page of the website.
Unfortunately, I've got an S6 as my daily user phone, and there is currently no stable version of LineageOS that supports the S6 (as far as I'm aware).
I always found it wierd that people talk about "flashing" "ROMs", like it's firmware. It's not, it is under the hood not too different from installing a desktop OS on a hard disk (except you can't pop in a USB drive, you have to use a cable and ADB).
The (e.g. CyanogenMod) ROMs for different phones are not too different. In principle, you could wrap something around ADB that "flashes" (well, copies) a base OS, and then the needed drivers / radio / apps per model.
Also wierd that you can't easily replace individual components. If I want to make a change to a base package or the kernel, I have to reflash everything, instead of replacing one file (well, you can yourself, but nobody in the scene offers that).
You can actually boot your device into TWRP and "flash" the OS zip from USB OTG.
While drivers are supplied as binary blobs, this will be impossible.
UPD:
Jolla -- company behind SailfishOS (ex-Nokia people) https://jolla.com/about/
Nevertheless, if Samsung can't push their Tizen into mainstream I doubt a tiny company from Finland can.
https://techcrunch.com/2016/11/29/jollas-sailfish-os-now-cer...
cool.
Samsung put itself in a position where the company simply cannot walk away from Google, at least in the mobile space (Tizen is actually pretty "mainstream" in smart TVs and wearables). Market shares are pretty much set at this point, and no alternative mobile OS based on linux has a chance to become mainstream, no matter the size of the company backing it. That doesn't stop a small company like Jolla from delivering viable products though, since they don't need to keep Google happy.
Based on what a _single person_ from Finland has achieved, I wouldn't be so sure. ;)
Seriously, though, why even mention the country of origin?
Here's a zany answer: maybe they're proud of their country of origin. Hi-larious, I know, right?
By the way, the phone runs a real Linux distro. There's Wayland, OpenSSH, bash, systemd (ugh...), RPM's, and a ton of good old commandline software like htop, tmux, python, - heck, even gcc if you feel like rebuilding the kernel :) Native apps are built with Qt & QML. There's very little NIH.
There's also support for Android apps. Many of the apps from F-Droid run OK, and even lots of commercial stuff.
Oh, and the phone is pretty fantastic for all the normal everyday things, like being an actual phone.
It looks to me that all Sailfish devices that have ever been available are not compatible with 3G/4G US carriers (but some are compatible with 2G).
It seems that if anyone in the US wants to seriously use Sailfish, they need to flash a community port of Sailfish to a US-sold Android device. Not a huge deal - it looks like a few manufacturers are actively supporting this ports (e.g. for the Fairphone 2): https://www.fairphone.com/en/2015/10/22/jolla-community-work...
Can someone enlighten me? I do understand what blobs are, but I guess I'm not clear on why they're needed.
As natch said, lack of documentation. This lack of documentation prevents others from developing their own drivers etc.
>why so many manufacturers do not make "open" hardware
Multiple reasons. The first four of which I am confident that often play a large role, and the two last of which are more speculation.
1. Companies might feel that open hardware would put them at a disadvantage because others could copy them.
2. Company might have licensed portions of the hardware from other companies and therefore must adhere to agreements about not sharing information about the licensed hardware with others.
3. Maintaining an open project is a lot of work for a company. Everything from ensuring that the whole process is repeatable, to having a team of lawyers approve everything for release.
4. There is no incentive. Users buy their phones either way, even if everything is closed and proprietary.
5. Regulations regarding wireless communications hardware might apply?
6. Company might be using software tools in the hardware development process that they can't share freely so even if they did share the files others still wouldn't be able to use the files for anything?
What you need to understand is that your mobile phone is not a single computer. There are at least three computers inside your phone that have their own CPU, memory and ability to run code.
First, there is your SIM chip. Your SIM chip is a fully functional, standalone computer with its own CPU and memory. Your SIM card can (and does) run arbitrary java applets that can be forced onto it by your carrier without your knowledge. Yes, that is indeed as terrible and horrifying as it sounds.
Second, there is the baseband processor which handles all of the tricky real-time radio comms with the cell towers and which could not be preempted by your browser or other apps you would be running on the AP (see below). The baseband processor is not controlled by you, can be controlled by your carrier, and in many cases has DMA control over the memory in your application processor (what you think of as your "phone"). Yes, you read that right - many, many mobile phones can have their physical memory directly manipulated by a baseband processor that they do not control. Remember that next time some cute "secure" messaging/encryption/marlinspikey/secretive communications app gets released.
Finally, there is the application processor which is the "actual" CPU and memory that you think of as "my phone" which runs things like the uber app and chrome and facebook.
We are sort of, kind of, getting closer to having a free/open stack on the application processor only. There are two other very powerful agents in your telephone that we have made almost zero progress in opening up. There are very powerful financial interests that stand in the way of opening those up.
Sounds pretty logical though. As @rsync said, there are very powerful financial interests behind the hardware backdoors in phones.
As a replacement for the Play Store, check out https://f-droid.org/
[1] https://f-droid.org/forums/topic/what-to-do-with-private-api...
You distribute user-specific secrets after a user has logged in over a secure channel.
You don't get to have app-specific secrets - since anybody can get and run the app (and modify it!), nothing in it has a reason to be secret. This means that you don't get to have an API that's available only through that app and with limitations set by that app. If you use a third-party API that requires you to enforce limits on its use (e.g. that end users can't redistribute access to that API), this means that you can't meet the requirements of that API licencing.
Don't include API_KEY in the published source, include rot13(API_KEY).
It's the source code part that is open to interpretation. I could of course just ask for explicit permission for that.
---
I dont get all that API key nonsense, you can search this board for our opinions on API keys. I’ll keep this short:
If your app requires an API key and you withhold it (because you entered an agreement with the service provider), this basically makes it not buildable for 3rd parties in a useful manner. F-droid will not sign an agreement with whatever service provider you use nor will we withhold build information.
There are actually only two solutions:
1) Provide a way for the user (!) to enter API key or account information at runtime.
2) Provide a way for us to get the key at buildtime, e.g. there was one app where I had to download a pre-compile APK file, extract the key from it and re-use that key in our builds.. which sucked. Anyway, I dont see what’s the difference to just providing the API key. If you distribute an APK, you distribute the API key (in one form or another) — since without it the app would not work… sigh.
I think many times you can limit the FOSS version to not include functions such as leader boards to avoid such issues and no one will complain.
Other alternative app stores are the Yandex Store (https://store.yandex.com/) or the Amazon App Store, those include non-free software too.
[1] https://f-droid.org/forums/topic/api-keys-and-free-software-...
F-Droid has several apps where they download a built APK, decompile it automatically, extract the API key, and build the open source app with that key.
You can do exactly that already.
GPLv3 would help.
https://www.amazon.com/LG-Tablet-Snapdragon-Android-JellyBea...
https://download.lineageos.org/v500
There are over 150 devices supported, but the vast majority are smartphones
My last 3 mobile phones were MediaTek phones, but that's one of my biggest gripes with them.
I've been carrying Windows but Microsoft just effectively announced end of life for the last two phones on my carrier.
Why do you think that?
Heck, Fuchsia is built with a reasonable security model, most work on Android goes into making excuses for theirs.
At least if I'm carrying something obscure the likelihood of being targeted is low.
I don't have the time or desire to do what's required to securely operate on the Android platform.
Extended per-app privacy settings, built-in root manager, lots of customization options... And the best of all: enormous community. There are builds for crazy amounts of devices.
However news that one researcher has found 40 0-days for it doesn't really sound good:
https://motherboard.vice.com/en_us/article/samsung-tizen-ope...
I remember reading about Plasma Mobile
But it looks like the latest phone they use as a Dev device is a Nexus 5x so it may be stalled/dead
https://forums.thedailywtf.com/topic/21368/samsung-insisting...
The story was Samsung's Tizen is riddled with security flaws, amateurishly written
You can install custom software on these devices, and even SSH in over Wi-fi (which sounds like a crazy thing to do on a watch!).
I made a native EFL app for the Gear S2/S3 that did ship (the client was an European airline). The tools are kind of retro (compared to e.g. Xcode), but they work.
http://www.omgubuntu.co.uk/2016/10/purism-wants-make-truly-o...
Sony put everything you need to run your OS on some of their Xperia phones on GitHub as part of their Open Device Program. Jolla which is going to become open source sometime has been successfully (in feburary 2017) run on one of the devices.
So in the near future, there is hope in that direction.
Not all the UI components are open source (yet?) though it's pretty close to stock Qt; at least the base system is open-source, and that's more important to me – I think they want to prevent full rip-offs rather than lock down the system from their own users.
I've been critical of these computer-in-your-pocket claims a few years ago, but I can see now that if the hardware keeps improving at the rate it does, having a full Linux system based on something like Sailfish or Ubuntu Phone with a keyboard and screen attached could work out for a lot of scenarios.
I think the biggest issue is still device support.
[0] https://mail.kde.org/pipermail/plasma-devel/2017-April/threa...
Question is, are you willing to spend money (or testing/integration efforts) on a community O/S for your phone in exchange for knowing that you're not being spied on all the time?
I could imagine a model where you pay a reasonable price for a tested/supported third-party O/S, but maybe CM has shown this isn't economically feasible.
IMHO the effort put into cyanogenmod would have been better used if put into building an actual OS. Though this is a mostly unreachable moving target as devices get obsolete faster than one can add support for at best manufacturers do not help.
Right now I'm considering jolla/sailfish for the next time I buy a phone which hopefully will not happen before 4 or 5 years.
I've been running it for some time now and I like it a lot. Support for a lot of phones? No. Wide range of apps available via F-droid? Decent.
I'm not a very appy guy though. Most of my needs are browser based.
They truly care about the privacy and redesign the hardware according to this goal.
Maybe by 2020 and for $5000 we will have a truly free phone with the specs of a device from 2009!
https://en.wikipedia.org/wiki/Maemo https://en.wikipedia.org/wiki/Nokia_N900
There's still a relatively active community going:
My personal expectations from Pyra are very high.
I have no doubt the pyra will deliver.
Now the thing with Android is that, it is just a framework, so saying Android is Open Source is missing big points There are two major limits: 1. What about apps? 2. What about drivers?
Today, if you get an Android phone with Google Apps, especially Google Play Store, you have access to many tools that can be considered useful for everyday use, which you won't have with FOSS Android. Here are some examples:
With Play Store, you can have (mostly?) any IM, as long as you install the app going with it. The only possibility I know to do that with FOSS Android, is to use matrix or IRC, and have server-side libpuprle connectors.
With FOSS Android You don't have factorized push socket: Most apps pushing notifications on Android require GCM. But even if it doesn't require GCM, there is nothing fully open-source an app developer can use. All they can do, is open a socket to their own server, and deal with it, which is a huge battery-killer.
Many people are mentioning f-droid as an alternative to Play Store. I'm sorry, but I consider this a joke. I highly respect the work done on f-droid, but this is not a usable alternative. For instance, you want to save your SMS. We call that backup, but not every knows that. Well you search for "save sms" on f-droid. No result. You search for "save sms" on Google Play Store, the second result is SMS Backup+ which is open-source! You search for SMS, the result is on the first page. Same thing happen if you just search for "sms", QKSMS (an opensource SMS application) is much easier to find with Google Play Store than f-droid. Even to look for open-source apps, you're better off with Google Play Store! Again, I totally respect F-Droid devs, this is this way because of their choice of not tracking or saving any user information at all, which is legit. But then, some people might want something intermediary. Just counting the number of installations of an app can be really useful to better sort apps (SMS Backup+ and QKSMS really deserve to be among the top in the results for SMS).
Now, about the drivers. Yes Android is open-source, but good luck running a phone with a FOSS Android! At the moment, you have the choice with either replicant, which is old and missing gpu acceleration, or running a mainline Linux kernel with Mesa & stuff, but then you have no radio.
Though I have to mention that on the drivers side, Sailfish OS and Ubuntu phone have also those problems.
Is it ? I thought that only the AOSP part of Android was actually open source and not that useful by itself. I might be wrong here but my understanding is that the opensource in Android is mostly for show/marketing and is getting worse with time.
Unfortunately it is not well supported yet, as porting it to any given device seems to require rewriting several proprietary Android drivers.
Looks like the core maintainer could benefit from donated android devices for Replicant to run on newer devices.
http://blog.replicant.us/2017/02/replicant-6-0-development-u...
https://hackaday.io/project/19035-zerophone-a-raspberry-pi-s...
Reddit AMA: https://www.reddit.com/r/raspberry_pi/comments/5nwmfx/im_mak...
$50. Calling, SMS. Alarm clock, calendar, calculator, phonebook, file browser, web browser and music player. I expect these will be very simple given the screen.
[1] check out https://stats.lineageos.org/ for popular devices and also check the devices subforum on the XDA forums
If you don't care about the aesthetic, your best bet is Lineage. It is Android without Google and you can still get lots of stuff done.
Personally, I came back to a cheap WebOS phone with a cheap plan and after I installed WebOS 2, it has been really usable. LuneOS is supposed to be the continuation of WebOS, but it's just not that usable yet - I see no way to sync with my Google account (which syncs fine with the 10 year old WebOS instance via Exchange). So I would keep an eye on the LuneOS development. For such a niche and small dev team, they have been continuing making improvements. Totally impressed by that.
(For a little while, there was an unofficial Whatsapp API which I used to bridge chats to my Firefox OS ZTE)
Would my life be better if I use it?
* Tizen OS https://developer.tizen.org/ https://en.wikipedia.org/wiki/Tizen
Alternatively you could use Termux on Android to use the GNU/Linux ecosystem on your phone.
Project seems to be abandoned?
http://www.davidhunt.ie/piphone-a-raspberry-pi-based-smartph...
Inb4 nay-sayers, but if you have followed Fuchsia for a few months and have seen the speed of development and just how many people and new technologies are involved, you will see why this isn't even a question.
The real problem is the hardware driver blobs.
Would you still consider them part of Android?