Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GNU Shepherd 0.5.0 released

lists.gnu.org

Post reply on HN
Print view View original

51–60 of 62 posts

Re: GNU Shepherd 0.5.0 released

#51

Post by _emacsomancer_ »

yorwba wrote: post #32
_emacsomancer_ wrote: post #26

Earlier quoted context omitted.

Guix does have the capacity to add 'channels', e.g. https://gitlab.com/mbakke/guix-chromium , so while non-free software while never be part of the distribution itself, it could be done unofficially. Also, you can run the Nix standalone on top of GuixSD, so you could run GuixSD and then use Nix to install whatever's missing.

> you could run GuixSD and then use Nix to install whatever's missing. 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

I'm not certain about CUDA drivers and whether this sort of thing work "just work" via the Nix package manager on GuixSD. That sounds like you might need to recompile kernel headers or the like.

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.

Re: GNU Shepherd 0.5.0 released

#52

Post by _emacsomancer_ »

There's a quote from the GNU Shepherd manual I really appreciated:

> 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.

Re: GNU Shepherd 0.5.0 released

#53

Post by _emacsomancer_ »

noobermin wrote: post #39
dreamofkoholint wrote: post #17

Earlier quoted context omitted.

There are a smattering of code snippets around 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 be…

As someone who is sympathetic to their cause and their stance, I think the extreme position of excluding all non-free software can actually hamper the movement by making it less accessible to people. I get you always have to draw a line somewhere, but FSF draw it too firmly.

> you always have to draw a line somewhere, but FSF draw it too firmly.

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.

Re: GNU Shepherd 0.5.0 released

#54

Post by bjoli »

zeveb wrote: post #45
bjoli wrote: post #38

Earlier quoted context omitted.

I find many common lisp users' attitude towards scheme condescending. It is as if we are completely oblivious to the CL ecosystem or outright stupid to prefer something else. 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 find many common lisp users' attitude towards scheme condescending. 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 fo…

I have written applications weighing in at about 10k lines of code (not huge, but big enough to have to manage some complexity) using LispWorks. I doubt I would have problems writing the same software in guile. I don't really understand which inadequacies you mean.

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!)

Re: GNU Shepherd 0.5.0 released

#55

Post by rekado »

nerdponx wrote: post #25
serhart wrote: post #13

Earlier quoted context omitted.

None that I know of currently. The OS is version 0.15.0. It's very young and doesn't have a huge user base. I'm sure there will be non gnu repositories that will eventually spring up. I've even toyed with the idea of setting one up.

Even as a toy example, a blog post and code that demonstrates setting up a 3rd-party package repository would be helpful. I'm just afraid of the GUIX team deciding they don't want to support 3rd-party repos because it encourages non-free software use, and deliberately stonewalling development of related features.

Guix has had support for external package definitions for a long time (via GUIX_PACKAGE_PATH) and recently gained a channels feature, which makes this even easier.

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" ;)

Re: GNU Shepherd 0.5.0 released

#56

Post by rekado »

yorwba wrote: post #32
_emacsomancer_ wrote: post #26

Earlier quoted context omitted.

Guix does have the capacity to add 'channels', e.g. https://gitlab.com/mbakke/guix-chromium , so while non-free software while never be part of the distribution itself, it could be done unofficially. Also, you can run the Nix standalone on top of GuixSD, so you could run GuixSD and then use Nix to install whatever's missing.

> you could run GuixSD and then use Nix to install whatever's missing. 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

If you have a Guix package definition for CUDA then you can install it. There's no need to use Nix when Guix can be easily extended.

Re: GNU Shepherd 0.5.0 released

#57

Post by nerdponx »

rekado wrote: post #55
nerdponx wrote: post #25

Earlier quoted context omitted.

Even as a toy example, a blog post and code that demonstrates setting up a 3rd-party package repository would be helpful. I'm just afraid of the GUIX team deciding they don't want to support 3rd-party repos because it encourages non-free software use, and deliberately stonewalling development of related features.

Guix has had support for external package definitions for a long time (via GUIX_PACKAGE_PATH) and recently gained a channels feature, which makes this even easier. 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 t…

Thanks for the reply. As long as it's easy to mix free and non-free packages at my discretion, I'm willing to give it a shot.

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!

Re: GNU Shepherd 0.5.0 released

#58

Post by davexunit »

zeveb wrote: post #45
bjoli wrote: post #38

Earlier quoted context omitted.

I find many common lisp users' attitude towards scheme condescending. It is as if we are completely oblivious to the CL ecosystem or outright stupid to prefer something else. 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 find many common lisp users' attitude towards scheme condescending. 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 fo…

>But the language as it exists simply isn't ready for systems work, and (due to its underlying philosophy) probably never will be.

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.

Re: GNU Shepherd 0.5.0 released

#59

Post by equalunique »

logicchains wrote: post #15
bjoli wrote: post #12

For anyone interested in guile, guile 3.0 will have a JIT, making it even faster than 2.2 (by quite a large margin). Guile is becoming really nice, and I find myself reaching for other lisps less and less.

How far along is it towards becoming the underlying runtime for Emacs lisp?

https://www.emacswiki.org/emacs/GuileEmacs

Re: GNU Shepherd 0.5.0 released

#60

Post by equalunique »

rhabarba wrote: post #2

> The GNU Shepherd is developed jointly with the GNU Guix project Wasn't it made for the hurd?

Yes it was, but more activity with Shepherd is occurring in the Guix SD project.

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).

Post reply on HN