New Exherbo+musl stage: x86_64-pc-linux-musl-20160621

New Exherbo+musl stage: x86_64-pc-linux-musl-20160621

[Kylie McClain]

Hi everyone, just wanted to give an update on the status of musl on Exherbo.

I just finished the creation of a new stage completely automatically, without
any intervention on my part done other than modification of the stage creation
script. :)

This stage comes almost 6 months after the previous stage was made, and as such
provides a much more up-to-date base for people wishing to run a musl system.
So, if you're interested in coming over to Exherbo in search of musl, now's a
good chance to give it a shot. :)

The usual details:

The latest musl stage can always be found at:
https://www.somasis.com/stages/exherbo-x86_64-pc-linux-musl-current.tar.xz

Make sure to consult the install guide for Exherbo, as it's applicable to
all Exherbo stages: https://exherbo.org/docs/install-guide.html

Note that musl stages do not come with systemd. A list of alternative init
systems can be found at https://exherbo.org/docs/without-systemd.html
OpenRC is likely the best supported alternative at the moment; it's fairly
new on Exherbo but OpenRC support has been added to many packages as of late.

Download links:

https://www.somasis.com/stages/exherbo-x86_64-pc-linux-musl-20160621.tar.xz
https://www.somasis.com/stages/sha1sum

63338f9e78d0669e2456fb3112c60d055bd4ac72
exherbo-x86_64-pc-linux-musl-20160621.tar.xz

If you have any issues feel free to poke me (Somasis) on #exherbo@freenode.

Re: New Exherbo+musl stage: x86_64-pc-linux-musl-20160621

[Matias A. Fonzo]

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

El Tue, 21 Jun 2016 18:26:45 -0400
Kylie McClain <somasissounds@gmail.com> escribió:
> Hi everyone, just wanted to give an update on the status of musl on
> Exherbo.
> 
> I just finished the creation of a new stage completely automatically,
> without any intervention on my part done other than modification of
> the stage creation script. :)
> 
> This stage comes almost 6 months after the previous stage was made,
> and as such provides a much more up-to-date base for people wishing
> to run a musl system. So, if you're interested in coming over to
> Exherbo in search of musl, now's a good chance to give it a shot. :)

Sounds good.  :-)
 
> The usual details:
> 
> The latest musl stage can always be found at:
> https://www.somasis.com/stages/exherbo-x86_64-pc-linux-musl-current.tar.xz

Please, consider switching to another format, like lzip/clzip.  See:

  http://www.nongnu.org/lzip/xz_inadequate.html
 
> Make sure to consult the install guide for Exherbo, as it's
> applicable to all Exherbo stages:
> https://exherbo.org/docs/install-guide.html
> 
> Note that musl stages do not come with systemd. A list of alternative
> init systems can be found at
> https://exherbo.org/docs/without-systemd.html OpenRC is likely the
> best supported alternative at the moment; it's fairly new on Exherbo
> but OpenRC support has been added to many packages as of late.
> 
> Download links:
> 
> https://www.somasis.com/stages/exherbo-x86_64-pc-linux-musl-20160621.tar.xz
> https://www.somasis.com/stages/sha1sum
> 
> 63338f9e78d0669e2456fb3112c60d055bd4ac72
> exherbo-x86_64-pc-linux-musl-20160621.tar.xz
> 
> If you have any issues feel free to poke me (Somasis) on
> #exherbo@freenode.



-- 
GPG pub ID = 0x3AAF1CEC203A99D5
Key servers = hkps.pool.sks-keyservers.net - keys.gnupg.net
Key fingerprint = 35BD B9D4 6B56 B5FA CB64  7C9B 3AAF 1CEC 203A 99D5

[-- Attachment #2: Firma digital OpenPGP --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: New Exherbo+musl stage: x86_64-pc-linux-musl-20160621

[Shiz]

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


> On 22 Jun 2016, at 01:22, Matias A. Fonzo <selk@dragora.org> wrote:
> 
>> The latest musl stage can always be found at:
>> https://www.somasis.com/stages/exherbo-x86_64-pc-linux-musl-current.tar.xz
> 
> Please, consider switching to another format, like lzip/clzip.  See:
> 
>  http://www.nongnu.org/lzip/xz_inadequate.html

Switching to a format almost nobody has a decompressor for, especially for
something like a stage3 that is often extracted in a live environment with
no options to extra install packages, doesn’t seem like a good idea.

- Shiz

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: New Exherbo+musl stage: x86_64-pc-linux-musl-20160621

[Matias A. Fonzo]

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

El Wed, 22 Jun 2016 14:01:17 +0200
Shiz <hi@shiz.me> escribió:
> > On 22 Jun 2016, at 01:22, Matias A. Fonzo <selk@dragora.org> wrote:
> >   
> >> The latest musl stage can always be found at:
> >> https://www.somasis.com/stages/exherbo-x86_64-pc-linux-musl-current.tar.xz  
> > 
> > Please, consider switching to another format, like lzip/clzip.  See:
> > 
> >  http://www.nongnu.org/lzip/xz_inadequate.html  
> 
> Switching to a format almost nobody has a decompressor for,
> especially for something like a stage3 that is often extracted in a
> live environment with no options to extra install packages, doesn’t
> seem like a good idea.
> 
> - Shiz

Distribute files and impose to your users in having xz, is a bad idea.

To decompress the stage3, the users will require an important amount of
RAM, because `xz -9' uses a dictionary size of 64MiB by default.  Lzip
usually compresses large files about as much as xz, but using half the
RAM and requiring half the RAM to decompress[1].

For fun, I've re-compressed the stage3 using my lzip 1.15:

-rw-r--r-- 1 selk users 231566875 jun 21 17:55
exherbo-x86_64-pc-linux-musl-current.tar.lz

-rw-r--r-- 1 selk users 284602164 jun 21 17:55
exherbo-x86_64-pc-linux-musl-current.tar.xz

[1] http://www.nongnu.org/lzip/lzip_benchmark.html

See also:
http://www.nongnu.org/lzip/manual/lzip_manual.html#Quality-assurance

-- 
GPG pub ID = 0x3AAF1CEC203A99D5
Key servers = hkps.pool.sks-keyservers.net - keys.gnupg.net
Key fingerprint = 35BD B9D4 6B56 B5FA CB64  7C9B 3AAF 1CEC 203A 99D5

[-- Attachment #2: Firma digital OpenPGP --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: New Exherbo+musl stage: x86_64-pc-linux-musl-20160621

[Shiz]

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


> On 22 Jun 2016, at 17:20, Matias A. Fonzo <selk@dragora.org> wrote:
> 
> Distribute files and impose to your users in having xz, is a bad idea.

I don’t think you understand what I said. Technical arguments about the
superiority of your format aren’t particularly relevant if the user can’t
decompress it in the first place.

- Shiz


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: New Exherbo+musl stage: x86_64-pc-linux-musl-20160621

[Matias A. Fonzo]

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

El Wed, 22 Jun 2016 17:32:47 +0200
Shiz <hi@shiz.me> escribió:
> > On 22 Jun 2016, at 17:20, Matias A. Fonzo <selk@dragora.org> wrote:
> > 
> > Distribute files and impose to your users in having xz, is a bad
> > idea.  
> 
> I don’t think you understand what I said. Technical arguments about
> the superiority of your format aren’t particularly relevant if the
> user can’t decompress it in the first place.
> 
> - Shiz
> 

I understand that you are losing in make the right thing just for the
availability of a bad implementation.  If the user can't decompress is
really your main concern, think in the RAM usage as a possible
limitation (among other things).


-- 
GPG pub ID = 0x3AAF1CEC203A99D5
Key servers = hkps.pool.sks-keyservers.net - keys.gnupg.net
Key fingerprint = 35BD B9D4 6B56 B5FA CB64  7C9B 3AAF 1CEC 203A 99D5

[-- Attachment #2: Firma digital OpenPGP --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: New Exherbo+musl stage: x86_64-pc-linux-musl-20160621

[Luca Barbato]

On 22/06/16 17:57, Matias A. Fonzo wrote:
> El Wed, 22 Jun 2016 17:32:47 +0200
> Shiz <hi@shiz.me> escribió:
>>> On 22 Jun 2016, at 17:20, Matias A. Fonzo <selk@dragora.org> wrote:
>>>
>>> Distribute files and impose to your users in having xz, is a bad
>>> idea.  
>>
>> I don’t think you understand what I said. Technical arguments about
>> the superiority of your format aren’t particularly relevant if the
>> user can’t decompress it in the first place.
>>
>> - Shiz
>>
> 
> I understand that you are losing in make the right thing just for the
> availability of a bad implementation.  If the user can't decompress is
> really your main concern, think in the RAM usage as a possible
> limitation (among other things).
> 

The format seems a little too new and you seem to derail the discussion
in a mailing list unrelated to the main project (exherbo).

Would you please stop flaming?

xz took a lot of time to supplant bzip2 mainly because to make it viable
you would need to provide alternatives.

You might suggest to look at the format and help spreading the mindshare
or act like a bully and make people consider the whole thing bad
marketing and start ignoring you and your proposals like it is spam.

my 2 cents.

lu

Re: New Exherbo+musl stage: x86_64-pc-linux-musl-20160621

[Rich Felker]

On Wed, Jun 22, 2016 at 12:20:30PM -0300, Matias A. Fonzo wrote:
> El Wed, 22 Jun 2016 14:01:17 +0200
> Shiz <hi@shiz.me> escribió:
> > > On 22 Jun 2016, at 01:22, Matias A. Fonzo <selk@dragora.org> wrote:
> > >   
> > >> The latest musl stage can always be found at:
> > >> https://www.somasis.com/stages/exherbo-x86_64-pc-linux-musl-current.tar.xz  
> > > 
> > > Please, consider switching to another format, like lzip/clzip.  See:
> > > 
> > >  http://www.nongnu.org/lzip/xz_inadequate.html  
> > 
> > Switching to a format almost nobody has a decompressor for,
> > especially for something like a stage3 that is often extracted in a
> > live environment with no options to extra install packages, doesn’t
> > seem like a good idea.
> > 
> > - Shiz
> 
> Distribute files and impose to your users in having xz, is a bad idea.

Decompressing xz is supported by busybox and internally by busybox tar
and gnu tar, so I don't see any practical risk of the user not having
support. On the other hand, nobody has ever heard of lzip or clzip and
they're certainly not supported in the widely available tools.

For a compression format (from the perspective of the party doing the
decompression), the only technical details that are relevant are the
compression ratios and the memory and time requirements for
decompressing.

Rich

Re: New Exherbo+musl stage: x86_64-pc-linux-musl-20160621

[Rich Felker]

On Wed, Jun 22, 2016 at 05:59:44PM +0200, Luca Barbato wrote:
> On 22/06/16 17:57, Matias A. Fonzo wrote:
> > El Wed, 22 Jun 2016 17:32:47 +0200
> > Shiz <hi@shiz.me> escribió:
> >>> On 22 Jun 2016, at 17:20, Matias A. Fonzo <selk@dragora.org> wrote:
> >>>
> >>> Distribute files and impose to your users in having xz, is a bad
> >>> idea.  
> >>
> >> I don’t think you understand what I said. Technical arguments about
> >> the superiority of your format aren’t particularly relevant if the
> >> user can’t decompress it in the first place.
> >>
> >> - Shiz
> >>
> > 
> > I understand that you are losing in make the right thing just for the
> > availability of a bad implementation.  If the user can't decompress is
> > really your main concern, think in the RAM usage as a possible
> > limitation (among other things).
> > 
> 
> The format seems a little too new and you seem to derail the discussion
> in a mailing list unrelated to the main project (exherbo).
> 
> Would you please stop flaming?

I'd like to second this. The discussion about xz is irrelevant to the
thread it was posted on and to this list. It might be relevant on the
Exherbo lists (up to them to decide) but the post here was just
announcing a release of a distro using musl, not soliciting input for
that distro's choice of archive format.

Rich

Re: New Exherbo+musl stage: x86_64-pc-linux-musl-20160621

[Matias A. Fonzo]

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

Hi Dalias,
El Wed, 22 Jun 2016 12:37:01 -0400
Rich Felker <dalias@libc.org> escribió:
> On Wed, Jun 22, 2016 at 12:20:30PM -0300, Matias A. Fonzo wrote:
> > El Wed, 22 Jun 2016 14:01:17 +0200
> > Shiz <hi@shiz.me> escribió:  
> > > > On 22 Jun 2016, at 01:22, Matias A. Fonzo <selk@dragora.org>
> > > > wrote: 
> > > >> The latest musl stage can always be found at:
> > > >> https://www.somasis.com/stages/exherbo-x86_64-pc-linux-musl-current.tar.xz    
> > > > 
> > > > Please, consider switching to another format, like lzip/clzip.
> > > > See:
> > > > 
> > > >  http://www.nongnu.org/lzip/xz_inadequate.html    
> > > 
> > > Switching to a format almost nobody has a decompressor for,
> > > especially for something like a stage3 that is often extracted in
> > > a live environment with no options to extra install packages,
> > > doesn’t seem like a good idea.
> > > 
> > > - Shiz  
> > 
> > Distribute files and impose to your users in having xz, is a bad
> > idea.  
> 
> Decompressing xz is supported by busybox and internally by busybox tar
> and gnu tar, so I don't see any practical risk of the user not having
> support. On the other hand, nobody has ever heard of lzip or clzip and
> they're certainly not supported in the widely available tools.

GNU Tar has support for lzip, Star from Solaris, too.  And there's a
patch to include full lzip support in busybox:

  http://download.savannah.gnu.org/releases/lzip/busybox/
  http://savannah.c3sl.ufpr.br//lzip/busybox/README_busybox_lzip_patch

Lzip was created *before* than xz, as a replacement for the old
"lzma-alone".

Quote from http://lzip.nongnu.org/xz_inadequate.html :

"Then, why some free software projects use xz?

Because evaluating formats is difficult and most free software projects
are not concerned about long-term archiving, or even about format
quality. Therefore they tend to use the most hyped formats. Both
lzma-alone and xz have gained some popularity in spite of their defects
mainly because they are associated to the popular 7-zip archiver.

This of course is sad because we software developers are among the few
people who are able to understand the strengths and weaknesses of
formats. We have a moral duty to choose wisely the formats we use
because everybody else will blindly use whatever formats we choose."
 
> For a compression format (from the perspective of the party doing the
> decompression), the only technical details that are relevant are the
> compression ratios and the memory and time requirements for
> decompressing.
> 
> Rich

-- 
GPG pub ID = 0x3AAF1CEC203A99D5
Key servers = hkps.pool.sks-keyservers.net - keys.gnupg.net
Key fingerprint = 35BD B9D4 6B56 B5FA CB64  7C9B 3AAF 1CEC 203A 99D5

[-- Attachment #2: Firma digital OpenPGP --]
[-- Type: application/pgp-signature, Size: 949 bytes --]