Hints on kernel config for a dula pII/450 system anyone?

[Bill Hacker]

onflybsd.org> <450DE1EA.7090303 at xxxxxxxxx> <450de68a$0$789$415eb37d at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <450de82f$0$790$415eb37d at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <450dedb2$0$787$415eb37d at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <450e79fe$0$787$415eb37d at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
In-Reply-To: <450e79fe$0$787$415eb37d at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 57
Message-ID: <450e8785$0$786$415eb37d at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
NNTP-Posting-Host: 218.253.81.177
X-Trace: 1158580101 crater_reader.dragonflybsd.org 786 218.253.81.177
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 
is proving.

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' 
with kludges.

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.

Bill