On Sat, Jul 21, 2012 at 4:51 AM, Tom Gundersen <teg@xxxxxxx> wrote: > On Sat, Jul 21, 2012 at 8:48 AM, Evangelos Foutras > <evangelos@xxxxxxxxxxxxx> 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> > Tom: The concerns expressed by Evangelos and Tobias were some of the concerns I had when the push towards systemd started. Systemd is great if you are managing a large number of computers, but excessive overkill for one or two desktops with no server. The network setup is probably great for laptops also, but not in my instance. I get to learn to do it with iproute2. The simplest possible configuration for that setup is rc.conf. I'm not attempting to be a luddite, but something about this seems to violate the Arch KISS policy. Users of desktop systems shouldn't be forced into something like this. One of the reasons I chose Arch was the simplicity of setting up my system and not having some built in utility bork it for me. I find Arch much easier to set up and maintain than Fedora, Suse, Debian, Ubuntu, etc, etc, etc, and I wasn't forced in to their philosophy of setting up a "CORPORATE", yes I'm screaming, desktop. Currently Arch provides simple control mechanisms in central locations, and IMHO should stay that way. Please pardon my intrusion on a developer discussion, as I truly have no say in the matter. Just thought I'd toss in my 2 cents. Myra -- Life's fun when your sick and psychotic!
