unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* What’s next?
@ 2021-05-15 17:47 Ludovic Courtès
  2021-05-15 18:08 ` Julien Lepiller
                   ` (8 more replies)
  0 siblings, 9 replies; 71+ messages in thread
From: Ludovic Courtès @ 2021-05-15 17:47 UTC (permalink / raw)
  To: guix-devel

Hello Guix!

So, now that 1.3.0 is out the door, what’s next?!

Here’s my wish list of things that look achievable within 4 to 6 months
(I hope to help on some of these):

  • Merging Guix Home.

  • Completing and consolidating Disarchive support (see
    <https://issues.guix.gnu.org/47336>): continuously building the
    Disarchive database, making sure it’s replicated or backed up by
    SWH, and having a blog post or two explaining the whole endeavor
    (I’m looking at you, Timothy ;-)).

  • Merging Magali’s ‘guix git log’ work.

  • Merging ‘core-updates’, perhaps with a switch to GCC 10?  Perhaps
    with support for “simplified packages” (getting rid of input
    labels)?  We’ll see how much can go in there, but the sooner the
    better.

  • On ‘core-updates’, merging either the full-source bootstrap or
    the reduced bootstrap on ARM, whichever comes first.  :-)

  • Consolidating the POWER9 and AArch64 ports (more build machines
    behind ci.guix!).

  • Maybe a step towards “early cutoffs” to reduce the amount of
    rebuilding (more on that in a future post).

  • Maybe optimized substitute downloads based on
    <https://lists.gnu.org/archive/html/guix-devel/2021-01/msg00080.html>
    or at the store item level (same as for early cutoffs).

  • Maybe parameterized packages based on
    <https://lists.gnu.org/archive/html/guix-devel/2020-11/msg00312.html>.

What do people think?  What’s your wish list?  What do you feel an urge
to hack on?  :-)

Ludo’.


^ permalink raw reply	[flat|nested] 71+ messages in thread
* What’s next?
@ 2021-05-16 12:24 Brendan Tildesley
  2021-05-17 20:25 ` Ludovic Courtès
  0 siblings, 1 reply; 71+ messages in thread
From: Brendan Tildesley @ 2021-05-16 12:24 UTC (permalink / raw)
  To: guix-devel@gnu.org; +Cc: ludo@gnu.org

[-- Attachment #1: Type: text/plain, Size: 3271 bytes --]

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"

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
$ guix pull
$ guix upgrade
$ sudo guix system reconfigure...
GUI desktop crashes back to TTY mysteriously.

Basically if guix pull can become as reliable as 'guix pull; guix pull; guix
pull; guix pull;, that would be great.  I think guix has many code paths
pertaining to downloading files where it chooses "Give Up" where "Try 2 or 3
times first" might be better.

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. 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.

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.


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


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.
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.

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.


[-- Attachment #2: Type: text/html, Size: 3958 bytes --]

^ permalink raw reply	[flat|nested] 71+ messages in thread
* What’s next?
@ 2017-05-24 13:11 Ludovic Courtès
  2017-05-24 13:23 ` Ricardo Wurmus
                   ` (3 more replies)
  0 siblings, 4 replies; 71+ messages in thread
From: Ludovic Courtès @ 2017-05-24 13:11 UTC (permalink / raw)
  To: guix-devel

[-- Attachment #1: Type: text/plain, Size: 2421 bytes --]

Hello Guix!

I think it’s time to think about what we want to work on next, ideally
before the next release, and ideally said release should be in a couple
of months rather than in 5 months.  Here are some important items I can
think of:

  • Merge the ncurses installer (the ‘wip-installer’) branch.

  • We’re supposed to freeze ‘core-updates’ in a couple of days and we
    have defined a couple of important goals:
    <https://lists.gnu.org/archive/html/guix-devel/2017-04/msg00120.html>.
    I have a vague feeling that the ‘wip-build-systems-gexp’ merge is
    not for this time yet…

  • ‘guix offload’ terrible bug: <https://bugs.gnu.org/26976>.

  • Guile 2.2 compiler terrible issue:
    <https://lists.gnu.org/archive/html/guile-devel/2017-05/msg00033.html>.

  • Adjust the release process so we don’t find ourselves without
    substitutes for the ‘guix’ package, as reported at
    <https://bugs.gnu.org/27032>.

  • Prepare to migrate to the new build farm: the hardware of
    bayfront.guixsd.org has been fixed (it was unreliable until we
    changed its CPUs), so now we need to fix a couple of issues in
    Cuirass and generally improve it so we can, via its HTTP interface,
    add new jobsets and so on.  Of course we’ll have to work
    on that incrementally.

  • Finalize the new bootloader API and support for new bootloaders:
    <https://bugs.gnu.org/26339>.

  • Merge the potluck!  <https://bugs.gnu.org/26645>

I think everything above could pretty much go into a 0.13.1 release not
far away.  And the missing bits, IMO, for a “1.0” label would be:

  • Improve the UI: add colors (yay!), hide build logs by default for
    most commands, improve progress reports, display how much will be
    downloaded, etc.

  • Implement channels: <https://bugs.gnu.org/22629>.  A first step may
    be to fix some of the obvious shortcomings of ‘guix pull’: use (guix
    git) to optimize bandwidth usage, and compute the derivation of the
    new ‘guix’ and use that.

  • Authenticate Git checkouts: <https://bugs.gnu.org/22883>.

What do people think?

I think the key idea is that we should fix all the annoyances and bugs,
many of which seasoned Guix hackers more or less got used to, but which
are nevertheless a serious hindrance when using Guix “normally.”

Ludo’.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

^ permalink raw reply	[flat|nested] 71+ messages in thread

end of thread, other threads:[~2021-05-26 13:27 UTC | newest]

Thread overview: 71+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-15 17:47 What’s next? Ludovic Courtès
2021-05-15 18:08 ` Julien Lepiller
2021-05-18 19:30   ` Leo Famulari
2021-05-18 21:19     ` Julien Lepiller
2021-05-18 20:25   ` Ludovic Courtès
2021-05-19 15:39     ` Katherine Cox-Buday
2021-05-19 16:22       ` Ricardo Wurmus
2021-05-15 20:24 ` Efraim Flashner
2021-05-16 18:25   ` raingloom
2021-05-16 22:06     ` Joshua Branson
2021-05-17 20:13   ` Ludovic Courtès
2021-05-21 11:07     ` Efraim Flashner
2021-05-26 13:26       ` Ludovic Courtès
2021-05-16  4:09 ` Maxim Cournoyer
2021-05-16  8:57   ` Pierre Neidhardt
2021-05-16 18:18     ` Christopher Lemmer Webber
2021-05-17  5:43       ` Pierre Neidhardt
2021-05-16 13:38 ` Maxime Devos
2021-05-16 16:08 ` Vagrant Cascadian
2021-05-16 16:26 ` Svante Signell
2021-05-17 14:45   ` Leo Famulari
2021-05-18  2:35     ` Joshua Branson
2021-05-18 14:05       ` Leo Famulari
2021-05-22 23:11         ` raingloom
2021-05-24 22:32           ` Joshua Branson
2021-05-17 12:36 ` zimoun
2021-05-18  3:37 ` Bone Baboon
2021-05-18 13:08   ` Bone Baboon
2021-05-18 20:24   ` Ludovic Courtès
2021-05-18 16:44 ` Maxime Devos
  -- strict thread matches above, loose matches on Subject: below --
2021-05-16 12:24 Brendan Tildesley
2021-05-17 20:25 ` Ludovic Courtès
2017-05-24 13:11 Ludovic Courtès
2017-05-24 13:23 ` Ricardo Wurmus
2017-05-27 10:01   ` Ludovic Courtès
2017-05-27 21:44     ` Ricardo Wurmus
2017-05-28 20:44       ` Ludovic Courtès
2017-05-28 21:36         ` Ricardo Wurmus
2017-05-30 15:55           ` Ludovic Courtès
2017-05-24 15:52 ` Brendan Tildesley
2017-05-27 10:04   ` Ludovic Courtès
2017-05-28 20:41     ` Maxim Cournoyer
2017-05-30 15:17       ` Ludovic Courtès
2017-06-03 21:16         ` Maxim Cournoyer
2017-05-24 16:09 ` Catonano
2017-05-24 16:25 ` Jan Nieuwenhuizen
2017-05-24 18:40   ` Adonay Felipe Nogueira
2017-05-24 19:34   ` Catonano
2017-05-24 19:56     ` Ricardo Wurmus
2017-05-30  0:09       ` myglc2
2017-05-24 21:47     ` Leo Famulari
2017-05-24 21:45   ` Leo Famulari
2017-05-25  8:11     ` What???s next? Pjotr Prins
2017-05-27 10:16       ` Ludovic Courtès
2017-05-28  7:30         ` What's next? Pjotr Prins
2017-05-28 20:48           ` Ludovic Courtès
2017-05-28 22:05             ` Roel Janssen
2017-05-30 15:19               ` Ludovic Courtès
2017-05-30 20:15                 ` Pjotr Prins
2017-05-29  2:31             ` Maxim Cournoyer
2017-05-28 20:37         ` What???s next? Maxim Cournoyer
2017-05-28 21:34           ` Ricardo Wurmus
2017-05-30 15:14           ` Ludovic Courtès
2017-05-25 14:57     ` What’s next? Chris Marusich
2017-05-25 18:32       ` Leo Famulari
2017-05-25 20:01       ` Ricardo Wurmus
2017-05-25 20:41         ` Adonay Felipe Nogueira
2017-05-27 10:13         ` Ludovic Courtès
2017-05-29 23:28           ` myglc2
2017-06-08 14:35           ` Ricardo Wurmus
2017-05-27 10:09   ` Ludovic Courtès

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).