1. Better planning and stage-by-stage management can help reduce this. In theory:-)
2. If there were more standards-adoption and less proprietary-ness then maybe people can code to expect less buggy hardware/drivers. CD-ROMs appear to use a pretty standard set of drivers, same with basic monitor usage. Modems are based on the Hayes set, but more and more extentions are causing grief, and then there's SCSI...
3. Time is a major problem, so make programmers go on strike until managers listen to the people that ultimately pay for the entire company's survival.
The tide for going GPL and getting publicity can only be good - so long as Companies understand what it means in real terms.
Perhaps in the education sector, universities and colleges should teach how to avoid bugs by planning on paper first, then peer-review and then code, then re-visit stage one again. Also how to ignore managers - if all software engineers did that the managers wouldn't have any more engineers to hire so they'd have to let the process slow down and let stability win.
And if people actually sent back their commercial software purchases for refunds rather than assigning them to a shelf while they install another product, maybe managers would get the message from the public perspective.
$ rpmfind will, when configured correctly, find any apps matching that, plus work out the dependencies needed that aren't met on your system, and offer to d/l it all for you. It's not perfect, but IMHO a reasonable solution.
I'd like to a new packaging system developed, combining the strengths of rpm and apt together with standard tarballs for distribution and local/remote management. Such a thing would be really cool and kick everything else into touch.
I concur, and I would advise reading of the DETAILED DESCRIPTION if you scroll the page down a bit.
What is interesting is that they appear to have created a CPU capable of running applications designed for one of many target systems (Intel x86/Pentium, PPC, Postscript and Java even) by buffering the instructions, optimising them, and then checking their execution for errors before execution occurs. Quite brilliant and mind-bogglingly complicated.
Note the business-angles hinted at: speed and optimisation come at significant cost; cost of producing any microprocessor is out of reach of most companies (inferring a mass market), large number of applications written for many targets (Windows, java, etc.), problems associated with traditional thinking with regard to optimization and parralel processing.
To create a microprocessor which overcomes the above at viable cost to both manufacturer and customer would be enormous!
Just think of it, you're running the Transmeta CPU which is running some OS, and running Office 2000 through it and knowing that the CPU will trap any problems before they occur! This is a hardware VM-Ware!
Slashdot Mirror
You'd think The Economist would be safe from the /. effect, but no, we've done it again...
1. Better planning and stage-by-stage management can help reduce this. In theory :-)
2. If there were more standards-adoption and less proprietary-ness then maybe people can code to expect less buggy hardware/drivers. CD-ROMs appear to use a pretty standard set of drivers, same with basic monitor usage. Modems are based on the Hayes set, but more and more extentions are causing grief, and then there's SCSI...
3. Time is a major problem, so make programmers go on strike until managers listen to the people that ultimately pay for the entire company's survival.
The tide for going GPL and getting publicity can only be good - so long as Companies understand what it means in real terms.
And if people actually sent back their commercial software purchases for refunds rather than assigning them to a shelf while they install another product, maybe managers would get the message from the public perspective.
What am I talking about, I'm just a consumer <g>
wrt RPMs, try rpmfind. www.rpmfind.net
$ rpmfind will, when configured correctly, find any apps matching that, plus work out the dependencies needed that aren't met on your system, and offer to d/l it all for you. It's not perfect, but IMHO a reasonable solution.
I'd like to a new packaging system developed, combining the strengths of rpm and apt together with standard tarballs for distribution and local/remote management. Such a thing would be really cool and kick everything else into touch.
I concur, and I would advise reading of the DETAILED DESCRIPTION if you scroll the page down a bit.
What is interesting is that they appear to have created a CPU capable of running applications designed for one of many target systems (Intel x86/Pentium, PPC, Postscript and Java even) by buffering the instructions, optimising them, and then checking their execution for errors before execution occurs. Quite brilliant and mind-bogglingly complicated.
Note the business-angles hinted at: speed and optimisation come at significant cost; cost of producing any microprocessor is out of reach of most companies (inferring a mass market), large number of applications written for many targets (Windows, java, etc.), problems associated with traditional thinking with regard to optimization and parralel processing.
To create a microprocessor which overcomes the above at viable cost to both manufacturer and customer would be enormous!
Just think of it, you're running the Transmeta CPU which is running some OS, and running Office 2000 through it and knowing that the CPU will trap any problems before they occur! This is a hardware VM-Ware!
Ooh I'm drooling already!
James Green