Re: What’s next?

["Ludovic Courtès" <ludo@gnu.org>]

Hi Brendan,

Brendan Tildesley <btild@mailbox.org> skribis:

> Since you asked I'll dump my nebulous wishes here. Sorry that I don't have very
> concrete suggestions and solutions, just things I think could be better.  I
> should also state that 99% of my thoughts about Guix are through the filter of
> "I want to build a Guix based desktop distribution that can be installed on
> library, school, and home computers and Just Work better than Microsoft Windows"

This is great.  I agree that polishing what already exists should remain
a major goal.

> 1. Improve guix pull and updating reliability.
> Updating guix for me is often like this:
> $ guix pull
> retrieving git objects....
> TLS error in stream blah blah blah
> $ guix pull
> retrieving git objects..34%......... *dies but doesn't return to the prompt*
> ctrl-c

I’ve literally never experienced this.  Could you file a bug or two to
bug-guix@gnu.org, with at least the command and all the output?

> $ guix pull
> $ guix upgrade
> $ sudo guix system reconfigure...
> GUI desktop crashes back to TTY mysteriously.

Likewise, please!

> Often downloads to source tarballs will download at ~30KiB/s. maybe some
> axel-like system where both upstream an mirror urls are used might be
> good.

Could you report as many details when that happens?

> Also this may be wrong but from memory I think if the hash is wrong on
> a source tarball, it will not bother trying to use the guix ci mirror
> of it, only if it's 404. So people with --no-substitutes can get
> completely stuck.

True: <https://issues.guix.gnu.org/28659>.

> 2. 'guix system reconfigure' without instantiating the new system until reboot.
> I think the fact that reconfigure changes the whole system while its running is
> a bit of a party trick, like pulling the table cloth out without any glasses
> falling over.  For a Desktop GNU/Linux it kinda just accidentally works much of
> the time. I've always thought I'd prefer the default to simply install the new
> configuration in to GRUB and tell the user to reboot or add some flag like
> --instatiate-now.

I’m satisfied with the current default, but we could have an option to
delay activation until reboot.  Likewise, please file as a “wishlist”
item to bug-guix@gnu.org.

> 3. CLI consistency, e.g.,
> $ guix package => nothing
> $ guix system =>
> guix system: missing command name
> Try 'guix system --help' for more information.
>
> $ guix package --list-generations, but
> $ guix system list-generations ???\
>
> Also https://issues.guix.gnu.org/47618

All good points!

> 4. Make guix simpler and more performant.
>
> Guix is complex. It has features that make it theoretically superior in many
> ways, but in practice hasn't reached the reliability of simpler systems.  Every
> aspect of Guix seems to take more time, cpu, ram, hd space than say pacman.
> It's a bit beyond my skills to figure out how to actually improve these things
> though.
>
> $ guix system foobar
>
> takes 1.5-3.0 seconds on SSD, stats 2374 files, with 345 No such file or
> directories in order to determine the command doesn't exist and do nothing.

Agreed.  There have been improvements over time, such as the ld.so cache
in ‘core-updates’ (not merged yet), but there’s still a long way.

It’s frustrating for all of us, but one way to help is by pinpointing
specific bottlenecks and gathering as much data as possible so we have a
good starting point for optimization work.

> A fast guix could have 'guix time-machine -- environment --ad-hoc emacs --
> emacs' run instantly after its been ran once, and some kind of 'guix run'
> command could be added.

Yeah.

> 5. I think Guix should have some simple system to only update to the latest
> commit where behemoths like webkit/chromium already have substitutes available
> and that should maybe be the default way to update. It's not a big deal if we
> are making people build stuff that only takes 30 seconds and uses minimal
> ram. Doesn't need to be perfect. Ricardo made some simple scripts that did stuff
> like that in the past.

Yes, this is being worked on (you may have seen
‘channel-with-substitutes-available’ in 1.3.0, which is a first step in
that direction.)

Thanks for sharing!  I guess my message here is that all these should be
broken down into individual bug reports/wishes that can be more easily
addressed.  :-)

Ludo’.