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
signature.asc
Description: PGP signature
