We're building the GNU system [pdf] | Hacker News Reader

We're building the GNU system [pdf]

git.savannah.gnu.org

149 pointsrev60 comments

Maybe it's just me, but I find -- style flags that are actually commands to be extremely irritating. The new firewall-cmd system is an example of how obnoxious this can be, where every operation requires arbitrary -- prefixes.

While git has received a lot of well-deserved criticism for it's complexity, "git commit" is a lot better than "git --commit".

I knew someone would complain about the longopts shown in the slides. That was done to make it easier to understand. Normally, you'd just use the short flag, '-i' instead of '--install'. Also, in Guix, you would say 'guix package', not 'guix --package'. A full example would be 'guix package -i emacs', which looks fine to me.

You're missing the point, it's not about the longopts. install is a command, not an option of a command.

Install is not a command, it's a possible transaction type of 'guix package'. Since Guix is transactional, it's perfectly valid to install and remove software at the same time: guix package -i emacs -r zile

I suppose you could see it like that although I don't see the use of it. Why not just have straight-forward commands like `guix install` `guix uninstall` `guix search` `guix update`

It's going to be much easier to read something like the above,

    guix package -i emacs -r zile

than your alternative:

    guix package install emacs remove zile

Bear in mind that a transaction could get arbitrarily long.

"Much easier" obviously means something different for you. So many utilities have "-r" meaning "recursive", for example, so it requires a real mental shift to think of it in these terms.

Describing transactions with arguments seems clunky at best.

"Much easier" because you can quickly tell the difference between a package you're installing or removing, versus the action to be taken with the package - as opposed to a bunch of strings of the form [a-z0-9]+ that you can't scan and need to actually read.

For your convenience, the link to the "mothership" NixOS: http://nixos.org/

I've been using NixOS happily for over a year now. The "secret sauce" is the same between Guix and NixOS. The main differences are:

* Programming language (Guile vs Nix)

* Choice of basic building blocks such as dmd / systemd

* Strong preference for GNU tools in Guix

* No support for unfree packages at all in Guix (in NixOS, they're disabled by default, but you can enable them)

Just curious. For anyone who has used both Nix and Guix, which one do you prefer, and which do you think is more likely to gain traction (ignoring the 800lb gorillas of deb and rpm, for the moment)?

I have used both NixOS and Guix and can say that I definitely prefer Guix. Internally, the package manager is really the same. On the interface side, Nix uses its own functional programming language, while Guix uses Scheme which I am used to and prefer syntax-wise. It's awesome to write configuration files in Scheme! You can write scheme functions that output a valid system configuration for guix. You can then apply guix, reboot, and have a new system. It's also very easy to maintain different configurations.

On the OS side, dmd is also pretty damn cool. The whole system feels kind of polished and reminded me much of current *BSD systems, including a decent texinfo manual on the first boot. With the difference that you get a working framebuffer through linux on startup.

While NixOS is kind of an academical experiment, I think Guix really has the potential to become the only true GNU system. It still lacks stability and has some rough edges of course. Maybe Guix will also help merging the Emacs and GNU operating systems to create a single, tightly integrated Lisp OS ;) There is already an Emacs interface for Guix.

Calling NixOS an "academical experiment" is slightly disingenuous. The initial author does come from academia, but works in industry now, and you just need to look at the Github [1] to see that NixOS is maintained quite actively.

[1] https://github.com/NixOS/nixpkgs/commits/master

I concur. Besides NixOS is certainly more polished right now, at least for my definition of "polish" (I think, the right word for Scheme based Guix is "cohesive", maybe even "elegant"). It should be, being several years old, compared to Guix, which has been running on real hardware for mere weeks.

After playing with NixOS the past few days, never touched Guix, I think the former is more likely to be "taken seriously."

The ideas behind Nix/Guix are really interesting and a major improvement from traditional packagement solutions, and personally I much prefer using Scheme than a Haskell-derived DSL to configure my environment and operating system.

The problem is a political one: NixOS ships with current Linux standard technologies such as systemd, while this Guix-based OS uses this GNU dmd project I've never heard of until now, but I have no doubts its features and maturity is a fraction of systemd's (whatever is your opinion on systemd).

All for the sake of the free software radicalism. I love GNU and FSF and everything, but as a Linux user and administrator I'd really like we settle on something and build from there.

I may be mistaken, and open to criticism.

systemd works exclusively with the Linux kernel, and thus it's infeasible for the GNU system to settle on it. Here's current dmd maintainer's (Courtès) take on the matter: http://www.reddit.com/r/linux/comments/25abkh/what_is_wrong_...

I clicked through to gnu42's profile to make sure I correctly identified Courtès in that thread and... wow.

"Seriously, when was the last time you heard someone arguing whether it's dmd or DMD, or the same for any other init system other than SystemD? The reason SystemD fags complain is because they want people to respect their brand image - they're in the marketing business. Nobody else gives a shit."

You, uh, wow.

Talk about technological merits, huh? The onus is on him to prove that dmd is a viable alternative.

You've incorrectly identified Courtès.

Well, than I would like to extend my apologies to Ludovic Courtès.

Aforementioned discorteous post from reddit user would really be understandable coming from a GNU enthusiast if caustic in form.

The features are a fraction of systemd's, yes. This is because dmd actually has a concrete idea of what it wants to do, and doesn't just arbitrarily consolidate functionality under the pretense of being a "basic building block to make a Linux-based OS from".

As for maturity, you are mistaken. GNU dmd was first started around 2003, before even launchd existed.

Software isn't a biological entity, you can't measure maturity with just age.

Hell, you can't even measure a person's maturity with just age.

Maturity != age, maturity == number of eyes on a project + bugs fixed + real world usage.

As a comparison, the Hurd project started in 1990, Ubuntu in 2004. Which one is more mature? That is, which one would you use in a production environment?

You're comparing apples and squirrels. You probably wanted to say Linux or more mature than Hurd despite its 1 year head start, which is not as dramatic.

Neither.

Guix seems nice in that it is all-free and is configurable in Scheme, but packages for quite common stuff like Java and Haskell and Jack-audio server are not present yet, although they are in NixOS. Looking forward to Guix 1.0 as I like Scheme and GNU :-)

I've been using NixOS and Nix to install things in my servers. It's very mature. Most things I need are packaged, including not so popular utilities like isync or notmuch.

However, I'm curious about containers. For example systemd-nspawn seems like a simple way to achieve many of the functionality NixOS brings into the table.

Note that you can use Nix packages in Guix. They are compatible.

I've not used Guix, but looking at those slides, the ability to take the build definition of the "hello" program, inherit everything but change the version, looks very interesting.

I'm not aware of a way to do that in Nix, but I think it's more a consequence that the convention is to call

    stdenv.mkDerivation { descriptor }

(where the descriptor includes things like the upstream url, version, etc.)

without providing a direct handle to the descriptor (which one might inherit and modify just the upstream url, for example).

(In practice, I find it an order of magnitude easier to create custom packages in Nix compared to .deb.)

> I've not used Guix, but looking at those slides, the ability to take the build definition of the "hello" program, inherit everything but change the version, looks very interesting.

To do this with any derivation in in nixpkgs, call pkgs.lib.overrideDerivation on it, passing the relevant new attributes. This'll inherit the old attributes, only modifying the ones you supply. This is described in the manual: http://nixos.org/nixos/manual/#sec-customising-packages

Excellent, thank you!

I had seen the talk at ELS in 2013 (really? that was last year?) and was pretty intrigued back then. Might be some time before it replaces my beloved Slackware but I must say Guix is darn sexy already!

Also, finally, Lisp as a GNU systems programming language is becoming reality. :)

Will give Guix a spin now, interested in anything posix/real-unix style, which means I'd like to avoid systemd, that also means no nixos.

Yes, that's one of the reasons Guix attracts me as well. By the way, it's interesting to note here that when it comes to directory structure POSIX is much less strict than FHS [0], which NixOS and Guix largely abandon.

[0] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_...

Racket is getting pretty popular. Emacs is built on emacs-lisp. And now this is based on guile. I wonder how different these three lisps/schemes are.

I feel lisp enlightenment is long overdue for me. I'm just too busy for the past few years.

Elisp is quite old and lacking some modern features like lexical scoping and tail recursion as far as I know. I recall a project for replacing Elisp with Guile: http://www.emacswiki.org/emacs/GuileEmacs

Elisp recently gained optional lexical scoping[0].

[0] https://www.gnu.org/software/emacs/manual/html_node/elisp/Us...

This looks like it's the slides from a presentation... does anyone happen to have link to a video of it?

Videos from the GHM 2014 aren't online yet. They will probably be posted at http://www.gnu.org/ghm/previous.html eventually. You can find video and slides of Ludovic Courtès' talk on Guix from the GHM 2013 at http://www.gnu.org/ghm/2013/paris/.

Thanks!

There is a video of a similar presentation here: http://www.gnu.org/software/guix/#talks

Guile? Great idea. Can someone fix Emacs so that Guile (Scheme) is the default language? Stallman was pretty shortsighted with elisp.

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

I wouldn't blame Stallman for being shortsighted with elisp. He began work on GNU Emacs in 1984. Scheme wasn't standardized until 1990.

I agree that Scheme would be a better choice of an extension language, and honestly I think Stallman would probably agree. It's more that changing the extension language would cause a lot of compatibility problems. I hope the Guile Emacs guys can pull it off.

Scheme was plenty standardized by the mid-80s when RMS forked (James) Gosling Emacs and replaced its Mocklisp with a real LISP. Very few if any pay attention to the 1990 IEEE standard; for one thing, you've got to pay money to get it (currently $138 for a PDF, $110 if you're a member), vs. the free RnRS series.

RMS could in theory have adopted a Scheme, or even a lexicaly scoped version of mainline LISP, but by then he was so experienced with normal, pre-Common Lisp mainline LISP (Maclisp and Lisp Machine Lisp) I'd wonder if it even occurred to him.

Yes, it was standardized 24 years ago. I think Stallman's argument was that too much code was already written in elisp. For example, calc is a huge elisp app. He didn't want to lose apps like this:

http://www.gnu.org/software/emacs/manual/html_mono/calc.html

Not sure if calc already existed in 1984.

But Stallman argued (in one of the early emacs papers) that dynamic scope is much more convenient for a editor than lexical scoping (as implemented in scheme or Common Lisp)

Dynamic scope makes it easier to change some variable per buffer. With lexical scoping you would need to simulate dynamic scope somehow to be able to change state per buffer.

Common Lisp supports both dynamic and lexical scope.

Emacs-like editors have been implemented in it, and there's no fundamental reason that a true Emacs couldn't be.

Scheme is more of a toy; I'd not prefer it to Common Lisp for a production system, whether that system is an OS or an editing environment.

I don't know much about Guile, but can't it compile elisp too?

But you would need dynamic scope in Scheme to mix elisp/Guile code in Emacs?

Edit: Ah, this was discussed in your link at the top of this comment thread.

There have been efforts in that direction for a long time: http://www.emacswiki.org/emacs-en/GuileEmacsHistory . The current push seems to have reached the "80% done, 80% to go" stage.

Not really. Look at the "Current State" section here:

http://www.emacswiki.org/emacs-en/GuileEmacs

> As of the end of GoogleSummerOfCode 2014, the Elisp engine of Emacs is fully replaced with that of libguile, and most things Just Work™. Some performance regression of dynamic scoping (lexically scoped code should be fine), and broken corner cases (like crazy Elisp macros that directly output legacy Elisp bytecode) remain.

From its earliest days, one of the selling points of Guile was that eventually it should be possible to use it to run Emacs Lisp. This is one of the reasons RMS chose it as the GNU's official extension language. For some of the other reasons, google "Tcl war".

It appears that we're quite close to having a usable, if not production-ready, pure GNU distribution. The vast majority of Debian packages have already been ported to its GNU/Hurd.

On the other hand, they made the unorthodox decision to switch from dmd to sysvinit. Probably one of the very little systems to switch to SysV, rather than from it.

The PDF talks about dmd. Do you mean they recently decided to switch to sysvinit? Got any link to the discussion?

I'm referring to Debian GNU/Hurd specifically, though it is the de facto main hub for Hurd development.

Yes, here's the announcement: https://lists.debian.org/debian-devel-announce/2014/05/msg00...

This is the blog of the person who did it, which features detailed development logs: https://teythoon.cryptobitch.de/

I can't find any mention of dmd in those. Only "proof-of-concept upstream shell scripts"

I started to think: if dmd was revived in 2013, how could Debian/Hurd have started the effort to switch away from it in the same year?

This post talks of Debian/Hurd having "relied on its own init and rc system": http://osdir.com/ml/general/2014-01/msg61628.html

Are you sure? AFAIK Hurd is pretty much dead.

s/dead/complete/ ;-)

Is there a VM image for a system running guix? I am having trouble finding one.

ftp://alpha.gnu.org/gnu/guix/

It requires QEMU.

Direct link instead of Google creep: http://git.savannah.gnu.org/cgit/guix/maintenance.git/plain/...

Reply on news.ycombinator.com