From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Partelly Subject: Suboptimal experience Date: Sun, 17 Jun 2018 13:09:54 +0300 Message-ID: <5F881124-7897-40FD-B554-B845CB1200C5@rdsor.ro> 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]:57684) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fUUdF-00030d-5g for guix-devel@gnu.org; Sun, 17 Jun 2018 06:10:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fUUdC-0006Sn-06 for guix-devel@gnu.org; Sun, 17 Jun 2018 06:10:01 -0400 Received: from imap.rdsor.ro ([193.231.238.8]:42702 helo=mail.rdsor.ro) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fUUdB-0006SE-OQ for guix-devel@gnu.org; Sun, 17 Jun 2018 06:09:57 -0400 Received: from [192.168.1.100] (unknown [79.117.86.147]) by mail.rdsor.ro (Postfix) with ESMTP id 3CE044042A for ; Sun, 17 Jun 2018 13:09:55 +0300 (EEST) 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: guix-devel@gnu.org Hello, 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 = 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. Now some points: 1. Why does exist a tight coupling between guix proper and package = definitions ? 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. It exposes the user to all kind of issues, from mundane to = unmangeable / unusable systems . 2. Why failing to rebuild guix results into an unmanageable system ? If = the OS prides itself with atomicity and safety, then IMO any warning in = the build process of this core tool (for any final build artifact ). If = the build process results in N=20 artifacts, then care should be taken that those are atomically = inserted in the new system so no broken state can exist 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 + . 4. again, if 3 is true, this can be mitigate by releasing a guix package = which is updated automatically in binary form, but it=E2=80=99s a hack = IMO. Cutting the dependency of package manager from package descriptions = is the only sane way to solve this issue IMO 5. How secure is guix SD ? I see that you use a kernel with no = provisions of loading microcode into CPUs. Given the recent rainbow of = speculative execution bugs, this is a big issue if kernel mitigations = are not enough and updated CPU microcode=20 is required ? How secure is Guix SD and do you plan to do anything = about it ? Or do you recommend to use it only in secure physical = environments which are air-gapped , give that known bugs might be active = ? 6. How do you plan to handle the future with a kernel which does not = allow firmware uploads to devices. As of today, for example, virtually = no current generation GPU for PCs on the market works in parameters = without firmware. That means that=20 you cannot use Guix SD on server for any computing loads with = current gen hardware, and on desktop you are limited to old hardware. = What is the project stance on this ? Is it doomed from start to work = only on legacy hardware which in 5 to 10 years will be virtually extinct ? Yes, today you can still use it this = way, since you have firmware free legacy GPUs available yet, but what = about the future ? How about in 5 years, Will it run only on second = hand machines using antiquated hardware 7. while I realize that Im inexperienced with guix, I consider that the = type of issues I encountered should not be part of a software product in = beta stage. It may be acceptable for the first one year in the life = cycle of the product, but not on a beta system with what, like 8 -9 = years under the belt . Besides giving a very bad first impression, it = wastes human time, and people time is the most precious resource.=20 8. if I am mistaken on any point, please correct me.=20 9.=20 With thanks