Am 21.07.2012 08:48, schrieb Evangelos Foutras:

On Sat, Jul 21, 2012 at 2:52 AM, Tom Gundersen wrote:

...

[..] * All variables in rc.conf can now be left unset and will default to something sensible I find removing most of the variables to be confusing and would suggest that [1] and [2] get reverted.

The commit log for [1] lists the following as the main reasoning behind this change:

"Keeping everything in the manpage means we don't have to deal with .pacnew files when updating minor detals (such as default options)."

My counterargument is the nonexistence, in the previous rc.conf, of default options that would need to be changed in a way that is transparent to the user.

Moreover, stuff like TIMEZONE, LOCALE and MODULES should be included in rc.conf; nobody really wants to run their system with the default LOCALE=C, and quite a few people will want to load extra modules (in my case vboxnetflt), without messing around with other files (/etc/locale.conf) or adding variables back into rc.conf, respectively.

In conclusion, a) the existing rc.conf is already stripped down to the essential system configuration options, b) I like having a default structure of these options in rc.conf instead of adding them back in at random places (in rc.conf), c) if we want to shift the task of configuring the hostname/locale/keymap/etc to external files, it might be preferable to remove them completely from rc.conf instead of having multiple points of truth.

(The above is my view on this change after spending 10 minutes trying to figure out how I can load modules through /etc/modprobe.d, after I noticed that MODULES was removed from rc.conf. In my defense, I thought it could be similar to the time MOD_BLACKLIST was dropped. :p)

[1] https://projects.archlinux.org/initscripts.git/commit/?id=5b0626 [2] https://projects.archlinux.org/initscripts.git/commit/?id=70810a I already raised this 2 days ago, seems no other devs have opinions on this. If someone uses systemd you have to deal with systemd's config files, but if you deal with rc.conf I would like to keep rc.conf as it is for years or make a reference where to set the new options.

greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org

On Jul 21, 2012 8:49 AM, "Evangelos Foutras" wrote:

On Sat, Jul 21, 2012 at 2:52 AM, Tom Gundersen wrote:

...

[..] * All variables in rc.conf can now be left unset and will default to something sensible

I find removing most of the variables to be confusing and would suggest that [1] and [2] get reverted.

The commit log for [1] lists the following as the main reasoning behind this change:

"Keeping everything in the manpage means we don't have to deal with .pacnew files when updating minor detals (such as default options)."

My counterargument is the nonexistence, in the previous rc.conf, of default options that would need to be changed in a way that is transparent to the user.

Moreover, stuff like TIMEZONE, LOCALE and MODULES should be included in rc.conf; nobody really wants to run their system with the default LOCALE=C, and quite a few people will want to load extra modules (in my case vboxnetflt), without messing around with other files (/etc/locale.conf) or adding variables back into rc.conf, respectively.

In conclusion, a) the existing rc.conf is already stripped down to the essential system configuration options, b) I like having a default structure of these options in rc.conf instead of adding them back in at random places (in rc.conf), c) if we want to shift the task of configuring the hostname/locale/keymap/etc to external files, it might be preferable to remove them completely from rc.conf instead of having multiple points of truth.

(The above is my view on this change after spending 10 minutes trying to figure out how I can load modules through /etc/modprobe.d, after I noticed that MODULES was removed from rc.conf. In my defense, I thought it could be similar to the time MOD_BLACKLIST was dropped. :p)

[1] https://projects.archlinux.org/initscripts.git/commit/?id=5b0626 [2] https://projects.archlinux.org/initscripts.git/commit/?id=70810a

Before answering in detail 1) did you read the man page? E.g. the replacement for MODULES is explained there, and also the reasoning why several of the options cause problems. 2) is it clear that only the default changed and that you can keep your old rc.conf if you want? Tom

On 07/21/2012 12:51 PM, Tom Gundersen wrote:

On Sat, Jul 21, 2012 at 8:48 AM, Evangelos Foutras wrote:

...

I find removing most of the variables to be confusing and would suggest that [1] and [2] get reverted.

I'm not going to revert them outright, but we can discuss individual options (some clearly must go, others are a matter of taste).

...

My counterargument is the nonexistence, in the previous rc.conf, of default options that would need to be changed in a way that is transparent to the user.

I guess I should have pointed out that I'd like a way to update the comments about each of the options frequently (mainly to add warnings or explanations as we realise them), but when the comments were in rc.conf that would create .pacnew files, which is annoying. I'd also like new users to have to read the manpage before they decide to use any of the discouraged options, so they will at least know the alternatives.

...

Moreover, stuff like TIMEZONE, LOCALE and MODULES should be included in rc.conf; nobody really wants to run their system with the default LOCALE=C, and quite a few people will want to load extra modules (in my case vboxnetflt), without messing around with other files (/etc/locale.conf) or adding variables back into rc.conf, respectively.

I agree that most people would want to configure /etc/locale.conf and /etc/vconsole.conf (or their equivalents in /etc/rc.conf). This is a matter of taste, but I'd really rather we start only using the two former files for this purpose. A benefit I did not mention yet is that they allow a lot more options than what rc.conf ever did.

As to modules: This should really not me necessary these days, and in the cases it is, it is something we should consider fixing. With kernel 3.5 the last of the mainline modules that I'm aware of (kvm) no longer needs to be specified manually.

In the case of virtualbox, I think the simplest solution here would be to load the needed modules whenever virtualbox is installed. I.e., ship a file with the virtualbox package (/usr/lib/modules-load.d/virtualbox.conf) containing

vboxnetadp vboxnetflt

(and whatever else is needed)

...

In conclusion, a) the existing rc.conf is already stripped down to the essential system configuration options, b) I like having a default structure of these options in rc.conf instead of adding them back in at random places (in rc.conf), c) if we want to shift the task of configuring the hostname/locale/keymap/etc to external files, it might be preferable to remove them completely from rc.conf instead of having multiple points of truth.

a) this is not the case. The current rc.conf contains several redundant and at least one harmful setting (HARDWARECLOCK).

b) fair enough, though does not seem like a major issue.

c) I'd like to do this in the long-run, but we can't just rip out the old support over night (see the old network settings or the crypttab changes for how I'd like these things to be done).

...

(The above is my view on this change after spending 10 minutes trying to figure out how I can load modules through /etc/modprobe.d, after I noticed that MODULES was removed from rc.conf. In my defense, I thought it could be similar to the time MOD_BLACKLIST was dropped. :p)

rc.conf(5) points to modules-load.d(5)[0].

-t

[0]: http://0pointer.de/public/systemd-man/modules-load.d.html

I pretty much hate everything you have described here. We started from a simple and elegant, single file configuration to over 9k(not to mention that i have no freaking idea which one to edit) Bring back the old rc.conf until we are switching to systemd or even better, kill initscripts right now and lets move to systemd. I don't like the transition, we are in the middle and it's frustrating. -- Ionuț

On 07/22/2012 12:40 AM, Pierre Schmitz wrote:

Am 21.07.2012 23:28, schrieb Ionut Biru:

...

I pretty much hate everything you have described here. We started from a simple and elegant, single file configuration to over 9k(not to mention that i have no freaking idea which one to edit)

Bring back the old rc.conf until we are switching to systemd or even better, kill initscripts right now and lets move to systemd.

I don't like the transition, we are in the middle and it's frustrating.

Did you even bother to read what Tom wrote? You can still use your old rc.conf. It is just recommend to use the new config files instead. This makes using initscripts and systemd in parallel easier. And there are not 9k config files but three.

sure i can use my old rc.conf but I'm about to install a new system and I don't like what I see. There are more than 3, 1) at least 1 for loading modules in some creepy location 2) hostname 3) time 4) locale 5) fonts At least 5 files that i have to edit in order to have the same benefit as I had with only editing 1 file.

So criticizing is all fine, but please keep it civil and based on facts.

Greetings,

Pierre

-- Ionuț

On 07/22/2012 01:01 AM, Tom Gundersen wrote:

On Sat, Jul 21, 2012 at 11:28 PM, Ionut Biru wrote:

...

I pretty much hate everything you have described here. We started from a simple and elegant, single file configuration to over 9k

Before rejecting everything, please explain why the problems I outlined are not real?

...

(not to mention that i have no freaking idea which one to edit)

I now added a comment to the standard rc.conf with pointers to all the files you could possibly want to edit.

...

Bring back the old rc.conf until we are switching to systemd or even better, kill initscripts right now and lets move to systemd.

I don't like the transition, we are in the middle and it's frustrating.

You can keep your old rc.conf, you can even use an old rc.conf when you setup a new system. Everything is clearly (I hope!) documented in the manpage. The only thing that changed was the defaults and the recommendations.

Forcing or not everyone to use systemd does not really change anything. At this stage both initscripts and systemd should support exactly the same config files.

I'm happy to revert specific things based on detailed technical feedback, but please make the effort to at least understand the issues before shooting down everything.

For one, I don't understand the logic behind. The only logic i can see is that you want to force existing users to move to this "awesome" configurations schema but in the same time you say "don't do it because your old rc.conf still works" You won't make me do this kind of transition to move to systemd compatibility.

-t

-- Ionuț

What we need is someone to write a daemon that monitors rc.conf for changes and then write them to the appropriate configuration file. Also the opposite needs monitored, so when the separate configurations files are changed (probably by GUI stuff), the changes are made back to rc.conf. (That was not a serious idea...) While I do still like the idea of a single system configuration file, it is down the list of reasons I pick Arch. I also see why it is becoming more difficult to support, with various efforts to standardize the configuration of these standard system properties across distros so that nice GUIs can edit them... Following the use of these more standard configuration files instead of having broken behaviour in software that tries to edit them, or having to patch the software to work with Arch does seem the more Arch like approach to me. I think Tom has done a good job in documenting the best practise and also supporting the old syntax (which is not "broken" in any way, but limited...). I have not moved to using the separate configuration files (and probably will not until we officially move to systemd or I do a new install) and everything seems to work. Allan

On 22 July 2012 16:14, Andreas Radke wrote:

I'm supporting all your effort to improve our boot process.

Arch was famous for its single rc.conf file configuration that now seems to fade away. While this may be done for good technical reasons I suggest to bring this up to some central point (hotplug/udev or systemd list ). I'd like to see something developed that we can call a common Linux early userspace configuration that would be equal in most distributions. Something like all is read from /etc/system/*

-Andy

I'm a bit taken aback by this, but that's just a natural reaction to change. One central configuration file was always the thing I loved most, but that doesn't mean it was the best approach technically. For eg., if I could shave off some seconds from offloading some things to upstream methods, then I could deal with a few more config files. We got rid of rc.conf variables one by one, as the need arose. Especially for module blacklisting, we couldn't continue to stick with the time-consuming shell logic we had back then. The bottom line is performance and balance. If you give me performance, I'll take it. But of course, one second of removed boot time for 3 more configuration files is not "performance". There needs to be more of a tangible benefit from all this change. Otherwise, we might as well skip all helper scripts and config files and edit every single upstream-provided one. -- GPG/PGP ID: C0711BF1