I just want to say that what made me move to arch was The Arch Way. I just fell in love with it the first time I read it in the wiki. Then came pacman.
It's amazing to configure your system yourself, editing configure files and keeping track of every modification. Pacman output is great: if you read it. And I think everyone that WANTS to use arch should, and should accept The Arch Way as it is.
I love it and I wouldn't like to see it go down in misery.
Long live Arch's Way.
Not for lazy ones.
Thank you all,
Guilherme
------------------------------
Message: 9
Date: Tue, 25 Mar 2008 15:07:17 -0500 (EST)
From: <w9ya@xxxxxxxxxxx>
Subject: Re: signoff kernel26-2.6.24.3-6
To: <arch-general@xxxxxxxxxxxxx>
Message-ID: <60645.192.168.1.110.1206475637.squirrel@gateway>
Content-Type: text/plain; charset=iso-8859-1
ONE comment inserted below;
> On Montag, 24. M?rz 2008 22:47 RedShift wrote:
>
> At first see this all only as the opionion of a normal user and i find
> it good that you challenge such things because this is even a good way
> to improve it.
>
> If this discussion is only for devs than please apologize this and copy
> the lines below to /dev/null.-)
>
>> Lots of software is patched nowadays, even for very stupid things most
>> of the old user base wouldn't have cared about. And when PKGBUILDs
>> starts to grow to the point they need scrolling and comments to be
>> clarified, that's just going the wrong way. (Hint, kernel26 PKGBUILD).
>
> I do not like patches too. And yes, i love it that archlinux is using in
> the most cases the sources as they comes from the upstream. But sorry to
> say, the kernel is a special case.
>
> If you find time take a look for the kernel source packages of another
> distributions and you will see that everyone is patching the kernel.
> Okay, what ist the reason for it? The kernel devs said in the past
> (sorry, i have no url) that getting the kernel stable is the job of the
> distributions teams. This is not fantastic and i don't like this
> situation too but this is the situation.
>
> That is why i find that tpowa is doing a great job and the kernel26
> PKGBUILD is a good example because all patches been commented so if you
> don't like it you can create very easy your own kernel package. And more
> than the half of the PKGBUILD is copying files and the reaons for it is
> that other packages need this include files.
>
>> Notice the large influx of new users. The fact alone that a topic has
>> been started for a stable package repository *and people are willing
>> to contribute to this*, shows the kind of users we're getting: the
>> wrong ones. There has been an ongoing discussion on the bug tracker
>> whether or not post uninstall scripts should stop daemons upon
>> removal. These ideas come from users that are either inexperienced, or
>> trying to mold Arch in something its not. And what about dependencies
>> in initscripts... wtf? Any sane user can find them out for themselves
>> and put them in the right order in rc.conf. What if someone doesn't
>> want this behaviour? For example I don't want dbus and hal started,
>> but what if the kdm rc.d script will do this for me? It ends up with a
>> pretty big mess. Let alone the complexity that is added to the
>> initscripts.
>
> Smile, because i find that a kdm rc.d script is from my view unnecessary
> because you can handle it easy in the inittab file and this is the first
> time that i see that there is a kdm script.-) But i can understand that
> people who switch from another distribution will miss in the first
> moment some of this automatic things. Give them time and this "problem"
> will gone away but perhaps i see this too easy.
Coddling the user by just such an addition achieves nothing of either
transient or of a lasting nature for a distro such as ours.
i.e. *IF* this was the right way to go, then the other distros that are
starting kdm via such a script wouldn't have people leaving their fold and
switching to ArchLinux.
Specifically, kdm, xdm, et al were ORIGINALLY started as part of the init
processing string and/or X startup and specifically not part of a rc.d
setup. The rc.d style of doing this for the various popular desktop
managers was a later invention that came from the beginner's based
distros.
As for the rest of this discussion, as a LONG TIME user of ArchLinux I am
finding it a good discussion to have at this point in time. Please keep
the comments coming. I am greatly encouraged by you all having this
discussion.
Very best regards;
Bob Finch
------------------------------
