I'm wondering if it would be best to split it up in 2 files.
One for guix and one for guixsd.
I would like to help new users understand more about GuixSD before they run it (and inevitably into errors)
Users come from other Distros where tough package manager errors mostly mean: you are screwed, reinstall. Because if you loose the central command to manipulate the system - how can you possibly recover? Imagine apt being corrupt or gone missing.
So when we have strong reactions to users used to being screwed and reinstall then we need to educate them that this is something completely different where it is actually hard to break (besides when running guix pull and not understanding how to set paths manually)
Another example:
The current parsing of config.scm is eh... crude and might work for seasoned programmers who know the exact differences between parameters, instantiated config, where inherit works (record types) and where they don't (service-types), what a service object is, how you remove an item from a list of service objects, etc.
I would like to tell new users NOT to change the config.scm at first install if they are not confident schemers. (besides the username and timezone perhaps).
Also the editors included in the image are crap because they lack two important features: 1) keeping track of the damn paranteses and 2) comment and uncomment region.
Edits to the configuration is in my view best done with small incremental steps in emacs and validating the config for each step (side note how do you validate your config from within emacs?). Access to irc to ask for questions/help when guix sometime spews incomprehensible errors at you is also advisable.
We also need a lot more complete examples of working snippets and whole config.scms to add to a config in the lack of good error reporting.
Maybe a list of links to working configs from community members would be good to add Somewhere. I learned a lot from reading the
Config of others. Perhaps in a new file called GUIXSD-CONFIGURATION-EXAMPLES?
I saw that some of you, Alex, sidesteps the removal of service objects-problem by defining all the services yourself in a list instead.