From mboxrd@z Thu Jan 1 00:00:00 1970 From: ng0@n0.is Subject: Re: End of beta soon? drop i686? Date: Tue, 11 Dec 2018 09:19:44 +0000 Message-ID: <20181211091944.dneczhtrave5jnjy@abyayala> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:57428) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gWeCl-0001sy-AB for guix-devel@gnu.org; Tue, 11 Dec 2018 04:19:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gWeCh-0008EN-0i for guix-devel@gnu.org; Tue, 11 Dec 2018 04:19:51 -0500 Received: from static.195.114.201.195.clients.your-server.de ([195.201.114.195]:60348 helo=conspiracy.of.n0.is) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gWeCg-0007MC-LO for guix-devel@gnu.org; Tue, 11 Dec 2018 04:19:46 -0500 Content-Disposition: inline In-Reply-To: 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: swedebugia@riseup.net Cc: guix-devel swedebugia@riseup.net transcribed 4.7K bytes: > Hi > > First of all thanks for building a great OS! (im writing this in vimb in > guixsd) :D > > Below is my reaction to the talk about 1.0 that has appeared on the > list. > > I see Ludo' is entuthiastic about 1.0 and hope to reach that soon. > > I recently decided to try running guix as a daily system to test and > hunt bugs and have fun. > > In my view we still have a system where encountering a bug is still far > more common than any other OS I ever used. > > Some of these bugs of course stems from the user not knowing how guix > works, but in my case I had to manage and work-around to just keep going > and getting things done. > > For that reason I think we are still quite far from 1.0 at the moment. > > That could of course change quickly, but I see more energy going into > updating (a tad rushed if you ask me) and packaging and this introduces > new instabilities and bugs a little faster than we can keep up it seems. > > E.g. on 0.16.0-3.6ddc63e (a few days behind master) on an i686-install > on a x86 64 bit machine with a slow disk and 2GB RAM > 1) right now webkit freezes on youtube > > 2) reconfigure is broken, see resent thread > $ sudo -E ~/src/guix/pre-inst-env guix system reconfigure ~/config.scm > Password: > guile: warning: failed to install locale > Backtrace: > In ice-9/boot-9.scm: > 2726:13 19 (_) > In ice-9/threads.scm: > 390:8 18 (_ _) > In ice-9/boot-9.scm: > 2994:20 17 (_) > 2312:4 16 (save-module-excursion #) > 3014:26 15 (_) > In unknown file: > 14 (primitive-load-path "gcrypt/hash" #) > In gcrypt/hash.scm: > 19:0 13 (_) > In ice-9/boot-9.scm: > 2874:4 12 (define-module* _ #:filename _ #:pure _ #:version _ # _ ?) > 2887:24 11 (_) > 222:17 10 (map1 (((gcrypt common)) ((gcrypt utils)) ((rnrs #)) # ?)) > 2800:17 9 (resolve-interface (gcrypt common) #:select _ #:hide _ # ?) > In ice-9/threads.scm: > 390:8 8 (_ _) > In ice-9/boot-9.scm: > 2726:13 7 (_) > In ice-9/threads.scm: > 390:8 6 (_ _) > In ice-9/boot-9.scm: > 2994:20 5 (_) > 2312:4 4 (save-module-excursion #) > 3014:26 3 (_) > In unknown file: > 2 (primitive-load-path "gcrypt/common" #) > In gcrypt/common.scm: > 35:13 1 (_) > In unknown file: > 0 (dynamic-link "/gnu/store/7y93yw3110fimzyrqlda7s7633ijk?") > > ERROR: In procedure dynamic-link: > In procedure dynamic-link: file: > "/gnu/store/7y93yw3110fimzyrqlda7s7633ijkxcq-libgcrypt-1.8.3/lib/libgcrypt", > message: "file not found" > > > 3) icecat does not have a substitute available and guix package -i > icecat -n outputs: > The following derivations would be built: > /gnu/store/7wmg5qw3s45mi8ss9q3q45hfmx3j91y6-profile.drv > /gnu/store/sfpiyr8mksl13g1kycigfi7yddf9pyi1-info-dir.drv > /gnu/store/rm2hf8k5iawdqwi4ngjkndnws47cwnb7-glib-schemas.drv > /gnu/store/rc6v87y5afpn5lcxn1fpm8dhzh9psgkj-xdg-desktop-database.drv > /gnu/store/r5zvxiwbglk3z0vv1vxpr00fz0j0bavp-ca-certificate-bundle.drv > /gnu/store/hxldf31yk8v0kx2vrmdxhca0vqmgd36h-xdg-mime-database.drv > /gnu/store/kc1g4aiizjd83cmfnr29qk36znkb971f-rust-1.19.0.drv > /gnu/store/4fc6d5aw42gpypq42svdn2l00lidw8r5-rust-1.20.0.drv > /gnu/store/bzgwrd3dyw6kxq6lkrqfdh13xfl5gq2q-rust-1.21.0.drv > /gnu/store/2s3y8vpvcc2rplsf8k3m787ildyd01xi-rust-1.22.1.drv > /gnu/store/gww3qar4hrab1r6cnyafpk8wg44znzb9-rust-1.23.0.drv > /gnu/store/aq8fy5fhr5rx3na83ziv48aqy4dbbf1w-rust-1.24.1.drv > /gnu/store/70p9k9zd680lmwxqa03whpwq6xwywr1i-fonts-dir.drv > /gnu/store/65hdbc7gzlxk1fwn658y6rjqb9k1dbh4-gtk-im-modules.drv > /gnu/store/3lwwhgh4sijdb7bf7lkhnb777xxvax4v-gtk-icon-themes.drv > /gnu/store/bxz8fxgmm1cgclkz5540nxibp0n3b5c9-icecat-60.3.0-gnu1.drv > /gnu/store/s7kskm9w8fr0fr5b7m2rlap843cmqh8s-manual-database.drv > > Having heard how a horror and RAM hog rust is I simply cannot use the > web on this guix version and would have to downgrade. The problem with > downgrading is lack of information. Building guix takes time and I dont > know which latest version of guix has an icecat x86 64-bit binary. > > 4) gnome-shell-extensions does not work with any of the browsers > available it seems. > > 5) our bug tracker is hard to navigate (for newcomers at least). > (surprisingly we do not seem to have a lot of duplicate bugs though) > > Earlier running 0.15 and later on a x86 64 bit install I had far better > coverage of substitutes and fewer errors (before latest core-updates > merge). > > To sum it up: lets not ruin what we have by rushing ahead and ending > beta too early. Agreed, and I would add a plea to focus more on Shepherd before it is called 1.0. > Lets either drop i686 support or test it more and look into the missing > substitutes. > > I'm in favor of dropping i686 and let somebody else create a guix-32-bit > fork like what happened in Arc. Entirely dropping it will be easy. But it involves much more than just the packages. And once you go beyond just the packages fork work is high-friction work. Even just the packages can be, depending on how the person approaches it, semi-high friction work. Let's not drop an architecture because occasionally something breaks for it. breakage is bad, yes. but it's more than just the broken packages. it is the way patches find their way into master. if you have more patience then I had, you can try to address the workflow in guix (there will be some past discussions you can find on the mailinglists). I've been on the high-friction lane with GuixSD, so I am talking from experience and not just assumptions. > Then we can focus on bughunting 64 bit > and working with the more promising architectures like those I mentioned > lately on devel instead of wasting time on slow legacy intel-backdoored > architecture. I disagree that legacy architectures should be dropped. Everything we have at the moment which is affordable is so called legacy. You have to go back very far in time to get hardware which wasn't build on the decisions intel (and AMD!) took. even if guix had support for those older architectures I'd still consider the idea not worth following through. guix would disregard a broad spectrum of people who financially or by locationcan not afford or get hardware other than the current supported one. Not everyone is capable or willing to send patches or bugreports to address their problems. If spectre and friends is the base of argumentation, x86_64 would have to be dropped too and instead only focus on a small subset of arm and older architectures. > -- > Cheers > Swedebugia >