From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Partelly Subject: Re: Suboptimal experience Date: Sun, 17 Jun 2018 22:51:51 +0300 Message-ID: <567433FC-8290-4F0C-9BCD-FA0FE93A8F1B@rdsor.ro> References: <5F881124-7897-40FD-B554-B845CB1200C5@rdsor.ro> <87vaah2ub7.fsf@netris.org> Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:46503) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fUdiQ-0007iK-Fu for guix-devel@gnu.org; Sun, 17 Jun 2018 15:52:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fUdiL-0000uj-IL for guix-devel@gnu.org; Sun, 17 Jun 2018 15:51:58 -0400 Received: from imap.rdsor.ro ([193.231.238.8]:44176 helo=mail.rdsor.ro) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fUdiL-0000uG-6c for guix-devel@gnu.org; Sun, 17 Jun 2018 15:51:53 -0400 In-Reply-To: <87vaah2ub7.fsf@netris.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: Mark H Weaver Cc: guix-devel@gnu.org HI Mark > 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. Well, is not all bad, there is a lot to like as well it seems, but I = need to experience it first hand as well :P The concept might be very = well the future, it reminded me of Plan9 Venti file system and Joe = Armstrong=E2=80=99s =E2=80=9CThe web of names hashes and UUIDs=E2=80=9D. = The concept of guix is powerful , maybe a solution to so many problems, = but when wielding powerful things, some care must be taken. Such as not = making an util update itself from the bleeding edge of a development = repository.=20 > 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? Yes I forgot. For any =E2=80=9Cguix system =E2=80=A6. =E2=80=9C the = message was: guix: system: command not found .=20 It basically could not execute any system command. I dont know yet the = architecture of guix componenets . I promise Ill read but it will take = time to go through all the docs. I assume guix is a dumb client, and all = the work is done by the demon. But is the daemon loading =E2=80=9Cplugins=E2=80=9D to execute the various tasks ? Or is = monolithic ? Im trying to see how can this happen. Client / server / = server plugins are all part of the same system , si it sould make sense = to intall them all as a single transaction, i.e an all or nothing to = minimize the chance of something like this happening.=20 > 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. I agree. This is the nature of software development. But what one can do = is to have as many safeguards as possible in place to *minimize* such = chanches. Some ideeas would be: - do not ever pull a core system utility update from bleeding = edge by *default* - introduce regresi=C3=B3n testing=20 - solve it socially by introducing rules for development=20 - have an =E2=80=9Cunstable=E2=80=9D branch for bleeding edge = from where who wants bleeding edge can pull at their own peril, > A bug introduced into package definitions can also result in a > temporarily unusable system. Keeping the package definitions separate > would not eliminate that possibility Well, if you keep them separately , you break one, two, 10 packages, and = you can mark them broken and thats it. If you argue that any package = which does something important in the OS if bugged I agree. But it=E2=80=99= s not about *eliminating* the chances for it is impossible. It is about = =E2=80=9Cminimizing=E2=80=9D the chance . The distinction is important = IMO. Keeping package definitions separately reduces this risk imo. > n 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. Yes very useful. May I suggest put a resume of basic functionality the = manual as the first page ? The implementation and filesystem paths in = guix are very alien for the first several hours of working with. An = heads up in manual would be very usefull to newcomers IMO. Its not that people do not read manuals (OK most = people do not). But usally when you evaluate a new thing there is an = exploratory direct phase , which is very important for the first = impressions. This over, some will go and read on the subject and lear = it, but IMO it has to go smooth to maintain the interest in the object. > 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. Well, I found those commands almost instantly, but I used them in = conjunction with system commands. Which was broken as I mentioned. It = may have worked in conjuction with papckages for the root store, but = until you finish reading the manual and get the concepts it is important = to be have a bump free exploratory ride.=20 > 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. Yes, i take your word for it, I almost no flight time on guix so =E2=80=A6= > 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=E2=80=99 = and Thanks. > On Jun 17, 2018, at 20:31, Mark H Weaver wrote: >=20 > Hi Dan, >=20 > Dan Partelly writes: >=20 >> First thanks for the development effort you guys do. Now the issues: >>=20 >> 1. I managed to install 0.14 to a Virtual box VM. I used bare-bones = configuration. >> 2. I tried to get familiar with guix / guixSD a bit, I never used it = before=20 >> 3. Within minutes I managed to break the system completely , due to = my misguided idea to execute a guix pull to upgrade the packages to the = latest available. 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 . = Guix reported:=20 >> 5. attempting to fix the issue by pulling from git branch 0.14 where = not successful. >=20 > 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. >=20 > 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? >=20 >> Now some points: >>=20 >> 1. Why does exist a tight coupling between guix proper and package >> definitions ? >=20 > 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. >=20 > 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. >=20 > 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. >=20 >> 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. >=20 > 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'. >=20 >> It exposes the user to all kind of issues, from mundane to >> unmangeable / unusable systems . >=20 > A bug introduced into package definitions can also result in a > temporarily unusable system. Keeping the package definitions separate > would not eliminate that possibility. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 >> 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 + . >=20 > 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. >=20 > 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. >=20 > * * * >=20 > 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: >=20 > https://www.gnu.org/distros/free-system-distribution-guidelines.html >=20 > Regards, > Mark