Trying to summarise my thoughts on what it takes to build an alternative mobile OS. There's some very important and imho rarely discussed reasons why using anything that depends on AOSP is fundamentally a bad idea.

It basically boils down to culture and politics. The way Android is built and maintained is so fundamentally anti-free-software and anti-community.
1/8

Firstly, you're relying on a downstream kernel which is impossible to maintain beyond LTS (Some of the smartest folks in the community tried HARD and failed to actually forward-port Android kernels). This exposes you to a whole host of poorly tested codepaths and non-standard drivers which require a whole host of userspace workarounds.

AOSP itself is so vast and complicated that it's just never gonna be possible to escape the grip of Google.
2/8

To even build your own Android image you need to jump through a bunch of hoops, download hundreds of GB of source code and take >1 hour on even a beefy build machine with ~100GB of binary artifacts. There ARE benefits to having the entire OS source code locally IF you're building an OS the way Google do with many separate teams who work independently.

But this is never how healthy FOSS projects work, they rely on individuals showing up and working in harmony together, something which is just plain annoying to do with AOSP.
3/8

Then consider what happens if you need to modify a core part of the OS: You have to fork it, because Google do not care about your patches, and if they do it will take months to get them upstreamed (using gerrit of course!).
4/8

Let's consider a successful AOSP fork in Lineage OS, they do a pretty great job at maintaining infrastructure to build images for lots of devices at a fairly substantial cost. Their developer community though seem to tend towards individualism and "proving" yourself as a good developer before you get treated with respect. This is an understandable result of getting burnt out trying to help everyone who wants to make a port for their phone but just isn't cut out for the work.
5/8

Showing my obvious bias here, but let's compare this to postmarketOS. The requirements for space, performance, and network bandwidth are an order of magnitude smaller... The biggest thing you have to compile is the Linux kernel.

The "onboarding" process for postmarketOS developers often starts with a downstream port, where you boot using the original Android kernel. This often gets you just far enough to have ssh working but not a lot more. But importantly it gets your in touch with other developers in the community and it gets your familiar with our tooling.
6/8

After this, if you want to go further then you basically have to learn kernel development. This can be a huge challenge, but it's something our community encourage and write plenty of guides and documentation to help.

The fundamental approach is different: you don't have to be running a specific distro or install a bunch of tools, you just run pmbootstrap and it does everything for you. It creates template packages for you and guides you through every step of the process. Compare this to having to manually edit XML files, get acquainted with the repo tool, and wait potentially hours to clone all the git repos.
7/8

When it comes to creating a truly emancipatory mobile OS, it is beyond absurd to consider AOSP as the basis. I truly believe that Linux Mobile and decentralised development built on top of FOSS is the only way. The same goes for making it as simple as possible to onboard and teach new developers, the more knowledge is shared and the more people are skilled up the more resilient we become.

TL;DR: FSF please reach out and let us help you actually bring freedom to people! I can be reached at kcxt@postmarketos.org
8/8

oh and when it comes to kernel development, that is (imo) a much more transferable and useful skill than being able to hack on AOSP. I know several people at this point (including myself!) who's entire career was only possible because of the postmarketOS community.

In the long run, the more independent developers we get contributing to upstream Linux the more we will be able to bring maintainable and resilient software to all the billions of smartphones out in the world, further reducing our dependence on big tech.

@cas well said on all counts. this is why our personal phone uses mobile-nixos heh, we went through a similar train of thought a few years ago. better to start from a solid foundation and build what we need above it.

@ireneista this has been on my mind for like a year at this point, i wanted to make some banger blog post but i guess i just needed to get it out there

maybe will still try and make a more cohesive piece about this topic but i should do more reading first.

The end goal is exodus

@cas Agree completely! And the same applies to userspace. Once it’s just another Linux we get everything that’s already available and can improve in small steps, instead of being stuck with approximately what Google decides.

Banger post @cas.

But I think there are some things that are getting confused.

I've noticed is people calling it an operating system. Which it is not. It is a research project focused on reverse engineering proprietary blobs.

I believe they are targeting blobs rather than drivers. Their core values go against any closed source blobs so either your phone won't work like a phone or they attempt to reverse engineer a modems firmware.

If you read their FAQ section:

> NO. There are many projects working in mobile phones, and many of them are largely free software. The FSF doesn't see the need to join these projects, but wants to build upon them and improve on their current state of freedom.

So I think the chance that they take you up on your offer is questionable at least.

@weirdtreething @craftyguy focusing on bootloader is extremely dumb tbh

@carbonatedcaffeine hmm that's good to have clarified. their press release was very poor in this case, zero context given

@cas Having read their main site page and FAQ I think it *mostly* clear.

What it is:
A research project focusing on reverse engineering binary blobs found on Android devices to "replace" them with FOSS versions.

What it is not:
* An operating system
* A piece of hardware

So I think "librephone" is kind of a weird name for a "research project" when my first thought is that it's going to be some kind of hardware project.

The part that is not clear to me is is this bit here

"This is a project to research proprietary files in Android to work towards a long-term goal of **free replacements**"

I interpret "free replacements" as replacing the blobs on Android with ones that are FOSS. Unsure if it would benefit everyone including mainline.

@cas i'm really hopeful about the fsf's future after the leadership change recently and would love to see this happen. have been getting into autotools recently and they (un?)surprisingly seem to have some converging ideas on build tooling

@neil @cas It depends if they manage to move something forward; like if they can find a _good_ chip that can run open firmware, or do a free firmware for a popular chip, then it might be great. But it would have to be for a physically practical phone; a lot of previous attempts have come out using very low end or odd hardware.

@cas I think a big issue here is apps and app stores. Both iPhone and Android have a massive range of developed applications that users/customers like. There’s also all the tools/SDKs out there for making mobile apps that run across iPhone and Android. For the Apple ecosystem some of the mobile apps can now run on desktops also (without recompiling I think).

I completely agree that PostmarketOS presents a better technical, ethical, and sustainable route - I personally am really grateful for this project as it means I get to run a distro (alpine) that I like on portable/niche hardware (ClockworkPi uConsole specifically).

I do want to run it on a phone also (I have an FP5 - not fully supported … I keep looking at buying a PinePhone instead).

The problem still is apps though. Some are really only made for phones and not true Linux phones, only Android and iPhone.

The phone OSes have massive momentum and shifting that is very very difficult unfortunately

@fionasboots yes! but thankfully it's super duper possible to run android in a container with nice tight integration into the host, see Jolla's app integration

@cas https://pine64.org

They have phone, and more.

@janisf yep i'm familiar, what's your point?

@cas
Last time I brought this up with GrapheneOS folks in passing, they were insistent that AOSP was the most capable open-source mobile project and that mobile Linux is nearly impossible to secure to the same extent.

@xerz Thanks for raising these points! This is definitely an interesting topic.

I don't agree with the implication that increasing choice and thus complexity is inherently negative:

Just considering the mobile ecosystem (since it has a more tangible scope for me at least), postmarketOS was the first major effort here. If we had tried to discourage folks from creating Mobian, Kupfer, nixOS-mobile, etc. The end result would likely be less communication between these projects... It simply isn't possible to create a unified ecosystem this way.

And fwiw we aren't even unified on glibc, since pmOS is built on Alpine, we had to put a lot of work into getting systemd and musl to somewhat work together.

But consider even just at the tiny scale of postmarketOS, we are able to offer a huge range of interfaces on top of a massive list of device exactly because we encourage choice, does this increase complexity somewhat? YES, but the end result unifies our community around the core goal of building a mobile operating system. We are able to focus on things like UI and apps as well as deeper UX like the initramfs/recovery environment, installation process, and immutable effort as a single community.

In my opinion postmarketOS is working towards creating a "federation" of sorts exactly as you describe. Heck maybe that becomes a more formal effort in the future...

We previously have discussed making a "linux mobile" website which covers the major distros, interfaces, and describes the overall goal as a way to introduce people to the movement, I think this is absolutely something we should revisit.

At the end of the day though I think it's very important to have *opinionated defaults* that offer the best possible experience for the average user, and I do think that's something we should come to agreement on.

Regarding GKI/GSI, I would actually consider these efforts to hugely raise the level of complexity. Consider what they are trying to solve (vendors not updating their drivers...) and why (money, mostly). In practise many vendors don't follow these abstractions properly, so things break... These kinds of technical efforts are only required when most of the development is done by people who have no ideological interest and are just getting paid to do their work (which i have no problems with fwiw, that's capitalism...)

When it comes to software created by people with a greater goal and a deep care for users, that's when people build things like postmarketOS which are tooling-first, well documented and easy to get involved in. We have to have this care because we want to attract new developers and new users, it's an earnest effort to improve peoples lives. As long as everyone works towards that fundamental goal I think the rest will fall into place over time.

Regarding tow-boot specifically, it's a shame that it went the way it did, i think the scope was too big from the get go. We are starting a new similar effort over at https://tauchgang.dev with muuuch stricter requirements, instead requiring device maintainers to step up if they want their device to be supported and ensuring they stick around to maintain it.

@cas I do wonder about everything that gets lost tho. In order to be emancipatory and empowering (and as a direct consequence of easing individual development) you have to increase choice, and thus complexity. For instance, the unified ecosystem, with a single stack, package manager, design language, API set, etc. is gone. Instead, you got community Linux (and ngl, not just Linux!) where, besides the glibc API, Systemd, Wayland and FreeDesktop (somewhat), there’s not much of a consensus, for better or worse.

This is, indeed, culture and politics, and they’re all directly tangible not just by devs and contributors, but also by users. Everyone needs to know where to get started and how. I wonder if we could do better than the status quo, instead of translating our fights into user liability. Perhaps e.g. by creating some sort of federation that makes getting started easy, via consensus mechanisms, websites and documentation?

It also makes me wonder about efforts like Tow-Boot, which seem completely stagnant, as well as the possibility to take ideas away from e.g. GKI and GSI. Standardizing everything into well-abstracted layers would most definitely bridge the gap between the expectations of a PC and the diversity of the mobile world, and hopefully ease development. But again: culture and politics.

@xerz heh interesting, i have hacked on something quite similar before. definitely something im interested in taking further

@airtower @cas so... Having bounced off of a PinePhone recently including trying out PostmarketOS, I initially thought that I'd love a "just Linux" phone, being a long-time Linux user on personal laptops. I was pretty willing to take big hits on app compatibility (which were painful already) but the thing that made me go back and buy another Android phone was battery life. To developers, I'm sure the whole "your program will be terminated at any time without warning" thing I assume is going on must be incredibly annoying, and it's basically antithetical to how most Linux stuff is designed to work, but it feels like the only way to get reasonable battery life. On the PinePhone, having a browser open in the background (LibreWolf) burned through battery steadily, not to mention all the other moving parts of a Linux keeping a steady few percent CPU load. Maybe I was doing something wrong, but between that and all the other problems, plus a few apps I'd really miss since family/friends used them, I decided not to take the plunge. At least I got to try out a handful of very cool alternative widow managers along the way?

Obviously the task is monumental, but the experience made me feel that a dedicated fresh-from-the-ground-up OS with Linux compatibility as a secondary goal would be the thing necessary to make a non-Google phone appealing to me. That or significant progress on battery life within phone Linux, which feels almost as monumental an undertaking...

I definitely do have a lot of respect for what's been achieved in the space so far, and maybe I should try again with less-niche hardware some time.

@tiotasram @airtower yep, there are two major factors here

1. the pinephone is crap hardware and it really was a double edged sword, any modern qualcomm phone with good pmos support can last a day with some careful maintenance

2. the software side id totally missing for push notifications and runtime powr management. We need good support for pausing background apps and other fancy features -- this is something that really holds me back too and im hopeful it's something we'll put funding into in the next year or so (cc @pabloyoyoista )

overall im confident we'll make drastic strides in this area of the next year or so, it's really one step at a time for us right now but the more folks get involved the faster in all the different parts of the stack the faster we can go (we would benefit greatly from having more people with project management experience get involved in pmOS)

@cas @airtower @pabloyoyoista that's super exciting to hear!

This convo inspired me to go dig it out and resume my project of trying to stick an SNES emulator on there for my kids to use in a few years.

@cas @tiotasram @airtower @pabloyoyoista From my side, PinePhone has two great features:

a) Cameras are actually working (but it has unusual setup)

b) It has video out

(It has other features that are not so great).

@pavel @cas @pabloyoyoista @airtower yeah the video out is cool. If I can get it accepting a Bluetooth controller & get an emulator working on it, I'm hoping it can be a nice fake console for SNES/PS1/GBA games. So far looks like I'm gonna have to flex my Linux knowledge a fair amount to get that far since between the non-standard-for-Linux input setup and the non-standard chipset a lot of things just don't work by default, but we'll see...

@tiotasram @pavel @cas @pabloyoyoista Bluetooth works on the Pinephone, wifi btcoex is not where I’d like though (with rtw88).

@cas @tiotasram @airtower

> the software side id totally missing for push notifications and runtime powr management. We need good support for pausing background apps and other fancy features -- this is something that really holds me back too and im hopeful it's something we'll put funding into in the next year or so

Bushan from Plasma Mobile has an nlnet grant and is working on this for quite some months already. I'm not not on top of it, but I'm pretty sure there will be good things coming out of there. He'll be with us at FOSDEM, so we should probably use the hackathon to review where we are in regards to that, what else needs done, and how to move forward.

@cas So you‘re up for mentoring?

@RawryCore though i desperately want to im still in the "much to do with so little time" era.... hoping that will change in the long run

best i can offer is occasionally helping out pmos devs and trusted contributors

@cas Awrr... 🫠
I hope so too, otherwise you might end up doing all the work alone which keeps you in a neverbreaking cycle of the underlying workload.
I think T2SDE lead dev had some mental breakdowns allready.

Hmm I wish you all the best, maybe we team up someday :P

@RawryCore I had to read your comment a few times, it initially came across as somewhat condescending but im pretty sure that wasn't your intention, still i feel it's worth pointing out

There's a lot of complicated and some personal reasons why I haven't been spending much time doing stuff I would class as mentoring in the pmOS community, particularly when it comes to random people who show up in our Matrix. This is something that bothers me but part of why I don't beat myself up about it too much is because there are so many other wonderful people in our community who can fill that role. I'm still really struggling to find a good balance to keep up with just the work I actually to want to get done for pmOS (which isn't something that would be fixed by mentoring)

Back when I was really just getting involved a few years ago the collective knowledge and understanding of the topics I worked on was really quite minimal and it was necessary for me to share that knowledge as much as possible, i wrote docs and notes and helped people, i also was still at university and not yet a part of the pmOS core team so I had a lot more time and a lot less scope.

Thankfully there has been a really huge snowballing since then, which I hope was something I played a part in. The community has grown by close to an order of magnitude, and new younger and enthusiastic folks (who also have a lot more time) have appeared to push the envelope even further.

On thinking about it more, I realised it's not really true at all that I dont do much mentoring anymore. I have always cared deeply about educating others and sharing what I've learnt, both as an autistic person who likes to share whatever is making me excited right now, but also as an anarchist. My more recent effort here has been to repeat the success I had pushing postmarketOS forward with newer hardware support but this time for U-Boot (for example https://docs.u-boot.org/en/latest/board/qualcomm/phones.html)

In any case, I'm all too familiar with being stuck with the workload of maintaining software for users that i really dont want to be maintaining and while i have no doubt that my approach could be improved I feel like i try my best to avoid getting myself in that position

@cas Oh wow..
I.. uhm. I like your brain.
No I really don‘t want to be condescending, I‘m sorry.

Maybe it‘s just me who thinks it would be great to have someone allready involved to grasp what exactly need to be done and which process ends up being usefull.

I‘m not saying you‘re not allready helpfull to your community, I literally admire your work.

Mentoring means to me something personal not broadcasting.
I feel like I’m not doing anything, except learning all about computers, but that is not contributing.
So this was more or less a.. try to see if you may have interest in that kind of teaming up.

I‘m very sorry, didn‘t mean to throw you off w/ my comment.

@RawryCore oh ty for clarifying. It was honestly nice to write down my thoughts in any case, i appreciate you asking about it ^^

i just realised what you mean by team up now. I don't think I quite have the experience or energy to commit to something like that but I'm more than happy to answer pings in the pmos channels or DMs if you need help with something specific ^^