Quick Tool NotesSun Feb 8, 2015
This is a thing now. And it wasn't for a very long time. I remember sitting down and honestly trying to figure out how I would go about getting a Yeeloong to Toronto. Eventually concluding that my best bet would be to learn Mandarin, then hang out around Jiangsu-based chatrooms/IRC channels and try to to make friends. This seemed like more work than I could realistically do, so I didn't. Instead I've been piloting a Lenovo x220i and putting up with this
~ $ vrms Non-free packages installed on self firmware-ralink Binary firmware for Ralink wireless cards firmware-realtek Binary firmware for Realtek wired and wireless network 2 non-free packages, 0.1% of 1672 installed packages. ~ $
Anyhow. That first link I put up earlier takes you to a CrowdSupply page that promises to ship a fully Free(Libre) 15-inch laptop in another couple of months. I've already been looking for a new machine for a year or so, and this is officially cool enough to get me to pull the trigger. So I've ordered one in the interests of being the canary; I'll let you know how it runs once I get mine, at which point I expect I'll be able to recommend it thoroughly.
To be clear, the goal here isn't "get a good deal on a laptop". This thing is going to cost me something like three or four hundred bucks above what I'd pay for a Lenovo piece. But. I'm committed enough to the idea of freedom in computation that I'll willingly pay that in order to subsidize a company with the same goals.
On the other side of the development coin, "purely functional" build systems/package managers are becoming a popular meme.
I mentioned last time that I was seriously considering getting a separate, frequently-snapshotted, VM for the purposes of Haskell development. To that end, I briefly looked at Qemu and Docker, before hearing about
nix. And shortly thereafter
guix. The idea behind both of these package managers|1| is that you never throw away a package. That is, when you "upgrade" a library or piece of software, you build the new version from scratch, sharing identical pieces but building any new dependencies non-destructively. Which I assume is the reason they both use the "purely functional" label, despite the fact that both clearly write information to disk, but I digress.
What this gives you is two things.
- First, because you still have the older versions of everything around, it's easy to revert back to a known-working state of the world. This sounds extremely useful when it turns out that the new version of
hasteneeds you to re-install half of fucking
hackageand still won't run.
- Second, because a particular build is self-contained and always internally consistent, you can easily share build artifacts across several local machines. That previous link was
nixspecific, but according to the
guixRequirements listings, you can run
guixas a front-end on a
nixstore, so you could use it either way. This sounds useful in the situation where you need to bring up a new machine with the same software stack; if you can share between local machines that have any particular piece installed, you can do it faster and with less external traffic.
Those two things are exactly the goals I had when looking at
docker for Haskell development. Which means that for my purposes,
guix directly obsoletes any kind of virtual machine setup. This isn't a general property, so don't let it stop you from putting some reading time into Xen, but I have very little reason to in the near future.
guix is another matter. As I mentioned, the
guix docs imply that I won't have to. And they both take the same general approaches to building software. The big difference, as far as I'm concerned, is that the
My GNU fanboyism and affection for parentheses is well documented, so I expect that predicting the outcome isn't hard here. Still, I plan to try both of them out to see how they feel. As always, I'll let you know how it goes.
1 - |back| - Both of Which have had full-on linux distros built around them, if that's your thing. Nixos for
nix and "Guix System Distribution" for