> You usually want to build your product for the biggest market first.
Not necessarily. What these folks were building was some fancy-schmancy high-quality sound-studio software. One of the problems with running such stuff on Windows now is that they all come with MS Media Player. When you run any of its components, any "non-approved" sound software simply dies and needs to be re-installed before it can be used again. If you want to be on Media Player's non-hit list, you need to license it to Microsoft. This means that you effectively lose the rights to your software, and Microsoft controls what you can do with it.
I wasn't privy to their talks with MS's licensing people, but I know the result was a minor bout of depression. This had a lot to do with their looking seriously at OSX and Linux. I also got the impression that, after they talked to a few professional sound people, they were even more comfortable with ignoring Windows and going with the other two platforms.
Anyone else have comments to add to this? Maybe it should be a new topic? Maybe it can all get rates flamebait?
A few months back, I helped some friends price out a "full" development Windows XP system. The idea was to get whatever was needed to do sufficient testing to guarantee that their software (mostly written in C and C++) would run on any Windows XP system. It turned out that the compiler was just the start of it. When they had a full list of all the libraries, packaging software, and testing packages that they'd need, the price was somewhat over $20,000.
Microsoft developer licenses can be pricey.
They decided to go with the Mac (which they already had) and linux (which they deemed a growing market). Later, when and if they got enough sales, they'd reconsider XP.
The word "culture" doesn't just mean human-type culture; it refers to any passing of information from one generation to the next by behavioral means.
Behavioralists have written a fair amount about parrot "culture". Parrots are generally adapted to exploiting a food source that is difficult to exploit. Parrots mostly eat seeds (and sometimes the fruit around them), so to a tree they are predators, and in areas with parrots, trees tend to protect their seeds. Part of the protectin is hard shells, but part is by hiding them so that parrots can't easily find them.
Part of the explanation of how parrots survive is that they learn to find seeds from the flock's elders. A flock member will remember that at this time of year, over on the east side of that hill, there are these trees that have good seeds about half-way up and 2/3 of the way out from the trunk. That parrot will lead the others there, and they'll learn about the seeds, and remember.
This is the conventional explanation of their intelligence, memory and longevity. These are needed to remember how to find all those hidden seeds from year to year.
We have a female cockatiel that we got from a friend with a breeding pair about 5 years ago. She's generally a skittish bird who is very wary of strangers. He moved away about 3 years ago. When he was in town a few months ago, he came by for a visit. After a few seconds of looking at him skeptically, she flew over, landed on his shoulder and nibbled his ear. This illustrates the memory abilities of even a small parrot.
Anyone who has had a pet parrot knows quite well how effective a "three-fingered hand" their beak and tongue are. If they had managed to spare a few brain cells for more complex language, they would now be the ones running the planet.
This has been handled for ages in the standard C library. If you want a comparison to be case sensitive, you call strcmp(). If you want case insensitivity, you call strcasecmp().
Similar things exist in most higher-level programming languages. For example, with perl pattern matches, you add 'i' to the list of flags, and a case-insensitive compare is done. This works with locales in all recent versions of perl. And so on for other languages.
This is an open invitation to implementers. It's very easy to to case-insensitive compares. If you are aiming your software at a user population that can't handle case distinctions, the tools are there and you have no excuse.
Unix and its clones don't impose any policy at all on user-level software, and they supply the tools to handle case sensitivity. Use them and stop complaining.
In the news lately has been the story that in Palm Beach County, Florida, they are replacing the voting equipment that caused so much trouble two years ago with new equipment. But the new equipment contains proprietary software whose inner working can't be examined. The result is that there will be no way to have an independent audit of the election results.
What we need is government accountability. This can only be done if the computers that control the data can be examined in detail. Any software that has closed components can and will be used to prevent auditing and accountability.
The only way to get honesty and accountability in government data systems is to require that all software be open to examination and auditing. This can only be done with a strict legal ban on binary-only software in government computers.
As with the Palm Beach voting equipment, proprietary software is an open invitation to Fraud and Abuse by whoever runs the equipment (or whoever bribes them).
This is one of the textbook examples of what people in several fields (such as economics evolutionary biology) have for some time referred to as "super-rational" behavior.
Th conventional definition of "super-rational" is taking into account the consequences of everyone (or at least the majority) following the strategy. It doesn't actually imply that the actors are rational (or even thinking). One of the topics where it has been used is the biological question of how altruism evolves. The best explanation so far is that a population that behaves altruistically among themselves has a survival advantage over purely individualistic populations.
The double toilet paper example is used as a clear way of illustrating this concept, in a way that doesn't impinge on people's social or religious ideologies. Very few people have any strong feelings about which roll you should use, so they are able to follow the argument without their beliefs causing distraction. And it's clear that a population could behave in a super-rational fashion in this case without being consciously aware that they were doing so. An irrational preference for the inner part of the roll would suffice.
If you ask google about "super-rational", you'll find a number of links to this concept buried among the silly and/or pretentious sites.
Here in Waltham, Massachusetts, there's a glass harmonica manufacturer. There are also a number of people in the Boston area who play it.
If you ask google about "glass harmonica player" you'll get info on a lot of them.
You might also note that the Finkenbeiner page claims that their instruments contain no lead. However, this may not be the explanation for the apparent insanity of a lot of the early players. The few people I've know who play glass harmonica have all replied to this idea with the claim that you have to be crazy to take up the instrument in the first place.
It does have a rather marvelous "new age" sound. But probably the reason it never really caught on is that it has no attack at all, and can't really be played rapidly. It's ideal for slow, dreamy music; it's not so good for fast, bouncy music.
The modern instruments are better in this regard than Franklin's originals. You can get them with an electric motor with speed control, dampers, etc. This expands their sound quite a bit. But they are still a stubtle, ethereal instrument, with very little attack.
Last October, NPR had a good article on the topic. They started off by saying that there were some airlines that were prepared to profit handsomely from the WTC attack. They then mentioned an aircraft manufacturer (not Penguin, could it have been Maverick?) that had already received orders for a billion dollars worth of airplanes. That's 1000 planes at $1 million each. The model was a new and very small jet with a seating capacity of 6, and the customers were new air taxi services.
They went on to explain that, because all flights would be "charter" and to/from small airports, they would be exempt from the new security checks. And unlike airliners, there were over 5000 airports in the US where they could land.
The estimated cost of a flight was somewhat more than the price of a first-class airline ticket. But for that price, you could take up to six people.
They were predicting lots of business as the airlines came under the control of the new security procedures.
Occasional followup reports have said that these predictions are slowly coming true.
> That's like saying "Europeans unhappy with the way the US government has been aligning the planets".
Well, there is precedent for this. There's the story from back in the Little Ice Age (1600-1800 roughly), of a small town in the Alps that was threatened by an encroaching glacier. So the town council did the logical thing: They passed an ordinance prohibiting glaciers from entering the town.
It really just shows that if you have a flock of MIT and BU and EFF lawyers on your side, Microsoft might back off. Otherwise, well, how much money do you have to spend on defense?
Also, it might be worth pointing out that MIT has a long history of defending the right to publish. They've gone up against various parts of the US government on various occasions, and they have a record of winning. Microsoft probably understands that MIT *will* fight it in the courts, with the explicit aim of getting the DMCA and other such laws thrown out.
The way to win DMCA fights is to pick on people who don't have the wherewithall to fight it in court. It's not so much a legal tool as it is an intimidation tool. If your opponent can't be intimidated, you stand a very real chance of losing not just the court case but your intimidation tool.
Some years back, at a university that will remain unnamed (so you might think it's yours;-), a bunch of us grad students decided to instrument the Fortran compiler that was used for most of the number crunching on the big department monster machine. The hardware handled integer overflows by setting a flag bit, which then had to be tested by a separate opcode, and the Fortran compiler didn't generate this test. (For floating point, there was an interrupt that couldn't be ignored.)
The instrumentation added a test that recorded the overflow, let the computation continue, and wrote some results to an accounting file.
What was found was that almost exactly half the Fortran runs produced at least one output number that was wrong due to an undetected overflow.
When this was publicised, a survey of Fortran users was done. They were asked whether the compiler should test for overflow if such a test would take an extra opcode and slow the program down. around 90% of the users said that such tests should not be done if the program would run slower.
This taught us an important lesson about the Fortran user community. And note that in the replies here, a lot is made of Fortran's optimizations. Now you know what that means.
Around the same time, there was one of several analyses of the Fortran runtime libraries on IBM 370 mainframes, which are still in wide use for big number-crunching applications. The analysis showed that the double routines were accurate to only float precision over roughly half the range of their arguments. At the time, these routines had been in widespread use for maybe two decades.
When a Fortran programmer uses double rather than float, it usually means that the computations needs the extra precision, and float doesn't have good enough precision to give correct output. For users to accept a Fortran that can't do doubles correctly half the time is another good sign of the nature of this user community.
So in general, Fortran users seem to use it because they consider efficiency more important than correct results.
Would the UCITA warranty requirements apply to alpha and beta releases? I haven't seen any mention of this topic, so I'd assume that the law treats all software the same in this respect.
If so, it would effectively stop such releases, since they would be a guaranteed legal and financial disaster. But clearly labelled alpha and beta releases are a very good approach to getting customer feedback, both for bugs and for features that are difficult to understand (or missing).
This is one of the ways in which software is different from most other commercial products. It's fairly rare for companies to provide test versions of products to customers, though it does happen. But it's very common with software.
If the UCITA inhibits alpha and beta releases, the result would be much lower quality software.
If what we want to do is stop viruses and worms and the like, there's a simple thing we could do that would eliminate over 99% of them.
Just ban all Microsoft systems from the Internet.
The remaining handful of viruses and worms wouldn't be enough of a problem to get the media's attention. We'd want a mop-up operation to stop them, of course. But that would be a minor technical project that the media wouldn't find interesting.
We should have done this five years ago, when it was becoming clear that Microsoft had no intention of fixing the security holes they were building into their systems, and their customers were too clueless to demand fixes.
There's at least one good reason for having a third party mediate in cases of security holes. It's a good way to "anonymize" the bug report.
Recent cases such as the HP/SnoSoft, Sklarov and DeCCS incidents show that the likely response of corporations to security bug reports is to threaten the person who made the report. This inherently has a chilling effect. If the person is intimidated by the corporation's lawyers, the problem may not be fixed.
If a third party like CERT can maintain a reputation for protecting people like me from the wrath of corporations like HP, I'm much more likely to tell them what I know about vulnerabilities. If not, I'll just stick to my policy of not risking my bank account and professional future.
Well, the metaphor that I prefer is the construction one: To do a good job of building something, whether it be a building or a program, you need to include a lot of scaffolding. You remove most of it when you're done. But with software, you can be slow about this, since the scaffolding is generally not too visible, and you invariably find that you need it when the user bug reports come pouring in.
If that makes me a cracker, well, I and all other good programmers are crackers.
Of course, I do like to document my "back doors" in the user manual. I've learned that this can save me some time. Instead of a customer calling up and saying "It doesn't work and it won't tell me what's wrong" they often look at the manual. They find the instructions for turning on the debug hooks, so they do it, direct the output to a file, and email it to me. We just skipped over the first phase of fixing their problem and went right to the second.
And sometimes the output tells them why it was failing. They move the config file to one of the places where it was looking, and change the permissions so the file can be read, and it works without even bothering me.
So a documented "back door" is even more useful than an undocumented one.
> It compiles a daemon that tries to contact 203.62.158.32 on port 6667 and offers a remote shell for the user compiling the package. After that all files involved are removed and the makefile changed to the original one.
This sounds like a fairly conventional sort of debug hook. Connect back to the source archive where there are lots of debug and alpha-release goodies, let the installer download stuff, and compile it all into the binaries. Just what you'd want when you're developing stuff and want to make it easy to install on test machines.
I've also sometimes forgotten to remove the debug hooks.
I'm really disappointed that nobody has yet pointed out that the Internet, SMTP, and all that were built on projects funded by the US Government. The DOD's ARPA (Advanced Research Projects Agency), to be precise. I was using it back in the 70's, and I was quite aware of where the funding came from.
And the actual constructions was done almost entirely by universities. The few "private" companies involved (such as BB&N) were living almost entirely off government grants and contracts.
The corporate enterprise ideologists are trying hard to invent their own history so that they can claim some of the credit. But this is all historic revisionism. The real credit belongs to the evil old government, in collusion with a lot of academic hackers.
It may be true that forms of email were developed by a number of computer vendors. But they were all proprietary (even UUCP and DECnet), didn't interoperate worth a damn, and mostly couldn't be licensed for a finite cost.
It's kinda too bad. I've always thought that UUCP mail was better than SMTP. But if was freed by AT&T a bit too late, and SMTP already had the territory. Note that SMTP is defined by a set of US government standards.
> People really resist the phone. Lots will reply to me here. A few will email. None will call.
To a great extent, this is intentional. One of the real benefits of email and posting replies is that you can stare at your text on the screen, rewrite, check facts, reword, and only hit the Send button when you think you've got it right. Granted, not everyone does this, but many (possibly most) of us do.
Also, a phone call can easily get lost in the shuffle. A text message sits there until someone deletes it. You can come back to it an hour or a year later. You can toss it into bins and count the pro/con messages. You can grep through your messages looking for keywords.
I can't see any reason for techies to ever use the phone for issues like this. Posted and emailed replies are so superior.
Phone calls and face time make sense for communicating with suits. They don't make sense in technical discussions. This is a lot of why Open Source development has been so outpacing corporate software lately. The corporate model has people in a room or on the phone. The Open Source model has everyone communicating via email and mailing lists. The latter is orders of magnitude more effective at getting ideas across without loss or misunderstanding.
It might be worth pointing out here that, even with a prior contract, the laws of most countries would still require disclosure at some point. No contract can be used to excuse conspiracy to commit illegal acts (such as fraud). The recent accounting scandals have brought this out quite clearly.
Tru64 Unix is openly marketed for gateway and firewall uses. If there is a known root exploit in such systems, and customers are not informed of the problem, there are good grounds for some serious charges. I'd bet that HP has a flock of lawyers looking at this right now. There's a good chance that they have some big customers also looking at it. If any Tru64 firewall has been rooted in the past year, there may be some big settlements in the news some time in the future.
If it's true that SnoSoft informed HP of the problem a year ago, then whether there's a contract between them is probably moot. The problem wasn't fixed, so most countries' laws would require SnoSoft to go public with at least the basic facts of the situation. A year is a long time to keep such information secret from vulnerable customers.
If the problem had been fixed, then we'd expect that HP would be going public with the facts (and the fix).
What I'd conclude from this is that if I discover a security problem in a government system, I'd better not tell them about it. Rather than hire me to fix it, they'll probably just arrest me.
What I should obviously do is pass the word among other interested parties that I know how to get info out of the government system. There are lots of people out there that will pay for this. And they won't arrest me, because they aren't part of the legal system.
I suspect that the folks in the Houston government understand this quite well. In fact, if I talk to some of them in private, I'd bet that they might be quite happy to pass my name to some of their campaign contributors, where I could pick up a few nice consulting contracts.
Does anyone here think I'm being overly cynical? If so, you don't know much about Texas politics. You oughta read some Molly Ivins.
> If often wonder if anyone has tried to get a grant for "the development of a disc-shaped flying object" yet.
If they do, they'll probably apply for a patent, and the US patent office will approve it. Then they'll charge manufacturers of frisbees with patent infringement. A call will go out for people who have knowledge of any prior art, but few people will respond, only a few geeks and we know how reliable they are. The frisbee manufacturers will attempt to show that they manufacturer their products before 2002, but the patent office and courts will have machines whose software treats all 2-digit dates as having an initial "20". As a result, the courts will conclude that frisbees won't be manufactured for another 60 years or so, and the manufacturers will be ordered to pay royalties.
Hey, maybe I can turn it into a short story and get it published...
> go for an operating system controlled by one company, who knows what their code does, and how to fix it if it goes wrong. The only option, in that case, is Microsoft.
Er... or Apple?
Yeah. Or, for that matter, RedHat.
And with RedHat (or any of the other linux vendors), not only do they know what their code does, but there are also thousands of programmers scattered around the world who know a lot about it.
So if you have a problem, you don't have to beg and plead with a disinterested CS department of a giant corporation. You don't even have to deal with your vendor.
If it's a small problem, you can probably hire one or two of the linux hackers at your local college. For bigger projects that take experience, you can hire a few of the local linux professionals.
You'll be up and running in far less time than it takes to persuade Microsoft to support your needs.
> How can something that was considered private enough to require a judge's approval now be sold to the highest bidder.
It probably has something to do with the fact that the US is now run by a fellow who has in all seriousness described himself as "America's CEO". He really, truly believes that the government should be run as a business.
This is how businesses do things. If you have a product, you sell it. If we don't like this, we'll just have to find ourselves a CEO who thinks the government should be run like a government.
Of course, we'll first have to make the presidency an elected office...
Slashdot Mirror
> You usually want to build your product for the biggest market first.
Not necessarily. What these folks were building was some fancy-schmancy high-quality sound-studio software. One of the problems with running such stuff on Windows now is that they all come with MS Media Player. When you run any of its components, any "non-approved" sound software simply dies and needs to be re-installed before it can be used again. If you want to be on Media Player's non-hit list, you need to license it to Microsoft. This means that you effectively lose the rights to your software, and Microsoft controls what you can do with it.
I wasn't privy to their talks with MS's licensing people, but I know the result was a minor bout of depression. This had a lot to do with their looking seriously at OSX and Linux. I also got the impression that, after they talked to a few professional sound people, they were even more comfortable with ignoring Windows and going with the other two platforms.
Anyone else have comments to add to this? Maybe it should be a new topic? Maybe it can all get rates flamebait?
A few months back, I helped some friends price out a "full" development Windows XP system. The idea was to get whatever was needed to do sufficient testing to guarantee that their software (mostly written in C and C++) would run on any Windows XP system. It turned out that the compiler was just the start of it. When they had a full list of all the libraries, packaging software, and testing packages that they'd need, the price was somewhat over $20,000.
Microsoft developer licenses can be pricey.
They decided to go with the Mac (which they already had) and linux (which they deemed a growing market). Later, when and if they got enough sales, they'd reconsider XP.
The word "culture" doesn't just mean human-type culture; it refers to any passing of information from one generation to the next by behavioral means.
Behavioralists have written a fair amount about parrot "culture". Parrots are generally adapted to exploiting a food source that is difficult to exploit. Parrots mostly eat seeds (and sometimes the fruit around them), so to a tree they are predators, and in areas with parrots, trees tend to protect their seeds. Part of the protectin is hard shells, but part is by hiding them so that parrots can't easily find them.
Part of the explanation of how parrots survive is that they learn to find seeds from the flock's elders. A flock member will remember that at this time of year, over on the east side of that hill, there are these trees that have good seeds about half-way up and 2/3 of the way out from the trunk. That parrot will lead the others there, and they'll learn about the seeds, and remember.
This is the conventional explanation of their intelligence, memory and longevity. These are needed to remember how to find all those hidden seeds from year to year.
We have a female cockatiel that we got from a friend with a breeding pair about 5 years ago. She's generally a skittish bird who is very wary of strangers. He moved away about 3 years ago. When he was in town a few months ago, he came by for a visit. After a few seconds of looking at him skeptically, she flew over, landed on his shoulder and nibbled his ear. This illustrates the memory abilities of even a small parrot.
Anyone who has had a pet parrot knows quite well how effective a "three-fingered hand" their beak and tongue are. If they had managed to spare a few brain cells for more complex language, they would now be the ones running the planet.
This has been handled for ages in the standard C library. If you want a comparison to be case sensitive, you call strcmp(). If you want case insensitivity, you call strcasecmp().
Similar things exist in most higher-level programming languages. For example, with perl pattern matches, you add 'i' to the list of flags, and a case-insensitive compare is done. This works with locales in all recent versions of perl. And so on for other languages.
This is an open invitation to implementers. It's very easy to to case-insensitive compares. If you are aiming your software at a user population that can't handle case distinctions, the tools are there and you have no excuse.
Unix and its clones don't impose any policy at all on user-level software, and they supply the tools to handle case sensitivity. Use them and stop complaining.
In the news lately has been the story that in Palm Beach County, Florida, they are replacing the voting equipment that caused so much trouble two years ago with new equipment. But the new equipment contains proprietary software whose inner working can't be examined. The result is that there will be no way to have an independent audit of the election results.
What we need is government accountability. This can only be done if the computers that control the data can be examined in detail. Any software that has closed components can and will be used to prevent auditing and accountability.
The only way to get honesty and accountability in government data systems is to require that all software be open to examination and auditing. This can only be done with a strict legal ban on binary-only software in government computers.
As with the Palm Beach voting equipment, proprietary software is an open invitation to Fraud and Abuse by whoever runs the equipment (or whoever bribes them).
This is one of the textbook examples of what people in several fields (such as economics evolutionary biology) have for some time referred to as "super-rational" behavior.
Th conventional definition of "super-rational" is taking into account the consequences of everyone (or at least the majority) following the strategy. It doesn't actually imply that the actors are rational (or even thinking). One of the topics where it has been used is the biological question of how altruism evolves. The best explanation so far is that a population that behaves altruistically among themselves has a survival advantage over purely individualistic populations.
The double toilet paper example is used as a clear way of illustrating this concept, in a way that doesn't impinge on people's social or religious ideologies. Very few people have any strong feelings about which roll you should use, so they are able to follow the argument without their beliefs causing distraction. And it's clear that a population could behave in a super-rational fashion in this case without being consciously aware that they were doing so. An irrational preference for the inner part of the roll would suffice.
If you ask google about "super-rational", you'll find a number of links to this concept buried among the silly and/or pretentious sites.
Here in Waltham, Massachusetts, there's a glass harmonica manufacturer. There are also a number of people in the Boston area who play it.
If you ask google about "glass harmonica player" you'll get info on a lot of them.
You might also note that the Finkenbeiner page claims that their instruments contain no lead. However, this may not be the explanation for the apparent insanity of a lot of the early players. The few people I've know who play glass harmonica have all replied to this idea with the claim that you have to be crazy to take up the instrument in the first place.
It does have a rather marvelous "new age" sound. But probably the reason it never really caught on is that it has no attack at all, and can't really be played rapidly. It's ideal for slow, dreamy music; it's not so good for fast, bouncy music.
The modern instruments are better in this regard than Franklin's originals. You can get them with an electric motor with speed control, dampers, etc. This expands their sound quite a bit. But they are still a stubtle, ethereal instrument, with very little attack.
Last October, NPR had a good article on the topic. They started off by saying that there were some airlines that were prepared to profit handsomely from the WTC attack. They then mentioned an aircraft manufacturer (not Penguin, could it have been Maverick?) that had already received orders for a billion dollars worth of airplanes. That's 1000 planes at $1 million each. The model was a new and very small jet with a seating capacity of 6, and the customers were new air taxi services.
They went on to explain that, because all flights would be "charter" and to/from small airports, they would be exempt from the new security checks. And unlike airliners, there were over 5000 airports in the US where they could land.
The estimated cost of a flight was somewhat more than the price of a first-class airline ticket. But for that price, you could take up to six people.
They were predicting lots of business as the airlines came under the control of the new security procedures.
Occasional followup reports have said that these predictions are slowly coming true.
> That's like saying "Europeans unhappy with the way the US government has been aligning the planets".
Well, there is precedent for this. There's the story from back in the Little Ice Age (1600-1800 roughly), of a small town in the Alps that was threatened by an encroaching glacier. So the town council did the logical thing: They passed an ordinance prohibiting glaciers from entering the town.
It really just shows that if you have a flock of MIT and BU and EFF lawyers on your side, Microsoft might back off. Otherwise, well, how much money do you have to spend on defense?
Also, it might be worth pointing out that MIT has a long history of defending the right to publish. They've gone up against various parts of the US government on various occasions, and they have a record of winning. Microsoft probably understands that MIT *will* fight it in the courts, with the explicit aim of getting the DMCA and other such laws thrown out.
The way to win DMCA fights is to pick on people who don't have the wherewithall to fight it in court. It's not so much a legal tool as it is an intimidation tool. If your opponent can't be intimidated, you stand a very real chance of losing not just the court case but your intimidation tool.
... and what we need to do is publicise the dangers of internet music piracy, as in this article.
(The Onion has had some very, uh, informative stories on this issue. They're well worth reading, and passing on to friends.)
Some years back, at a university that will remain unnamed (so you might think it's yours ;-), a bunch of us grad students decided to instrument the Fortran compiler that was used for most of the number crunching on the big department monster machine. The hardware handled integer overflows by setting a flag bit, which then had to be tested by a separate opcode, and the Fortran compiler didn't generate this test. (For floating point, there was an interrupt that couldn't be ignored.)
The instrumentation added a test that recorded the overflow, let the computation continue, and wrote some results to an accounting file.
What was found was that almost exactly half the Fortran runs produced at least one output number that was wrong due to an undetected overflow.
When this was publicised, a survey of Fortran users was done. They were asked whether the compiler should test for overflow if such a test would take an extra opcode and slow the program down. around 90% of the users said that such tests should not be done if the program would run slower.
This taught us an important lesson about the Fortran user community. And note that in the replies here, a lot is made of Fortran's optimizations. Now you know what that means.
Around the same time, there was one of several analyses of the Fortran runtime libraries on IBM 370 mainframes, which are still in wide use for big number-crunching applications. The analysis showed that the double routines were accurate to only float precision over roughly half the range of their arguments. At the time, these routines had been in widespread use for maybe two decades.
When a Fortran programmer uses double rather than float, it usually means that the computations needs the extra precision, and float doesn't have good enough precision to give correct output. For users to accept a Fortran that can't do doubles correctly half the time is another good sign of the nature of this user community.
So in general, Fortran users seem to use it because they consider efficiency more important than correct results.
I wonder if Enron's accountants use Fortran?
Would the UCITA warranty requirements apply to alpha and beta releases? I haven't seen any mention of this topic, so I'd assume that the law treats all software the same in this respect.
If so, it would effectively stop such releases, since they would be a guaranteed legal and financial disaster. But clearly labelled alpha and beta releases are a very good approach to getting customer feedback, both for bugs and for features that are difficult to understand (or missing).
This is one of the ways in which software is different from most other commercial products. It's fairly rare for companies to provide test versions of products to customers, though it does happen. But it's very common with software.
If the UCITA inhibits alpha and beta releases, the result would be much lower quality software.
If what we want to do is stop viruses and worms and the like, there's a simple thing we could do that would eliminate over 99% of them.
Just ban all Microsoft systems from the Internet.
The remaining handful of viruses and worms wouldn't be enough of a problem to get the media's attention. We'd want a mop-up operation to stop them, of course. But that would be a minor technical project that the media wouldn't find interesting.
We should have done this five years ago, when it was becoming clear that Microsoft had no intention of fixing the security holes they were building into their systems, and their customers were too clueless to demand fixes.
> You know that little chunk that Massachusetts has along the top of CT, I think CT is still pissed off about that ...
Well, I always thought that was a tab so that Massachusetts wouldn't just slide out to sea.
There's at least one good reason for having a third party mediate in cases of security holes. It's a good way to "anonymize" the bug report.
Recent cases such as the HP/SnoSoft, Sklarov and DeCCS incidents show that the likely response of corporations to security bug reports is to threaten the person who made the report. This inherently has a chilling effect. If the person is intimidated by the corporation's lawyers, the problem may not be fixed.
If a third party like CERT can maintain a reputation for protecting people like me from the wrath of corporations like HP, I'm much more likely to tell them what I know about vulnerabilities. If not, I'll just stick to my policy of not risking my bank account and professional future.
Well, the metaphor that I prefer is the construction one: To do a good job of building something, whether it be a building or a program, you need to include a lot of scaffolding. You remove most of it when you're done. But with software, you can be slow about this, since the scaffolding is generally not too visible, and you invariably find that you need it when the user bug reports come pouring in.
If that makes me a cracker, well, I and all other good programmers are crackers.
Of course, I do like to document my "back doors" in the user manual. I've learned that this can save me some time. Instead of a customer calling up and saying "It doesn't work and it won't tell me what's wrong" they often look at the manual. They find the instructions for turning on the debug hooks, so they do it, direct the output to a file, and email it to me. We just skipped over the first phase of fixing their problem and went right to the second.
And sometimes the output tells them why it was failing. They move the config file to one of the places where it was looking, and change the permissions so the file can be read, and it works without even bothering me.
So a documented "back door" is even more useful than an undocumented one.
> It compiles a daemon that tries to contact 203.62.158.32 on port 6667 and offers a remote shell for the user compiling the package. After that all files involved are removed and the makefile changed to the original one.
This sounds like a fairly conventional sort of debug hook. Connect back to the source archive where there are lots of debug and alpha-release goodies, let the installer download stuff, and compile it all into the binaries. Just what you'd want when you're developing stuff and want to make it easy to install on test machines.
I've also sometimes forgotten to remove the debug hooks.
I'm really disappointed that nobody has yet pointed out that the Internet, SMTP, and all that were built on projects funded by the US Government. The DOD's ARPA (Advanced Research Projects Agency), to be precise. I was using it back in the 70's, and I was quite aware of where the funding came from.
And the actual constructions was done almost entirely by universities. The few "private" companies involved (such as BB&N) were living almost entirely off government grants and contracts.
The corporate enterprise ideologists are trying hard to invent their own history so that they can claim some of the credit. But this is all historic revisionism. The real credit belongs to the evil old government, in collusion with a lot of academic hackers.
It may be true that forms of email were developed by a number of computer vendors. But they were all proprietary (even UUCP and DECnet), didn't interoperate worth a damn, and mostly couldn't be licensed for a finite cost.
It's kinda too bad. I've always thought that UUCP mail was better than SMTP. But if was freed by AT&T a bit too late, and SMTP already had the territory. Note that SMTP is defined by a set of US government standards.
> People really resist the phone. Lots will reply to me here. A few will email. None will call.
To a great extent, this is intentional. One of the real benefits of email and posting replies is that you can stare at your text on the screen, rewrite, check facts, reword, and only hit the Send button when you think you've got it right. Granted, not everyone does this, but many (possibly most) of us do.
Also, a phone call can easily get lost in the shuffle. A text message sits there until someone deletes it. You can come back to it an hour or a year later. You can toss it into bins and count the pro/con messages. You can grep through your messages looking for keywords.
I can't see any reason for techies to ever use the phone for issues like this. Posted and emailed replies are so superior.
Phone calls and face time make sense for communicating with suits. They don't make sense in technical discussions. This is a lot of why Open Source development has been so outpacing corporate software lately. The corporate model has people in a room or on the phone. The Open Source model has everyone communicating via email and mailing lists. The latter is orders of magnitude more effective at getting ideas across without loss or misunderstanding.
It might be worth pointing out here that, even with a prior contract, the laws of most countries would still require disclosure at some point. No contract can be used to excuse conspiracy to commit illegal acts (such as fraud). The recent accounting scandals have brought this out quite clearly.
Tru64 Unix is openly marketed for gateway and firewall uses. If there is a known root exploit in such systems, and customers are not informed of the problem, there are good grounds for some serious charges. I'd bet that HP has a flock of lawyers looking at this right now. There's a good chance that they have some big customers also looking at it. If any Tru64 firewall has been rooted in the past year, there may be some big settlements in the news some time in the future.
If it's true that SnoSoft informed HP of the problem a year ago, then whether there's a contract between them is probably moot. The problem wasn't fixed, so most countries' laws would require SnoSoft to go public with at least the basic facts of the situation. A year is a long time to keep such information secret from vulnerable customers.
If the problem had been fixed, then we'd expect that HP would be going public with the facts (and the fix).
What I'd conclude from this is that if I discover a security problem in a government system, I'd better not tell them about it. Rather than hire me to fix it, they'll probably just arrest me.
What I should obviously do is pass the word among other interested parties that I know how to get info out of the government system. There are lots of people out there that will pay for this. And they won't arrest me, because they aren't part of the legal system.
I suspect that the folks in the Houston government understand this quite well. In fact, if I talk to some of them in private, I'd bet that they might be quite happy to pass my name to some of their campaign contributors, where I could pick up a few nice consulting contracts.
Does anyone here think I'm being overly cynical? If so, you don't know much about Texas politics. You oughta read some Molly Ivins.
> If often wonder if anyone has tried to get a grant for "the development of a disc-shaped flying object" yet.
...
If they do, they'll probably apply for a patent, and the US patent office will approve it. Then they'll charge manufacturers of frisbees with patent infringement. A call will go out for people who have knowledge of any prior art, but few people will respond, only a few geeks and we know how reliable they are. The frisbee manufacturers will attempt to show that they manufacturer their products before 2002, but the patent office and courts will have machines whose software treats all 2-digit dates as having an initial "20". As a result, the courts will conclude that frisbees won't be manufactured for another 60 years or so, and the manufacturers will be ordered to pay royalties.
Hey, maybe I can turn it into a short story and get it published
> go for an operating system controlled by one company, who knows what their code does, and how to fix it if it goes wrong. The only option, in that case, is Microsoft.
Er... or Apple?
Yeah. Or, for that matter, RedHat.
And with RedHat (or any of the other linux vendors), not only do they know what their code does, but there are also thousands of programmers scattered around the world who know a lot about it.
So if you have a problem, you don't have to beg and plead with a disinterested CS department of a giant corporation. You don't even have to deal with your vendor.
If it's a small problem, you can probably hire one or two of the linux hackers at your local college. For bigger projects that take experience, you can hire a few of the local linux professionals.
You'll be up and running in far less time than it takes to persuade Microsoft to support your needs.
> How can something that was considered private enough to require a judge's approval now be sold to the highest bidder.
...
It probably has something to do with the fact that the US is now run by a fellow who has in all seriousness described himself as "America's CEO". He really, truly believes that the government should be run as a business.
This is how businesses do things. If you have a product, you sell it. If we don't like this, we'll just have to find ourselves a CEO who thinks the government should be run like a government.
Of course, we'll first have to make the presidency an elected office