Re: Please review blog post draft: powerpc64le-linux support

[Chris Marusich <cmmarusich@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 8352 bytes --]

Hi Joshua,

Joshua Branson <jbranso@dismail.de> writes:

> 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!

Thank you for the kind words, and your feedback!

>> +### 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".

Good catch!

>> +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?

Nope, it's a typo.  Good eyes!

>> +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"

Fixed!

>> +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?

Yeah, I forgot to do that on this line.  It's wrapped now.

>> +### 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!

Yes, Rust should work.  There's a Debian package on their ppc64el port
(the package is rustc), and the GNU triplet
"powerpc64le-unknown-linux-gnu" (which is the triplet corresponding to
the Guix system "powerpc64le-linux") is listed as a Tier 2 supported
platform in the Rust docs:

https://doc.rust-lang.org/nightly/rustc/platform-support.html

Whether or not it does work is another question.  I'll be surprised if
it builds in Guix on powerpc64le-linux the first time we try, but we
just have to try it and fix any problems that occur.

I'll build and try using it eventually, but others are more than welcome
to beat me to the punch!  I've been focusing on finishing this blog post
in my spare time first.

Again, thank you for the feedback!  I really appreciate it.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]