That's my first message to the mailing list, I've just been reading it since I started using archlinux as my distro in September 2007. 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@qrparci.net> Subject: Re: [arch-general] signoff kernel26-2.6.24.3-6 To: <arch-general@archlinux.org> 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
------------------------------