On Sat, Jul 21, 2012 at 4:51 AM, Tom Gundersen teg@jklm.no wrote:
On Sat, Jul 21, 2012 at 8:48 AM, Evangelos Foutras evangelos@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
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
On Sat, Jul 21, 2012 at 3:02 PM, Myra Nelson myra.nelson@hughes.net wrote:
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.
this is accurate/fair -- `systemd` is sort of an umbrella term for many tools at this point -- even udev -- and no one is being forced to use systemd proper. developers are merely leveraging the many small, *independent* tools it provides:
# pacman -Qql systemd-tools |grep -E 'systemd[-a-z]+$'
... will show you these tools -- all generic and useful in their own right -- highly relevant to the [near identical] duties tasked to initscripts.
[...]
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.
i don't think there is an obscene number of files to manage, and, at least IMO, using them simply means ones step closer to upstream. at the end of the day, one must acknowledge that we exist within a greater ecosystem, and resisting one's nature/environment rarely lends greater success. many upstream developers critical to Arch's basic operations are funded by distro's such as those you list ... it's only natural that their ideas and practices become intermixed and applied locally, no matter how much one resists otherwise. everyone is working towards the better, even if they appear -- or even literally *are* -- in conflict with each other or the status quo ... the greatest enemy, however, is that of stagnation, and perpetual "good enough", as that only takes you where you've already been.
--
C Anthony
On Sat, Jul 21, 2012 at 3:59 PM, C Anthony Risinger anthony@xtfx.me wrote:
On Sat, Jul 21, 2012 at 3:02 PM, Myra Nelson myra.nelson@hughes.net wrote:
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.
this is accurate/fair -- `systemd` is sort of an umbrella term for many tools at this point -- even udev -- and no one is being forced to use systemd proper. developers are merely leveraging the many small, *independent* tools it provides:
# pacman -Qql systemd-tools |grep -E 'systemd[-a-z]+$'
... will show you these tools -- all generic and useful in their own right -- highly relevant to the [near identical] duties tasked to initscripts.
[...]
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.
i don't think there is an obscene number of files to manage, and, at least IMO, using them simply means ones step closer to upstream. at the end of the day, one must acknowledge that we exist within a greater ecosystem, and resisting one's nature/environment rarely lends greater success. many upstream developers critical to Arch's basic operations are funded by distro's such as those you list ... it's only natural that their ideas and practices become intermixed and applied locally, no matter how much one resists otherwise. everyone is working towards the better, even if they appear -- or even literally *are* -- in conflict with each other or the status quo ... the greatest enemy, however, is that of stagnation, and perpetual "good enough", as that only takes you where you've already been.
--
C Anthony
C Anthony:
In fairness to your rebuttal, you are absolutely correct and moving Arch toward mainstream is probably a good idea. My hesitation is removing choices users are able to make. The choice for simplicity or complexity.
As for stagnation, I've fought stagnation in the oil and gas service industry for 30 years and the "we've always done it this way so why change". It's not change that bothers me, it's change for changes sake. I don't consider it change, it's evolution. I surprise most of the younger generation in the area I live in, under 50, because I've been using and repairing computers since 1987, building them since 1993, and online since 1998. I'm also one of the "old timers" who rebels against any system that forces me to do something I don't like or think is necessary. I've never believed that the PTB's are always right, they just happen to be in the drivers seat.
As John Cougar Mellencamp once stated " I fought authority and authority won"
IMHO opinion the option should remain to keep both solutions and let the user choose which way the wish to use. In all fairness to the developers, I realize that solution entails more work for them and I apologize for making such a request.
Myra
arch-general@lists.archlinux.org