Project

General

Profile

Feature #15288

Document tricks for power users vs. bigger downloads for automatic upgrade

Added by anonym almost 2 years ago. Updated 17 days ago.

Status:
Confirmed
Priority:
Normal
Assignee:
Category:
Installation
Target version:
Start date:
02/05/2018
Due date:
% Done:

0%

Feature Branch:
feature/15281-single-squashfs-diff
Type of work:
User interface design
Blueprint:
Starter:
Affected tool:

Description

Doing a manual upgrade (not including IUKs) will make the IUKs you download for the next release smaller. Power users might want to know about this so they can optimize their bandwidth usage. And they (e.g. if they are an instructor) can tell users with such needs about it.

base.svg View (43.9 KB) sajolida, 01/06/2020 02:17 PM


Related issues

Related to Tails - Feature #12493: Have Tails Upgrader automatically point to manual upgrade if running from an old version Confirmed 04/29/2017
Related to Tails - Feature #15281: Stack one single SquashFS diff when upgrading Resolved 04/13/2016
Blocks Tails - Feature #15289: Make Tails Upgrader suggest a manual upgrade to decrease future IUK sizes Confirmed 02/05/2018
Blocked by Tails - Feature #16991: Cognitive walkthrough of automatic and manual upgrades Resolved

History

#1 Updated by anonym almost 2 years ago

  • Blocked by Feature #15281: Stack one single SquashFS diff when upgrading added

#2 Updated by anonym almost 2 years ago

  • Blocks Feature #15289: Make Tails Upgrader suggest a manual upgrade to decrease future IUK sizes added

#3 Updated by intrigeri almost 2 years ago

  • Subject changed from Document tricks for power users vs 1BigIUK to Document tricks for power users vs. bigger downloads for automatic upgrade

#4 Updated by anonym about 1 year ago

  • Target version changed from 2018 to 2019

#5 Updated by sajolida 6 months ago

  • Assignee changed from anonym to sajolida
  • Parent task set to #15281

Let's put it under #15281 as one of the doc updates.

#6 Updated by sajolida 2 months ago

  • Target version changed from 2019 to Tails_4.2

Endless upgrades will be in 4.2.

#7 Updated by intrigeri about 2 months ago

sajolida wrote:

Endless upgrades will be in 4.2.

FWIW, the first time users may need this doc is when upgrading to 4.3. So it seems to me that if you don't do this in time for 4.2, the only drawback is that these tricks won't be documented in the offline version of the doc that's included in 4.2.

#8 Updated by sajolida about 2 months ago

  • Blocked by Feature #16991: Cognitive walkthrough of automatic and manual upgrades added

#9 Updated by sajolida about 2 months ago

Sure. I'm doing pretty good in terms of busyness and budget right now so the earlier the better :)

@intrigeri: The best place to display this information might actually be in the interface itself (in addition to the doc). Is it conceivable to display a string about this in Tails Upgrader when, let's say, it detects that the base version on the USB stick is more than N versions old or the IUK is more than N MB or N % of a full image? With no pressure, it could be either for Sponsor 2 or stored in #14544 for a later point in time.

#10 Updated by sajolida about 2 months ago

  • Related to Feature #12493: Have Tails Upgrader automatically point to manual upgrade if running from an old version added

#11 Updated by intrigeri about 1 month ago

  • Type of work changed from End-user documentation to User interface design

Is it conceivable to display a string about this in Tails Upgrader when, let's say, it detects that the base version on the USB stick is more than N versions old or the IUK is more than N MB or N % of a full image?

Yes. More specifically:

  • more than N versions old: with a rough approximation, it's doable, but requires more work than the other options (and gives less relevant/accurate feedback to the user IMO)
  • more than X MB: it's the easiest to code initially; but we need to figure out what N should be, and possibly to update this value later
  • more than Y % of a full image: doable

So I propose we go with "more than X MB" for now, computing the hard-coded X value based on "Y % of a full image".
And to compute this value, I propose we wait until we've built IUKs from 4.0 to 4.2 and from 4.0 to 4.3, so we have data about what size they are in practice.

But I guess the UX design can be done without knowing this value yet.

With no pressure, it could be either for Sponsor 2 or stored in #14544 for a later point in time.

ACK. I had tentatively put this under #15281 under the assumption this would "only" require doc work. Given this requires UX design and new code, I doubt it'll fit into the sponsor deadlines for #15281. I won't have time to implement this in 4.2 so no big hurry on your side to give me the UX design bits I need.

#12 Updated by sajolida about 1 month ago

Makes sense.

I'll propose a design when working on the doc itself in time for 4.2.

#13 Updated by intrigeri about 1 month ago

  • Parent task deleted (#15281)

Rationale: I would like #15281 to track the subset of the "single SquashFS diff" work that has to go in 4.2 (and that will be ready for review very soon now).

#14 Updated by intrigeri about 1 month ago

  • Related to Feature #15281: Stack one single SquashFS diff when upgrading added

#15 Updated by intrigeri about 1 month ago

  • Feature Branch set to feature/15281-single-squashfs-diff

#16 Updated by intrigeri about 1 month ago

I just (re)discovered #15289. Reverse engineering how these 2 tickets relate to each other, it seems to me that the idea was:

  1. First, document the manual upgrade trick via #15288.
  2. Second, design & code the Upgrader UI that will point to that new piece of doc when relevant.

This seems needlessly detailed to me and embeds assumptions that may or may not hold true once we dive into this. For example, it could be that the Upgrader UI can convey all the needed info itself, without having to point to a new dedicated doc page. We'll see.
So for now, I'll ignore #15289: let's continue the discussion and UX design that started here already :)

#17 Updated by sajolida 18 days ago

  • File base.svg added

I drafted (exciting) plans for this doc but I don't think I should work on this now and rather focus on #9814 in January.

See drawings in attachment :)

I'll introduce the term "base version" to refer to the version that was originally installed. People can boost their base version with either a manual upgrade or by cloning.

@intrigeri: I was wondering how people could check which base version they have installed on their USB stick, for example if a trainer wants to know whether it's worth upgrading someone by cloning. At first sight, it doesn't seem obvious from the content of the system partition. I didn't update to 4.1 because of #17316 and I'll have another look once I upgraded to 4.2 but I thought that you might have an idea already. Given the audience for this doc, a short command line would do I think.

#18 Updated by intrigeri 18 days ago

intrigeri: I was wondering how people could check which base version they have installed on their USB stick

This should do the trick:

grep '^TAILS_VERSION_ID=' \
/lib/live/mount/rootfs/filesystem.squashfs/etc/os-release

#19 Updated by sajolida 18 days ago

  • File deleted (base.svg)

#20 Updated by sajolida 18 days ago

#21 Updated by sajolida 17 days ago

  • Target version changed from Tails_4.2 to Tails_4.3

Also available in: Atom PDF