Re: Building a software toolchain that works
On 2022-03-18 07:27, Pjotr Prins wrote: On Thu, Mar 17, 2022 at 03:04:18PM -0500, Katherine Cox-Buday wrote: In addition, because free software is largely developed in people's spare time, they're going to use whatever tools make them most productive or even just happy. They're probably not thinking about their software against the backdrop of the larger software ecosystem. Agree. Though I would not underestimate these people involved in creating such ecosystems. Often they are not even on Linux. When the Dlang people created dub I pointed them to Guix. Obviously I failed to convince them. Guix solves a lot of issues, and is wonderful to use, but I don't think it solves the most difficult issues: human issues :) It is a complex world out there if you look at the mix of operating systems and compilers/interpreters. From my point of view GNU Guix greatly simplies development and deployment - targeting Linux - at the cost of some up-front investment. It is nice when people realise that so much complexity goes away living in a Guix world. Very interesting notes. And well don' think there is an understatement what so-ever that I basically agree with points here :) *I mean just was stated during the Guix online days a few weeks ago I think its "simplicity" that makes Guix such interesting and attractive project. And something which in turn I guess makes us motivated to contribute and further spread the knowledge about the power of Guix (and free software in general for that matter). -- Kinds regards Oliver Propst https://twitter.com/Opropst
Re: Interest in "guix lint" Meetup?
Hi, > I haven't really done this sort of thing virtually before; Where would > be a good place to host it? We are definitively lacking a BBB instance or something for that. :-) Depending on the numbers of participants, maybe Jami could be an option. IIRC, a service is around (an instance is even probably available) and the client just works with Guix (last time I tried, thanks Maxim! :-)) Well, I like the idea of one each day, for instance the traditional "advent calendar" done by Debian Med. Maybe it could also an option for this housecleaning. Say from now until April, 18th (Happy Birthday! :-)), let clean as much as possible: lint fixes, close irrelevant tickets, etc. The most productive people win a drink next time we will meet. :-) Another option to embark people (or for motivation) is pair programming. It could also ease the timezone constraint. Jérémy (jeko) wrote a nice blog post for a quick setup using Guix. https://rednosehacker.com/how-to-setup-a-remote-pair-programming-environment-with-gnu-guix (It appears to me being worth to turn it into a cookbook recipe, another story. :-)) Cheers, simon
Re: Interest in "guix lint" Meetup?
On Thu, 17 Mar 2022 21:04:13 -0400 Vagrant Cascadian wrote > I haven't really done this sort of thing virtually before; Where would > be a good place to host it? As an FSF associate member, you get access to the FSF's Jitsi meet instance (https://www.fsf.org/associate/benefits). I use it regularly and it works well. I'd be happy to host it.
Re: Interest in "guix lint" Meetup?
zimoun schreef op vr 18-03-2022 om 10:13 [+0100]: > maybe Jami could be an > option. IIRC, a service is around IIUC, the service is not required to hold a meeting, even among more than two parties. IIUC, one can simply create a ‘rendezvous point’, share the identifier and tell everyone to connect to the rendezvous point. No jami-service-type required unless you want to set up moderation or a list of allowed contacts. Greetings, Maxime. signature.asc Description: This is a digitally signed message part
Re: Building a software toolchain that works
On 2022-03-17 13:56, zimoun wrote: Hi Olivier, On another note, what I find fascinating is why Guix and Nix are not more used in academic papers. Indeed. One part of the answer is, IMHO: it is difficult to spread the word. For instance, with co-authors, we have tried to write a short paper detailing what Guix solves, i.e., the computational environment part of the “science crisis“, and targeting especially bioinfo folks. We got many refusals by the journals that bioinfo folks indeed read and we end in a “specialized” journal. On the top of that, add the fact that most of the time, people use what other people in their lab or collaborators already use. On the top of that, add the fact that the story of Guix on Windows or Mac is not really good. I am not arguing here, just to mention that many people are still using Windows or Mac and few one Linux variant. Therefore, all in all, the bootstrap of Guix is hard; as always. :-) The initiative Guix-HPC is an attempt to address that. The name is probably not fully representative since now it looks like Guix in scientific context; HPC being only one component. From my point of view, the bootstrap of Guix in scientific world requires more documentation materials for many common use cases and more popular applications or usual scientific stack. For instance PyTorch in Guix is one step but many things are still really hard to do with Guix when it is not elsewhere. Another instance is RStudio for bioinfo folks – it does not work out of the box with Guix when it does elsewhere. Help in these both areas – howto materials and popular applications – is very welcome. :-) Join the fun, join guix-scie...@gnu.org :-) Cheers, simon I run Guix including GUI applications from Windows via WSL2 (Windows Subsystem for Linux). It may help some to try it out if this setup was easier and more documented, though I suppose that is somewhat prevented to go via official channels by the FSDG guidelines. Best regards, David
Re: Building a software toolchain that works
Hello David, I am huge fan of Guix on WSL2 and I used to use it a lot 😄. And yes, it should be documented well (or even better, the installation should be made super simple) while as you mentioned, it might be easier to do this in another community. I don't share the ideology of hardline rejection of the use of proprietary software - I just need everything to be accountable, such as knowing which part of the system is Free and which isn't. (and of course more Free the merrier) Guix, the software, (IMHO, not necessarily the community unless a separate one is created) does the most perfect job for this 😄 -Yasu > On Mar 19, 2022, at 06:14, david larsson wrote: > > On 2022-03-17 13:56, zimoun wrote: >> Hi Olivier, >>> On another note, what I find fascinating is why Guix and Nix are not >>> more used in academic papers. >> Indeed. >> One part of the answer is, IMHO: it is difficult to spread the word. >> For instance, with co-authors, we have tried to write a short paper >> detailing what Guix solves, i.e., the computational environment part of >> the “science crisis“, and targeting especially bioinfo folks. We got >> many refusals by the journals that bioinfo folks indeed read and we end >> in a “specialized” journal. >> On the top of that, add the fact that most of the time, people use what >> other people in their lab or collaborators already use. >> On the top of that, add the fact that the story of Guix on Windows or >> Mac is not really good. I am not arguing here, just to mention that >> many people are still using Windows or Mac and few one Linux variant. >> Therefore, all in all, the bootstrap of Guix is hard; as always. :-) >> The initiative Guix-HPC is an attempt to address that. The name is >> probably not fully representative since now it looks like Guix in >> scientific context; HPC being only one component. >> From my point of view, the bootstrap of Guix in scientific world >> requires more documentation materials for many common use cases and more >> popular applications or usual scientific stack. For instance PyTorch in >> Guix is one step but many things are still really hard to do with Guix >> when it is not elsewhere. Another instance is RStudio for bioinfo folks >> – it does not work out of the box with Guix when it does elsewhere. >> Help in these both areas – howto materials and popular applications – is >> very welcome. :-) >> Join the fun, join guix-scie...@gnu.org :-) >> Cheers, >> simon > > I run Guix including GUI applications from Windows via WSL2 (Windows > Subsystem for Linux). It may help some to try it out if this setup was easier > and more documented, though I suppose that is somewhat prevented to go via > official channels by the FSDG guidelines. > > Best regards, > David >
Fetching sources using Guix (re: Building a software toolchain that works)
One of the side-threads in "Building a software toolchain that works" was essentially this: If I fetch sources for a package using Guix, with the intention to make changes and then build and test the software myself, what should we do with any patches & snippets that are part of the Guix package? There does not seem to be an obvious right answer. One reason is that patches and snippets fall into at least a few use cases: - The upstream package won't build at all as-is using the environment Guix creates, so we apply a patch to enable a successful build. - Upstream vendors some sources into their package, which we prefer to excise using a snippet so that we can do our own dependency management - Upstream includes non-free components, which we remove to build a fully free package - Upstream includes binaries in their package, which we prefer to snippet out so we can build them ourselves At present we don't include any semantic information with each patch or snippet to explain why it is needed. Many have helpful comments; some don't. Would it be feasible or desirable to create a set of "reason" symbols, similar to our "licenses," and attach a reason (or unknown?) to each snippet and patch? Then we can expose meaningful data to the end-user about patches & snippets that are available, enabling an informed choice about whether to apply them when fetching sources. This could also be useful in our own record-keeping, so that we can track the usage of patches and snippets for different reasons. It would be nice, for example, to see a downward trend in the number of patches for build systems that won't work at all without them, either because we improve the logic in our build steps or because we contribute changes upstream to make software easier to build.
Guix as a system vs as an end-user dev tool (re: Building a software toolchain that works)
One side-thread in "Building a software toolchain that works" notes that Guix faces challenges for adoption because it's not readily available to users of proprietary operating systems like macOS and Windows. I've witnessed over the past decade that GNU/Linux development on other platforms has become widespread, in large part due to the availability of the Docker for Desktop application which packages a lightweight, automagically managed GNU/Linux virtual machine running the Docker daemon with Docker client software built for the target platform. A user of Docker for Desktop on a proprietary OS can run "docker" commands which transparently execute commands inside a GNU/Linux container, making building and testing software quite convenient and reproducible without needing to set up cross-compile toolchains or spend time managing VM software. It makes absolute sense to me that Guix is not interested in building a native distribution for the Windows or macOS toolchains. One of Guix System's unique strengths is its adherence to the GNU FSDG and I don't think that's incompatible with making the Guix tools more generally available to end-user devs hacking on software using a proprietary OS. Technically, I think we could use a similar approach to the Docker for Desktop system: a "Guix for Desktop" installs software to create and manage a minimal Guix System virtual machine which automatically updates and reconfigures itself, requiring no manual administration by the end-user. And it would install a Guix client that connects to the Guix daemon running in the VM using a shared socket, enabling users to incorporate Guix transparently into their workflows. I think this would be a compromise for certain, the same way it is for Emacs and other GNU flagship projects that run on non-free systems. On the one hand, it serves to make those systems more valuable, which undermines our cause. But on the other hand it provides a major on-ramp to free software and superior build tooling, positively impacting the practical freedoms available to the end-users who adopt Guix. wdyt?
