Judd Vinet wrote:
> On Sun, Nov 27, 2005 at 10:56:10PM +0000, Philip Dillon-Thiselton wrote:
>
>>Touche. You know, you could have just said, "Shut up, Phil." and saved
>>yourself some typing.
>
>
> Hehe, I didn't want to insult, Phil.
Ah but instead you treated me like a distro hoping whinner that has done
nothing for Arch and expects everything in return! I may not be Mister
Diplomacy but I think my constructive contribution and support are
unquestionable.
> You're just frustated and that's
> cool - I understand that. Just be nice to others and they'll be nice
> back.
>
>
>>I'll try the diplomatic way.
>>
>>Please can someone explain why hwdetect has been hardcoded into the Arch
>>initscripts rather than provided separately as most similar tools are.
>>Can someone also explain why this does not violate the KISS philosophy
>>on which Arch is based and many of us have come to rely on.
>>
>>How's that? Better?
>
>
> Much better. And not hard at all, was it?
Not at all, but less satisfying.
>
> Tpowa saw the new kernel trend approaching (ie, the modalias /sys
> exports) and realized that this method is closer to plain, unadulterated
> "Linux" than hotplug, lshwd or any variants. It is hardware detection
> done by the kernel itself, more or less. We just have a script that
> facilitates the actual loading of the detected modules.
>
> The intent was never to break systems or cause large annoyances, but
> like most transitions, it has done both to some people. Though I hope
> the broken systems and annoyances are both temporary, and I hope the
> overall advtanages and elegance of the new system will pay off in the
> long run.
>
> As for this being an anti-Arch movement, I think you're wrong. Arch
> likes simple and elegant. hwdetect is both. Read it. It's basically a
> glorified `modprobe $(find /sys/devices -name modalias)`. How much
> simpler does it get? In my eyes, we've improved simplicity while still
> giving the admin utter choice over their hardware detection method. It
> is "hardcoded" into rc.sysinit, but a setting in rc.conf disables it.
> lshwd is still provided in Base, as well as hotplug, and both are
> trivial to enable.
That still doesn't really explain why it has been hardcoded tho does it?
If it was not hardcoded the script would be in my ignore pkgs list
and it would not be a problem. Having looked at the new rc.sysinit I
can see that hwdetect could simply be run as daemon, as all the other
hardware detect methods are. Also, seeing as these other methods are
"trivial to enable" what makes hwdetect worth being hardcoded? Sure
it's a benefit to some but it is also a detriment to others. I have
always felt that not forcing people to install programs that they might
not need or want was anti the Arch ethos too, regardless of how new and
fancy it is. hwdetect is a recommended dependency in my eyes and should
be treated as such.
>
> The feature hwdetect exploits is also a new, relatively-undiscovered
> feature. And as stated in the Arch manual[1], we are keen on adopting
> new systems and features if we see merit and longevity in them.
> Sometimes we're wrong too -- it sucks but it happens. Nobody trained us
> to maintain a distribution and make decisions that affect thousands of
> people. So we learn as we go. Sometimes we take risks, but we try to
> calculate them before betting the farm on something, and it usually pays
> off in the end. Forgive us in these tumultuous times when flux is high
> and complaints ubiquitous. It will pass and things will be groovy
> again.
Of course I appreciate that, I'm not always so quick to complain. Of
course people did readily complain about the initrd...but then I'll
never use that either. We pretty much have to use the initscripts tho
and currently hwdetect, and it's updates, are unavoidable.
>
> As an aside, I have asked tpowa to tone down on the initscripts updates
> unless the fixes are critical. He said the last fix actually repairs
> unbootable systems for custom kernels <2.6.12, so I think he made a good
> judgement call there. In the future, we will try to keep this kind of
> package flux in the Testing repo, not Current.
Well, fair enough but as I already said, he could update it as often as
he likes if it was pkg'ed separately. I think most people have to do
the .pacnew tango when they update their initscripts and that's
frustrating when the scripts themselves have not changed at all.
>
> Thanks (to everyone) for your understanding here. We truly do
> appreciate it.
>
>
> - Judd
>
>
> [1] Well, it doesn't say exactly that. It actually says "Arch Linux
> also strives to use some of the newer features that are available to
> linux users, such as hotplug and udev support." But we can broaden that
> statement, I think. There are many toys to play with.
>
>
> _______________________________________________
> arch mailing list
> [email protected]
> http://www.archlinux.org/mailman/listinfo/arch
>
>
_______________________________________________
arch mailing list
[email protected]
http://www.archlinux.org/mailman/listinfo/arch
