Hi,
(This is the last email I'll send to this thread on tor-talk.
Please follow-up where it belongs, that is on tails-dev.)
Chris wrote (13 Dec 2011 04:21:53 GMT) :
>>
>>> 1. A user should not have to download a CD from a site every time an
>>> update comes out.
>>
>> What kind of better solution are you thinking of?
>>
>> We've got an incremental upgrade system in the works:
>> https://tails.boum.org/todo/usb_install_and_upgrade/#index5h2
>>
>> Don't hesitate using the Tails communication channels to suggest
>> improvements etc.
> I think a solution with AUFS would make more sense. While there are
> some benefits initially to doing it with squashfs the compression
> gained is quickly overtaken by the amount of disk space this will
> eat up. Using AUFS with a read-only mode would be the better way to
> do it. There would be nothing left on the disk after a reboot
> (except for any encryption partitions which were mounted read/write)
> and users could still update the software through normal channels
> (apt).
Unless I misunderstood your words, Tails is already using AUFS the way
you are suggesting. Users who feel they seriously know what they're
doing, and want to take the risk, can already use APT to upgrade their
currently running system in RAM. However, we don't generally recommend
doing that for reasons I already highlighted and pointed you at.
The incremental upgrades idea I pointed you at is something entirely
different, though. It's about *persistently* upgrading a system when
a Tails point-release is out, while minimizing the amount of data that
must be downloaded. Please explain how AUFS could be used for solving
that problem, and why it would be better (size-wise, or whatever) than
the stacked SquashFS idea we've been thinking of.
>> I may be missing your point, but Tails is not a random collection of
>> packages that could be individually upgraded without any thought.
>> Tails is a carefully crafted system that aims at guaranteeing certain
>> properties. We do our best to ensure an ISO we ship meets a certain
>> specification. There is simply no possible way for us to ensure the
>> same for "that ISO plus any number of APT upgrades on top of it".
> I may not fully understand the problem here as it is not well
> explained. If I take an educated guess at where the problem lies
> I think it is nothing that can't be overcome. The "tails context" is
> a design issue and not something that can't be overcome. I believe
> the issue is mainly that Tails runs from a CD and if installed is
> using squashfs. Thus it can't be updated (except each time the
> system is booted, and even then some updates require a reboot, at
> which point those updates are lost).
This is merely implementation details. We already have a plan to fix
the "Tails is read-only" side of things (see the stacked SquashFS idea
I pointed you at). The main problem is that Tails is a full Live
system built upon a whole autonomous world (that is, Debian
repositories) that is constantly changing; again:
Tails is not a random collection of packages that could be
individually upgraded without any thought. Tails is a carefully
crafted system that aims at guaranteeing certain properties. We do
our best to ensure an ISO we ship meets a certain specification.
There is simply no possible way for us to ensure the same for "that
ISO plus any number of APT upgrades on top of it".
Please tell me what's unclear in this paragraph.
The only possible way we could propose incremental upgrades through
APT would be to manage our own APT repositories, so that we entirely
control the flow of packages that could flow into a given Tails
system. Personally, I don't think it would be worth the effort, and
I still think it makes sense to go the "incremental upgrades using
stacked SquashFS" way we've been pursuing. In any case, the APT way
would make bug reporting, reproducing, debugging and fixing much more
complicated: currently, one runs "Tails 0.9", not "Tails 0.9 plus this
and that upgrades".
Also, please be kind enough to quickly sum-up what is the exact
problem you are suggesting us to solve, so that other Tails developers
don't need to read the whole thread to (try to) understand what the
problem could be, among discussions about implementation details.
Cheers,
--
intrigeri <intrigeri@???>
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
| Who wants a world in which the guarantee that we shall not
| die of starvation would entail the risk of dying of boredom ?
