ISO image: to xz or not to xz?

ISO image: to xz or not to xz?

[Ludovic Courtès]

Hi!

Here’s the installation ISO image (with built-in zlib compression):

--8<---------------cut here---------------start------------->8---
$ ./pre-inst-env guix system image -t iso9660 gnu/system/install.scm
/gnu/store/kg63cyg94dmy9x7rpxf5ycn97sqx1ndl-image.iso
$ xz < /gnu/store/kg63cyg94dmy9x7rpxf5ycn97sqx1ndl-image.iso > /tmp/t.iso.xz
$ du -h /tmp/t.iso.xz
496M	/tmp/t.iso.xz
$ du -h /gnu/store/kg63cyg94dmy9x7rpxf5ycn97sqx1ndl-image.iso
647M	/gnu/store/kg63cyg94dmy9x7rpxf5ycn97sqx1ndl-image.iso
--8<---------------cut here---------------end--------------->8---

The xz-compressed image is 23% smaller, which is not negligible.
However, it’s apparently quite unusual to distribute compressed ISOs and
some services/tools such as libosinfo require plain ISOs (uncompressed).

Should we distribute the installation ISO without xz compression?

That could be done in respect of the string freeze (removing text, not
modifying it), though the relevant section would look odd because it’d
have a single step (info "(guix) USB Stick and DVD Installation").

Or maybe it’s safer to postpone that question until the next release.

What do people think?

Ludo’.

Re: ISO image: to xz or not to xz?

[Vincent Legoll]

On Wed, Apr 28, 2021 at 10:18 PM Ludovic Courtès <ludo@gnu.org> wrote:
> What do people think?

I'd say distribute both, so the bandwidth-starved can get the
smaller, and the CPU-starved can get the uncompressed one.

-- 
Vincent Legoll

Re: ISO image: to xz or not to xz?

[Simon Josefsson via Development of GNU Guix and the GNU System distribution.]

[-- Attachment #1: Type: text/plain, Size: 310 bytes --]

Ludovic Courtès <ludo@gnu.org> writes:

> Should we distribute the installation ISO without xz compression?

Yes.  I've always found that annoying with Guix, because it adds one
more step to the download and PGP verification process.  All of Debian,
Ubuntu, NixOS, etc distribute plain ISO's.

/Simon

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

[PATCH] maint: Do not xz-compress ISO images.

[Ludovic Courtès]

The xz-compressed image is 23% smaller than the original ISO image (with
built-in zlib compression), but the extra decompression step is
unconventional and often a hindrance for users.  See discussion at
<https://lists.gnu.org/archive/html/guix-devel/2021-04/msg00497.html>.

* Makefile.am (release): Do not compress ISO images.
* doc/guix.texi (USB Stick and DVD Installation): Remove ".xz" suffix
from URL and file name.
(Copying to a USB Stick, Burning on a DVD): Remove introductory words,
@enumerate, and first item.
---
 Makefile.am   |  6 +++---
 doc/guix.texi | 30 +++---------------------------
 2 files changed, 6 insertions(+), 30 deletions(-)

Hi!

This takes the simple step of providing plain ISOs only (rather than
.iso + .iso.xz as some suggested).

One advantage is that, unless I’m mistaken, this can be done without
breaking string freeze.

We’ll also have to update <https://guix.gnu.org/en/download> on the
release day.

Thoughts?

Ludo’.

diff --git a/Makefile.am b/Makefile.am
index 8d059eb033..623b1c497f 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -886,9 +886,9 @@ release: dist-with-updated-version all
 	    echo "failed to produced Guix installation image for $$system" >&2 ;	\
 	    exit 1 ;									\
 	  fi ;										\
-	  xz < "$$image" > "$(releasedir)/$(GUIX_SYSTEM_IMAGE_BASE).$$system.iso.xz.tmp" ;	\
-	  mv "$(releasedir)/$(GUIX_SYSTEM_IMAGE_BASE).$$system.iso.xz.tmp"		\
-	     "$(releasedir)/$(GUIX_SYSTEM_IMAGE_BASE).$$system.iso.xz" ;		\
+	  cp "$$image" "$(releasedir)/$(GUIX_SYSTEM_IMAGE_BASE).$$system.iso.tmp" ;	\
+	  mv "$(releasedir)/$(GUIX_SYSTEM_IMAGE_BASE).$$system.iso.tmp"			\
+	     "$(releasedir)/$(GUIX_SYSTEM_IMAGE_BASE).$$system.iso" ;			\
 	done
 # Generate the VM images.
 	for system in $(GUIX_SYSTEM_VM_SYSTEMS) ; do					\
diff --git a/doc/guix.texi b/doc/guix.texi
index 2fe7ad3a2a..3460c58cbc 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -2099,7 +2099,7 @@ about their support in GNU/Linux.
 
 An ISO-9660 installation image that can be written to a USB stick or
 burnt to a DVD can be downloaded from
-@indicateurl{@value{BASE-URL}/guix-system-install-@value{VERSION}.x86_64-linux.iso.xz},
+@indicateurl{@value{BASE-URL}/guix-system-install-@value{VERSION}.x86_64-linux.iso},
 where you can replace @code{x86_64-linux} with one of:
 
 @table @code
@@ -2115,8 +2115,8 @@ Make sure to download the associated @file{.sig} file and to verify the
 authenticity of the image against it, along these lines:
 
 @example
-$ wget @value{BASE-URL}/guix-system-install-@value{VERSION}.x86_64-linux.iso.xz.sig
-$ gpg --verify guix-system-install-@value{VERSION}.x86_64-linux.iso.xz.sig
+$ wget @value{BASE-URL}/guix-system-install-@value{VERSION}.x86_64-linux.iso.sig
+$ gpg --verify guix-system-install-@value{VERSION}.x86_64-linux.iso.sig
 @end example
 
 If that command fails because you do not have the required public key,
@@ -2140,17 +2140,6 @@ It is meant to be copied @emph{as is} to a large-enough USB stick or DVD.
 
 @unnumberedsubsec Copying to a USB Stick
 
-To copy the image to a USB stick, follow these steps:
-
-@enumerate
-@item
-Decompress the image using the @command{xz} command:
-
-@example
-xz -d guix-system-install-@value{VERSION}.x86_64-linux.iso.xz
-@end example
-
-@item
 Insert a USB stick of 1@tie{}GiB or more into your machine, and determine
 its device name.  Assuming that the USB stick is known as @file{/dev/sdX},
 copy the image with:
@@ -2161,21 +2150,9 @@ sync
 @end example
 
 Access to @file{/dev/sdX} usually requires root privileges.
-@end enumerate
 
 @unnumberedsubsec Burning on a DVD
 
-To copy the image to a DVD, follow these steps:
-
-@enumerate
-@item
-Decompress the image using the @command{xz} command:
-
-@example
-xz -d guix-system-install-@value{VERSION}.x86_64-linux.iso.xz
-@end example
-
-@item
 Insert a blank DVD into your machine, and determine
 its device name.  Assuming that the DVD drive is known as @file{/dev/srX},
 copy the image with:
@@ -2185,7 +2162,6 @@ growisofs -dvd-compat -Z /dev/srX=guix-system-install-@value{VERSION}.x86_64-lin
 @end example
 
 Access to @file{/dev/srX} usually requires root privileges.
-@end enumerate
 
 @unnumberedsubsec Booting
 
-- 
2.31.1

[bug#48173] [PATCH] maint: Do not xz-compress ISO images.

[Julien Lepiller]

Le Sun,  2 May 2021 23:16:48 +0200,
Ludovic Courtès <ludo@gnu.org> a écrit :

> The xz-compressed image is 23% smaller than the original ISO image
> (with built-in zlib compression), but the extra decompression step is
> unconventional and often a hindrance for users.  See discussion at
> <https://lists.gnu.org/archive/html/guix-devel/2021-04/msg00497.html>.
> 
> * Makefile.am (release): Do not compress ISO images.
> * doc/guix.texi (USB Stick and DVD Installation): Remove ".xz" suffix
> from URL and file name.
> (Copying to a USB Stick, Burning on a DVD): Remove introductory words,
> @enumerate, and first item.

I have to ask about the patch title: what does "maint" mean?

> ---
>  Makefile.am   |  6 +++---
>  doc/guix.texi | 30 +++---------------------------
>  2 files changed, 6 insertions(+), 30 deletions(-)
> 
> Hi!
> 
> This takes the simple step of providing plain ISOs only (rather than
> .iso + .iso.xz as some suggested).
> 
> One advantage is that, unless I’m mistaken, this can be done without
> breaking string freeze.
> 
> We’ll also have to update <https://guix.gnu.org/en/download> on the
> release day.
> 
> Thoughts?
> 
> Ludo’.
> 
> diff --git a/Makefile.am b/Makefile.am
> index 8d059eb033..623b1c497f 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -886,9 +886,9 @@ release: dist-with-updated-version all
>  	    echo "failed to produced Guix installation image for
> $$system" >&2 ;	\ exit 1 ;
> 					\ fi ;
> 							\
> -	  xz < "$$image" >
> "$(releasedir)/$(GUIX_SYSTEM_IMAGE_BASE).$$system.iso.xz.tmp"
> ;	\
> -	  mv
> "$(releasedir)/$(GUIX_SYSTEM_IMAGE_BASE).$$system.iso.xz.tmp"
> 	\
> -
> "$(releasedir)/$(GUIX_SYSTEM_IMAGE_BASE).$$system.iso.xz" ;
> 	\
> +	  cp "$$image"
> "$(releasedir)/$(GUIX_SYSTEM_IMAGE_BASE).$$system.iso.tmp" ;	\
> +	  mv
> "$(releasedir)/$(GUIX_SYSTEM_IMAGE_BASE).$$system.iso.tmp"
> 		\
> +	     "$(releasedir)/$(GUIX_SYSTEM_IMAGE_BASE).$$system.iso"
> ;			\ done
>  # Generate the VM images.
>  	for system in $(GUIX_SYSTEM_VM_SYSTEMS) ; do
> 			\ diff --git a/doc/guix.texi b/doc/guix.texi
> index 2fe7ad3a2a..3460c58cbc 100644
> --- a/doc/guix.texi
> +++ b/doc/guix.texi
> @@ -2099,7 +2099,7 @@ about their support in GNU/Linux.
>  
>  An ISO-9660 installation image that can be written to a USB stick or
>  burnt to a DVD can be downloaded from
> -@indicateurl{@value{BASE-URL}/guix-system-install-@value{VERSION}.x86_64-linux.iso.xz},
> +@indicateurl{@value{BASE-URL}/guix-system-install-@value{VERSION}.x86_64-linux.iso},
>  where you can replace @code{x86_64-linux} with one of:

Sorry, this actually breaks string freeze. Now for something like this,
we could grant an exception? It's not like it's too hard to fix, even
manually and even if you don't know the language :)

>  
>  @table @code
> @@ -2115,8 +2115,8 @@ Make sure to download the associated
> @file{.sig} file and to verify the authenticity of the image against
> it, along these lines: 
>  @example
> -$ wget
> @value{BASE-URL}/guix-system-install-@value{VERSION}.x86_64-linux.iso.xz.sig
> -$ gpg --verify
> guix-system-install-@value{VERSION}.x86_64-linux.iso.xz.sig +$ wget
> @value{BASE-URL}/guix-system-install-@value{VERSION}.x86_64-linux.iso.sig
> +$ gpg --verify
> guix-system-install-@value{VERSION}.x86_64-linux.iso.sig @end example

Even that example actually breaks it: examples can contain comments
that should be translated, so po4a lets translators do whatever they
want with them. Again, it's easy to fix.

> If that command fails because you do not have the required public
> key, @@ -2140,17 +2140,6 @@ It is meant to be copied @emph{as is} to
> a large-enough USB stick or DVD. @unnumberedsubsec Copying to a USB
> Stick 
> -To copy the image to a USB stick, follow these steps:
> -
> -@enumerate
> -@item
> -Decompress the image using the @command{xz} command:
> -
> -@example
> -xz -d guix-system-install-@value{VERSION}.x86_64-linux.iso.xz
> -@end example
> -
> -@item

Now removing text is fine :)

LGTM, but what should we do about the strings?

[bug#48173] [PATCH] maint: Do not xz-compress ISO images.

[François]

On Mon, May 03, 2021 at 02:15:22AM +0200, Julien Lepiller wrote:
> LGTM, but what should we do about the strings?

sed -i 's/\.iso\.xz/.iso/g' po/doc/guix-manual.*.po

and add that to the patch ?

(notwithstanding some misunderstanding related to how translation works
as I know nothing about that)

Re: bug#48173: [PATCH] maint: Do not xz-compress ISO images.

[Ludovic Courtès]

Hi Julien,

Julien Lepiller <julien@lepiller.eu> skribis:

>> --- a/doc/guix.texi
>> +++ b/doc/guix.texi
>> @@ -2099,7 +2099,7 @@ about their support in GNU/Linux.
>>  
>>  An ISO-9660 installation image that can be written to a USB stick or
>>  burnt to a DVD can be downloaded from
>> -@indicateurl{@value{BASE-URL}/guix-system-install-@value{VERSION}.x86_64-linux.iso.xz},
>> +@indicateurl{@value{BASE-URL}/guix-system-install-@value{VERSION}.x86_64-linux.iso},
>>  where you can replace @code{x86_64-linux} with one of:
>
> Sorry, this actually breaks string freeze. Now for something like this,
> we could grant an exception? It's not like it's too hard to fix, even
> manually and even if you don't know the language :)

In what sense does it break the string freeze?

I understand translations would appear as below 100% on Weblate, but I
checked guix.{fr,es,de}.info and they all read well after this change.

Am I missing something?

Thanks for commenting!

Ludo’.

Re: bug#48173: [PATCH] maint: Do not xz-compress ISO images.

[Julien Lepiller]

Le 3 mai 2021 11:39:03 GMT-04:00, "Ludovic Courtès" <ludo@gnu.org> a écrit :
>Hi Julien,
>
>Julien Lepiller <julien@lepiller.eu> skribis:
>
>>> --- a/doc/guix.texi
>>> +++ b/doc/guix.texi
>>> @@ -2099,7 +2099,7 @@ about their support in GNU/Linux.
>>>  
>>>  An ISO-9660 installation image that can be written to a USB stick
>or
>>>  burnt to a DVD can be downloaded from
>>>
>-@indicateurl{@value{BASE-URL}/guix-system-install-@value{VERSION}.x86_64-linux.iso.xz},
>>>
>+@indicateurl{@value{BASE-URL}/guix-system-install-@value{VERSION}.x86_64-linux.iso},
>>>  where you can replace @code{x86_64-linux} with one of:
>>
>> Sorry, this actually breaks string freeze. Now for something like
>this,
>> we could grant an exception? It's not like it's too hard to fix, even
>> manually and even if you don't know the language :)
>
>In what sense does it break the string freeze?
>
>I understand translations would appear as below 100% on Weblate, but I
>checked guix.{fr,es,de}.info and they all read well after this change.
>
>Am I missing something?

po4a is not that intelligent. The result will be either the old translated string, or the new English string.

But it's fine. We already have a similar change on version-1.3.0, so go ahead and push this, I'll take care of weblate :)

>
>Thanks for commenting!
>
>Ludo’.

bug#48173: [PATCH] maint: Do not xz-compress ISO images.

[Maxim Cournoyer]

Hi,

Julien Lepiller <julien@lepiller.eu> writes:

[...]

>>In what sense does it break the string freeze?
>>
>>I understand translations would appear as below 100% on Weblate, but I
>>checked guix.{fr,es,de}.info and they all read well after this change.
>>
>>Am I missing something?
>
> po4a is not that intelligent. The result will be either the old
> translated string, or the new English string.
>
> But it's fine. We already have a similar change on version-1.3.0, so
> go ahead and push this, I'll take care of weblate :)

I've pushed this to version-1.3.0, along a slightly edited version of a
a diff Julien shared earlier that fixed an issue with building the doc
after recent changes.

Thank you both!

Closing.

Maxim

Re: bug#48173: [PATCH] maint: Do not xz-compress ISO images.

[Ludovic Courtès]

Julien Lepiller <julien@lepiller.eu> skribis:

> I have to ask about the patch title: what does "maint" mean?

It means “maintenance”.  Some GNU packages use this convention to
categorize changes related to “maintenance” in a broad sense, things
that are not user-visible.

Thanks for paying attention.  ;-)

Ludo’.

Re: ISO image: to xz or not to xz?

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 1196 bytes --]


Ludovic Courtès <ludo@gnu.org> writes:

> Hi!
>
> Here’s the installation ISO image (with built-in zlib compression):
>
> --8<---------------cut here---------------start------------->8---
> $ ./pre-inst-env guix system image -t iso9660 gnu/system/install.scm
> /gnu/store/kg63cyg94dmy9x7rpxf5ycn97sqx1ndl-image.iso
> $ xz < /gnu/store/kg63cyg94dmy9x7rpxf5ycn97sqx1ndl-image.iso > /tmp/t.iso.xz
> $ du -h /tmp/t.iso.xz
> 496M	/tmp/t.iso.xz
> $ du -h /gnu/store/kg63cyg94dmy9x7rpxf5ycn97sqx1ndl-image.iso
> 647M	/gnu/store/kg63cyg94dmy9x7rpxf5ycn97sqx1ndl-image.iso
> --8<---------------cut here---------------end--------------->8---
>
> The xz-compressed image is 23% smaller, which is not negligible.
> However, it’s apparently quite unusual to distribute compressed ISOs and
> some services/tools such as libosinfo require plain ISOs (uncompressed).
>
> Should we distribute the installation ISO without xz compression?

Personally I think the ISO is more useful if it's published as such,
rather than an as a xz compressed file.

I believe this will make things like getting Guix through Gnome Boxes
easier, and using Guix at various hosting providers easier.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

Re: ISO image: to xz or not to xz?

[Leo Famulari]

On Wed, Apr 28, 2021 at 10:18:01PM +0200, Ludovic Courtès wrote:
> What do people think?

We've received several complaints about the images being compressed. I
guess we might as well offer it uncompressed, and maybe offer both ways.

Re: ISO image: to xz or not to xz?

[Alexandre Oliva]

On Apr 28, 2021, Ludovic Courtès <ludo@gnu.org> wrote:

> However, it’s apparently quite unusual to distribute compressed ISOs and
> some services/tools such as libosinfo require plain ISOs (uncompressed).

Indeed, install ISOs normally hold already-compressed filesystems or
files, so recompressing the .iso doesn't gain much if at all.

> Should we distribute the installation ISO without xz compression?

If the iso is so compressible, offering a compressed version for
download makes sense, but it will still be wasteful of install media.

Consider using something like a loopback-mounted squashfs for the bulk
of the data in the install media for a future release.

-- 
Alexandre Oliva, happy hacker                https://FSFLA.org/blogs/lxo/
   Free Software Activist                       GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>

Re: ISO image: to xz or not to xz?

[Leo Famulari]

On Mon, May 03, 2021 at 01:47:02PM -0300, Alexandre Oliva wrote:
> Indeed, install ISOs normally hold already-compressed filesystems or
> files, so recompressing the .iso doesn't gain much if at all.

To quote the introductory message of this thread:

"The xz-compressed image is 23% smaller, which is not negligible."

Re: ISO image: to xz or not to xz?

[Vagrant Cascadian]

[-- Attachment #1: Type: text/plain, Size: 1066 bytes --]

On 2021-05-03, Leo Famulari wrote:
> On Mon, May 03, 2021 at 01:47:02PM -0300, Alexandre Oliva wrote:
>> Indeed, install ISOs normally hold already-compressed filesystems or
>> files, so recompressing the .iso doesn't gain much if at all.
>
> To quote the introductory message of this thread:
>
> "The xz-compressed image is 23% smaller, which is not negligible."

Well, the suggestion to use squashfs does bear merit; it would require
having some type of writeable filesystem on top, such as using overlay
fs to mount the installer rootfs with squashfs for the readonly bits,
and tmpfs for the writeable bits.

As a bonus, using a tmpfs overlay would solve the issue brought up
recently by someone who tried using the same installer image multiple
times, and /gnu/store and /var/guix got out of sync due to the cow-store
only writing to the newly installed system, so that the second install
failed.

Another angle might be to use a compressable but writeable filesystem
(btrfs?).

Obviously, it requires someone to do the work to get there!


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: ISO image: to xz or not to xz?

[Tobias Geerinckx-Rice]

[-- Attachment #1: Type: text/plain, Size: 1679 bytes --]

Hi Vagrant!

Tangent: I sense some undeserved mysticism surrounding squashfs. 
It is not designed to be loop-mounted, any more than ext2 was.  It 
does not enjoy it.  People should stop doing it.

But they won't, because many distributions still insist that the 
same installer image must be both a bootable CD/DVD *and* boot 
when dd'd to a USB drive, on every PC ever made.

That ‘isohybrid’ dream justifies doing unmentionable things to an 
iso9660 file system (and only an iso9660 file system), so they 
must put the real squashfs on top of that and loop-mount it and 
ignore the screams I guess and--

...sorry; I got carried away.

Vagrant Cascadian 写道：
> Well, the suggestion to use squashfs does bear merit;

It's not a *bad* suggestion, just a bit obvious.

> it would require
> having some type of writeable filesystem on top, such as using 
> overlay
> fs to mount the installer rootfs with squashfs for the readonly 
> bits,
> and tmpfs for the writeable bits.

We've always done this.

> As a bonus, using a tmpfs overlay would solve the issue brought 
> up
> recently by someone who tried using the same installer image 
> multiple
> times, and /gnu/store and /var/guix got out of sync due to the 
> cow-store
> only writing to the newly installed system, so that the second 
> install
> failed.

...so no, it definitely wouldn't, but I think it's valuable to 
understand why you thought so!

Could you elaborate?

> Another angle might be to use a compressable but writeable 
> filesystem
> (btrfs?).

A persistently mutable . . . installation medium . . . ?

Very lost, slightly frightened,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

Re: ISO image: to xz or not to xz?

[Vagrant Cascadian]

[-- Attachment #1: Type: text/plain, Size: 2144 bytes --]

On 2021-05-03, Tobias Geerinckx-Rice wrote:
> Tangent: I sense some undeserved mysticism surrounding squashfs. 
> It is not designed to be loop-mounted, any more than ext2 was.  It 
> does not enjoy it.  People should stop doing it.

The only mysticism I see here is attributing enjoyment to a
filesystem. :)

Is mounting on a loopback device really any different from any other
block device?


> But they won't, because many distributions still insist that the 
> same installer image must be both a bootable CD/DVD *and* boot 
> when dd'd to a USB drive, on every PC ever made.

> That ‘isohybrid’ dream justifies doing unmentionable things to an 
> iso9660 file system (and only an iso9660 file system), so they 
> must put the real squashfs on top of that and loop-mount it and 
> ignore the screams I guess and--

Never heard the screams; what frequency does squashfs emit screams at?
:)

People have made it work well enough for only slightly less long than I
can remember using free software operating systems...


> Vagrant Cascadian 写道：
>> Well, the suggestion to use squashfs does bear merit;
>
> It's not a *bad* suggestion, just a bit obvious.

Fair enough.


>> it would require having some type of writeable filesystem on top,
>> such as using overlay fs to mount the installer rootfs with squashfs
>> for the readonly bits, and tmpfs for the writeable bits.
>
> We've always done this.

I *thought* so, but...


>> As a bonus, using a tmpfs overlay would solve the issue brought up
>> recently by someone who tried using the same installer image multiple
>> times, and /gnu/store and /var/guix got out of sync due to the
>> cow-store only writing to the newly installed system, so that the
>> second install failed.
>
> ...so no, it definitely wouldn't, but I think it's valuable to 
> understand why you thought so!
>
> Could you elaborate?

Mostly I was referring to:

  https://lists.gnu.org/archive/html/guix-devel/2021-04/msg00546.html

Though I haven't confirmed that behavior myself. Probably deserves a
proper bug report.


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: ISO image: to xz or not to xz?

[Tobias Geerinckx-Rice]

[-- Attachment #1: Type: text/plain, Size: 607 bytes --]

Alexandre Oliva 写道：
> Consider using something like a loopback-mounted squashfs for 
> the bulk
> of the data in the install media for a future release.

Read <https://issues.guix.gnu.org/40514>.

I did play with the obvious alternative, but got so bored -- 
squashfs is no forgotten 1990s Linux-only extension to iso9660! -- 
that saving a mere 20% more was not worth it.

By this I hope to trick you into thinking it is, and submitting a 
patch, because to do so you'd have to fix one of the Forever Bugs 
that *is* worth fixing: separate /boot support.  :-)

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]