On 6/7/05, David D. Rea <[EMAIL PROTECTED]> wrote: > > At the risk of playing devil's advocate, there's a flipside to this. > Code is [almost] never perfect, and anyone who subscribes to > gentoo-announce knows that there are almost always security flaws > discovered (and patched) after an initial version is released. >
You're right. > If more functionality is pulled into the hardware, with the same > potential for flaws (security or otherwise), then you've got a tough > predicament. As a hardware engineer, do you spec more expensive > re-programmable parts, or do you risk premature obsolescence (and > potentially millions of $$ in lost NRE charges) by using ROM-based > parts? Consider a video vendor who spins an ASIC (a custom chip) for its > latest graphics card... They might spend $50 million in mask fees to > have the new chip produced. Amortized over 100,000 graphics cards > produced, this is less expensive to them (and thus to us as consumers) > than instead spec'ing a re-programmable chip that costs 5x as much. > > What's really needed is not for hardware engineers to integrate more > functionality into their hardware, but rather for hardware and software > engineers to better work together. There's plenty of open-ness on the > part of software engineers; but the companies don't want to release the > gritty technical details of their products, and thus the hardware > engineers' hands are tied. Open the eyes of the managers and > administrators, and you'll open the hardware. I COMPLETELLY AGREE WITH THAT!!! The problem is that most managers and administrators are not hardware or software developers and struggles more with money and dealings than with compatibility issues. And money rules the world, so... > > Just my $0.02 as a hardware designer who regularly struggles with these > same issues... :) > > DDR > > -- > [email protected] mailing list > > -- Daniel da Veiga Computer Operator - RS - Brazil -- [email protected] mailing list
