unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: 宋文武 <iyzsong@gmail.com>
To: goglosh@openmailbox.org, guix-devel@gnu.org
Subject: Re: First guix impressions
Date: Sat, 26 Sep 2015 16:54:20 +0800	[thread overview]
Message-ID: <87d1x54l37.fsf@gmail.com> (raw)
In-Reply-To: <2e2ee8b4a357b09ec06a2025e54676f4@openmailbox.org>

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.

  reply	other threads:[~2015-09-26  8:53 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-25 18:50 First guix impressions goglosh
2015-09-26  8:54 ` 宋文武 [this message]
2015-09-26 13:39   ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87d1x54l37.fsf@gmail.com \
    --to=iyzsong@gmail.com \
    --cc=goglosh@openmailbox.org \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).