rekado

Conda does not solve the problems of deployment and they don't have any reproducibility guarantees. That's not surprising considering how Conda binaries are built.

I use a Guix manifest for every project, which describes what dev tools and dependencies I want. When I enter a directory the shell automatically evaluates the manifest and all my tools are ready.

With tooling for deployment I prefer to heed an adaptation of Greenspun's Tenth Rule. Neither Guix nor Nix are really all that "complex" from a user's perspective.

Chinese. https://en.wikipedia.org/wiki/Chinese_punctuation

Chinese uses different symbols for punctuation and the comma in particular is surrounded by padding.

I'm using it on Guix via the Rosenthal channel: https://codeberg.org/hako/rosenthal.git

I quite like it because it's more predictable than automatic tiling window managers and generally less work than manual tilers. (I've used tilers since maybe 2010 with xmonad.)

I really dislike the cartoons, because they are carelessly generated images. On the first look they appear to be actual cartoons (you know, where details were deliberately placed to convey meaning), but the more you look the more confusing they get because it seems that most details here are accidental.

To me bad illustrations are worse than no illustrations. They also reflect poorly on the author, so I'm much less inclined to give them the benefit of the doubt, and probably end up dismissing their prose.

It is documented here: https://github.com/YaLTeR/niri/wiki/Xwayland I use xwayland-satellite (for Emacs) and I can copy text in Emacs to a terminal running on Wayland.

In all those years working on and playing with free software, I still cannot understand the incessant need for badmouthing other projects and calling things "half-assed". What a destructive habit!

If you like this you may also be interested in Emmett Chapman's Offset Modal System:

https://www.stick.com/method/articles/offsetmodal/ https://www.stick.com/method/articles/parallel/

Teenagers have to get up too early. Teenagers experience a shift in their circadian rhythm and also require more sleep than before puberty. School schedules do not account for this shift.

`guix pack` can create bundles that use a static proot to make them relocatable:

https://hpc.guix.info/blog/2017/10/using-guix-without-being-...

It also supports other more performant ways, but in some situations proot is the best choice.

I think stating it this way gets the history backwards. The live bootstrap came about as a separate implementation of what had been done for Guix earlier. It then became a proving ground for new ideas, which then fed back into Guix.

This may be of interest: https://programming-journal.org/2023/7/1/ "Building a Secure Software Supply Chain with GNU Guix"

I'm using Guix System on my rockpro64. I patched uboot to allow it to boot via SATA. (One of the patches I needed was to ignore a spurious CPU reset while enumerating SATA devices.)

Identity in this sense: https://en.wikipedia.org/wiki/Identity_(philosophy)

Humans already have ways to build software on macos, so why bother doing it with something called "Guix" if the thing that we would necessarily --- and for technical reasons --- end up with bears little resemblance to Guix? If someone sees value in that, enough to warrant converting resources to realize this value, they are welcome to do just that.

Note that we also have a way of using Guix as it is on macos via virtualization of Guix System. It also sits atop a large binary blob (the size of the native bits of the qemu closure), just like a macos-native bootstrap of the roots of the Guix graph does.

Clearly we do not have a shared understanding of identity.

What is the real reason then? Please enlighten me, because I have been blocked by these technical issues in my past attempts to bring Guix to macOS. Guix is built around glibc and there is no glibc port for macOS. Using XCode for everything is like replacing a bicycle drive train with a steam engine; I guess it's still a vehicle of some sort, but Theseus is still unhappy with his new ship.

You can use Guix on macOS with https://superkamiguru.org/projects/msg.html, but it's probably not what people want when they ask for macOS support.

Guix has the nonguix channel, which provides the vanilla Linux kernel and other packages that contain blobs or nonfree parts: https://gitlab.com/nonguix/nonguix/

It's part of Guix. It starts here: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages...

The technical details of the quote are correct, but FWIW I'm no longer working on the GHC bootstrap. It's fun for a while but the lack of interest in the Haskell community and the general high level of ridicule and hostility from the rest of the software world towards all things GNU / free software / bootstrapping have kinda turned me off the whole computer thing.

I've built up to GHC 6 (I've stopped after reaching 6) from GHC 4. GHC 4 does use some generated C files, so it's not a pure bootstrap, but it's still much better than taking a binary of GHC 6 or later.

(I'm the author of the 2017 blog post. I had planned a follow-up but since I didn't have much to show I scrapped it.)

CUDA is available in the guix-science-nonfree channel. https://hpc.guix.info/channels/non-free/

I use a Samsung S4 mini with it. There are unofficial builds for it, but it's not the most pleasant experience.

On any Guix System you can use the childhurd service or generate a disk image. More details here: https://guix.gnu.org/en/blog/2020/childhurds-and-substitutes...

> quite hostile to any implementation on non-Linux platforms

Guix has a usable Hurd implementation, which is a "non-Linux platform".

> But you're not the spokesperson for Guix, are you?

I used to be co-maintainer and I'm working close to full time on Guix. I also happen to have worked on Guix on Mac before; in fact I'm involved in the very mailing list thread you dug up.

We are familiar with the way Nix does it on Mac, but I won't repeat my assessment here. Doing it with XCode and adding an arbitrary cut to the graph would get us to something that resembles Guix only in uninteresting ways.

Well, there's nobody blocking the work. If not I then surely somebody would personally have to do it. And it's akin to building a completely separate distribution on top of a different foundation, so we could only superficially reuse existing infrastructure.

I'm writing my comments in the first person, because I have actually made the effort to investigate this in the past, more than once.

This is precious little to do with some kind of abstract purity. Hell, I've packaged Tensorflow and CUDA crap, which is as far removed from purity as it gets.

It gets a little tiring to read about values that are projected onto Guix, that I can't find in my own work.

Forking code is easy. Forking a community is not and you end up with lots of duplicated work to the detriment of both groups.

Not hostile. We just can't do it. There is no free toolchain for Mac. So we'd have to arbitrarily cut the trust graph and graft it on top of a huge blob of a proprietary toolchain and set of system libraries. That's like building a completely new distribution. Since I'm not using macos and have no interest in committing my own money to keep paying for freedom restricting software to provide a service that would earn the label "supported" there's no way I'm going to make that effort.