From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: Re: Suboptimal experience Date: Sun, 17 Jun 2018 13:31:56 -0400 Message-ID: <87vaah2ub7.fsf@netris.org> References: <5F881124-7897-40FD-B554-B845CB1200C5@rdsor.ro> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:54817) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fUbYP-0002ib-Q8 for guix-devel@gnu.org; Sun, 17 Jun 2018 13:33:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fUbYM-0002VJ-MW for guix-devel@gnu.org; Sun, 17 Jun 2018 13:33:29 -0400 Received: from world.peace.net ([64.112.178.59]:49246) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fUbYM-0002QW-Ht for guix-devel@gnu.org; Sun, 17 Jun 2018 13:33:26 -0400 In-Reply-To: <5F881124-7897-40FD-B554-B845CB1200C5@rdsor.ro> (Dan Partelly's message of "Sun, 17 Jun 2018 13:09:54 +0300") 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: Dan Partelly Cc: guix-devel@gnu.org Hi Dan, Dan Partelly writes: > First thanks for the development effort you guys do. Now the issues: > > 1. I managed to install 0.14 to a Virtual box VM. I used bare-bones confi= guration. > 2. I tried to get familiar with guix / guixSD a bit, I never used it befo= re=20 > 3. Within minutes I managed to break the system completely , due to my mi= sguided idea to execute a guix pull to upgrade the packages to the latest a= vailable. This command is a liability, while it should 100% safe given how = central is to the OS. > 4. This resulted into an unusable system , the command =E2=80=9Csystem=E2= =80=9D for guix did not functioned at all after whatever git pull did . Gu= ix reported:=20 > 5. attempting to fix the issue by pulling from git branch 0.14 where not = successful. A major change was recently made to 'guix pull', and there's apparently a bug. I'm sincerely sorry that this was your first impression of Guix. In general, it's more helpful to report problems like this as a bug report sent to , with relevant information. It would have been useful to see the error message. At the end of #4 above, you wrote "Guix reported:" but I see nothing anything after that. Did you forget to include the error message? > Now some points: > > 1. Why does exist a tight coupling between guix proper and package > definitions ? My answer would be: the same reason that Linux (the kernel) has a tight coupling between its device drivers and the core code. If they were separated, then all of the internal programming interfaces used in device drivers would need to be frozen as public APIs, and it would drastically curtail our ability to evolve those APIs and to keep the code in the system clean. On systems where device drivers and the kernel are separate, the device drivers need to be written to handle several different kernel versions, work around bugs in the kernel, etc, and the kernel is not free to change these interfaces but must always consider backward compatibility issues with older drivers. The same issues arise in Guix between package definitions and the core code in Guix that's used by the package definitions. When we keep them together, we retain the freedom to evolve not only the packages, but also the *way* the packages are written. We open the possibility of Guix becoming a far more elegant system in the future. > It is OK to recompile the package manager to get new functionality, > not OK to recompile the package manager proper to get definitions for > latest software. The package definitions are by far most of the code, so separating them would not make a huge difference in the time needed to run 'guix pull'. > It exposes the user to all kind of issues, from mundane to > unmangeable / unusable systems . A bug introduced into package definitions can also result in a temporarily unusable system. Keeping the package definitions separate would not eliminate that possibility. We are not able to eliminate the possibility that bad bugs will sometimes be introduced into Guix. However, what we can ensure is that it's almost always possible to *roll* *back* to a working version. In your case, it might have been useful to know that 'guix pull' only changes ~/.config/guix. If 'guix pull' gets you into a bad state, you can always delete that directory as a last resort. Going forward, recent versions of 'guix pull' include the ability to list the "generations" of guix that have been compiled by 'guix pull', and to roll back to an earlier generation, or to an arbitrary commit from the git repo. So, once you know your way around Guix, it is almost always possible to recover by rolling back to older versions until the issue is resolved. I write "almost always" to cover myself, but in practice I've been using Guix for years as my primary development systems, and so far I've always been able to easily roll back. I can even install an experimental untested version of glibc, without the slightest worry that it will be difficult to recover from. There are not many distros that can say that. > 3. compilation time of guix at guix pull time is horrendous. I dont > know the system good enough, so I can be mistaken, but probably the > bulk of is is because of package definitions . If this is true, then > you have an issue. You are at about 7k packages, it will increase > linear with n , you'll grow old near a computer running this package > manager by the time you'll reach 30k + . I agree that it's a problem, but it's not a fundamental problem with Guix. There are many ways that we can improve this. The first observation is that we needn't recompile all package definitions, only the ones that have changed. Also, we could compile package definitions with far fewer optimizations. Some work is needed in Guile here as well. Also, I should mention that it's possible to run Guix without ever using 'guix pull'. I haven't run 'guix pull' in years. Instead, I compile guix from a git checkout, and updating guix involves 'git pull' and 'make', which is typically quite fast on modern systems. Occasionally a longer 'make clean' is required. You can learn how to do this in the "Contributing" chapter of the Guix manual. * * * I don't have time at the moment to respond to the rest of your email, except to say that Guix is committed to including only free software, and more specifically to follow the GNU Free Software Distribution Guidelines (FSDG), described here: https://www.gnu.org/distros/free-system-distribution-guidelines.html Regards, Mark