unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* First guix impressions
@ 2015-09-25 18:50 goglosh
  2015-09-26  8:54 ` 宋文武
  0 siblings, 1 reply; 3+ messages in thread
From: goglosh @ 2015-09-25 18:50 UTC (permalink / raw)
  To: guix-devel

Hello.
I am currently a new user of the GuixSD system. I am also a rather new
user of the whole *NIX familly. I have been using it for less than a
week, with no few surprises.
I write this to lay down in an organized (sort of) manner my thoughts
and first impressions about the system and those issues I've had most
trouble with. Along with friendly suggestions. I hope it's helpful,
and, anyway, I'd be happy to put together some documentation given a
few pointers if needed. Sorry if I am still inexperienced with the
whole *nix thing.
Alright, first the good things. I really liked the fact that you can
instantiate system configurations (as in `guix system reconfigure`)
and also that regular users can build up their environment and that it
is quite 'safe', system-wise. There is one thing that should probably
change, though. When I install a package using root, I usuallly expect
the package to be available system-wide, so that any user has access
to it. This would make it easier to install a package just once for
all users. After all, that's the purpose of root, rather than as a
user in it's own right (at least, that's how I see it).
I know this can be done with a system declaration. But of course,
there is a difference between setting up a whole system and putting up
a package.
Another astonishing (and confusing) feature, which, think of it, is
sort of a consequence of the previous issue, is the lack of a global
configuration directory. Sure, there is /etc/, but, at least in my
case, setting up /etc/slim.config (a concrete example of course) would
just get ignored. Again, I am thinking of root as a sort of parent
environment for the userspace, which all users should be able to
inherit and override. A Super-user, if you don't mind.
I am aware that these changes would require a change in the design,
still there could be a sort of compromise.
And again, the applications usually have their own config files (their
/etc/ /share/, etc) *within* their directories in /gnu/store/, which
is a read-only filesystem. I'm not complaining about read-only
/gnu/store, I understand it's crucial. But then, ~/.guix-profile is
also read-only. As I write this I notice that it is actually a bunch
of symlinks all leading to /gnu/store.
See, what I would expect, being this a sort of nix system, is that I
could also have configurations for each file, which I should be able
to modify. Probably I should be able to have dedicated /share/ or
/etc/ for each user and even one system-wide.
I too haven't really read the dmd manual, and I will do so right
now.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: First guix impressions
  2015-09-25 18:50 First guix impressions goglosh
@ 2015-09-26  8:54 ` 宋文武
  2015-09-26 13:39   ` Ludovic Courtès
  0 siblings, 1 reply; 3+ messages in thread
From: 宋文武 @ 2015-09-26  8:54 UTC (permalink / raw)
  To: goglosh, guix-devel

goglosh@openmailbox.org writes:

> Hello.
> I am currently a new user of the GuixSD system. I am also a rather new
> user of the whole *NIX familly. I have been using it for less than a
> week, with no few surprises.
Hi, welcome!
> I write this to lay down in an organized (sort of) manner my thoughts
> and first impressions about the system and those issues I've had most
> trouble with. Along with friendly suggestions. I hope it's helpful,
> and, anyway, I'd be happy to put together some documentation given a
> few pointers if needed. Sorry if I am still inexperienced with the
> whole *nix thing.
It's very useful and pleasure to get feedback :-)
> Alright, first the good things. I really liked the fact that you can
> instantiate system configurations (as in `guix system reconfigure`)
> and also that regular users can build up their environment and that it
> is quite 'safe', system-wise. There is one thing that should probably
> change, though. When I install a package using root, I usuallly expect
> the package to be available system-wide, so that any user has access
> to it. This would make it easier to install a package just once for
> all users. After all, that's the purpose of root, rather than as a
> user in it's own right (at least, that's how I see it).
I agree the root user is special and having a global packages set
managed by root sounds reasonable.
> I know this can be done with a system declaration. But of course,
> there is a difference between setting up a whole system and putting up
> a package.
Yes, maybe reconfigure the whole system is too expensive.
Currently, I think we can add 'source /root/.guix-profile/etc/profile'
to '~/.bash_profile' for users who want this behavior.  Or add it to
'/etc/profile' for all users.
> Another astonishing (and confusing) feature, which, think of it, is
> sort of a consequence of the previous issue, is the lack of a global
> configuration directory. Sure, there is /etc/, but, at least in my
> case, setting up /etc/slim.config (a concrete example of course) would
> just get ignored.
The intention is to use guix manage those files by services, so for 
example, you can add a '(slim-service #:auto-login? #t)' to the system
configuration for slim which is auto login.  The parameters for services
is (should be) well documented and cover most usage, so we don't have to
learn the specified config syntax for every packages.

But I agree most packages should use '/etc' as default sysconfdir
instead of an etc in the store, so that if we don't use services to
manage them, they can still configure by root.  In practice, this
need to be handled per-package in its recipe. See 'fish' for an example:

<http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/fish.scm>

> Again, I am thinking of root as a sort of parent
> environment for the userspace, which all users should be able to
> inherit and override. A Super-user, if you don't mind.
> I am aware that these changes would require a change in the design,
> still there could be a sort of compromise.
It's not very clear what to inherit and override, but I think we can
do most of this already.

For packages (build-time), by using GUIX_PACKAGE_PATH:
 <http://www.gnu.org/software/guix/manual/html_node/Package-Modules.html#Package-Modules>

For packages's configurations (running-time), by using '/etc'.

> And again, the applications usually have their own config files (their
> /etc/ /share/, etc) *within* their directories in /gnu/store/, which
> is a read-only filesystem. I'm not complaining about read-only
> /gnu/store, I understand it's crucial. But then, ~/.guix-profile is
> also read-only. As I write this I notice that it is actually a bunch
> of symlinks all leading to /gnu/store.
> See, what I would expect, being this a sort of nix system, is that I
> could also have configurations for each file, which I should be able
> to modify. Probably I should be able to have dedicated /share/ or
> /etc/ for each user and even one system-wide.
Most (if not every) normal user oriented applications put config files
in user's home (eg: ~/.bashrc, ~/.emacs.d ,~/.config, etc).  And the
system-wide one is '/etc' :-)

> I too haven't really read the dmd manual, and I will do so right
> now.
I haven't read the dmd manual too.  As the init system, I think it's
an implementation detail.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: First guix impressions
  2015-09-26  8:54 ` 宋文武
@ 2015-09-26 13:39   ` Ludovic Courtès
  0 siblings, 0 replies; 3+ messages in thread
From: Ludovic Courtès @ 2015-09-26 13:39 UTC (permalink / raw)
  To: 宋文武; +Cc: guix-devel

宋文武 <iyzsong@gmail.com> skribis:

> goglosh@openmailbox.org writes:

[...]

>> Alright, first the good things. I really liked the fact that you can
>> instantiate system configurations (as in `guix system reconfigure`)
>> and also that regular users can build up their environment and that it
>> is quite 'safe', system-wise. There is one thing that should probably
>> change, though. When I install a package using root, I usuallly expect
>> the package to be available system-wide, so that any user has access
>> to it. This would make it easier to install a package just once for
>> all users. After all, that's the purpose of root, rather than as a
>> user in it's own right (at least, that's how I see it).
> I agree the root user is special and having a global packages set
> managed by root sounds reasonable.

I never tried, but ‘root’ can run something like this:

  guix package -p /run/current-system/profile -i emacs

This will add Emacs to the “global” profile–i.e., the set of packages
visible to all users.

However, I wouldn’t recommend it, because such changes will be undoed
upon the next ‘reconfigure’.

>> I know this can be done with a system declaration. But of course,
>> there is a difference between setting up a whole system and putting up
>> a package.
> Yes, maybe reconfigure the whole system is too expensive.
> Currently, I think we can add 'source /root/.guix-profile/etc/profile'
> to '~/.bash_profile' for users who want this behavior.  Or add it to
> '/etc/profile' for all users.

Ideally ‘guix system reconfigure’ wouldn’t be more expensive than ‘guix
package -i’, but yeah.

>> Another astonishing (and confusing) feature, which, think of it, is
>> sort of a consequence of the previous issue, is the lack of a global
>> configuration directory. Sure, there is /etc/, but, at least in my
>> case, setting up /etc/slim.config (a concrete example of course) would
>> just get ignored.
> The intention is to use guix manage those files by services, so for 
> example, you can add a '(slim-service #:auto-login? #t)' to the system
> configuration for slim which is auto login.  The parameters for services
> is (should be) well documented and cover most usage, so we don't have to
> learn the specified config syntax for every packages.

I think there are two cases:

  • Applications for unprivileged users, such as Emacs, GIMP, Mutt,
    etc.  For these, you can just use ~/.emacs and similar dot files in
    your home directory, as you would do on another distro.  No
    difference here.

  • System services such as SLiM, udev, the SSH server, etc.  Here we
    assume that everything that pertains to these services is managed by
    GuixSD, via the configuration file.

    So instead of modifying, say, /etc/slim.conf or /etc/sshd.conf, you
    would simply pass the right configuration parameters to the service
    procedures in the ‘operating-system’ declaration:

      http://www.gnu.org/software/guix/manual/html_node/Using-the-Configuration-System.html

    The fact that GuixSD manages these configuration files for you means
    that (1) a single ‘operating-system’ declaration very precisely
    specifies the system’s configuration, and (2) you can roll-back to a
    previous configuration via the entries that GuixSD adds to GRUB’s
    menu.

> But I agree most packages should use '/etc' as default sysconfdir
> instead of an etc in the store, so that if we don't use services to
> manage them, they can still configure by root.  In practice, this
> need to be handled per-package in its recipe. See 'fish' for an example:
>
> <http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/fish.scm>

Yes that’s fine, but only for packages that are not system services.
For system services, I think we must insist on having configuration
happen in the ‘operating-system’ declaration.

Thanks, and welcome!

Ludo’.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2015-09-26 13:39 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-09-25 18:50 First guix impressions goglosh
2015-09-26  8:54 ` 宋文武
2015-09-26 13:39   ` Ludovic Courtès

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).