Re: ATI video comes out of the closet

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Les wrote:
> Hi, Frank,
> 	I can't dispute that this is how software has developed.  But that
> still doesn't make it right.  Would you drive over a bridge that had a
> 10% or higher chance of failure?  Or ride in an elevator with similar
> risks?  Of course not.  Standards were developed that governed how those
> things are designed based upon tragic failures.  Yet software
> engineering seems dead set on avoiding the issues surrounding the
> effective standardization that makes this possible.  IEEE and ACM both
> have committees on software reliability, yet I don't know many engineers
> who even know about the committees, much less read their proceedings or
> make any attempt to discover what is known already about software
> reliability, and how to incorporate it into their work.
> 
Something to think about - how many years did it take, and how much
experimentation, to get mechanical engineering to the point it is
today? Compare that to the time programming has been around. We are
still in the experimentation stage. Closed source and the way
Microsoft follows the standards are not helping. Too many of the
lessons learned are not being passed on.

Now, as far as riding risky machines, it is done all the time. What
are the chances of something breaking on your car? A motorcycle has
a bigger risk. How many bridges develop cracks or other defects that
have to be repaired? (Why are so many bridges being inspected right
now?) For that matter, bridges have a much higher chance of failure
then 10% That is why they have to be repaired/replaces. Bridges are
designed with a lifespan of X years. Push them past that point, and
you are asking for failure. The problems with software are closer to
cracks in a bridge then total bridge failure.

Mikkel
-- 

  Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!

Attachment: signature.asc
Description: OpenPGP digital signature

-- 
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux