Date: Thu, 08 Jun 2000 00:19:13 -0600 From: Drew Eckhardt <drew@Poohsticks.ORG> To: chad@DCFinc.com Cc: freebsd-smp@FreeBSD.ORG Subject: Hardware and MS rant Was: Tyan Thunder 2400/i840 SMP no good Message-ID: <200006080619.e586JDR01400@chopper.Poohsticks.ORG> In-Reply-To: Your message of "Wed, 07 Jun 2000 22:53:04 PDT." <200006080553.WAA15952@freeway.dcfinc.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200006080553.WAA15952@freeway.dcfinc.com>, chad@DCFinc.com writes:
>As I recall, Mike Smith wrote:
>> Yes. I've even see this with "high quality" SDRAM; the i840 board I'm
>> currently using has some cheap and nasty 64MB DIMMs which work fine, but
>> most of the "high quality" parts I've tried have failed miserably.
>
>Does this seem like a problem to anyone besides me?
Sure.
>Given the MoBo's sold at Fry's with the memory sold at Fry's will run
>Windows98 without falling over in a way that is not clearly Windows
>fault, then we (FreeBSD) will look bad if we can't run on the same
>hardware.
Good. Joe Random Clueless Luser will be scared off by the reports
he sees on free unix hardware compatability problems, stick to windows,
and not burden us with questions that are answered in the FAQs . With a
more intelligent user community, unix software will be written for
functionality (like nvi, with infinite undo), and not crippled to make
it drool proof (like Netscape, where regexes weren't included in the
released versions because "they would confuse people").
>Can we claim (with a straight face) that there is a legitimate reason
>FreeBSD is more picky about its hardware platform than Windows/NT
>Server?
Yes.
1. Hardware is thoroughly tested and tweaked to work with common
Windows/NT applications because otherwise it won't sell. Since
failures under FreeBSD, OpenBSD, NetBSD, RedHat, Caldera, SUSE,
or the free unix du jour will have a negligible impact on sales
but a substantial impact on time to market it doesn't get tested
and problems not detected in testing are more likely.
2. Many free unix programs are more complicated than their commercial
counterparts. This means they do a better job (compare the code
generated by GCC 1.37 to that from the Microsoft compiler resold by
SCO at the same time), at the expense of more complex memory access
patterns that are more likely to trigger bugs (search your Usenet
archives for signal 11 or SIGSEGV and gcc).
>If it were not, these MoBo/memory configurations would be
>being shoved back up the <expletive deleted>
>of the vendors when
>the customers tried to run the software package that is on 90% of
>the Intel boxen out there and failed.
The accepted practice when something fails under Windows is to
1. Reboot
2. Rerun the application
3. Reboot
4. Reinstall the application
5. Reboot
6. Rerun the application
7. Reboot
8. Install all of the service packs
9. Reboot
10. Rerun the application
11. Reboot
12. Reinstall Windows du jour
13. Reboot
14. Install the service packs
15. Reboot
16. Reinstall the application
17. Reboot
18. Rerun the application
19. Bang head against wall in frustration
20. Live with the problem
People's expectations of personal computer (PC, Mac, TRS80, Commodore
64, etc) software aren't very high, and they manage when it fails.
Common hardware + driver + applications configurations DO fail with great
regularity under Windows, and beyond a quiet "Oh yeah, that happened to
me too. Buy a different board" people do nothing constructive about the
situation.
For that matter, some make a sport out of it. "Sure, my over-clocked
system won't run the Wazzyding benchmark, but it runs 3 frames per
second faster under quake demo".
(Yeah, I'm feeling cranky tonight).
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200006080619.e586JDR01400>