According to this a group of hardy hackers are hard at work on a complete, from scratch, re-implementation of perl in C++. This reimplementation is supposed to be completely compatible with perl5. How can you guarantee compatibility without a specification? My guess is, in the same way that perl5 broke some obscure perl4 scripts, perl6 will break perl5 scripts - but without a spec, it's impossible to tell which of those breakages are bugs and which are features!
you have pushed a lot of that workd down to having the OS identify 2 processes
Actually, you have pushed the work all the way back to the programmer, forcing the code to be broken up into n parallelizable parts. Now, some code is "embarassingly" parallel, but most is not. Being a lazy programmer, I prefer tradeoffs that allow me to work less. For example, look at all the work that's gone into making the Linux kernel support SMP effectively for large numbers of CPUs. It's coming along, but it's taken a while, and hasn't been easy.
The problem with writing servers and gateways in Java is that there is no way to do non-blocking i/o, or select(2) in the Java libraries. Instead, you need (at least) one thread per fd, which is often memory expensive. VolanoMark shows this off, and the fastest Java VM for Volano (TowerJ) is the one with the most scalable thread implementation. There is a proposal in process (java.nio) to fix this, but who knows when it will see the light of day.
Lawmakers are idiots, not QNX engineers
on
QNX Crypt Cracked
·
· Score: 2
I'd don't know positively why QNX used such a terrible algorithm for the passwd file, but I have a pretty good guess. QNX is a small company, with superb engineers. They aren't idiots. They certainly know about *BSD and friends, and from the looks of it have certainly reused code from many other places. It probably would be less work to take the DES encryption from BSD, or wherever, than to come up with ones own.
The reason, I suspect, that they didn't use DES is that they were afraid of legal issues - I'm sure that QNX is sold all over the world, and they didn't want to make a diferent non-DES release for idiotic contries (France, US) with restrictive crypto laws. Even if an expensive legal effort would determine what's exportable where, laws change all the time. This way, there is no "export controlled" code that they need to worry about.
The author is mainly talking about patient medical record software, which is generally not audited by the FDA. The FDA spends most of its time worrying about medical devices which directly, and without human oversight, effect patients' lives. e.g. pacemakers, ventilators, etc.
Patient record software, though important, always has a human interpreting the results, so it is considered less critical. Many commercial patient record systems have terrible reliability today - many run on Windows and Windows NT. Even some of the mainframe based products have to be taken off-line nightly to do backups, for they don't have the capability to backup their databases online. Open Source would do these products a world of good, IMHO.
Moreover, in my experience, the FDA mostly looks at software developed by commercial entities. I am familiar with one prominent hospital where a physician developed an information system (in Fortran(!)) used on a daily basis, then lost the source in a disk crash! The system was apparently used for years without the ability to make changes to it. I'm sure the FDA never bothered to audit that program or its maintenence. How's this for another benefit of OSS, one that is never cited - backups!
After Snow Crash, Headcrash, by Bruce Bethke
on
Snow Crash
·
· Score: 1
Bruce Bethke's _Headcrash_ is my vote for the best geek book you've never heard of. You'll laugh, you'll cry, nah, you'll just laugh.
In all the hoopla about this challenge, the party that is most culpable for the break-in has been the most silent. Neither PC Week,/., jfs, or anyone else involved has heard from the company that wrote the buggy perl scripts. Are they notifying their customers? Though their web site is suprisingly quiet on the matter, they do list their customers, which are presumably still running this buggy software! Will hoffice release a fix? Will they warrant that future versions have no new security holes?
I don't begrudge a company for releasing buggy software, rather how they handle buggy (especially security related) releases.
Legal liability is another interesting issue. If I was running hoffice's software, and lost millions of dollars because of a hacker, how liable would hoffice be, shrinkwrap licenses notwithstanding? Would PC Week be liable at all? jfs?
Well, Microsoft is correct on this - I know of no Linux vendors who guarantee 99.9% availability, but why not? How much would, say, VA Research lose by offering this guarantee? I'm guessing not much. They probably could tack on another 9 without too much trouble.
If NT is so robust - why doesn't Microsoft offer this self-same guarantee itself, instead of relying on third parties, who probably don't even have source?
More importantly, for many uses, availability isn't a very useful statistic. For example, most extremely highly available systems, like telephone switches and airline reservation systems rely on extremely quick re-booting times to meet their high availability numbers. If you can reboot in three seconds, you can crash every hour, and still claim 99.9% availability! Desktop users, who lose work on a system crash, no matter how long it takes to reboot, care more about MTTF (Mean Time To Failure) than availability.
A more useful analog to the "crack this box" challenge would be for Slashdot (or some other high volume site) to challenge NT to a MTTF contest. That is, keep track of all downtime for an extended period of time (six months), and the total number of web hits. Then calculate the average time between crashes, and the average number of hits between crashes.
Slashdot Mirror
According to this a group of hardy hackers are hard at work on a complete, from scratch, re-implementation of perl in C++. This reimplementation is supposed to be completely compatible with perl5. How can you guarantee compatibility without a specification? My guess is, in the same way that perl5 broke some obscure perl4 scripts, perl6 will break perl5 scripts - but without a spec, it's impossible to tell which of those breakages are bugs and which are features!
Actually, you have pushed the work all the way back to the programmer, forcing the code to be broken up into n parallelizable parts. Now, some code is "embarassingly" parallel, but most is not. Being a lazy programmer, I prefer tradeoffs that allow me to work less. For example, look at all the work that's gone into making the Linux kernel support SMP effectively for large numbers of CPUs. It's coming along, but it's taken a while, and hasn't been easy.
The problem with writing servers and gateways in Java is that there is no way to do non-blocking i/o, or select(2) in the Java libraries. Instead, you need (at least) one thread per fd, which is often memory expensive. VolanoMark shows this off, and the fastest Java VM for Volano (TowerJ) is the one with the most scalable thread implementation. There is a proposal in process (java.nio) to fix this, but who knows when it will see the light of day.
The reason, I suspect, that they didn't use DES is that they were afraid of legal issues - I'm sure that QNX is sold all over the world, and they didn't want to make a diferent non-DES release for idiotic contries (France, US) with restrictive crypto laws. Even if an expensive legal effort would determine what's exportable where, laws change all the time. This way, there is no "export controlled" code that they need to worry about.
I've used bibliofind and abebooks, and both seem to work well.
Patient record software, though important, always has a human interpreting the results, so it is considered less critical. Many commercial patient record systems have terrible reliability today - many run on Windows and Windows NT. Even some of the mainframe based products have to be taken off-line nightly to do backups, for they don't have the capability to backup their databases online. Open Source would do these products a world of good, IMHO.
Moreover, in my experience, the FDA mostly looks at software developed by commercial entities. I am familiar with one prominent hospital where a physician developed an information system (in Fortran(!)) used on a daily basis, then lost the source in a disk crash! The system was apparently used for years without the ability to make changes to it. I'm sure the FDA never bothered to audit that program or its maintenence. How's this for another benefit of OSS, one that is never cited - backups!
Bruce Bethke's _Headcrash_ is my vote for the best geek book you've never heard of. You'll laugh, you'll cry, nah, you'll just laugh.
I don't begrudge a company for releasing buggy software, rather how they handle buggy (especially security related) releases.
Legal liability is another interesting issue. If I was running hoffice's software, and lost millions of dollars because of a hacker, how liable would hoffice be, shrinkwrap licenses notwithstanding? Would PC Week be liable at all? jfs?
If NT is so robust - why doesn't Microsoft offer this self-same guarantee itself, instead of relying on third parties, who probably don't even have source?
More importantly, for many uses, availability isn't a very useful statistic. For example, most extremely highly available systems, like telephone switches and airline reservation systems rely on extremely quick re-booting times to meet their high availability numbers. If you can reboot in three seconds, you can crash every hour, and still claim 99.9% availability! Desktop users, who lose work on a system crash, no matter how long it takes to reboot, care more about MTTF (Mean Time To Failure) than availability.
A more useful analog to the "crack this box" challenge would be for Slashdot (or some other high volume site) to challenge NT to a MTTF contest. That is, keep track of all downtime for an extended period of time (six months), and the total number of web hits. Then calculate the average time between crashes, and the average number of hits between crashes.