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.
There is a certain sense of "the leopards won't eat my face" that crosses my mind every time someone writes about skills in the age of AI but then inserts generated images.
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!
It does seem that I include all Chapman's scales (while saying nothing about chords), although oddly enough he's chosen to use the modes of harmonic major but not those of its inversion, harmonic minor?
Edit: In fact I found the second link (first one's pretty vague and wasn't enough for me to follow the diagram) relevant enough that I added a paragraph to point out the connection!
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.
But can it pack the whole system? I've been trying to run Guix on my Android for a while without resorting to a full VM. Nix has a custom termux, and lots of distros run under proot under termux[0], but seemingly not Guix.
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.
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.)
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.
Unwillingness to compromise, as you might recall from our last conversation on the topic. This is your right, but framing it as a technical problem is incorrect.
You don't have to use it for everything, that's a straw man. If Guix-darwin was willing to accept some impurity, you could probably use XCode just enough to bootstrap a glibc and compiler chain, and then dispense with it.
Having a completely verifiable toolchain is a laudable political goal, not a technical requirement.
nix-darwin's existence clearly shows there are no technical obstacles to an equivalent guix-darwin.
Believe me, I wanted to like Guix. I'd prefer a Lisp over the nix language, easily. But I'm losing respect for the project based on its messengers.
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.
We're going around in circles now. I believe the Guix equivalent to something like nix-darwin would still be sufficiently guix-like (like a new language impl) to be worthwhile. You believe it wouldn't be guix, and iiuc, nothing short of your vision of guix would be guix, and since that can't be done from top-to-bottom on macOS, guix can't be done. I take it you don't view nix-darwin as nix?
And yet, the nature of identity is always in flux. You are not made up of the same atoms as when you were an infant. Many lines of code in a software project change, and yet it remains the same, ship-of-Theseus style.
Guix's identity could encompass a guix-darwin side project and still remain guix. You think of it as a technical issue, but it's only your choice of what guix means that entails that view. Which comes right back around to my assertion that no macOS support is fundamentally a political choice of guix's devs, not a technical problem.
> end up with bears little resemblance to Guix
Based on my experience with nix-darwin, this seems like exaggeration, and I think most others would agree.
> 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.
You are possibly the only person who is using "binary-blob-at-root" as equivalency criteria. Are you genuinely confused why macOS users aren't just using the Qemu Guix? Part of the appeal of nix/guix on mac is not having to pay the virtualization cost.
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.