Purism’s Librem 5 phone starts shipping—a fully open GNU/Linux phone (Ars Technica)

Posted Sep 27, 2019 20:16 UTC (Fri) by mgedmin (subscriber, #34497)
Parent article: Purism’s Librem 5 phone starts shipping—a fully open GNU/Linux phone (Ars Technica)

If there's one thing that Nokia's N900/N9 phones taught me, it's that apt is not the right tool for smartphone app distribution. It does too much work and is therefore slow.

Purism’s Librem 5 phone starts shipping—a fully open GNU/Linux phone (Ars Technica)

Posted Sep 28, 2019 1:15 UTC (Sat) by intgr (subscriber, #39733) [Link] (12 responses)

Have you ever tried using Google Play Store to update apps on Android? It can take 10 minutes to update a handful of "apps" on modern phone hardware (with 2019 SSD-like phone disks, not the N900 from TEN YEARS AGO!)

Surely the *performance* of apt can't be a reason. Far more likely it was the political and financial alignment of arbitrary "app stores" to proprietary app vendors.

Purism’s Librem 5 phone starts shipping—a fully open GNU/Linux phone (Ars Technica)

Posted Sep 28, 2019 2:18 UTC (Sat) by m4rtink (guest, #95458) [Link] (1 responses)

Sailfish OS has been using RPMs on mobile devices from the start (late 2013) for both OS & third party apps and it works well. Sytem upgrades are also RPM based and use pretty much the same technique Fedora and other distros use - reboot into a minimal systemd target.

So a regular Linux distro packaging format can certainly be used on mobile devices, you just need to select the right one.

Purism’s Librem 5 phone starts shipping—a fully open GNU/Linux phone (Ars Technica)

Posted Oct 1, 2019 14:32 UTC (Tue) by walters (subscriber, #7396) [Link]

Fedora has two different update mechanisms for host systems - there's your traditional dnf/yum and system-update; we also ship rpm-ostree for Fedora CoreOS and Fedora Silverblue which unifies online/offline updates, is image (OSTree) based and not package-based by default, is also fully transactional, etc.

Purism’s Librem 5 phone starts shipping—a fully open GNU/Linux phone (Ars Technica)

Posted Sep 28, 2019 2:30 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (9 responses)

The problem with APT is that it can take quite a bit of time to resolve dependencies. Google Store updates are very fast - it's just writing a new copy of the app and doing some metadata updates. Additionally, it might involve AoT compilation of DEX code for some apps.

Purism’s Librem 5 phone starts shipping—a fully open GNU/Linux phone (Ars Technica)

Posted Oct 1, 2019 21:13 UTC (Tue) by jccleaver (guest, #127418) [Link] (7 responses)

> The problem with APT is that it can take quite a bit of time to resolve dependencies. Google Store updates are very fast - it's just writing a new copy of the app and doing some metadata updates. Additionally, it might involve AoT compilation of DEX code for some apps.

I really don't understand the demands for time sensitivity on this -- either in the mobile space or on distros, to be frank. I mean, how often do you have to synchronously perform an update except in a framework where you're being paid to make sure that it works successfully?

On mobile devices, just say "updating in background" and be done with it. Half the time the end user isn't going to know or care that it's slow, as that's always a possibility depending on network downlink speed (and customers rarely have detailed visibility into what's going on anyway).

On Linux distros, sure speed is nice, but I find it hard to imagine a situation where I actually have to care about apt or yum's dependency resolution and calculation. Certainly it was never degenerate enough that I felt that the switch to DNF was worth it, even though they kept on using that as a selling point. ("Seth is sadly no longer available to support this software" is a reason; "RPM calculation is 15% faster" is not, if it comes with bugs thanks to a codebase swap.)

Purism’s Librem 5 phone starts shipping—a fully open GNU/Linux phone (Ars Technica)

Posted Oct 1, 2019 21:47 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses)

In my personal experience in one case APT took about 10 minutes to resolve deps during an especially hairy Debian upgrade. On a powerful desktop computer. It'd probably drain battery completely if you try it on a phone.

> On mobile devices, just say "updating in background" and be done with it. Half the time the end user isn't going to know or care that it's slow, as that's always a possibility depending on network downlink speed (and customers rarely have detailed visibility into what's going on anyway).
So you come to New York and want to download a bus map application. Would you be OK with waiting for a couple of hours to do it?

Then there's a question of atomicity. Phones are famous for dying in various interesting ways and you really need to make sure that your package manager can recover from a partial installation. Neither APT nor RPM can do this completely reliably.

Purism’s Librem 5 phone starts shipping—a fully open GNU/Linux phone (Ars Technica)

Posted Oct 1, 2019 22:11 UTC (Tue) by jccleaver (guest, #127418) [Link] (3 responses)

> In my personal experience in one case APT took about 10 minutes to resolve deps during an especially hairy Debian upgrade. On a powerful desktop computer. It'd probably drain battery completely if you try it on a phone.

That's definitely pretty pathological -- I don't think I've ever had anything take longer than a minute and a half with pre-dnf yum, and that was on a full Fedora version upgrade.

It might have happened once on an attempted EL5-EL6 upgrade, but that's kind of orthogonal, though. The parallel to that would be an Android System Update, and my LG is usually out of commission for a good 30m for that no matter what.

> So you come to New York and want to download a bus map application. Would you be OK with waiting for a couple of hours to do it?

No, of course not. But the difference between a 30 second download and 1 minute install and 45 second download and 2 minute install is not something super critical.

> Then there's a question of atomicity. Phones are famous for dying in various interesting ways and you really need to make sure that your package manager can recover from a partial installation. Neither APT nor RPM can do this completely reliably.

This is a good point, but it's also something that could be dealt with through tweaks into packaging for that "distro" and other concerns. Power outages during any script will be a bad thing, but will be a bad thing in most any case.

I'm not suggesting phones move to rpm/dpkg absent a compelling reason (running an OS that uses it is a compelling reason, IMO), I'm just saying that I don't get the demand for it at the expense of stability. I've been running RH back to the RHL6 days and yum update speed (even old school yum) has never been on my radar of things to care about.

Purism’s Librem 5 phone starts shipping—a fully open GNU/Linux phone (Ars Technica)

Posted Oct 1, 2019 22:32 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

> That's definitely pretty pathological -- I don't think I've ever had anything take longer than a minute and a half with pre-dnf yum, and that was on a full Fedora version upgrade.
This was Debian upgrade from stable to unstable, with many pinned packages and backports. So I guess it's probably not very representative, but on the other hand, I wouldn't be surprised if it's possible to get into this state more easily.

> It might have happened once on an attempted EL5-EL6 upgrade, but that's kind of orthogonal, though. The parallel to that would be an Android System Update, and my LG is usually out of commission for a good 30m for that no matter what.
My Pixel was able to update itself to a new Android major version in less than 5 min downtime, which I consider quite impressive.

> This is a good point, but it's also something that could be dealt with through tweaks into packaging for that "distro" and other concerns. Power outages during any script will be a bad thing, but will be a bad thing in most any case.
Or perhaps by switching to a different packages, like Snap?

Purism’s Librem 5 phone starts shipping—a fully open GNU/Linux phone (Ars Technica)

Posted Oct 6, 2019 16:50 UTC (Sun) by jospoortvliet (guest, #33164) [Link] (1 responses)

The smartest move would be, if you're putting in so much effort in building a phone OS anyway, to fix APT - do what Red Hat did, take libsolv from the openSUSE folks. As openSUSE systems typically have over 20 repositories enabled, with some users running over than 200 repo's enabled*, zypper was early in its life confronted with the fact that it needed a much better solver than what apt and yum were getting away with. So, the story goes, SUSE management tasked the compiler developer team to develop a solver library that the zypper team could use. They build one. It was fast. End of story.

You know, it's open source. It can be adopted, as Red Hat did show. They still didn't do a very good job if you ask me (they just used the solver, not all of zypper, and dnf is quite an ugly pig compared to the easy cli of zypper) but it was a big improvement over the older versions. And while it'd be smart to just port over all of zypper (nicest package manager I've ever used), just taking libsolv would already be a big step up.

* I know this sounds insane to a Debian or Fedora users. But 1. the Open Build Service makes it possible to easily keep software fully build against a range of distribution versions so there are far more repo's available with special builds, older and newer versions, daily builds and so on for openSUSE and 2. people tend to do whatever is possible and the developers haven't thought about ;-)

Purism’s Librem 5 phone starts shipping—a fully open GNU/Linux phone (Ars Technica)

Posted Oct 7, 2019 20:56 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

Sort of a tangent here, but what makes dnf a pig and zypper so nice? For a previous yum user, dnf is perfect since it's no different than before. Granted I've never used zypper itself (yast for the brief stint I had a suse install, but I went back to Fedora (10?) after a few weeks), so I just don't know.

I do agree that apt is obtuse and hard to use. The suite of tools hasn't had an overarching thought applied to it and I always have to look up how to ask things like "what files are in this package" and "what package contains this file". Auto-accept on no-new-dep installs and auto-enable of daemons has also been frustrating.

Purism’s Librem 5 phone starts shipping—a fully open GNU/Linux phone (Ars Technica)

Posted Oct 4, 2019 13:02 UTC (Fri) by foom (subscriber, #14868) [Link] (1 responses)

> In my personal experience in one case APT took about 10 minutes to resolve deps during an especially hairy Debian upgrade.

I wonder if you may have used aptitude rather than actually apt-get/apt? Aptitude has a different, and famously sluggish, dependency resolver.

Purism’s Librem 5 phone starts shipping—a fully open GNU/Linux phone (Ars Technica)

Posted Oct 4, 2019 17:47 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

I'm pretty sure it was just apt, I'm not using aptitude at all.

Purism’s Librem 5 phone starts shipping—a fully open GNU/Linux phone (Ars Technica)

Posted Oct 4, 2019 0:42 UTC (Fri) by jschrod (subscriber, #1646) [Link]

I type this on a Pixel 3 with Android 10.

I update my apps via Google Play currently once a week. It usually needs ca. 10 minutes. My Internet connection has 100 MBit/s, so it's not a bandwidth issue.

You write that "Google Store updates are very fast". Do you mean updates via Google Play?

I don't consider them to be fast. My updates for Debian, OpenSUSE, and CentOS are much faster - via the same connection and for many more and larger packages.