all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Suboptimal experience
@ 2018-06-17 10:09 Dan Partelly
  2018-06-17 15:40 ` Julien Lepiller
  2018-06-17 17:31 ` Mark H Weaver
  0 siblings, 2 replies; 13+ messages in thread
From: Dan Partelly @ 2018-06-17 10:09 UTC (permalink / raw)
  To: guix-devel

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 
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 “system” for guix did not functioned at all after whatever git pull did .  Guix reported: 
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 
   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’s 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 
    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 
	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. 
8. if I am mistaken on any point, please correct me. 
9. 

With thanks

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2018-06-18 18:29 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-06-17 10:09 Suboptimal experience Dan Partelly
2018-06-17 15:40 ` Julien Lepiller
2018-06-17 19:55   ` Dan Partelly
2018-06-17 20:09     ` Julien Lepiller
2018-06-17 20:13       ` Dan Partelly
2018-06-17 20:16         ` Julien Lepiller
2018-06-17 17:31 ` Mark H Weaver
2018-06-17 19:51   ` Dan Partelly
2018-06-18 11:11     ` swedebugia
2018-06-18 15:01       ` Dan Partelly
2018-06-18 15:52         ` Julien Lepiller
2018-06-18 18:08           ` Dan Partelly
2018-06-18 18:29             ` Nils Gillmann

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.