> - It would double the size of the image, uselessly or almost so for most users
This is unlikely. The uncompressed `/usr/share` folder in Tails is 1.2 GB this
is architecture independent data.
https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s11.html
The total unsquashed size is 4.1 GB, so possible image size increases 70%, but
likely arch-dependent software compresses well with its other arch pair.
> Create a lot of issues as soon as, e.g., the system starts to store
> arch-dependent files as dotfiles (think of caches or binary config files!),
> and good luck to who has to deal with that.
Arch-dependent application files and dotfiles could be written to the
Persistent Storage with permissions so only the current arch can read them.
Applications complying with XDG Base Directory Specification or FHS 3.0 will
require no intervention, besides needing to install the software for both
arches during separate sessions, although installing both (if both exist) could
be automated.
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
I quite like the cross-arch medium, it's ambitious but very useful.
Sent with Proton Mail secure email.
On Tuesday, February 20th, 2024 at 1:10 PM, tails-dev-requ...@boum.org
wrote:
> Send Tails-dev mailing list submissions to
> tails-dev@boum.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www.autistici.org/mailman/listinfo/tails-dev
> or, via email, send a message with subject or body 'help' to
> tails-dev-requ...@boum.org
>
> You can reach the person managing the list at
> tails-dev-ow...@boum.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Tails-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Tails for arm64 (with support for Apple Silicon)
> (noisyc...@tutanota.com)
> 2. Tor Browser 13.0.10 (Android, Windows, macOS, Linux)
> (Richard Pospesel)
> 3. Re: Release schedule for Tails 6.0 (anonym)
>
>
> --
>
> Message: 1
> Date: Mon, 19 Feb 2024 20:21:48 +0100 (CET)
> From: noisyc...@tutanota.com
> To: "David A. Wheeler via Tails-dev" tails-dev@boum.org
>
> Cc: The Tails public development discussion list tails-dev@boum.org,
>
> "David A. Wheeler" dwhee...@dwheeler.com
>
> Subject: Re: [Tails-dev] Tails for arm64 (with support for Apple
> Silicon)
> Message-ID: nr1oieq--...@tutanota.com
>
> Content-Type: text/plain; charset=UTF-8
>
> Hi David,
>
> Yes, I thought you'd already mentioned that. The quite long email I sent last
> week detailing some of the differences between the Apple Silicon and
> Raspberry Pi builds was also in response to you.
>
> Something which I didn't address there is the possibility of cross-arch (!)
> images. Although I believe literally no distribution in human history has
> attempted something like this, I think that, paradoxically, building an
> arm64+x86_64 live image of Tails might be easier than building an image that
> works properly on two arm64 platforms with conflicting software requirements.
> If two platforms, one x86_64 and one arm64, boot via grub-efi at?UEFI's
> removable path, then the latter is different for the two architectures
> (EFI/BOOT/BOOTAA64.EFI for arm64 and EFI/BOOT/BOOTX64.EFI for x86_64), so the
> two boot paths wouldn't conflict with each other and could coexist on the
> same medium. Each version of grub could then be configured to load the kernel
> and initramfs for its architecture, and live-boot (I think this is the right
> component) could be configured (or tweaked) to load the squashfs filesystem
> from an arch-specific path.
>
> As for persistence, one could keep the behavior of arch-dependent and
> arch-independent files separate. For instance, one could share dotfiles,
> network configurations, greeter settings, etc. between architectures and
> create two separate "additional software" repositories on persistence
> storage, one for each arch.
>
>
> A few downsides to this approach:
>
> - It would double the size of the image, uselessly or almost so for most users
> - It would require an almost-complete rewrite of the image-building process
> (live-build is unable to build this kind of arch-hybrid image)
> - It still doesn't solve the issue of software incompatibilities between
> different arm64 hardware (see one of my previous emails for details on this),
> which of course has a higher priority and may not have a solution at all
> - Sure as hell it would create a lot of issues as soon as, e.g., the system
> starts to store arch-dependent files as dotfiles (think of caches or binary
> config files!), and good luck to who has to deal with that
>
>
> In the end it would probably be easier to make "Backup Persistent Storage"
> selective and allow the user to backup arch-independent files to a USB drive
> hosting a version of Tails for a different arch.
>
> Best,
>
> NC
>
>
>
