From mboxrd@z Thu Jan 1 00:00:00 1970 From: ng0 Subject: Re: Guix infrastructure Date: Sat, 8 Jul 2017 23:50:44 +0000 Message-ID: <20170708235044.kdaig76tc4nn37kp@abyayala> References: <20170701173604.vjzta4fccjfuqxoy@abyayala> <20170701180111.GA29205@jasmine.lan> <86d19dxg42.fsf@gmail.com> <20170707030042.GD1280@jasmine.lan> <87tw2o8mno.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hw5obhy3nbtf7jv7" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:50201) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dTzVF-0000zP-9n for guix-devel@gnu.org; Sat, 08 Jul 2017 19:51:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dTzVE-0008W0-2a for guix-devel@gnu.org; Sat, 08 Jul 2017 19:51:09 -0400 Content-Disposition: inline In-Reply-To: <87tw2o8mno.fsf@gnu.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel@gnu.org, mail@dvn.me --hw5obhy3nbtf7jv7 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Ludovic Court=C3=A8s 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! >=20 > Thanks, > Ludo=E2=80=99. >=20 >=20 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 Guix= SD 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. =20 - 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.=20 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. --=20 ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://n0is.noblogs.org/my-keys https://www.infotropique.org https://krosos.org --hw5obhy3nbtf7jv7 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEqIyK3RKYKNfqwC5S4i+bv+40hYgFAllhb9MACgkQ4i+bv+40 hYhh4xAAlJ3fwKDT5jhrYvWFyHDRsSMWFUAOT9ikU/EUL2g8A/nMB7gESptDyAlH AUkWvWuFkMUOlZEM/adwV30LtQ3qma7MIVVT3/Ex/u+tmtrv+AriIILssUipZaCD wOjXjfS67AcJMqtuV0ByhO8hD+CY/Vw/Jkg0p8uGsRtJZvNnNfvDGQdcXb6O9Kho pLVkfrpfOTZI5jrxKzBnQAWOKRfH7cT5iq7DoTJAfS0JJQH9G4dPaX6PeGcneTZR o8LAX+UztOqw63blIgbhBiyX26xbUBgVqB5tD7bWN6r6SHCf1h/xvYr0w93IdQ9i LgEi+LOFdtdNjos4JlLn7py4dcZAIWW3HSgXRvoo3xO4g51ugPiPiuSPyEPwHcwr KjrBDfabKGfTZyefQsj5KglXru4wsLjuzI/eKQZ84KjCdUYBJVcJVxtR12M3WWwU DyvTzLQfcLsSac6NrnFOcCWLF398dDWa7KeLykHOgsBYGViJAywza+RHT1+1ibuT tzaMN8mzBc+th7InVPTF+P2ameOmcHeRvJ0iI26hcVnr8r0mgWeaq/YpW0DVDjLf 67kRux5G7uQA2fpmQzfjf4D0H9b8G8lbiv6CMt8INk6hWP7jL61aCzFTM82FoOTV yjARDztZfMD4ZMOvD7E8xmU47Gxgl5OIs5tTSG9asFQfbKwradA= =E3Xm -----END PGP SIGNATURE----- --hw5obhy3nbtf7jv7--