Re: RFC: Portability should be a higher priority for Guix (was Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.)
Hello, On Thu, Jul 05, 2018 at 11:04:31AM +0200, Jonathan Brielmaier wrote: > I just want to bring POWER up as a freedom-respecting architecture. > Especially the TalosII from RaptorCS[0]. I know that guix does not work > on ppc64le yet, but I'm working for it :) They tend to be quite > expensive, but you get a decent performance on compiling and packing[1]. this is indeed an exciting architecture. Vikings had a machine on display at their FOSDEM table earlier this year. But the price is still quite steep, if you know anybody who would sponsor a machine... Andreas
Re: RFC: Portability should be a higher priority for Guix (was Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.)
l...@gnu.org (Ludovic Courtès) writes: > Hello Kei, > > Kei Kebreau skribis: > >> I am interested in helping with non-x86_64 issues. Particularly, helping >> with i686-related changes should be just a change in workflow, but I'm >> interested in obtaining freedom-respecting non-x86 hardware (or at least >> using a virtual machine as close as possible to real hardware >> configurations). Any recommendation or links for where I can get a >> Yeeloong laptop or what freedom-respecting armhf computers are >> available? > > Without having actual hardware, you can use the qemu-binfmt service on > your machine (info "(guix) Virtualization Services"). It’s slow, but it > allows you to reproduce and debug issues for other architectures. > > Thanks, > Ludo’. Wow, this is excellent! Thanks for the tip. signature.asc Description: PGP signature
Re: RFC: Portability should be a higher priority for Guix (was Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.)
Hello all, of course I can all but agree that support for "exotic" hardware is very desirable, especially since, as Mark pointed out, we would like it to become more mainstream! On Thu, Jul 05, 2018 at 08:38:19AM +0200, Ricardo Wurmus wrote: > One thing that would help, in my opinion, is to purchase hardware and > make it available to interested developers and/or join these new > machines to the build farm. If people want to look at armhf, one of the donated Novena boards is currently running in my living room, under the name of redhill.guixsd.org. I could of course create accounts for Guix developers who want to have access to debug the architecture. Andreas
Re: RFC: Portability should be a higher priority for Guix (was Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.)
On 7/5/18 12:32 AM, Kei Kebreau wrote: >> I'm open to suggestions. Do you see any solution to the problem of how >> to attract more non-x86_64 users, given our current policies? >> >> Thanks, >>Mark > > I am interested in helping with non-x86_64 issues. Particularly, helping > with i686-related changes should be just a change in workflow, but I'm > interested in obtaining freedom-respecting non-x86 hardware (or at least > using a virtual machine as close as possible to real hardware > configurations). Any recommendation or links for where I can get a > Yeeloong laptop or what freedom-respecting armhf computers are > available? I just want to bring POWER up as a freedom-respecting architecture. Especially the TalosII from RaptorCS[0]. I know that guix does not work on ppc64le yet, but I'm working for it :) They tend to be quite expensive, but you get a decent performance on compiling and packing[1]. Regarding ARM hardware: I have access to a bunch of performant ARM machines (Cavium Thunder, AMD ARM stuff etc.) at work. So feel free to drop me a mail or set me to CC, if you need something to be tested on ARM :) [0] https://raptorcs.com/ [1] https://www.phoronix.com/scan.php?page=article=power9-talos-2=3
Re: RFC: Portability should be a higher priority for Guix (was Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.)
Hi again Mark, Mark H Weaver skribis: > l...@gnu.org (Ludovic Courtès) writes: > >> Mark H Weaver skribis: >> >>> The end result is that the wishes of the x86_64-using majority are the >>> only ones that seem to matter in this community, and other users are >>> frequently left in a bad spot. This makes it increasingly unlikely that >>> we'll ever gain a significant number of non-x86_64 users. >> >> This kind of rant is really unhelpful. You’re shouting at someone who >> *is* doing the work of keeping things running. > > I wasn't actually shouting, but in retrospect I can see how it came off > that way. I apologize for any hurt feelings that I caused. I think the error is to suggest that people genuinely don’t care about the issues. Often they’re unaware, and sometimes they make suboptimal tradeoffs, as in the PatchELF case, simply because the status quo is worse than the suboptimal tradeoff. > However, I do feel frustrated by the fact that it's considered > acceptable in this community to leave non-x86_64 users with broken > systems in the name of "moving things forward" for x86_64 users. Like I write, it’s not “considered acceptable.” That’s just not the way it works. There’s an implicit rule that we should not break any architecture badly, but just like sometimes packages fail to build, sometimes there are architecture-specific issues; and just like an unpopular package that fails to build is likely to remain that way, an unpopular architecture is more likely to have issues. We don’t have to take it as a fact of life, though. We can work proactively to mitigate that, and support for those architectures in the build farm, along with heads-up from overseers (like you’ve been doing to great effect!) can greatly help. It won’t bring, say, MIPS to the level of support of x86_64, but it can reduce damage. > I'm open to suggestions. Do you see any solution to the problem of how > to attract more non-x86_64 users, given our current policies? Efraim, Danny, Vagrant, Julien, Mathieu, etc. have done a lot of work fiddling with ARMv7 and AArch64. We should encourage that, and providing timely substitutes for the arches is one way to do it, and ultimately to attract more users and contributors. Thanks, Ludo’.
Re: RFC: Portability should be a higher priority for Guix (was Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.)
Mark H Weaver skribis: > Another problem is that Guile 2.2's compiler has become so heavy that > it's nearly unbearable to use on slower hardware. Simply running "make" > in my Guix git checkout after updating on my mips-based Yeeloong is so > slow that I'm in the habit of letting it run overnight. This is a topic on its own, and I really think we can and should do better. I posted observations on where the compiler is spending its time and memory earlier; Andy pushed improvements, but I believe there’s much more than can be done: https://lists.gnu.org/archive/html/guile-devel/2017-10/msg00035.html https://lists.gnu.org/archive/html/guile-devel/2017-05/msg00033.html Ludo’.
Re: RFC: Portability should be a higher priority for Guix (was Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.)
Hello, Ricardo Wurmus skribis: >> However, I do feel frustrated by the fact that it's considered >> acceptable in this community to leave non-x86_64 users with broken >> systems in the name of "moving things forward" for x86_64 users. > > I don’t think this is true. What is true is that most Guix users use x86_64 primarily. But there’s also a lot of interest in ARM. Guix doesn’t exist in a vacuum, and I think the situation of non-x86_64 support in Guix is just as good or bad as in other free software projects. We have fewer packages available on non-x86_64 architectures, but that’s in large part due to upstream packages not supporting those architectures in the first place. I agree this is sad, but repeating it doesn’t help address it. > I do agree with your laments about a lack of popularity of non-x86_64 > systems and thus developers, but I do think this has been getting better > with the work this community has done to support Guix for the aarch64 > and armhf architectures, and by adding aarch64/armhf build servers to > the build farm. We can and should do more of this, but it won’t happen > by decree. Agreed. > One thing that would help, in my opinion, is to purchase hardware and > make it available to interested developers and/or join these new > machines to the build farm. We would need to come to an agreement about > at least these things: > > * what exact system configurations do we want? > * where would these systems be hosted? > * how many do we need / can we afford to buy and pay hosting fees for? > > The last time this has come up the discussion kinda tapered out. It > would be good if someone or a group of people would volunteer to take > this on and drive this project to its conclusion. I agree! If someone cares about ARM, for instance, now’s the time to tell us what we should buy and to offer to help out with hosting/sysadmin. That would be immensely helpful in maintaining non-x86_64 up to speed. Thanks, Ludo’.
Re: RFC: Portability should be a higher priority for Guix (was Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.)
Hello Kei, Kei Kebreau skribis: > I am interested in helping with non-x86_64 issues. Particularly, helping > with i686-related changes should be just a change in workflow, but I'm > interested in obtaining freedom-respecting non-x86 hardware (or at least > using a virtual machine as close as possible to real hardware > configurations). Any recommendation or links for where I can get a > Yeeloong laptop or what freedom-respecting armhf computers are > available? Without having actual hardware, you can use the qemu-binfmt service on your machine (info "(guix) Virtualization Services"). It’s slow, but it allows you to reproduce and debug issues for other architectures. Thanks, Ludo’.
Re: RFC: Portability should be a higher priority for Guix (was Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.)
Hi Mark, > However, I do feel frustrated by the fact that it's considered > acceptable in this community to leave non-x86_64 users with broken > systems in the name of "moving things forward" for x86_64 users. I don’t think this is true. > When I suggest that the community would not take certain suggestions > seriously, e.g. the suggestion to block upgrades or merges that would > break non-x86_64 systems, that statement has some meaning. I means that > I expect that most people here would disagree, and that the maintainers > would rule in favor of "moving forward" at full speed, and that it will > be the responsibility of the tiny number of non-x86_64 Guix users to fix > portability bugs as quickly as needed so that the x86_64-using majority > need not suffer any delays. It’s neither about “moving forward” at all costs nor about “full speed”; while we are generally moving forward, it’s hardly at full speed. The last core-updates merge was blocked for months, but it contained critical fixes that had to be worked around in other branches, which was an untenable position given the number of developers. FWIW, I’m using a i686 machine with 2GB RAM myself, and I did test the core-updates things on that machine (as far as the software is concerned that I’m using). I was rather surprised by the GRUB bug, to be honest. I do agree with your laments about a lack of popularity of non-x86_64 systems and thus developers, but I do think this has been getting better with the work this community has done to support Guix for the aarch64 and armhf architectures, and by adding aarch64/armhf build servers to the build farm. We can and should do more of this, but it won’t happen by decree. One thing that would help, in my opinion, is to purchase hardware and make it available to interested developers and/or join these new machines to the build farm. We would need to come to an agreement about at least these things: * what exact system configurations do we want? * where would these systems be hosted? * how many do we need / can we afford to buy and pay hosting fees for? The last time this has come up the discussion kinda tapered out. It would be good if someone or a group of people would volunteer to take this on and drive this project to its conclusion. -- Ricardo
Re: RFC: Portability should be a higher priority for Guix (was Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.)
Mark H Weaver writes: > Hi Ludovic, > > l...@gnu.org (Ludovic Courtès) writes: > >> Mark H Weaver skribis: >> >>> The end result is that the wishes of the x86_64-using majority are the >>> only ones that seem to matter in this community, and other users are >>> frequently left in a bad spot. This makes it increasingly unlikely that >>> we'll ever gain a significant number of non-x86_64 users. >> >> This kind of rant is really unhelpful. You’re shouting at someone who >> *is* doing the work of keeping things running. > > I wasn't actually shouting, but in retrospect I can see how it came off > that way. I apologize for any hurt feelings that I caused. > > This is not Marius' fault, and I didn't intend to target him > specifically. I'm grateful for the large amount of important work that > he does on Guix. > > However, I do feel frustrated by the fact that it's considered > acceptable in this community to leave non-x86_64 users with broken > systems in the name of "moving things forward" for x86_64 users. > > Portability is important to the long-term health of the free software > movement. Especially given that fact that Intel has long ago stopped > producing processors that can be used without large amounts of nonfree > software (including the Intel Management Engine), I think we should work > to ensure that Guix works well for users of non-x86_64 systems. > > The origin of this problem is not in the Guix project. Ultimately, it's > due to the fact that x86_64 has far too much market share among > GNU/Linux developers, and therefore the upstream projects upon which > Guix depends are not being sufficiently tested on other platforms. > > However, there is one aspect of Guix that is greatly exacerbating this > problem: our impatience to always have the latest software, even if it > breaks other systems, is a serious problem in my view. > > It means that if I want to ensure that Guix works well for i686 or armhf > users, then I would need to start trying to use Guix on those systems > for real work, which at the present time would entail almost > single-handedly fixing all of the portability bugs in all of the > software that I use, at the full pace of upstream development. I would > need to keep this up for long enough to make Guix appear to be a safe > choice for i686 or armhf users, so that some of them might help work on > these portability issues in the future. > > Another problem is that Guile 2.2's compiler has become so heavy that > it's nearly unbearable to use on slower hardware. Simply running "make" > in my Guix git checkout after updating on my mips-based Yeeloong is so > slow that I'm in the habit of letting it run overnight. > > So again, and I'm saying this calmly but with great concern: given the > current priorities of the project, I could not recommend Guix to users > of non-x86_64 architectures, and I don't see how we can fix that without > attracting more developers who use those architectures. However, I > don't see how we could attract those developers if we continue to > prioritize "moving forward" at full speed for x86_64 users, even when it > breaks other systems. > >> Generalizations about “this community” obviously make no sense. You are >> a part of “this community” so it cares just as much as you do. > > By that reasoning, since I'm part of the community of humans on planet > Earth, the community of humans on planet Earth therefore cares as much > about free software as I do. > > When I suggest that the community would not take certain suggestions > seriously, e.g. the suggestion to block upgrades or merges that would > break non-x86_64 systems, that statement has some meaning. I means that > I expect that most people here would disagree, and that the maintainers > would rule in favor of "moving forward" at full speed, and that it will > be the responsibility of the tiny number of non-x86_64 Guix users to fix > portability bugs as quickly as needed so that the x86_64-using majority > need not suffer any delays. The problem is, we would need a *lot* more > non-x86_64 developers in our community to make that work, and we cannot > attract those developers given the current policies. > >> Please let’s work in a friendly manner towards finding solutions to the >> problems. > > I'm open to suggestions. Do you see any solution to the problem of how > to attract more non-x86_64 users, given our current policies? > > Thanks, >Mark I am interested in helping with non-x86_64 issues. Particularly, helping with i686-related changes should be just a change in workflow, but I'm interested in obtaining freedom-respecting non-x86 hardware (or at least using a virtual machine as close as possible to real hardware configurations). Any recommendation or links for where I can get a Yeeloong laptop or what freedom-respecting armhf computers are available? signature.asc Description: PGP signature
