
We're building the GNU system [pdf] - rev
http://git.savannah.gnu.org/cgit/guix/maintenance.git/plain/talks/ghm-2014/guix-ghm-2014.20140815.pdf
======
astrodust
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".

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

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

~~~
davexunit
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

~~~
zimbatm
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`

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

~~~
astrodust
"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.

~~~
dllthomas
"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_.

------
aristidb
For your convenience, the link to the "mothership" NixOS:
[http://nixos.org/](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)

------
tbirdz
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)?

~~~
1_player
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.

~~~
vezzy-fnord
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.

~~~
1_player
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?

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

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

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

~~~
rev
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_...](http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap10.html)

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

~~~
gkya
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](http://www.emacswiki.org/emacs/GuileEmacs)

~~~
malisper
Elisp recently gained optional lexical scoping[0].

[0]
[https://www.gnu.org/software/emacs/manual/html_node/elisp/Us...](https://www.gnu.org/software/emacs/manual/html_node/elisp/Using-
Lexical-Binding.html#Using-Lexical-Binding)

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

~~~
rev
Videos from the GHM 2014 aren't online yet. They will probably be posted at
[http://www.gnu.org/ghm/previous.html](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/](http://www.gnu.org/ghm/2013/paris/).

~~~
Quequau
Thanks!

------
melling
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](http://www.emacswiki.org/emacs/GuileEmacs)

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

~~~
melling
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](http://www.gnu.org/software/emacs/manual/html_mono/calc.html)

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

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

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

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

~~~
vezzy-fnord
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...](https://lists.debian.org/debian-devel-
announce/2014/05/msg00006.html)

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

~~~
buovjaga
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](http://osdir.com/ml/general/2014-01/msg61628.html)

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

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

It requires QEMU.

------
aw3c2
Direct link instead of Google creep:
[http://git.savannah.gnu.org/cgit/guix/maintenance.git/plain/...](http://git.savannah.gnu.org/cgit/guix/maintenance.git/plain/talks/ghm-2014/guix-
ghm-2014.20140815.pdf)

