[arch-general] Was [arch-dev-public] [ANNOUNCE] initscripts-2012.07.3

[Myra Nelson]

On Sat, Jul 21, 2012 at 4:51 AM, Tom Gundersen <teg at jklm.no> wrote:

> On Sat, Jul 21, 2012 at 8:48 AM, Evangelos Foutras
> <evangelos at foutrelis.com> 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!