Awesome! Great work! I read the below draft blog post like a Harry Potter novel! It is superbly written. And it makes a lot of sense!
Chris Marusich <cmmarus...@gmail.com> writes: > Hi, > > Léo and I have drafted the following blog post. Could you take a few > minutes to read it and give us your thoughts? > > It's a work in progress. The primary goal is to announce the new > powerpc64le-linux support and explain why it matters (POWER9 is an > exciting, freedom-friendly platform!). The secondary goal is to explain > some of the details about what we did, and invite people to get > involved. > > Your feedback would be highly appreciated! > > -- > Chris Seriously good job on this blog post, and all involved in the powerPC porting work! Fabulous job chaps! Cheerio! Also below are my tiny edits: > + > +### Why Is This Important? > + > +This is important because it means that GNU Guix now works on the [RYF > +Talos II and Talos II Lite > +mainboards](https://www.fsf.org/news/talos-ii-mainboard-and-talos-ii-lite-mainboard-now-fsf-certified-to-respect-your-freedom) > +and it's IBM POWER9 processor. This is a modern, performant hardware I believe you should use "its". it's is short for "it is". > +platform that respects your freedom. It can run without any non-free > +code, all the way down to its bootloader and firmware. It's a > +freedom-friendly platform that aligns well with GNU Guix's commitment > +to software freedom. > + > +How is this any different from existing RYF hardware, you might ask? > +The existing RYF > +[laptops](https://ryf.fsf.org/products?category=1&vendor=All&sort_by=created&sort_order=DESC), > +[mainboards](https://ryf.fsf.org/products?category=5&vendor=All&sort_by=created&sort_order=DESC), > +and > +[workstations](https://ryf.fsf.org/products?category=30&vendor=All&sort_by=created&sort_order=DESC) > +can only really be used with Intel Core Duo or AMD Opteron processors. > +Those processors were released over 15 years ago. Since then, > +processor performance has increased drastically. People should not > +have to choose between performance and freedom, but the fact is that > +for many years, that is exactly what we were forced to do. However, > +the Talos II and Talos II Lite have changed this: the free software > +community now has an RYF-certified option that can compete with the > +performance of modern Intel and AMD systems. > + > +Although the performance of POWER9 processors is competitive with > +modern Intel and AMD processors, its real advantage is that it< Why is there "it<" ? Is that some markup I'm not familiar with? > +respects your freedom. Modern processors from [both Intel and AMD > +include back > +doors](https://www.fsf.org/blogs/sysadmin/the-management-engine-an-attack-on-computer-users-freedom) > +over which you are given no control. Additionally, hardware design > +defects in the processors of both vendors have been discovered, giving > +rise to critical security vulnerabilities like > +[Spectre](https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)) > +and > +[Meltdown](https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)). > +In many cases, these vulnerabilities can only be fixed by installing > +[non-free CPU microcode](https://wiki.debian.org/Microcode) - unless, > +of course, [the vendor decides not to provide any fix at > +all](https://arstechnica.com/gadgets/2018/04/intel-drops-plans-to-develop-spectre-microcode-for-ancient-chips/)! > + > +Compared to that, the RYF Talos II and Talos II Lite are a breath of > +fresh air that the free software community really deserves. Raptor > +Computing Systems' commitment to software freedom and owner control is > +an inspiring reminder that it **is** possible to ship a great product > +that respects the freedom of your customers. And going forward, the > +future looks bright for the open, royalty-free Power ISA, [which is > +now a Linux Foundation > +project](https://www.linuxfoundation.org/press-release/2019/08/the-linux-foundation-announces-new-open-hardware-technologies-and-collaboration/) > +(see also: [the same announcement from The OpenPOWER > +Foundation](https://openpowerfoundation.org/the-next-step-in-the-openpower-foundation-journey/). > + > + > +In Guix, all software for a given system (e.g., powerpc64le-linux) is > +built starting from its bootstrap binaries. It is intended that the > +bootstrap binaries are the only pieces of software in the entire > +package collection that Guix cannot build from source. In practice, > +[additional bootstrap roots are > +possible](https://lists.gnu.org/archive/html/guix-devel/2015-02/msg00814.html), > +but introducing them in Guix is highly discouraged, and our community > +[actively](https://guix.gnu.org/en/blog/2019/guix-reduces-bootstrap-seed-by-50/) > +[works](https://guix.gnu.org/en/blog/2020/guix-further-reduces-bootstrap-seed-to-25/) > +to [reduce](https://guix.gnu.org/en/blog/2018/bootstrapping-rust/) our > +overall bootstrap footprint. > + > +So first you need to build the the bootstrap binaries for your "the the" --> "the" > +platform. In theory, you can do this in many ways. For example, you > +might try to manually compile them on an existing system. However, > +Guix has [package > +definitions](https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/make-bootstrap.scm?id=5d8c2c00d60196c46a32b68c618ccbe2b3aa48f4) > +that you can use to build them - using Guix, of course! > > +In both the big-endian and little-endian case, we were saddened to > +discover that the bootstrap binaries are not entirely reproducible. > +This fact is documented in [bug > +41669](https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41669), along > +with our extensive investigations. In short, if you build the > +bootstrap binaries on two separate machines without using any > +substitutes, you will find that the derivation which cross-compiles > +%gcc-static (the bootstrap GCC, version 5.5.0) produces different > +output on the two systems. However, if you build %gcc-static twice on > +the same system, it builds reproducibly. This suggests that something > +in the transitive closure of inputs of %gcc-static is perhaps > +contributing to its non-reproducibility. There is an interesting graph > toward the end of the bug report that suggests that the non-reproducibliity > is introduced by one or more of 21 derivations in the transitive closure of > %gcc-static's inputs that do not build reproducibly across systems. On my computer, the above line is SUPER LONG. Should you do a M-x fill-paragraph on the above line? Or does that not really matter? > +### Next Steps > + > +It is now possible to install Guix on a powerpc64le-linux system and > +use it to build some useful software - in particular, Guix itself. So > +Guix is now "self-hosted" on this platform, which gives us a > +comfortable place to begin further work. > + > +The following tasks still need to be done. Anyone can help, so please > +get in touch if you want to contribute! > + > +- Solve the GCC bootstrap binary reproducibility issue. > +- Get Guix System to work on powerpc64le-linux. > +- Get CI infrastructure to work (Cuirass, guix-build-coordinator, > + substitutes, etc.) > +- Fix all package build failures. > +- Try building rust, and if it works, judiciously re-introduce the > + librsvg dependency for powerpc64le-linux in gtk+ and gtk+-2, since > + [it is currently > + missing](https://git.savannah.gnu.org/cgit/guix.git). Just out of curiosity, does rust work on power? I'm under the impression that rust, while memory safe, is not so easy to bootstrap. Though I am eager to see someone bootstrap rust to power! Best of luck you brave soul! > +- Upgrade GCC to 8 on core-updates, fix issues that occur. > +- Merge core-updates to master after that. -- Joshua Branson (joshuaBPMan in #guix) Sent from Emacs and Gnus https://gnucode.me https://video.hardlimit.com/accounts/joshua_branson/video-channels https://propernaming.org "You can have whatever you want, as long as you help enough other people get what they want." - Zig Ziglar
