Hi Brendan, Brendan Tildesley <bt...@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-g...@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-g...@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’.
