Hello Konrad, this thread is slowly going OT from the initial subject, anyway I found an interesting comment from you I would like to reply Konrad Hinsen writes: > Hi Ludo, [...] >> Just to say I’m not willing to replace ‘config.scm’ with >> ‘config.yaml’, if that’s what you had in mind. :-) > > YAML is for kids. Real managers won't settle for less than full > XML. ;-) When I started studying Guix/Scheme (and I'm still far away from understanding) I stubled on an article advocating Lisp to XML-minded people like I was: http:/www.defmacro.org/ramblings/lisp.html The point is: config.scm is better than config.xml that is better than config.yaml that is better than config.json :-D The real question is: a configure file is code or data? IMHO is code, especially when it comes to system configuration; for this reason every user learn to *code* in some way or another (even when using a GUI to configure software) Systems are complex, we should avoid complicating them (think any configuration management system you like :-O ) *and* we should also avoid oversimplifying them [1]; this also means users must know what they are doing [...] > The question is if we want Guix to remain exclusively a power tool for > power users. Mumble... but every user *is* a power user when installing and configuring a system, no? The "only" difference is what tools *and* binary distribution (or binary building) system we decide to trust when installing and configuring our system, and our decision should be informed ...so yes, if it's not a channel under your control - or of someone you decide to trust - you should better not use it (and do not copy/paste configuration files you do not understand) I recently read this "Curl to shell isn't so bad" article (thanks ARota) https://arp242.net/curl-to-sh.html «In the end it’s still just running code you didn’t personally audit on your computer, and a matter of trust.» Guix is the best candidate to build a software ecosystem which we can trust (and we already have), starting from "almost zero" binary depends via GNU Mes and stage0; and we can always /challenge/ any substitute server :-) This obviously does not solve the "trust in source code" problem [2], but this is another story [...] Thanks! Gio' [1] Docker "containers" are easier from an "end user" POV than installing and configuring via a "classic" package manager... but have you ever tried to understand what's installed in a 7 layer filesystems container?!? So what is *seems* simple is often _complicated_ :-O [2] and that was also *not* the scope of the famous Trusting Trust speech -- Giovanni Biscuolo Xelera IT Infrastructures