[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

zstd compression for packages

On 21 March 2018 at 00:25, Steve Langasek <steve.langasek at> wrote:
> 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> 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

That's not the use case I brought up.

I said users of the devel series, aka ubuntu+1.

The compression vs download trade off, is irrelevant on the ubuntu+1
series, since the churn is so high anyway, that the only way to win,
is to not update every transition / archive push, and only
dist-upgrade weekly. And optimizing for users of ubuntu+1 is very
niche, in comparison to the stable series users.

I make no distinction among the stable series users - be that
"developers" or "not", they are all simply stable series users.