On Fri, Jan 10, 2020 at 09:53:57PM +0200, Αγαθοκλής via lfs-dev wrote:
> On Thu, Jan 09, at 05:43 Ken Moffat via lfs-dev wrote:
> > On Wed, Jan 08, 2020 at 10:01:48PM -0600, Bruce Dubbs via lfs-dev wrote:
> > >
> > > I do agree that we could classify this as 'might be needed in {,B}LFS one
> > > day', but I am anticipating what I think upstream will do. I just don't
> > > know when. The issue really is whether we should be proactive or
> > > reactive.
>
Hi Ag,
nice to see you back on the lists.
[ snipping a lot of good stuff ]
>
> For this kind of application, three things matters:
> - compression speed
> - decompression speed
> - compression ratio/size
>
> What we are really interested here is about the latters. And we should do, as
> compression
> is about economy, both when transferring bytes over the network and while
> spending cpu
> cycles when decompressing.
>
> I'm curius though to see, what are those main advantages of this algorithm.
> Douglas mentioned a benchmark. It would be good i think, a brief summary that
> lists
> those advantages.
>
From what I've seen, it typically creates slightly larger compressed
files, and takes varying amounts of time to compress - depending on
the settings. But it seems to be much faster at decompressing,
which is why Arch have now moved to it for their binaries.
It also apparently uses multiple cores well.
See e.g. https://en.wikipedia.org/wiki/Zstandard
And the kernel already supports it for compressing bzImage and for
initrds (ok, initrds aren't common in LFS but soem people need
them).
>
> I'm afraid this is not quite strong of an argument. Prerequisity for a
> package to be
> included in LFS-BOOK, unless the rules has been relaxed with time, it was
> because it
> was a dependency of a based package.
> Or, and in this particular case, if a package in BLFS didn't offered its
> distributed
> sources in one of the established formats.
>
> Is there any such package?
>
Some things have crept in for other reasons, e.g. openssl. Also,
for our convenience the things needed by "That OS which would be good
if it had a decent init system" are in the sysvinit book too.
> > OK, go for it.
>
> This isn't to say do not go for it. I say, go ahead if you feel quite
> confident about
> your instict, and if you can anticipate the future.
>
[...]
> And there is no alternative, as also Firefox followed this route, when in
> 2004 (in
> their phoenix days) promised the first beta testers a lean browser (and it
> was really).
> That's why we should be skeptical to leave buissness to lead the standards,
> though i
> reckon this case it's not this kind of thing.
>
Unfortunately, the fight against the bad guys, plus people's
expectations that they should be able to get video playback in the
browser, as well as attempting to get mindshare (firefox's move to a
4-week release cycle), mean that what used to be regarded as an
adequate installed system is now laughed at.
At the moment we can get by, but anything with less than 4 cores and
older than (random figure) 5 years will be a pain on which to
compile, as will laptops.
The way things are going, adding another decompressor is probably a
minimal overhead.
ĸen
--
The right of the people to keep and arm Bears, shall not be infringed.
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
