From: Eddie Chapman <eddie@ehuk.net>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Update on the 23.0 profiles
Date: Mon, 8 Apr 2024 16:16:29 +0100 [thread overview]
Message-ID: <d029718e-83c5-43a7-89dc-88f66dc40c65@ehuk.net> (raw)
In-Reply-To: <240ec469649053c8dafc3f2beddd405825c88098.camel@gentoo.org>
Michael Orlitzky wrote:
> On Sun, 2024-04-07 at 15:07 +0200, Andreas K. Huettel wrote:
>
>>> tl;dr can we turn them back off in the profile? In any scenario where
>>> they are beneficial, there's a better place to put them.
>>
>> Easily doable with lzma, if there is consensus for it.
>>
>> Slightly more complex for zstd since this affects gcc and binutils.
>> Still doable though.
>
> Thanks:
>
> * https://bugs.gentoo.org/928932
> * https://bugs.gentoo.org/928933
I know this thread is only for people actually involved in Gentoo
decision making, but I'll add my 2c anyway.
I'm sure nobody is surprised that I support Michael Orlitzky here 100%.
My personal "dream" is to have a Gentoo in the future where *all*
compression is optional, only enabled by those who want it, not forced
on anybody.
In my opinion the importance of compression in general diminishes every
year that goes by as naturally the trend in storage space has to be that
it increases. So compression will increasingly become a) an extra
undesirable security risk (it's quite complex to write and maintain
which only increases rather than decreases the likelihood of security
issues) and b) a cpu cycle waster (cpu resources will likely remain more
precious than storage).
I'd love to eventually see a Gentoo where most upstream source is pulled
in untouched and uncompressed by default and if people want compression
they can enable it. So I would hope that as each new profile release
comes, Gentoo becomes less chained to any particular compression
libraries than it was before, not more. But I'm aware this is
unrealistic today from the pov of Gentoo infra. Still, I'm allowed to
dream right?
P.S. This is not a demand, just 2c, and yes, I do know ultimately the
ones who role their sleeves up and submit patches will decide these things.
Eddie
next prev parent reply other threads:[~2024-04-08 15:16 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-06 15:06 [gentoo-dev] Update on the 23.0 profiles Andreas K. Huettel
2024-04-07 2:03 ` Michael Orlitzky
2024-04-07 12:35 ` Andreas K. Huettel
2024-04-07 12:51 ` Michael Orlitzky
2024-04-07 13:07 ` Andreas K. Huettel
2024-04-08 6:40 ` [gentoo-dev] " Duncan
2024-04-08 12:00 ` [gentoo-dev] " Michael Orlitzky
2024-04-08 15:16 ` Eddie Chapman [this message]
2024-04-07 14:48 ` Michał Górny
2024-04-07 21:09 ` Michael Orlitzky
2024-04-08 0:22 ` Alex Boag-Munroe
2024-04-08 3:07 ` Michał Górny
2024-04-07 11:35 ` Florian Schmaus
2024-04-07 12:31 ` [gentoo-dev] " Madhu
2024-04-07 13:27 ` Andreas K. Huettel
2024-04-11 16:37 ` [gentoo-dev] " Madhu
2024-04-07 12:32 ` [gentoo-dev] " Andreas K. Huettel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d029718e-83c5-43a7-89dc-88f66dc40c65@ehuk.net \
--to=eddie@ehuk.net \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox