Hacker News Reader

1) 3 Gb of RAM is plenty for debian. I own lots of machines with less and they're just fine (just don't do anything stupid like running GNOME)

2) Android is a fucking awful mess: the whole thing is a single monolithic project that in general doesn't accept community contributions and is extremely difficult to build yourself. It's built expecting the user to be a danger to them self and handicaps them in ways that make it very difficult to run useful software. The devtools are pretty awful compared to what you have on GNU/Linux IMO, which is quite the achievement.

3) the people buying these phones are buying them because they don't want to deal with "polish" and are happy with something like debian or alpine.

4) there are almost no apps on android that are actually useful or can't be replaced with the companies web page or a small piece of (already available and much more mature) community maintained software that runs on debian. Youtube is an absolutely fantastic example of that, if I really want something native I have youtube-dl and ffplay. graphopper (the engine used on the librem5 for mapping) is arguably an improvement on google maps (except for geocoding heh. that's a different thing anyway and google's solution was to just pay people to drive around and collect house numbers which no one is probably going to volunteer for.)

5) f-droid is amazing compared to the play store but sucks compared to a real distribution package manager.

> google's solution was to just pay people to drive around and collect house numbers which no one is probably going to volunteer for

While Google’s Streetview cars were pretty nifty things, apparently the Streetview cars were not the source of house numbers in many countries. Instead, Google simply bought the rights to existing sources of information. National postal systems and municipalities had quietly created their own databases over the years.

People do volunteer to add house numbers to OpenStreetMap. My own city of half a million people got house numbers precisely because our local OSM club organized weekend outings where we would walk around town and add all the numbers. Then, when I moved out to the countryside, I would bicycle around to add all the house numbers for the surrounding villages.

> except for geocoding heh. that's a different thing anyway and google's solution was to just pay people to drive around and collect house numbers which no one is probably going to volunteer for.

theres the mozilla stumbler app that collects wifi ap's but I think the firefox app also collects the same thing unless you opt out. then there is opencellid as well.

i drove every road in my area capturing photos using mapillary with the end goal to use them to improve openstreetmap. i had the above apps running the whole time because why not. I'm sure other mappers do the same but if not I'm sure it would be easy enough to find a few people in most areas that would be willing to contribute

Nobody is going to rewrite thousands of applications not to use Play Services either, so open-source Android doesn't actually get you much in the way of app support. Many of Android's features actually exist in a binary blob shipped by Google.

Building a free-as-in-freedom ecosystem for phone software, that isn't connected to a single company, is really important as a goal. Purism's work is/was largely being upstreamed to major community projects like GNOME, where others can build on it and influence its direction.

As far as I know, there are replacements for Play Services, and it might be easier to write and maintain them (the API is public, right?) than rewrite existing Linux apps for mobile screens.

For example, in China Google is blocked but they can use Android and applications from local stores.

The “replacement for Play Services” is MicroG, which does its magic with the rather ugly hack of certificate spoofing, and consequently no larger distribution wants to touch it so that the masses would be able to use it more easily. Mentioning MicroG can get you banned on LineageOS forums, not because the Lineage team thinks that MicroG is unwelcome competition, but rather because they don’t want Lineage to be identified with a project that takes that approach to getting around Google.

But Play Services and related libraries for analytics or ads have a documented API. Isn't it easier either to write an implementation of that API or put Play Services into a safe sandbox rather than find time to write or port thousands of apps (that would require millions of man-hours) you could take for free from Android ecosystem?

Also, there are open source apps like Calendar, Gallery, Camera or Music that don't have ads and don't need proprietary components that you could use for free.

There is microG, but last time I attempt using it I run into issues installing their base services on a modern Lineage OS. Some people are using it successfully. It's kinda a shot in the dark really.

Android is a spyware delivery vehicle for google and others, I want an open and free phone that works for me not against me.

Development on android is absolutely horrible, tonnes of xml and java just to get a simple hello world working, a huge bloated IDE that's practically required to do anything, glacially slow emulators to debug with instead of just running the app natively. Java and all the performance problems from that.

> Nobody is going to rewrite thousands of applications like Youtube, Telegram, Maps or Happy Farm for Debian.

Good, they aren't wanted, I don't want to have to rely on malware and proprietary messaging apps from the play store. Once you get rid of that you don't need the crazy permissions system, the users that need that permissions system don't understand it anyway.

> Is writing in Java less productive than in C/C++/GTK or whatever they use in Ubuntu?

Yes, at least when coupled with the horrible android ecosystem. Compare a hellow world app with c + gtk (https://riptutorial.com/gtk3/example/18820/-c---hello-world-...) to one in android (https://www.tutorialspoint.com/android/android_hello_world_e...). Having a sane and performant environment to build apps in is the most promising aspect of the Librem 5.

> Nobody is going to rewrite thousands of applications like Youtube, Telegram, Maps or Happy Farm for Debian.

Funnily enough, the libre YouTube app of choice on Android, NewPipe, if I am not mistaken, just uses youtube-dl under the hood, which is a script that was originally written for desktop Linux.

With regard to Maps, the sort of people who want to buy a Librem phone are probably often the people who like to use OpenStreetMap-based apps like OSMAnd or Maps.Me. I am concerned about the availability of a map app on Librem, but surely one of the existing libre OSM solutions could be ported over?

> Also 3 Gb of RAM might be not enough for Debian/Ubuntu based OS.

The Raspberry Pi 3 has less and has still served people well for many uses.

> I am concerned about the availability of a map app on Librem, but surely one of the existing libre OSM solutions could be ported over?

I think that you underestimate the amount of work required to port applications for a new OS. You cannot use existing desktop apps on mobile without remaking their UI and refactoring them. Who is going to do it? Who will pay for it? Will Linux users who got used to free software, pay for apps?

I know how many time it takes developing a single mobile app, and it is not less than hundreds or thousands of man-hours for one app.

Android has a working model for developers to earn money which attracts them and motivates to write new software, and the costs are distributed across millions of users which allows to keep the prices low.

Privacy-oriented phones are unlikely to become a mass product quickly so they won't create an attractive market in the nearest future, and even if someone writes or ports an app, they won't be able to keep the price low.

And as I understand, this small market of privacy/freedom-oriented phones is going to be divided between several vendors with incompatible OS distributions.

That means that there won't be many third-party applications. There will be a Firefox-based browser, Terminal (not very usable on the phone), several built-in apps and that's all. There will be no games, no popular messenger apps, no bank apps, no apps to play music, no manga selling apps, no photo editing apps, no apps to buy clothes or order a taxi.

Regarding memory usage, Android has a system that can start or stop background services, unload applications to free memory while preserving their state. Linux applications are not written with this in mind, and you cannot unload them and restore back. So they will use more memory.

> You cannot use existing desktop apps on mobile without remaking their UI and refactoring them.

Supposedly the GNOME platform that Librem has chosen makes this much easier.

> There will be no games, no popular messenger apps, no bank apps, no apps to play music, no manga selling apps, no photo editing apps, no apps to buy clothes or order a taxi.

That sounds rather like how life already is for Android users who only get stuff through F-Droid. I don’t have games on my Android phone, I told my bank I don’t want their app and I use their other 2FA solution instead. I don’t read manga, so obviously I have no manga-related apps. When it comes to online shopping, I do all that through the browser – honestly, I have never even thought about installing a retailer’s own app.

When it comes to “popular messenger apps”, again, the sort of people who would be interested in Librem’s phone are probably the sort of people who are presently using Telegram or Signal on their Android phones. There are already Desktop Linux versions of those apps, and while the UI may be an issue, it is not hard to believe that usable ports will appear for Librem.

As for “apps to play music”, back on my old Nokia N900 I was very satisfied with using MPD to play music, which could be readily installed on Librem’s phone without even having to port it. I also know that whipping up a new MPD client for whatever UI is not that much work at all, definitely not “millions of man hours”.

Different approaches: Daniel Micay's https://grapheneos.org is a step in the direction you're looking for.

With Android 8 Google introduced Project Treble which kind of enforces that AOSP work out-of-the-box on every (!) Google Certified device. This has kick-started a popular project, phh-treble, by a senior XDA developer that I keep a keen eye on.

You could flash AOSP today on any (!) Google certified android phone that launched with Oreo+ with very few quirks, if any.

https://github.com/phhusson/treble_experimentations/wiki/Fre...

Phh-Treble author here.

First, to outside looks, your post might be confusing: GrapheneOS and (Phh-)Treble are independent, and complementary. GrapheneOS is focusing on hardening Android (and tbh I'm impressed by Daniel Micay's work). Phh-Treble is about bringing AOSP (the fully opensource Android provided by Google) to the maximum of post-Oreo devices, but using OEM's proprietary drivers. It is technically possible to make a Phh-Treble GrapheneOS, to have an hardened Android that runs on any post-oreo Android device, though that's probably an heresy.

Going back to the subject, I have to say that (one of) my goal when doing Phh-Treble is that some people use my work to create a whole new "Smartphone OS". There are many restrictions, and such a "new Smartphone OS" would probably need to be based on Android to be able to use Treble, but still, imagination is the limit, and you don't need to worry about the drivers! You can just create whatever you think has value, and pretty much anyone can use it straight away! And I'm not just thinking of FLOSS-oriented, privacy-focused, I'd be happy to see alternative "Smartphone OS" emerge.

Looking at Android as it is today, and the opensource apps the community has made, it is possible to make a privacy-focused "Smartphone OS" that is usable to the masses without much effort.

Some other post mentioned /e/, who are people that actually are trying this route. (Though they are totally ignore Treble for the moment...) Though they get quite a bad reputation, for fairly good reason (for instance there are few google "trackers" inside AOSP. they are easy to remove, yet /e/ still have them)

I personly have tried to maintain a distribution of AOSP with pre-installed FLOSS apps to get out of Google's ecosystem, but I haven't had users for it.

Back to the subject of Purism and Librem 5, even though I'm happy such an initiative exists, I feel like they are trying to do too many things at the same time. In my understanding, they are trying to: 1. Make a secure hardware (cf modem over USB) 2. Create a brand new Smartphone OS, going down to drivers, up to applications themselves, basically from scratch. 3. Make a device that runs mainline kernel.

All of those steps can be done independently, and have much higher chances of success if done independently. Also the skill-set required for those are extremely different

> and such a "new Smartphone OS" would probably need to be based on Android to be able to use Treble

Not really, one could most likely use libhybris and Halium to run Project Treble's userspace parts on a fairly ordinary Linux distribution. In fact, I'm surprised that people aren't starting to test this using the likes of Debian, or Arch, or even pmOS.

(One of the remaining issues is that Project Treble images aren't really as standard or unified as people assume them to be, there are a few varieties based on architecture (32- vs. 64-bit) the "hardware-native" Android version (Android 7, 8, 9, 10) that ships on the device, and "A-only" vs. "A+B" booting scheme. But it sure beats having to use one image per phone model, and having to include proprietary blobs in the image.)

Android is a bit of a siren... since there are many devices on current hardware working great, it looks like it should be possible to be the starting point for a lovely FOSS solution.

But it isn't, due to the Android approach of piling together unmaintainable vendor junk like gpu driver and sensors on old kernel that doesn't work with FOSS gpu apis, radioactive horror story wifi / bt stack using non-upstream apis. The different kernels as a whole are individual flies in amber that are impossible to keep working on newer upstream basis.

Therefore your 'secure FOSS phone' becomes the usual Android security apocalypse as soon as the vendor stops patching the security holes found monthly; that's if your vendor even bothered patching and updating those pieces quarterly or even once.

Purism got it right that there's no way to get the needed result - that it's like putting linux on your x86_64 laptop - out of Android / existing devices. The story seems to be about whether their laptop business and the kickstarter gave them enough runway and ability to pay suppliers up front for initial production.

> But it isn't, due to the Android approach of piling together unmaintainable vendor junk like gpu driver and sensors on old kernel that doesn't work with FOSS gpu apis

That's not the Android approach, it's just the embedded-on-ARM approach that Android inherited wholesale. Pre-Android Linux mobile/embedded OS's were just as bad. In fact, we're starting to see some improvements. The SoC's used in the latest Google Pixel (3 and 4) phones are getting mainline support in the Linux kernel.

Could Treble enable a containerized environment for OSS distributions on certified Android-shipping hardware?

I'm thinking of something using an upstream kernel with cgroups and other required options to run containers enabled, libhybris or similar for low-level drivers.

There would be a default e911-capable dialer that would provide basic phone capabilities when other containers aren't running.

The containers would share fullscreen access to a wayland socket or similar arbiter of the display device.

Users could support Android in a container, and any X or wayland-based userland.

> smart engineers from Google

Questionable.

> well-tested and maintained

Not really.

> well-documented

Not really.

> has permissions and isolation for apps which Debian doesn't have

Having compared google play and the apt-get ecosystem, I cannot trust the first.

Also, Debian has seccomp, cgroups and the tooling required to provide very fine-grained access control.

> has several app stores including FDroid and lots of apps made by independent developers

True

> Are there some technical or licensing issues

Concentration of power; monopoly; corporate surveillance

> Is writing in Java less productive than in C/C++/GTK or whatever they use in Ubuntu?

There is no "they use in Ubuntu". It's a distribution. It benefits from application written in two dozen languages and most people don't want to rewrite applications in java.

> UPD: Also 3 Gb of RAM might be not enough for Debian/Ubuntu based OS.

Nonsense. I was using it with 32MB of RAM. Now 4 and I have free memory while running 2 browsers.

Because the whole point is to escape the Android monoculture.

I thought the whole point was to have an open-source, hackable device from top to bottom.

It's a red flag when you have multiple areas you're trying to differentiate in with one product. Sometimes you can hit two birds with one elegant stone. Sometimes the two goals are so inextricable that you have no other choice. Most of the time, it's just a bad idea.

Yes, that too. I just don't consider Android hackable enough for me. Too constrained by design choices of others.

And there are plenty of unlocked Android devices out there that users can modify already.

That might be not easy. Microsoft have failed to do this as I understand, though they had invested a lot of money into Windows Mobile.

You can escape the Android monoculture in different ways.

Creating the clone of the whole business model as MS tried may be one way.

But I think a single lone dev can probably manage to make an app that will provide UI to call/sms/manage contacts, stream some frames from camera to display, and generally anything s/he dreams up on top. It can be as simple as a single app, that allows to play with interesting concepts like running everything on a PostgreSQL database runing on the phone and replicated to VPS or whatever.

There's nothing all that time intensive/insurmountable about that.

And if single dev can do that, more can be done by a community. I certainly don't care about creating a generic app ecosystem or some such. What I care about is experimenting with reducing the bloat as much as possible, and very tight integration of everything, even as much as having things that are typically in separate apps integrated in a single UI app, with all the possibilities that come from that.

All the more reason.

There is also the /e/ initiative: https://e.foundation

Its not for nothing that Debian is called the Universal operating system. Last I checked, laptops on the International Space Station weren't said to be running Android, or even AOSP. They were in fact running Debian.

> has permissions and isolation for apps which Debian doesn't have

"Debian buster has AppArmor enabled per default. AppArmor is a mandatory access control framework for restricting programs' capabilities (such as mount, ptrace, and signal permissions, or file read, write, and execute access) by defining per-program profiles. ..."

> Why don't they want to use at least Dalvik...

Dalvik is dead anyway. Modern AOSP versions use ART.

Because Android, even with all those apps is still severely limited to what you can do compared with an actual Linux distribution.

Then the next problem is that Android itself is a mess to work with, it's not designed with an open-source community in mind, the barrier is high to make it work for this kind of use case.

Not sure what you mean by "not near as polished" but reading it as "nowhere near as polished for mobile devices" perhaps.