is that the technically astute think Unix is great and the unwashed masses think it's hard. We can debate the merits of Unix vs. other OS's, but let's not resort to the "smart people agree with me" argument.
Interview problem solving often has something in common with Adventure style games: Guessing what the author was thinking is more effective then solving the problem.
When was the last time you solved a real-world problem in a few minutes with someone looking over your shoulder who already knew the "correct" answer?
There is no reliable algorithm or heuristic for hiring the best people, but some companies are comforted by introducing pseudo-rigor into the process.
I see your point, but the effort to write an installation procedure for each platform is insignificant compared to effort to write the application itself. In addition, I doubt there are many DBAs that don't have experience on the platforms they are going to work with.
As far as the specific problems I (and many others encountered) in installation, it had to do with how a Pentium 4 bug messed up the Java environment during the installation. The fix was to create a new installation CD with some of the files renamed so that JIT function was effectively disabled.
I was merely trying to make the point that there is no secure OS's if you consider a single exploit sufficient to disqualify it as you were.
I'm not going to attempt to refute all of your arguments (and perhaps I can't anyway), but I think your analysis lacks a bit of perspective as well.
For example, IBM's mainframes for most of their existence were not connected to anything outside of IBM so if there were buffer overruns etc, they could not be exploited. Even today, it's likely that most mainframes are not directly connected to the Internet but are on a private net within an organization. In addition, knowledge of the architecture of a mainframe is more obscure and thus it takes more effort to exploit any holes. Finally, the administration of mainframes is performed more carefully then the average Windows box (or Linux box, for that matter).
The bottom line is that you can't just talk about relative numbers of exploits, you have to take the entire environment and history into account to determine relative security or quality.
Surely if MS had been willing to throw away backward compatibilty and make Windows as hard to administer and use as Unix they could have created an OS that was at least as secure as Unix (It's not rocket science after all.) The reason they didn't was that that's not what their customers wanted and they would have lost a lot of their business if they had.
Now their customers are becoming more interested in security over ease of use and they have been making changes in that direction.
"It seems to me that Microsoft can't design a secure OS"
If by "secure OS" you mean one that can't be exploited, than yes, MS like all other OS creators so far can't design one. If you mean MS's OS's are less secure than some others, that's something reasonable to discuss.
"After talking about security for more than 2 years, their latest incarnation is even less secure on its release date than Windows 95!"
So you're suggesting that the measure of how secure an OS is, is based on when exploits are available rather how many vunerabilities it has. That's an unusual approach.
Ah yes, Oracle's Java install process that doesn't work out of the box. In any case, if the database code itself is not written in Java, I don't see how having the installation program in Java buys you anything.
It's an interesting strategy, but it might not be good for their business. Many of their Windows-based customers might conclude that their support from Oracle is waning and switch to MS's database. It's better to let your customers believe that you are OS agnostic.
Obviously, you may want to choose a single platform for your primary development, but you don't have to expose that detail to your customers and risk alienating some of them.
What I find interesting is that today's more capable hardware makes Atari 2600-style programming impossible. For example, a cache will increase average performance, but destroys timing consistency. The ability to determine exactly how many cpu cycles a section of code will use is critical to progamming the 2600.
Today, real-time software is a fading art. The good news is that the real-time stuff has migrated to hardware so even OS's with non-deterministic timing like Windows and Unix/Linux can particpate in at least modest real-time applications.
The bank-switching capability was not part of the 2600 design. It was a feature that was added to the cartridge hardware toward the end of the 2600 era. Each big-game vendor created their own unique implementation. Bank-switching was required for games larger than 4K due to the fact that the 6507 only had 13 address lines and 1/2 of the address space was reserved for hardware devices (note also that all ROM was in the cartridge, the 2600 unit has 128 bytes of internal RAM and 0 bytes of internal ROM).
Some of the big-game cartridges contained RAM as well as ROM and those had to bank-switch on 2K boundries since 1 address line had to be used to differentiate reads from writes (no R/W line was brought out to the cartridge port). This sometimes led to some interesting bugs because an incorrectly formed address could read bad data and write bad data in a single instruction.
I agree that the lack of a framebuffer was the defining limitation, but its implications are very broad. About 90% of your code and processing time in the 2600 was dedicated to drawing the screen with only 10% for gameplay. Horizontal positioning was based on time rather than position. Your display routine had to have consitent timing or the picture would roll. The implications go on and on.
Isn't anyone who has contributed to an open source project technically astroturfing when they make pro-open source comments on Slashdot without revealing their participation. Isn't this true of closed source posters as well? Hell, even first-posters have their agenda.
Some people believe dancing is immoral, but if they're smart they don't lecture their boss or customers about it. That's good advice for the "idealogical" OSS folks as well.
IBM recently acquired Rational which will not have any impact on selling mainframes. IBM "consulting" mostly consists of advising you to buy IBM stuff. It's not a viable business on its own.
".. enjoys excercising engineering talent to blow the covers off a sub par OS, which has gotten way too much more credits than what it deserves"
I'm sure the people who have been infected with viruses are grateful to the virus writers for informing them of their opinion on the OS they have chosen in such a positive way.
It's comments like yours the add credibility to the theory that open source advocates are pro-virii when it suits their political agenda.
When I read comments about how we have all the computing power we need, I think of the cover of PC Magazine in the mid-80's that asked the question "Do you really need a 286?"
I'm not sure which of my points you are attempting to refute. You don't believe that the BSD license allows each software writer to choose his own license? Or you don't think it's fair?
"BSD does not insure that what people create and then desire to be free, remains free."
Sure it does. Code that has the BSD license is free forever. What it doesn't do is force those who incorporate the code in their own projects adopt the same license.
So under the BSD license whoever writes the line of code gets to determine whether it's free or not. That's sounds quite fair to me.
I have no problem with any company wanting to make a profit. I just think it's naive to conclude that these companies really buy into the open source philosophy because they repackage others work or because they give away a few crumbs from their IP mountain.
I think it's great that people want to give their work away, but they should realize going in that they probably won't get any credit, money, or thanks for efforts. For truly generous people, it's not a problem, but they're a rare breed.
It's really very simple. Commercial companies have no philosophical commitment to open source, but they are quite willing to make money off of unpaid labor.
Sometimes they tweek the product like Red Hat and sometimes they use it to sell hardware like IBM. These companies either don't have any significant IP (like Red Hat) or they keep their significant IP out of open source projects (like IBM).
Slashdot Mirror
is that the technically astute think Unix is great and the unwashed masses think it's hard. We can debate the merits of Unix vs. other OS's, but let's not resort to the "smart people agree with me" argument.
Interview problem solving often has something in common with Adventure style games: Guessing what the author was thinking is more effective then solving the problem.
When was the last time you solved a real-world problem in a few minutes with someone looking over your shoulder who already knew the "correct" answer?
There is no reliable algorithm or heuristic for hiring the best people, but some companies are comforted by introducing pseudo-rigor into the process.
I see your point, but the effort to write an installation procedure for each platform is insignificant compared to effort to write the application itself. In addition, I doubt there are many DBAs that don't have experience on the platforms they are going to work with.
As far as the specific problems I (and many others encountered) in installation, it had to do with how a Pentium 4 bug messed up the Java environment during the installation. The fix was to create a new installation CD with some of the files renamed so that JIT function was effectively disabled.
I was merely trying to make the point that there is no secure OS's if you consider a single exploit sufficient to disqualify it as you were.
I'm not going to attempt to refute all of your arguments (and perhaps I can't anyway), but I think your analysis lacks a bit of perspective as well.
For example, IBM's mainframes for most of their existence were not connected to anything outside of IBM so if there were buffer overruns etc, they could not be exploited. Even today, it's likely that most mainframes are not directly connected to the Internet but are on a private net within an organization. In addition, knowledge of the architecture of a mainframe is more obscure and thus it takes more effort to exploit any holes. Finally, the administration of mainframes is performed more carefully then the average Windows box (or Linux box, for that matter).
The bottom line is that you can't just talk about relative numbers of exploits, you have to take the entire environment and history into account to determine relative security or quality.
Surely if MS had been willing to throw away backward compatibilty and make Windows as hard to administer and use as Unix they could have created an OS that was at least as secure as Unix (It's not rocket science after all.) The reason they didn't was that that's not what their customers wanted and they would have lost a lot of their business if they had.
Now their customers are becoming more interested in security over ease of use and they have been making changes in that direction.
"Somehow I think the number of people running Linux outnumber the people running Win64 by about 1,000,000:1 (maybe more)."
Number of Win64 viruses: 1
Number of Linux viruses: >> 1
So I guess you've proven that MS is right. The more popular OS (Linux) has more viruses. MS never said it was directly proportional.
"It seems to me that Microsoft can't design a secure OS"
If by "secure OS" you mean one that can't be exploited, than yes, MS like all other OS creators so far can't design one. If you mean MS's OS's are less secure than some others, that's something reasonable to discuss.
"After talking about security for more than 2 years, their latest incarnation is even less secure on its release date than Windows 95!"
So you're suggesting that the measure of how secure an OS is, is based on when exploits are available rather how many vunerabilities it has. That's an unusual approach.
Ah yes, Oracle's Java install process that doesn't work out of the box. In any case, if the database code itself is not written in Java, I don't see how having the installation program in Java buys you anything.
And what non-Unix OS is Linux compatible with? I think portability is red herring here.
It's an interesting strategy, but it might not be good for their business. Many of their Windows-based customers might conclude that their support from Oracle is waning and switch to MS's database. It's better to let your customers believe that you are OS agnostic.
Obviously, you may want to choose a single platform for your primary development, but you don't have to expose that detail to your customers and risk alienating some of them.
What I find interesting is that today's more capable hardware makes Atari 2600-style programming impossible. For example, a cache will increase average performance, but destroys timing consistency. The ability to determine exactly how many cpu cycles a section of code will use is critical to progamming the 2600.
Today, real-time software is a fading art. The good news is that the real-time stuff has migrated to hardware so even OS's with non-deterministic timing like Windows and Unix/Linux can particpate in at least modest real-time applications.
The bank-switching capability was not part of the 2600 design. It was a feature that was added to the cartridge hardware toward the end of the 2600 era. Each big-game vendor created their own unique implementation. Bank-switching was required for games larger than 4K due to the fact that the 6507 only had 13 address lines and 1/2 of the address space was reserved for hardware devices (note also that all ROM was in the cartridge, the 2600 unit has 128 bytes of internal RAM and 0 bytes of internal ROM).
Some of the big-game cartridges contained RAM as well as ROM and those had to bank-switch on 2K boundries since 1 address line had to be used to differentiate reads from writes (no R/W line was brought out to the cartridge port). This sometimes led to some interesting bugs because an incorrectly formed address could read bad data and write bad data in a single instruction.
I agree that the lack of a framebuffer was the defining limitation, but its implications are very broad. About 90% of your code and processing time in the 2600 was dedicated to drawing the screen with only 10% for gameplay. Horizontal positioning was based on time rather than position. Your display routine had to have consitent timing or the picture would roll. The implications go on and on.
In my opinion the role of a standards body is to codify existing practice, not to create new ideas.
The fact that the W3C tries to innovate is exactly why it is becoming less and less relevent in the real world.
I don't see astroturfing as such a big deal.
Isn't anyone who has contributed to an open source project technically astroturfing when they make pro-open source comments on Slashdot without revealing their participation. Isn't this true of closed source posters as well? Hell, even first-posters have their agenda.
Some people believe dancing is immoral, but if they're smart they don't lecture their boss or customers about it. That's good advice for the "idealogical" OSS folks as well.
IBM recently acquired Rational which will not have any impact on selling mainframes. IBM "consulting" mostly consists of advising you to buy IBM stuff. It's not a viable business on its own.
Oh yes, businessweek.com. The other "News for Nerds" site.
".. enjoys excercising engineering talent to blow the covers off a sub par OS, which has gotten way too much more credits than what it deserves"
I'm sure the people who have been infected with viruses are grateful to the virus writers for informing them of their opinion on the OS they have chosen in such a positive way.
It's comments like yours the add credibility to the theory that open source advocates are pro-virii when it suits their political agenda.
"Several people complained Eclipse wasn't usable because it didn't have folding... Needless whining serves no one any good."
Since the desired feature was implemented, the "whining" was apparently quite effective.
When I read comments about how we have all the computing power we need, I think of the cover of PC Magazine in the mid-80's that asked the question "Do you really need a 286?"
"I just said GPL can be desireable because it prohibits proprietary forks of free code."
No, that's not what you said. You said:
"BSD does not insure that what people create and then desire to be free, remains free."
These are entirely different statements.
"Not necessarily"
I'm not sure which of my points you are attempting to refute. You don't believe that the BSD license allows each software writer to choose his own license? Or you don't think it's fair?
Since when is readabililty a concern of any 'C' derived language? To wit:
+=,-=, etc.
var++ vs. ++var
& vs. && etc
>> vs. >>>
?:
The GOTO may be bad practice but it's one of the most readable statements in Java.
"BSD does not insure that what people create and then desire to be free, remains free."
Sure it does. Code that has the BSD license is free forever. What it doesn't do is force those who incorporate the code in their own projects adopt the same license.
So under the BSD license whoever writes the line of code gets to determine whether it's free or not. That's sounds quite fair to me.
I have no problem with any company wanting to make a profit. I just think it's naive to conclude that these companies really buy into the open source philosophy because they repackage others work or because they give away a few crumbs from their IP mountain.
I think it's great that people want to give their work away, but they should realize going in that they probably won't get any credit, money, or thanks for efforts. For truly generous people, it's not a problem, but they're a rare breed.
It's really very simple. Commercial companies have no philosophical commitment to open source, but they are quite willing to make money off of unpaid labor.
Sometimes they tweek the product like Red Hat and sometimes they use it to sell hardware like IBM. These companies either don't have any significant IP (like Red Hat) or they keep their significant IP out of open source projects (like IBM).