zstd compression for packages

[Steve Langasek]

On Sat, Mar 17, 2018 at 03:09:55PM +0000, Dimitri John Ledkov wrote:
> On 16 March 2018 at 22:13, Steve Langasek <steve.langasek at ubuntu.com> wrote:
> > In other words: if we want to make this the default, we should quantify
> > Daniel's remark that he would prefer a 6% faster download over a 10% faster
> > unpack.

> Well, I think it does not make sense to think about this in absolute
> terms. Thinking about user stories is better.

Sure.

> A stable series user will be mostly upgrading packages from -security
> and -updates. The download speed and/or size of debs does not matter
> much in this case, as these are scheduled to be done in the background
> over the course of the day, via unattended upgrades download timer.
> Installation speed matters, as that is the window of time when the
> system is actually somewhat in a maintenance mode / degraded
> performance (apt is locked, there are CPU and disk-io loads).

Does unattended upgrades download both -security and -updates, or does it
only download -security?  From what I can see in
/usr/bin/unattended-upgrade, the allowed-origins check applies to both the
downloads and the installation.

So by default, increases in the download time of non-security SRUs would be
perceivable by the user (though perhaps not of interest).

> New instance initialization - e.g. spinning up a cloud instance, with
> cloud-init, and installing a bunch of things; deploying juju charm /
> conjure-up spell; configuring things with puppet / ansible / etc =>
> these are download & install heavy. However, users that do that
> heavily, will be in a corporate / bussiness / datacentre environment
> and thus it is reasonable to expect them to have either a fat internet
> pipe, and/or a local mirror. Meaning download speed & size, are not
> critical.

Generally agreed (but the assertion should still be tested, not assumed).

> Then there are devel series users, developers who do sbuild builds,
> etc. These users are most likely to be on slower home-user connections
> and watch things a lot more closely interactively, who indeed care
> about the total download+install time. These users, are most likely
> very vocal / visible, but are not ultimately the target audience as to
> why we develop Ubuntu in the first place. Thus I would be willing to
> trade personal developer/devel-series user experience, in favor of the
> stable series user. I'm not sure how much it makes sense to
> proxy/cache/local-mirror devel series, if it is only a single machine
> in use.

I disagree that we don't develop Ubuntu for developers.  The developer
desktop continues to be an important use case, and while it shouldn't
necessarily dominate every time there is tension between the desktop and
server use cases, it also shouldn't be ignored.

But furthermore, I think there's a separate use case you've not included
here, which is "client user selects a piece of software for installation and
wants to use it immediately".  In that case, the total clock time from
expression of intent, to when the package can be used, does matter.  And
it's not limited to developers of Ubuntu or people tracking the devel
series; this is relevant to the usability of the desktop in stable releases. 
It is also, I would argue, the use case that is most important in terms of
its impact on user satisfaction, because it's precisely in the critical path
of a task that has the user's attention; whereas improvements to the other
use cases may improve overall efficiency, but have little or no proximate
benefit to the human user.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20180320/be6ac8da/attachment.sig>