Actually MS wasn't that big on patents until a few years back when they noticed how many IBM was filing.
If you are part of the computer or software industry it would be a good idea to examine any patent reform idea in detail regardless who is for or against it.
Don't let your disdain for MS dictate your actions.
If the processor cache can be turned off, then that is at least one less hurdle. What about processor pipelines, bus locking, etc.? Can they all be disabled?
Any non-deterministic behavior (or deterministic behavior too complex to be considered in a real-time software design) will still trip you up.
I think people are confusing real-time with "as fast as a bunny".
A truly real-time system can actually be slower because even if it's ready to respond, it still has to wait until the appropriate time to do so. It like batting in baseball: swinging too early is just as bad as swinging too late.
Yes 1 millisecond is pretty slow. On the Atari 2600 we used to meet a.84 microsecond timing requirement with a 1.19 MHz processor.
In any case I don't think many people on Slashdot understand that tough, classical real-time software can't really run on a PC (or Pentium processors for that matter) no matter what OS is used.
The key to real-time software isn't speed, it's deterministic timing. Once you have a cache involved, it's pretty much game over. Unless, of course, your timing requirements are several orders of magnitude slower than the time it takes the processor to execute an instruction. In that case the non-deterministic behavior may be swallowed up by the large gaps between real-time events.
Nevertheless there may still be the possiblity of memory management accessing the disk and blowing your timing away.
Obviously there were a few years between the time UNIX was developed and GUI based systems were feasible. I think my Xerox Alto was no less stable and a lot more useful than UNIX systems of that era.
If you are referring to Windows, I suggest you try porting UNIX to an 8088 based system with less than 640K of RAM and see how reliable it is. Keep in mind that all programs on the 8088 use the same address space and no kernel levels can be enforced by hardware.
I'm not claiming that UNIX hasn't changed at all but if the average user still needs to use the command line to do their work, UNIX will not succeed on the desktop.
"What was meant to be Microsoft's most secure OS ever turned into a disaster."
Security wasn't the major feature MS advertised for Windows 2000, it was stability with compatability. Although NT was the first Windows OS written entirely without real mode code, it was difficult to use with laptops and wasn't as backward compatible as Windows 2000.
"Little did those who suffered in the early years of Unix ever realize that their kids would one day be masochists on a level undreamt of even by the Marquis de Sade and actually find Unix cool."
Very well put. Those who were working in the computer industry at the time GUIs were introduced know that they were widely recognized as a major development by virtually everyone in the field.
It took years of academic propaganda to drop us back into the 1970s.
As you say, it depends on the nature of the problem. Not all bugs are specific to a particular variation so having one test case may still provide value.
"Automated testing is helpful, though mainly for known errors or conditions."
But in this case it was a known error. If the nature of the bug allowed it to be generated and verified using an automated test, you could add it to your regression test. Then if the bug showed up again, the regression test would catch it. This assumes that the automated test isn't dependent on the exact code snippet that caused the orginal problem but rather on the behavior.
"If it doesn't render readably on standards compliant browsers, that's the fault of the web page, not the browser."
Well the "standards compliant browser" is a rather theoretical construct. In the real world if a page doesn't render readably it could be the browser or the page.
Of course from the point of view of the user the browser that renders the most pages readably is the best one. There's no virtue in rendering a page badly when you could have rendered it well just because you were strictly enforcing a standard.
Yes, as in the case of non-embedded software, general experience is quite valuable. The issue is one of perception. Employers generally prefer 2-3 years of specific experience over 10 or more years of general experience.
The market leading browser prior to IE was a non-standard browser. If MS had never entered the broswer market we'd probably be seeing "Best viewed in Netscape XX" on web pages.
If you test the non IE browsers you mentioned I'll bet you'll find none of them are 100% compatabile with standards and none render pages exactly the same.
There's a lot of valid critism's that apply only to IE but non-standard browsing isn't one of them.
I think the embedded market is pretty much like the rest. If your resume includes the specific processors, DSPs, languages, and business sector a company is looking for you're gold. If not, it doesn't matter how much embedded experience you have.
Yes, tell it to your landlord and parking garage. The fact is that nearly everyone signs or implicitly agrees to contracts the violate one or more of these principles but it doesn't stop them from being enforced.
Geek #1: Windows really sucks! Geek #2: I know what you mean. Only an MCSE would use Windows and you know how dumb they are. Geek #3: I just read on Slashdot that you could upgrade Windows XP home to professional by just changing a few bytes. Geeks #1 and #2: Sweet, how do you do it?
I guess you believe that Red Hat is all sweetness and light. Perhaps having 90% of your product development done by unpaid volunteers does that to you.
I predict we'll be hearing a lot less about Fedora in the years to come. We'll see if I'm right or wrong.
Slashdot Mirror
Actually MS wasn't that big on patents until a few years back when they noticed how many IBM was filing.
If you are part of the computer or software industry it would be a good idea to examine any patent reform idea in detail regardless who is for or against it.
Don't let your disdain for MS dictate your actions.
OK. I sent you an email.
Is it really true in your reality that Slashdotters say that "Microsoft is x times better than Linux"? Or is x less than 1?
If the processor cache can be turned off, then that is at least one less hurdle. What about processor pipelines, bus locking, etc.? Can they all be disabled?
Any non-deterministic behavior (or deterministic behavior too complex to be considered in a real-time software design) will still trip you up.
I think people are confusing real-time with "as fast as a bunny".
A truly real-time system can actually be slower because even if it's ready to respond, it still has to wait until the appropriate time to do so. It like batting in baseball: swinging too early is just as bad as swinging too late.
Yes 1 millisecond is pretty slow. On the Atari 2600 we used to meet a .84 microsecond timing requirement with a 1.19 MHz processor.
In any case I don't think many people on Slashdot understand that tough, classical real-time software can't really run on a PC (or Pentium processors for that matter) no matter what OS is used.
The key to real-time software isn't speed, it's deterministic timing. Once you have a cache involved, it's pretty much game over. Unless, of course, your timing requirements are several orders of magnitude slower than the time it takes the processor to execute an instruction. In that case the non-deterministic behavior may be swallowed up by the large gaps between real-time events.
Nevertheless there may still be the possiblity of memory management accessing the disk and blowing your timing away.
Obviously there were a few years between the time UNIX was developed and GUI based systems were feasible. I think my Xerox Alto was no less stable and a lot more useful than UNIX systems of that era.
If you are referring to Windows, I suggest you try porting UNIX to an 8088 based system with less than 640K of RAM and see how reliable it is. Keep in mind that all programs on the 8088 use the same address space and no kernel levels can be enforced by hardware.
I'm not claiming that UNIX hasn't changed at all but if the average user still needs to use the command line to do their work, UNIX will not succeed on the desktop.
"What was meant to be Microsoft's most secure OS ever turned into a disaster."
Security wasn't the major feature MS advertised for Windows 2000, it was stability with compatability. Although NT was the first Windows OS written entirely without real mode code, it was difficult to use with laptops and wasn't as backward compatible as Windows 2000.
I really don't want to link my real name with my name on Slashdot. If I sent you an email directly would you agree not to reveal my name?
"Little did those who suffered in the early years of Unix ever realize that their kids would one day be masochists on a level undreamt of even by the Marquis de Sade and actually find Unix cool."
Very well put. Those who were working in the computer industry at the time GUIs were introduced know that they were widely recognized as a major development by virtually everyone in the field.
It took years of academic propaganda to drop us back into the 1970s.
Yes, I really am an old Atari 2600 programmer but not a famous one.
Congratulations on completing your game. People like yourself that have written a 2600 game without being paid a salary are amazingly dedicated.
Then we old Atari 2600 programmers could get back in the game.
On the other hand, you can't perform advanced gameplay on the 2600 unless you embed a hard drive in the cartridge.
It's a nice fantasy though.
As you say, it depends on the nature of the problem. Not all bugs are specific to a particular variation so having one test case may still provide value.
"Automated testing is helpful, though mainly for known errors or conditions."
But in this case it was a known error. If the nature of the bug allowed it to be generated and verified using an automated test, you could add it to your regression test. Then if the bug showed up again, the regression test would catch it. This assumes that the automated test isn't dependent on the exact code snippet that caused the orginal problem but rather on the behavior.
"If it doesn't render readably on standards compliant browsers, that's the fault of the web page, not the browser."
Well the "standards compliant browser" is a rather theoretical construct. In the real world if a page doesn't render readably it could be the browser or the page.
Of course from the point of view of the user the browser that renders the most pages readably is the best one. There's no virtue in rendering a page badly when you could have rendered it well just because you were strictly enforcing a standard.
Yes, as in the case of non-embedded software, general experience is quite valuable. The issue is one of perception. Employers generally prefer 2-3 years of specific experience over 10 or more years of general experience.
The market leading browser prior to IE was a non-standard browser. If MS had never entered the broswer market we'd probably be seeing "Best viewed in Netscape XX" on web pages.
If you test the non IE browsers you mentioned I'll bet you'll find none of them are 100% compatabile with standards and none render pages exactly the same.
There's a lot of valid critism's that apply only to IE but non-standard browsing isn't one of them.
I think the embedded market is pretty much like the rest. If your resume includes the specific processors, DSPs, languages, and business sector a company is looking for you're gold. If not, it doesn't matter how much embedded experience you have.
So far there's only two who don't understand how to tell a joke.
Thanks for the clarification. Next time I tell a bar joke I'll make sure to include all the conversations in the bar to be fair.
Yes, tell it to your landlord and parking garage. The fact is that nearly everyone signs or implicitly agrees to contracts the violate one or more of these principles but it doesn't stop them from being enforced.
Geek #1: Windows really sucks!
Geek #2: I know what you mean. Only an MCSE would use Windows and you know how dumb they are.
Geek #3: I just read on Slashdot that you could upgrade Windows XP home to professional by just changing a few bytes.
Geeks #1 and #2: Sweet, how do you do it?
I guess you believe that Red Hat is all sweetness and light. Perhaps having 90% of your product development done by unpaid volunteers does that to you.
I predict we'll be hearing a lot less about Fedora in the years to come. We'll see if I'm right or wrong.
I can't imagine why Microsoft would want to buy Red Hat. It probably cost more time and effort to create MS Bob than it would to create MS Linux.
It means that Red Hat will phase out its engineering and financial support for Fedora once it has slipped off the radar screen.