FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Development

 
 
LinkBack Thread Tools
 
Old 07-20-2012, 11:52 PM
Tom Gundersen
 
Default initscripts-2012.07.3

Hi guys,

I have pushed initscripts-2012.07.3 to testing.

Summary of changes:

* Add support for systemd's crypttab syntax
* Deprecate our old crypttab syntax, but keep supporting it
* All variables in rc.conf can now be left unset and will default to
something sensible
* Deprecate all non-initscripts-specific settings from rc.conf, and
remove them from the standard rc.conf. The standard rc.conf can now be
used unchanged on a simple system (earlier this would give network
errors).
* Rework the rc.conf manpage, adding examples and suggestions for
replacement for the deprecated settings
* No longer hard-code Arch-specific welcome message (this is mostly so
our various derivatives so they can use /etc/os-release rather than
patching rc.sysinit)
* Drop /etc/conf.d/wireless. It has been deprecated for a long time,
so no longer ship the file
* Several bugfixes

I'll leave it in testing for some time to make sure that the crypttab
changes went smoothly.

I'll make sure to only push this to core after the next systemd is in
core (it is not yet in testing, but has been released upstream), as
that will add the keyfile-offset= option to crypttab.

If you agree, I'll post a news item about the change to the
recommended config options in both crypttab and rc.conf.

Cheers,

Tom
 
Old 07-21-2012, 06:48 AM
Evangelos Foutras
 
Default initscripts-2012.07.3

On Sat, Jul 21, 2012 at 2:52 AM, Tom Gundersen <teg@jklm.no> 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. )

[1] https://projects.archlinux.org/initscripts.git/commit/?id=5b0626
[2] https://projects.archlinux.org/initscripts.git/commit/?id=70810a
 
Old 07-21-2012, 07:46 AM
Tobias Powalowski
 
Default initscripts-2012.07.3

Am 21.07.2012 08:48, schrieb Evangelos Foutras:
> On Sat, Jul 21, 2012 at 2:52 AM, Tom Gundersen <teg@jklm.no> 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. )
>
> [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
 
Old 07-21-2012, 09:15 AM
Tom Gundersen
 
Default initscripts-2012.07.3

On Jul 21, 2012 8:49 AM, "Evangelos Foutras" <evangelos@foutrelis.com>
wrote:
>
> On Sat, Jul 21, 2012 at 2:52 AM, Tom Gundersen <teg@jklm.no> 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. )
>
> [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
 
Old 07-21-2012, 09:24 AM
Tom Gundersen
 
Default initscripts-2012.07.3

On Jul 21, 2012 9:46 AM, "Tobias Powalowski" <
tobias.powalowski@googlemail.com> wrote:
>
> Am 21.07.2012 08:48, schrieb Evangelos Foutras:
> > On Sat, Jul 21, 2012 at 2:52 AM, Tom Gundersen <teg@jklm.no> 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. )
> >
> > [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.

Just want to point out: existing users are free to keep the current rc.conf.

I really would like to at one point in the future only have one way of
configuring the basic system regardless if what init system or even what
distro you use.

This was meant to push everyone gently in this direction, and in particular
make all new users use the new files, without forcing anyone. This is the
same as we did with the network options (the old ones should still work).

Tom
 
Old 07-21-2012, 09:51 AM
Tom Gundersen
 
Default initscripts-2012.07.3

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. )

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

-t

[0]: <http://0pointer.de/public/systemd-man/modules-load.d.html>
 
Old 07-21-2012, 08:02 PM
Myra Nelson
 
Default initscripts-2012.07.3

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. )
>
> 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!
 
Old 07-21-2012, 08:59 PM
C Anthony Risinger
 
Default initscripts-2012.07.3

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
 
Old 07-21-2012, 09:28 PM
Ionut Biru
 
Default initscripts-2012.07.3

On 07/21/2012 12:51 PM, Tom Gundersen 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. )
>
> 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Č›
 
Old 07-21-2012, 09:35 PM
Myra Nelson
 
Default initscripts-2012.07.3

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
--
Life's fun when your sick and psychotic!
 

Thread Tools




All times are GMT. The time now is 05:07 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org