DragonFly users List (threaded) for 2006-09
Re: Hints on kernel config for a dula pII/450 system anyone?
onflybsd.org> <450DE1EA.7090303@xxxxxxxxx> <450de68a$0$789$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <450de82f$0$790$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <450dedb2$0$787$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <450e79fe$0$787$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii; format=flowed
X-Trace: 1158580101 crater_reader.dragonflybsd.org 786 188.8.131.52
Xref: crater_reader.dragonflybsd.org dragonfly.users:7256
Gergo Szakal wrote:
> Bill Hacker wrote:
>> We've all been (still are) there w/r the economics.
>> But when funds are needed elsewhere, and 'run what hardware you have'
>> is mandatory, then DFLY would not be the best choice.
>> For that to change sooner, rather than someday-maybe, best to leave
>> the 'scarce resource' DFLY dev team to concentrate on current,
>> reasonably-mainstream hardware.
>> Hard enough to keep up with 5-week/month-old goods, let alone 5+
>> *years* old.
> While completely sharing your point, my opinion is that testing DF on
> older (or any x86) hardware may help catching bugs that are otherwise
> hidden. :-)
It can do. Sometimes.
Unfortunately it is very much a 'dimishing returns' exercise, as your experience
First, it requires too much work, as the hardware already has 'minority'
presence, and too few players have direct access to something on which to test.
Secondly, the problem if/as/when solved at all is frequently related to an
environment that was uncommon even when new, and has already left the 'majority'
scene, so even a correct result is of limited value.
Basically, it is too much work for too little gain - even on, for example, a
'populist' platform, such as Linux, where lots of older hardware abounds, simply
because of the size and diversity of the user community.
'Production Server' operators - a majority of *BSD'ers, go without lots of
life's niceties - meals included from time to time - to keep reasonably modern
and solid hardware online. Not necessarily 'sexy' - but predictable.
Odd-designs and 'minority' gear that proves problematic are more likely to be
reassigned to less critical use or even scrapped outright than 'accomodated'
Time is the one thing we cannot 'buy back'. It needs to be invested where it
does the most good for the least effort. PII-450 or K62-450 'clones' on dual-CPU
MB with rare NIC's are no longer such a target. If ever they were.
If there is *really* a code error, it will show up on modern hardware as well as
ancient. But here the work toward a solution can proceed more easily, as the
hardware is less likely to be unique.