GNU Shepherd 0.5.0 released
lists.gnu.org
lists.gnu.org
The fact that they’re using Scheme for so much of it is also pretty cool, as I think this sort of high level systems programming is a great potential use case for showcasing meta programming as well as the unique power of lisps for code-as-data.
However, I do like the pragmatic nature of NixOS (you're able to easily install non-free packages). GUIX doesn't make this easy at all from what I understand. I appreciate those virtues, but practically speaking, I have to use non-free software on the desktop all the time.
How much cooperation between the two is necessary? If I wanted to install CUDA drivers with Nix would it "just work" (i.e. if it works on NixOS it works on GuixSD) or could GuixSD make problems?
I found a comment from a year ago claiming that the kernel wouldn't load blobs: https://news.ycombinator.com/item?id=14630581
Re: the comment about the Guix kernel and blobs: Guix uses the linux-libre kernel which has blobs removed. BUT you can use a custom kernel on Guix, so you could use a blobby kernel, but you would have to configure it. If you poke around, you can find examples of people doing this, e.g.: https://gist.github.com/TeMPOraL/306bbb7c627ab0d32fa84af8319...
But, in general, the standalone Nix package manager (and the standalone Guix package manager, for that matter) are designed to work as isolated units, not depending as much on the 'host' system, so lots of stuff does 'just work' regardless of whether the host distro is GuixSD or Debian or Void or Arch or whatever.
Guile is becoming really nice, and I find myself reaching for other lisps less and less.
Elisp code runs fine under guile, but it has seen virtually no optimisation work and does a lot of unnecessary work. I suspect there is an lot of low hanging fruit, but since there is virtually no interest in guile-emacs apart from in comments on HN and Reddit I doubt the situation will get much better.
The guile VM is getting better and better though. Maybe they'll come around by guile 4 :)
I have no idea how viable that is, but it would be pretty sweet. Too much for me to take on right now, but the idea has been rattling around my brain for a few years.
Meanwhile, implementations like SBCL are free, compile to machine code and are competitive on some benchmarks with C/C++.
Common Lisp — while it does have some warts — is intended for building long-lived, durable, full-featured systems. It's a really good language, and it standardises quite a lot. Often, what look like warts are actually useful features in large systems.
It really saddens me that so much effort has been expended trying to make Scheme a reasonable language for large systems, when there already exists one which is. That doesn't even get to the bits of Scheme which I believe are mistakes (e.g. a single namespace, making NIL, () & #f different).
I assure you, we look in envy at CL and what a standardised module system, portable networking and CFFI achieves. However, we still prefer scheme. Some of us actually like a single namespace, and don't mind the difference between false and nil (I have never really met a case where that distinction mattered much).
Are you familiar with the Blub Paradox[0]? I contend that the things you dislike about Common Lisp or don't mind about Scheme having or not having are precisely the things which make Lisp better for real-world systems.
My opinion — a professional, educated & considered opinion, but an opinion nonetheless — is that Scheme is simply not suitable for large-systems work, and that all attempts to take a Scheme core and make it suitable founder on the shoals of Greenspun's Tenth. The Scheme maintainers agree, because in R6RS they tried to build a more capable language. The Scheme community agrees, because it rebelled against R5RS, deeming a more capable Scheme an un-Scheme-like Scheme.
I like Scheme. It's a pretty, elegant language, with an exciting model. But the language as it exists simply isn't ready for systems work, and (due to its underlying philosophy) probably never will be. That's not a bad thing. Scheme is great for what it is. It's great for teaching; great for reasoning about computation; great for learning evaluators & compilers. But it isn't great for building systems like an OS, emacs, a distribution, a package manager, an init system or a window manager — and the effort spent working on making its inadequacies tolerable could instead be spent on implementing features in a more-than-adequate language.
Also, Lisp doesn't have portable networking. That's one of its warts (I did say it has them — and plenty of them! Lisp is not perfect!). It does have portable streams (and I think all implementations make sockets available as streams), but Scheme's ports are analogous.
Neither is CFFI standarised.
The only thing I really miss is conditions and restarts (which is a pretty big downside) and how integrated CLOS is (and the fact that LW pre-populates the CLOS caches is pretty neat!)
One of the flaws with this argument is insisting that comparisons be made between CL and standard Scheme. No one uses strictly standard Scheme. It's better to think of Scheme as a family of loosely connected languages. I know that both Guile and Racket are languages (and they are their own unique languages) capable of serious systems work. CL is great, too, but I don't know why you keep insisting that it's the only lisp worth using. The Guix developers have shown that Guile can be used successfully for the initial RAM disk, init system, package manager, configuration management system, continuous integration system, web site generator, etc.
The plan is to use the JIT as a first step to do AOT compilation to native code and thus come a bit closer to the speed of chez. Hopefully quite a bit closer.
This is what I have gathered from Andy Wingo's mailing list posts, so grains of salt for everyone!
If you never used CML you should try it out.
ps: well I was wrong, it's wingo as usual https://news.ycombinator.com/item?id=18077710
This makes me wonder about the GuixSD distribution. Is this distro ready for prime-time. Suppose I switched from Linux Mint to GuixSD, what would be the advantages and disadvantages?
I like Lisp and program in Racket, so Guile wouldn't be far from that. I just wonder about experiences of other. How much does switching to such a lesser known free distro as the main OS "constrain" you?
You'd lose a lot of software choices. Actually, the restriction to "GNU-friendly software" was what made me skip GuixSD so far. I guess that my WiFi wouldn't work.
At the institute where I work we use this feature to provide package variants that aren't going to be added to Guix proper (e.g. because they are no longer supported upstream or because they are only useful on obscure systems).
This mechanism can be used to include package definitions for non-free software, of course, but this doesn't mean that the Guix project encourages the use of non-free software.
You have the freedom to package up and use non-free software, but we won't make them part of Guix, build them on our build farms, and we won't hold back changes to the mechanism even if that might break 3rd-party collections of non-free software.
You don't really need a blog post about how to set up a package repository, because it's right there in the Guix manual.
PS: It's "Guix", not "GUIX" ;)
Also, thank you for the capitalization correction. It grinds my gears when people capitalize things unnecessarily and I wouldn't want to be one of them!
This[1] is the one I used as a reference for my kernel build which includes brcmfmac
There is also a feature called 'channels' (not widely documented AFAIK) which allows you to describe an outside repository of code you can reference to install packages. There is one[2] that provides Chromium (though I cannot get the build to succeed).
The downside to all of these not being provided in mainline is the amount of time and energy to build them. I suspect there are more people than I would like curating their build of the linux kernel, manually specifying drivers included in the kernel. I really wish the community were a little less hard-set on the principle of 'freedom' and a little more pragmatic; I am sure the community is smaller due to people being turned away at the sheer amount of effort required to get their machine to a usable state.
[1]: https://github.com/wingo/guix-nonfree [2]: https://gitlab.com/mbakke/guix-chromium
They actually don't draw it exactly where I would. I don't care so much for games if they're open/free or not (it's nice when they are of course), but I am concerned with unauditable code on, for instance, the SATA controllers in my machine, even if it 'read only' code. Where the FSF is more concerned with the first and less with the second.
On the other topic, I think the ability to create (and share) your own recipes/channels for software on Guix allows for people to create fairly easy ways to install non-free software (or using Nix on top of GuixSD) without the Guix team having to support unethical software.
When you first boot GuixSD most of the core stuff should work fine. Wireless will not work but you should have ethernet. I created mainline linux kernel and firmware packages [1]. Then you need to get the broadcom b43 firmware to get wireless support. I think I made 2 packages. One for b43-fwcutter and one the broadcom-wl firmware which uses b43-fwcutter to cut and install it. I think just about everything on my MBP was working after that.
[1] example linux package https://github.com/wingo/guix-nonfree/blob/master/gnu/packag... [2] http://linuxwireless.sipsolutions.net/en/users/Drivers/b43/
https://gist.github.com/steve-ayerhart/81c9dfc773472e08002cd...
Guix includes free software packages of all sorts (more than 8k today), be it "GNU-friendly" (whatever that means) or not; you can browse them at https://guix-hpc.bordeaux.inria.fr/browse .
> I guess that my WiFi wouldn't work.
Maybe, maybe not; see https://gnu.org/s/guix/manual/en/html_node/Hardware-Consider... (the same issue applies to other distros that value user freedom.) Note that you're talking about GuixSD here, not Guix, which can be installed on top of other distros.
In the end the choice is up to each one of us. It's also up to us to determine what to do with hardware companies that deny us, collectively and individually, the right to control the devices they sell us.
The benefits to me are immense, because I travel between around six machines on a daily or weekly basis. Prior to moving to NixOS, I'd have to manually keep those machines in sync in terms of software installs, etc. However, after switching to NixOS, I have a set of files I version control which will declaratively build the system the way I want it.
So, if I install a new package and I'd like it be the same across all machines, I simply configure it, commit to git, and then pull down the config on the other machines and do "nixos-rebuild switch". Everything becomes exactly the same.
It's saved me so much time in terms of managing my computing life. I really couldn't see going back to a regular distro after using one which is declarative.
The drawbacks? Well, for one, Nix and Guix have various tricks with symlinking, etc, to make it appear to applications as if it's a typical Linux filesystem, but it's not. E.g. there's no /lib, etc. It's a little weird getting used to.
And with nix, there's the nix language, which isn't that difficult to learn but it's not my favorite. If the underlying language needs to be functional, I'd prefer a lisp over nix. Also, with nixos, there are too many different commands required to learn when you get deeper into it, but work is underway to improve that story.
At least for me...the benefits far outweigh the risks. I don't think I can ever go back. I think there's a real opportunity for a commercially-backed declarative Linux os...it really is a game changer and would do well in the enterprise.
My most favourite thing is that i can just override the packages to compile and install a new version/extra configure flags of a package that's not yet upstream.
With a good deamon manager, we're one step closer to HURD!
Last time I checked, they were loading user-defined scripts right into PID 1, so a badly written script could bring down the whole system.
People blame systemd for pid 1 instability, but at least systemd crashes get fixed eventually. With Shepherd, any package on the system can cause PID 1 to crash, and this just seems to crazy for me.
Now, one could imagine that maybe configs are parsed in a separate process, and then serialized and shipped to the main process for safe execution. But it does not seem to be the case -- the manual explicitly says you can use any Guile code to start processes, not just a safe subset.
Another option is that maybe there is a thread or a forked process for parsing config. But this does not seem to be the case either -- the manual does not mention that, and searching of the source code for "fork" or "thread" or "timeout" does not seem to indicate anything related.
The only mention of timeness expectation seem to be a single sentence "Actions are expected to be non-blocking." in one of the mailing lists [2].
So together, it seems to me that any bad script will just cause the daemon, and by extension the whole system, to not start.
[1] "https://www.gnu.org/software/shepherd/manual/shepherd.html#S...
[2] http://lists.gnu.org/archive/html/guix-devel/2016-11/msg0094...
I'm outside of my Debian comfort zone, apologies for my ignorance! What's significant about this?
> I decided to not make it too sophisticated by trying to guess what the user might want just to theoretically fulfill the request we are processing. If something goes wrong, it is usually better to tell the user about the problem and let her fix it, taking care to make finding solutions or workarounds for problems (like a misconfigured service) easy. This way, the user is in control of what happens and we can keep the implementation simple. To make a long story short, we don't try to be too clever, which is usually a good idea in developing software.
Wasn't it made for the hurd?
Guix has also been ported to Hurd, so it's all going to be one big happy family (one day when Hurd finally gets USB and 64-bit support).