Re: Guix infrastructure

[ng0 <ng0@infotropique.org>]

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

Ludovic Courtès transcribed 2.5K bytes:

> I not only sympathize with your frustration, ng0, I feel it even ten
> times more.  ;-)  Several of us are determined to come up with a
> solution quickly, so I hope that will materialize soon!
> 
> Thanks,
> Ludo’.
> 
> 
Okay.

About that..

It was not just no builds available. What for me the real grave issues are at
the moment as someone who's primarily considering to base a project on GuixSD
and who secondarily and within that scope contributes to GuixSD:

- master is not stable and it is not being treated as a high priority
  problem, at least that is my impression from remarks in chat/emails
  and what I've been able to read. All arguing aside, that's something
  which can be fixed. CC'd dvn: in our last mumble session you mentioned
  that ii could get in touch with Guix. I don't think you'll forget it
  but here's an email for the start.
  I think you (Ludovic) suggested something similar to what ii is
  offering, but maybe I just imagined that ou commented on that.
  
- a bug in the compiler which is used in the core of Guix is bad. In my
  understanding that we could at least try to evade this by reducing the
  module sizes is met with arguments like "this will be fixed in the
  future, for now we can only split 1 module the rest has to stay
  together for semantic and linguistic reasons".
  If my understanding of the whole situation is wrong this is due to the
  intransparent dealing with this serious problem and the way my idea
  to temporarily fix it was met.

  For me GuixSD as it is at the moment, is unusable. Not with my hardware,
  not with my knowledge and devices I have. But with the intention of the
  project I am running it aims at hardware which can not evade this bug.
  On my side even when we set up our own build infrastructure it will
  not change the fact that the current pull/make is using way too much
  resources for the end result I target.

- Writing system services in Shepherd is hard. The debugging of these
  services is a major pain compared to writing services for OpenRC or
  systemd. I'm no expert in Guile, I understand more than 2.7(?) years ago
  (coming to Guix was my first exposure to Guile). With OpenRC I'm not
  really sure why it is easier. I just know what would work and what
  doesn't work. It has its limits, it operates in another system
  structure.
- Debugging in general. It would be *very* good if debugging symbols and
  capabilities wouldn't be an 'write your local inherits and overrides
  so that you get debug outputs' thing. This is not just my opinion,
  people brought this up in off the record chats (and possibly even in
  irc) before.

These are the major issues Guix could fix.
There's more where I know it will not be fixed and/or it can not be fixed[0],
those are reasons why we are currently re-evaluating the choice of the
system. Maybe it turns out playing the high-chase speed run with Guix
is the only sane choice. Maybe it doesn't. There are no hard feelings if
the issues above will not be fixed, it's just something which makes it
frustrating to work with Guix. The frustration did set in when the 0.13
/ guile 2.2.2 related bug(s) came to the list of existing issues for me.

When I came to GuixSD in Winter 2015 I saw a huge potential. I still see
it. I hope we can fix this, no matter how the re-evaluation on our side
turns out. 

0: Most of these issues are differences in goals and how it applies to
   what is technically implemented, etc.
   Public docs are incomplete and intransparent, so the links below
   (for the curious) will not represent the actual state of what is
   being worked towards.
-- 
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://n0is.noblogs.org/my-keys
https://www.infotropique.org https://krosos.org

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