Hi Konrad, On 2026-05-20 at 09:32+02:00, Konrad Hinsen wrote: > My take on this is likely to be unpopular here: I think that Guix is > already too big and diverse in its current state. I'd prefer Guix to > concentrate on a minimal core with just the packages necessary for a > minimal viable system.
Not sure about popularity, but I suggested something similar a couple weeks ago: On 2026-04-28 at 19:18+09:00, Nguyễn Gia Phong wrote: > On 2026-04-28 at 10:55+02:00, Ricardo Wurmus wrote: > > I can't help but look with envy at the automated > > guix-cran and guix-bioc channels that get updated every day. It's > > not ideal that the "blessed" collection of R packages in the main > > Guix channel is less fresh. > > Wouldn't it be possible then to split all R packages > to a separate channel, say guix-r that depends on guix, > then either (if possible) have guix depends on guix-r, > or bless a guix-meta channel that depends on both guix and guix-r? With dependent channels pinning the core, we can update packages with many dependents with less friction. On 2026-05-20 at 09:32+02:00, Konrad Hinsen wrote: > For such a core, it would be much easier to be > strict about rejecting vibe-coded software. Everything else could be in > separate channels, and each of these channels could have its own genAI > policies. With today's approach of "the more packages the better", it is > hard to draw a line that includes enough package for Guix to remain > useful and at the same time excludes enough packages to send a credible > anti-genAI message to the outside world. There's a tad complication with excluding slops, as the last CPython version without any LLM output, 3.13, is reaching is EoL late 2029, and Python is a dependency for most of our world. (Not to mention linux-libre already contains LLM outputs.) Best wishes, Phong
signature.asc
Description: PGP signature
