Congratulations! This is one of the most amazing projects I've seen on here and I can't believe I haven't heard of this earlier, especially since you got the phones to boot it as well!
Amazing article as well. I learned 600 new things from this :)
Do you have any more information on sh.rt and its use cases?
To anyone who would like to see sr.ht grow, please note that Drew DeVault is running it on donations. He chose to go work full time on free software with these donations:
> I need to clarify that despite choosing to work full-time on these projects, my income is going to be negative for a while. I have enough savings and income now that I feel comfortable making the leap, and I plan on working my ass off before my runway ends to earn the additional subscriptions to sr.ht and donations to fosspay et al that will make this decision sustainable in the long term.
As my old ARM Chromebook gets nearer to it's EOL I start to look for how to install Linux on it. I'm wondering if postmarketOS could be used to do this. Has anyone tried to do something like this or where should I look?
I'm slowly dabbling on my own Linux distribution [0]. I'm using Void Linux packages and build system to prepare a rootfs image. Thanks to how it's done in Void I can build the whole image without root on newer kernels. I intend to have the update model of ChromeOS (two partition scheme, reboot to update), but Void being a rolling release only distribution may bring me same pains as Alpine edge brings to postmarketOS. So I wonder: how's Alpine build system in comparison to Void's? Does pmbootstrap bring the isolation or is it already an Alpine feature?
> I intend to have the update model of ChromeOS (two partition scheme, reboot to update), but Void being a rolling release only distribution may bring me same pains as Alpine edge brings to postmarketOS.
You're kind of reinventing NixOS, but worse (NixOS has atomic upgrades and allows you to return to any generation of your system, not only the last one).
No, I'm reinventing ChromeOS. I started on this project with my father in mind, to make it easier for me to maintain his computer. My father would not run NixOS, but maybe I'm wrong. This will give a single image and very little tooling outside of end user parts. It probably will be much simpler.
If totally seamless and _automatic_ updates can be achieved with NixOS I'm all ears.
Put whatever update command (nixos-rebuild switch --upgrade I believe? haven't touched nixos in a while) in a crontab and you get automatic updates. If the update fucked it up, you can boot back into the previous configuration. In this way, it's really, really hard to brick a NixOS install. That's the beauty of it.
Of course, it's not going to be as transparent as ChromeOS: If the update failed, you'll have to manually select the previous configuration in the GRUB menu. That's definitely something solvable with a bit of code though.
So, yes, automatic and seamless updates can be achieved with NixOS, given a bit of configuration and maybe a bit of code. Whether it's the right approach for your use-case remains an open question though. NixOS has many other rough edges (many applications don't "just work" on it) which might make it a deal-breaker, depending on your use-case. But you might want to look into its update models, you might get some good ideas :).
The point of the ChromeOS dual-partition scheme is that ChromeOS system installs are read-only and immutable - they're the equivalent to creating a squashfs live system and burning it to a fresh CD, so it wouldn't make sense to de-duplicate data among them. If you don't care about this property and need more flexibility than that anyway (as with the average Linux distribution, which is updating stuff in /usr all the time), snapshots are the sensible choice and the dual-partition scheme is quite pointless.
I’ve got an old Sprint Samsung Epic 4G slider (WiMAX, the old 4G), that would love to be a little mobile terminal...might be a little too dated though...
Anyway, this is a fantastic project and I’m eager to contribute!
> I’ve got an old Sprint Samsung Epic 4G slider (WiMAX, the old 4G), that would love to be a little mobile terminal...might be a little too dated though...
It's nice to see obsoleted hardware made useful once again.
I can see this becoming only more popular over time. Phones show already a slowing pace of improvements, so maybe in the future devices can be useful (at least in some form) way beyond current 2-3 year period.
Much as I admire the goal and the scrappiness, doesn't it make way more sense to start with an AOSP foundation (without Google Services) and invest one's energy improving (or even forking) that experience instead of reinventing such an enormous wheel?
There's already LineageOS and Replicant who work on Android-based OSes if you want an experience like that. This is a bit more sustainable and flexible as those OSes have to constantly maintain feature parity with Google's releases rather than prioritise other aspects.
If using Android kernel eliminating rest of Android OS is the goal, Ubuntu Touch is being developed & run by ubports community[1] after canonical discontinued it.
I recently tried it on Nexus 4 & it is certainly capable for daily use. It is running on 16.04. It will provide regular Ubuntu OS updates but the kernel remains the same as the android version.
Since the android kernel is dependent on the manufacturer, once the updates are stopped, the device is at higher risk even if it runs Ubuntu Touch, LineageOS or other 3rd party ROMS though they release regular updates.
I believe, postmarketOS aims to address this in long term by using mainline kernel & at present uses android kernel for drivers without the user space? I'm not sure whether this offers any particular advantage over UBPorts Ubuntu Touch at its present state, but I really appreciate what they are doing & looking forward to use/contribute to it soon.
The reasons don't really seem to address why Android has the issues it has -- device manufacturers don't upstream their code changes to the mainline Linux kernel, Linux doesn't have the same level of abstraction around hardware as eg Windows does, and the state of ARM SoCs isn't like the x86 platform where there's a lot of standards you can follow, everybody just ships bespoke code to boot their SoC and only their SoC. I don't see how shipping a "real" GNU/Linux userland addresses that.
We are addressing the mainline issue, a few devices actually run closely to the mainline kernel in postmarketOS. See our previous big update post for details:
The reasons are very clear, while I trust Apple so far, it’s both important and awesome that a bunch of nice peoples start building a real FOSS alternative in case they are actually screwing us.
Android can’t be trusted anymore unless major change of policy. By extension AOSP are better but still dubious since they can’t totally cut the cord from Google if needed (as far ad I understood).
What do you mean by "cut the cord?", AOSP doesn't use Google Services and it could be forked at any time (but would admittedly be difficult to maintain without Google's resources).
The mainstream Linux stack is getting closer to parity with AOSP and ChromiumOS anyway, gaining features like touch-screen-first input, small-screen support, phone calls & SMS, GPS location, privacy-focused sandboxing etc. It's all about having a single system for the community to focus on, thus reducing fragmentation. AOSP app support can then be layered over the basic system if needed.
Really good idea, fair play to everyone working on it. I generally try to keep my phone as long as possible but the main driver to make me get new phone is the diminishing battery capacity. This isn't helped by the fact it is very hard to get a replacement battery shipped to where I live.
If you control the OS and hardware drivers on your device, you can preserve its battery capacity substantially by keeping its state-of-charge around 50% as far as practicable (keeping it from reaching not just "lows" which you should always do, but "highs" as well). We aren't even close to reaching the full amount of battery optimization that's possible on mobile.
I wonder how that advice applies if the battery capacity has already degraded significantly. For example, my current laptop's battery reports itself to be "100% charged" at 60% of its original capacity. Should I keep it around 30%? I don't really know enough about battery chemistry to understand how high levels of charge cause damage.
No, keep it hovering around 50% as much as you can, provided that it never ever reaches really low states of charge, 15% or less. State of charge is always relative to the capacity at current time, not the original factory capacity.
I've got piles of old devices, I wouldn't mind having a go at getting this to boot on my Xperia Z5c and Z3.
I'm so glad this project exists, with smartphones being designed to be disposable embedded devices with none of the conveniences the IBM PC architecture provides this is going to be an uphill battle.
Very very nice project. Did you communicate with the lead developper of the Zero phone ? (https://www.crowdsupply.com/arsenijs/zerophone) These two projects could be a great match I think.
I hope to start hacking on my Motorola E 4G (surnia) for which works has started on the wiki but it is my main phone and I need to keep it working :(
This is something really interesting and great. Unfortunately, even to get the basic functionality (calls, audio) working, one has to spend a lot of time and effort.
I am sure I’m missing the point, but surely getting the GSM/3/4G radio working for a voice call would be the whole point here and there’s zero calls made yet by postmarketOS, in over 600 days that’s a pretty bad state to be in. No?
Is this supposed to be a Linux phone or not?
Getting radio working is not the sole point. The original motivation as was presented to me in early announcements was to give smartphones a 10-year lifecycle [1]. So more about getting extra life out of all these old phones people have laying around rather than specifically getting them to work as people's primary mobile device.
I keep trying to do things like that with old hardware, and find that it's really just a source of clutter, because the hardware device itself is still redundant with the new one. As well as my old phone can play music, my new phone can play music even better, and is also more likely to be in the same room as me when I decide to play some music.
Besides, on any time scale that matters from a big picture perspective, it's not the life span of the individual pieces of electronics that determines the rate at which waste is being produced, it's the rate at which they're being manufactured in the first place.
Where postmarket starts being able to make a meaningful dent in the world is when it can help me avoid ever having to buy the new device.
They're only manufactured at the rate of obsolescence though. If people don't feel the need to upgrade due to a lack of software updates or their current device slowing due to increased requirements of newer versions of their OS, why would the rate of manufacturing continue? The demand drives the supply, surely?
In saying that, the external hardware also degrades over time, I imagine a phone with entirely replaceable parts would be important in life extension also - à la Fairphone [0].
(Joking aside, I think that the problem is that having usable voice would be at the end of the journey; e.g. the Nexus 5 has the modem working but not the audio.)
I've found that it kinda-sorta works, on some hardware. I really wish they were targeting Debian instead of something as prone-to-broken as Alpine, but beggars can't be choosers.
Amazing article as well. I learned 600 new things from this :)
Do you have any more information on sh.rt and its use cases?