all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: 宋文武 <iyzsong@gmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel@gnu.org
Subject: Re: Few notes to 0.8
Date: Sun, 30 Nov 2014 19:05:57 +0800	[thread overview]
Message-ID: <878uithrsa.fsf@gmail.com> (raw)
In-Reply-To: <87y4qtwxaz.fsf@gnu.org>

Ludovic Courtès <ludo@gnu.org> writes:

> 宋文武 <iyzsong@gmail.com> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>>> Adam Pribyl <pribyl@lowlevel.cz> skribis:
>
> [...]
>
>>>> 2. during boot the system twice sets the console font, each time to a
>>>> different one (this is not always reproducible). Minor.
>>>
>>> Hmm, you mean on the same tty?
>> Yeah, I have issue too, solved by:
>>
>>   (initrd (lambda (fs . args)
>>             (apply base-initrd fs
>>                    #:extra-modules '("i915")
>>                    args)))
>>
>> To get fbcon in initrd before udev-service and console-font-service.
>
> Oh, OK.
>
>> I think the 'Console' lines of `dmesg' tell the reason.
>
> I have:
>
> --8<---------------cut here---------------start------------->8---
> $ dmesg |grep -E '(udevd.*starting|Conso)'
> [    0.000000] Console: colour VGA+ 80x25
> [    3.750956] udevd[190]: starting version 1.10
> [    4.536397] Console: switching to colour dummy device 80x25
> [    5.421016] Console: switching to colour frame buffer device 170x48
> --8<---------------cut here---------------end--------------->8---
>
> I don’t think we can solve it generically without adding udev and all
> the graphics drivers to the initrd, can we?  Or perhaps we could just
> include a few common graphics drivers by default?
>
>> I just put it in my config.scm:
>>
>>   (define (console-layout-service layout)
>>     (with-monad %store-monad
>>      (return
>>       (service
>>        (document "Setup keyboard layout for console")
>>        (provision '(console-layout))
>>        (start #~(lambda _
>>                   (system* (string-append #kbd "/bin/loadkeys") #$layout)))
>>        (stop #~(const #t))
>>        (respawn? #f)))))
>
> Excellent.  I was thinking that we should have a keyboard layout setting
> in the OS declaration, that would lead to a service like the one above
> as well as the appropriate X settings.
Currently, operating-system is not declarative, with the setting:
  (operating-system
    (keymap "dvorak"))
IIUC, the xorg-server service can't see it unless passed explicitly.

In NixOS, declarative configuration is implemented by 'modules':
  https://nixos.org/wiki/NixOS:Modules
  
Every module can define some options, access and contrib to the config,
the configuration.nix is just a normal module provided by user.

Yeah, how all the modules eval toghether is still a mystery for me.
>
>> Any plan for user services?
>> Get guix build a dmd.conf for user should be really cool.
>
> Yeah, that could be nice.
>
> I wonder how this should work.  Currently we’d have to start one dmd
> instance per user; I’m not sure where/when this should be started.
How about run:
   $ guix system --user reconfigure config.scm (or guix user-profile?)
   
With config.scm:
   (user-profile
     (locale "en_US.utf8")
     (services (list (emacs-daemon-service)))
     (packages (list emacs)))
     
Get ~/.guix-profile (a better name?):
   boot locale profile

The `boot' is just like system's boot, run the activate script, start
dmd, even populate user's home with files build by guix.

After login, I can just run `boot' manually, or automatic by adding
it to ~/.bash_profile, ~/.xsession (can be populated by guix too).

> Also, should the global OS declaration include user-specific service
> lists?  WDYT?
The global OS could provide the default settings for user profile.

  (operating-system
    (user-profile))

And access as a singleton as %os, then user can reuse or override with:
  (user-profile
    (services (list (operating-system-services %os))))

But the declarative way is more better!
>
> Thanks for your feedback!
>
> Ludo’.

  reply	other threads:[~2014-11-30 11:06 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-28 11:41 Few notes to 0.8 Adam Pribyl
2014-11-28 21:31 ` Ludovic Courtès
2014-11-29 11:57   ` 宋文武
2014-11-29 20:45     ` Ludovic Courtès
2014-11-30 11:05       ` 宋文武 [this message]
2014-11-30 11:34         ` Services and access to the global configuration Ludovic Courtès
2014-11-29 21:06     ` Few notes to 0.8 Alex Kost

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

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

  git send-email \
    --in-reply-to=878uithrsa.fsf@gmail.com \
    --to=iyzsong@gmail.com \
    --cc=guix-devel@gnu.org \
    --cc=ludo@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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.