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

41–50 of 62 posts

Re: GNU Shepherd 0.5.0 released

#41

Post by lfam »

theamk wrote: post #36

Does anyone know if they solved their "trust init script too much" problems? 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.

Can you give any more detail about this? Or a reference to a bug report or mailing list thread?

Re: GNU Shepherd 0.5.0 released

#42

Post by serhart »

tacolizard wrote: post #21
serhart wrote: post #7

Earlier quoted context omitted.

Not true. You can write your own packages in the same high level interface. Including the mainline Linux kernel and broadcom drivers. I have GuixSd running on my 2013 MBP

can you tell me how you got that running in some more detail? I also have a 2013 MBP and would like to try out GuixSD

I don't have access to it now. When I do I can put the package definitions and OS config up somewhere.

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/

Re: GNU Shepherd 0.5.0 released

#43

Post by dreamofkoholint »

_emacsomancer_ wrote: post #26
rufugee wrote: post #23

Earlier quoted context omitted.

Same here...as a NixOS user, I really wish it used scheme instead of the nix language. 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.

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.

Do you have more detail/instructions on running Nix on GuixSD?

Re: GNU Shepherd 0.5.0 released

#44

Post by theamk »

lfam wrote: post #41
theamk wrote: post #36

Does anyone know if they solved their "trust init script too much" problems? 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.

Can you give any more detail about this? Or a reference to a bug report or mailing list thread?

The manual [1] starts by saying: "When shepherd gets started, it reads and evaluates a configuration file." That config is full-featured, seemingly unrestricted, lisp file. While I saw some mentions of handling syntax errors on the mailing list, I saw no mentions of what happens if there is an infinite loop or if a script just reads a huge files and OOM's the process.

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

Re: GNU Shepherd 0.5.0 released

#45

Post by zeveb »

bjoli wrote: post #38
zeveb wrote: post #22

Earlier quoted context omitted.

Scheme is a neat little language, but it's really not ideal for writing full software systems. Indeed, Guile & Racket (back when it was PLT Scheme) are perfect exemplars of Greenspun's Tenth Rule: Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. E.g. GOOPS is similar to CLOS, but missing a bit and unsupported other than…

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

0: http://paulgraham.com/avg.html

Re: GNU Shepherd 0.5.0 released

#46

Post by rufugee »

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'd like to understand this as well. It's a viable option for me if it truly works.

Re: GNU Shepherd 0.5.0 released

#47

Post by rufugee »

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…

Can you explain why it's not ready systems work?

Re: GNU Shepherd 0.5.0 released

#48

Post by rufugee »

xfer wrote: post #35
rufugee wrote: post #24

Earlier quoted context omitted.

I use nixos, not GuixSD, but I can speak to "what would be the advantages and disadvantages", particularly since guix is a reimplementation of nix. 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…

For me, the problem isn't so much with the nix language(it's very similar to haskell), but the lack of discoverability for docs of library. The manual is mostly incomplete and i often have to look at sources. 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.

Interesting... I've found the manuals to be ok so far. Can you share what you've had problems finding?

Re: GNU Shepherd 0.5.0 released

#49

Post by agumonkey »

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.

who's working on guile 3.0 ? I thought wingo was too employed~ :)

ps: well I was wrong, it's wingo as usual https://news.ycombinator.com/item?id=18077710

Re: GNU Shepherd 0.5.0 released

#50

Post by _emacsomancer_ »

dreamofkoholint wrote: post #43
_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.

Do you have more detail/instructions on running Nix on GuixSD?

Just install the standalone Nix installer like you would on any other (non-Nix) distro (see this part of the Nix manual: https://nixos.org/nix/manual/#chap-quick-start ). Both Guix and Nix are designed to work on top of 'foreign' distros, and this includes using a standalone Nix package manager on GuixSD and a standalone Guix package manager on NixOS (or both the standalone Guix package manager and the standalone Nix package manager on top of Arch Linux, etc. etc.)
Post reply on HN