Actually, the problem isn't Microsoft's innovation making products unusable...
...since this technology hadn't existed before, Microsoft hadn't anticipated that some folks would hijack the API...
Anybody who cares about & understands security certainly can anticipate this sort of the problem; in fact it's the very first thing you think of when you contemplate "making it easy to extend the web with third party plugins".
So yes, actually, the problem really is Microsoft's so-called innovation, combined with their woefully inadequate implementation, making things insecure, unstable, and unusable.
Given that most of the difficulty in writing software is not
banging out code, nor even finding and fixing bugs, but rather
coomunicating between, and coordinating the work of: programmers,
project managers, spec writers, third party vendors, salesmen,
customer representatives, etc., all mired in the shifting sands
of poorly-understood and changing requirements -- how can it help
to put the programmers half a world away?
We test exhaustively... I'm not sure that more testing would have revealed that.
For an obscure race condition, this is undoubtedly true.
Unfortunately, that's kind of the nature of software...
you may never find the problem.
This is sorta true, sorta false, and definitely misleading.
I don't think that's unique to control systems
or any particular vendor software.
No, it's not unique; bugs that may never be found are rampant in
most varieties of software. What's false -- tragically,
crushingly false -- is the presumption that these unfindable bugs
are therefore inevitable. They are not.
If there's a class of bugs that's hard to test for -- and of course there are many such classes -- the prudent thing to do is to find development methodologies that skirt those bugs entirely.
If you don't put in so many bugs in the first place, you obviously don't have to work so hard trying to find and fix them.
You can't expect just testing to reveal all bugs...
The only way to have bug-free software is to write it properly.
You have to... simplify everything down to [be] easily understandable...
I know it's far easier to say it than do it, but it seems like nobody
even tries to do it these days.
Hear, hear.
The current "state of the art" in software is pathetic, and unfortunately the vast majority of computer users (including, it appears, users of systems that ought to be safety-critical) have become so inured to buggy systems that they don't demand anything better, and few vendors are therefore motivated to try to do better.
And yet the techniques for writing reliable, robust software have been known for decades -- but they're never as fashionable as the latest whiz-bang methodology du jour that lets you bang out a huge volume of seemingly-working code in a hurry.
As you programmers all know, avoiding race conditions is really difficult.
I'm sorry, but this is just wrong.
It's easy to avoid race conditions:
don't write excessively complex, multithreaded systems that are too complicated for you or anyone else to understand. Unfortunately, it's also easy -- quite seductively easy -- to try to write excessively complex, multithreaded systems that are too complicated for you or anyone else to understand, and that's why so much code is so buggy. But it doesn't have to be that way.
"The fellow Neumann" isn't overly optimistic, he's dead-on accurate. Don't try to excuse GE's failings by claiming that "it's theoretically impossible" to find some bug. It's theoretically impossible for a bumblebee to fly, it's theoretically impossible for life to exist, yet somehow we and the birds and the bees are all here.
"People who believe a thing to be impossible should not stand in the way of those who are doing it."
I fervently wish all the apologists for bad code would get out of the way, so that we could start raising the bar a little and get software out of the Dark Ages it's currently mired in.
Again, it doesn't have to be that way.
If a bug exists in the code, but it's never triggered, is it really a bug?
You may have been joking, but in case someone takes you seriously, I'll respond seriously.
Yes, a bug that has not been triggered is absolutely a bug. Real-world software gets used under evolving circumstances, and ought to be able to respond at least somewhat robustly to circumstances beyond those for which it was explicitly tested.
If you believe that bugs that haven't shown themselves don't exist, it's easy to get into a sloppy mindset where you code for the end of the day, relying on your QA department to catch your mistakes, and imagining that the code is somehow "perfect" if it passes its test cases. (But what about the test cases that the QA department hasn't written yet?)
If, on the other hand, you can figure out ways of writing code that's initially and inherently bug-free, not because someone found and reported each bug and you fixed it, but rather because you were careful right from square one, and imagined and coded for all the cases that could come up (not just the ones that seemed important), you'll end up with code that is robust, that doesn't fall over every time something unexpected happens...
Don't let anyone tell you that this is impossible -- it can be done, and with practice it's even easy.
It's true that knowing assembler is a boon to really understanding how the machine works, and therefore to writing better code. Unfortunately, it's also a boon to knowing too much about how the machine works, tempting you to write overly machine-specific, nonportable code.
Some days it's seemed to me that there's so much unnecessarily machine-specific code about (i.e. that so many programmers have succumbed to the temptation) that learning assembler should be discouraged.
Other days it seems that you're doomed to writing cripplingly inefficient bloatware if all you know is a handholding HLL.
Striking the right balance -- knowing the innards, but using that knowledge only for good, not evil -- is tough.
However, the patents all have to do with VFAT long filenames...
Wait a minute -- you mean they got a freaking patent on the kludges they used to work around the fact that they used a horribly misguidedly limited filename format in the first place? What ineffable cheek!
Maybe I'm just a grumpy old curmudgeon,
but I don't see what there is to celebrate here,
or what is about these little bits of code that's so "marvelous".
It's not so much that we "don't need" perfect code; it's that we'll never have perfect code.
Bruce Schneier said this very well in his Crypto-Gram newsletter for May 2000:
...computer security flaws are inevitable.
Systems break, vulnerabilities are reported in the press, and still many people put their faith in the next product, or the next upgrade, or the next patch. "This time it's secure," they say. So far, it hasn't been.
Security is a process, not a product. Products provide some protection, but the only way to effectively do business in an insecure world is to put processes in place that recognize the inherent insecurity in the products.
So then the next interesting question becomes,
what do you want the process to look like?
Certainly, the responsible vendors have to be a part of that process; equally certainly, the users do, too.
Now, for Bill to say "You don't need" instead of "we'll never have" is certainly a rather underhanded piece of spin control, because responsible vendors have to at least try to get it right, and the fact that we're busy putting processes in place to pick up the pieces when they blow it doesn't absolve them of that responsibility.
Why would you program for free, in your spare time, instead of getting paid to do so?
Why would you be a starving actor or artist, working poor-paying jobs to live on and doing what you love in your "spare time"?
Programming -- good programming, anyway -- is a creative process, and creative people love what they do, and will do it whether or not they get paid to do it. Heck, they'll do it even if it costs them.
Simply put, open-source programmers program for love rather than money.
And it turns out that this has a whole lot to do with the quality of open-source software.
Don Norman (who if you haven't read him, you should) has a bit in his book The Design of Everyday Things about a psychology experiment in which the subjects were asked to write an essay arguing against some point they'd ordinarily believe in. Some of the subjects were paid money to write the essay, some were asked to do it for next to nothing. Then, later, they were interviewed to find how strongly their former beliefs held, or how much they might have changed their minds.
Conventional wisdom suggests that the people who had been paid more would be more apt to change their minds, but actually, the reverse was true. The explanation is that the people who were paid could resolve the conflict in their mind between the beliefs they held and the contradictory statements they were writing by saying "heck, I still don't believe this, I'm not writing it because I believe it or anything, I'm writing it because I'm being bribed to." But the people who didn't have that "out" had to resolve their own cognitive dissonance another way, and for some of them, at least, the way was to realize that maybe there was something to the counterargument, after all.
Anyway, the reason I bring this up is that I was eerily reminded of it while reading Ballmer's arguments that Microsoft's commercial software is "obviously" better because it's written by professional programmers who are paid for it.
But if you're getting paid to write code, and the code is (for whatever reason) crap, that you can't take pride in, you can at least feel good about all the lovely $$$ you're being paid. The open source programmer, on the other hand, who is doing it for love rather than money, doesn't have that out, so has a much higher incentive to write code that's not crap, because feeling good about it is the only reward.
Then you make some little "harmless" change on the network that one os likes and the rest hate, and suddenly your nice and peaceful network is a chaotic mess...
Yup. But if you've got problems with a brittle network like that, you've got problems, period. Putting your fingers in your ears, pretending the open networking standards don't exist, stubbornly sticking with the one devil that you do know, come hell or high water, may seem to give you stability and security, but look at how many other problems it causes (and how unstable and insecure it can be, anyway).
That's the main reason our IT dept... has been pushing for a single os. It is not because of ignorance, but because of a drive towards simplification.
Or towards stagnation. (But Microsoft, along with the legions of virus authors out there, love you for it...)
WTF is any IT staff letting a civilian admin his own box in this situation?...
The author simply reinforces the the stereotype of the righteous Mac user with low knowledge and big attitude.
I can't believe the play this article is getting...
Believe it. Obviously there's something important going on here. The commentary, tons of it, here, and on osviews, and probably a bunch of other places, is fascinating, partly for what it's saying and partly by its sheer volume. It looks like some nerves -- more than a few -- have been touched.
That this user was willing to go through "all of that trouble" (e.g. running Office inside VPC inside Mac) shows, not that he's an idiot, but rather, how phenominally poor the Windows environment was, and how vastly more pleasant the Mac is, at least for him.
Even more informative is the chest-thumping from the big-stick "IT" folks who find all this variously unthinkable if not downright heretical.
I understand their concerns about stability and supportability, but obviously they have no clue about how productivity-sapping a clumsy (even if officially supported) computing environment can be, and how liberating a good one can be, especially to creative types like artists and programmers.
(And what's with all the nonsensical backlash against this guy for "just wanting to shout `I'm different!'"?! Don't we -- shouldn't we -- all want to shout that? Do you expect me to agree that it's a Good Thing if some corporation's work ethic, or its "IT" goons, feel the need to try to quash it?)
Biting the hand that feeds you...
on
Free-Floating UNIX
·
· Score: 5, Informative
The author of this page has apparently worked...
"The author of this page" is none other than Dennis Ritchie, who knows a thing or two about Unix.
He's had that page quietly sitting there for a year or two.
I don't think he deserved this...
...severe headaches of Sobig with its interesting effects on my 50M quota on the mail server... It wasn't nice to delete 20 megabytes of virus spam twice a day...
Get yourself a proper filter, bub!
No one -- especially someone you don't know -- should be able to force you to do that kind of manual labor.
(But I do sympathize -- I tried to deal with SoBig.F by hand for the first week, until someone pointed out what an idiot I was being.
So I re-learned about procmail,
and now at least the overflow-related problems of these latest viruses have gone away.)
The text is filled with typos and garbled and confusing to an experienced computer user like myself, it must come across as utterly incomprehesible to an inexperienced computer user.
You were being sarcastic there, right?
You've just described, of course, the vast majority of "professional" software documentation...
This message contains an unwanted file extension...
ade:adp:bas:bat:chm:cmd:com:cpl:crt:exe:hlp:hta:in f:ins:isp:js:jse:lnk:mdb:mde:msc:msi:msp:mst:pcd:p if:reg:scr:sct:shs:shb:url:vb:vbe:vbs:wsc:wsf:wsh...
How long before the number of kinds of attachments that can't be sent exceeds the number that can?
It's a very good idea these days to just reject all executable attachments...
If you want to send someone an executable, send it to them in a zip or tar.gz.
All this does is moves the problem around.
It's not a very good idea at all
(though unfortunately it's a compelling one).
1. Soon enough, executable malware will shroud itself in a.zip wrapper (some of it already does),
and at the same time, "for convenience", new idiot-aligned (made by and for) email software will make it easy to open attachments inside zip attachments.
2. Meanwhile, it becomes harder and harder for the rest of us to use e-mail at all, as the number of proscribed message attributes grows and grows.
I'm a Unix user, I want to send a fellow Unix user a script which I've placed in a file which I unthinkingly gave a name ending in ".scr", and though the file is not dangerous to me or my recipient or anyone else, it's filtered out on behalf of people who use an operating system which neither I nor my recipient use. Bleah.
The referenced header checks disallow 53 different filename extensions, all of which I now presumably have to remember to avoid using. (The problem is of course exacerbated by Windows' stubborn insistence that extension === file type.)
...this virus requires user interaction in order to spread, so we can't really blame M$...
That's about the same as saying, of a car without seat belts or air bags, that it requires the driver to get into an accident in order to maim himself, so we can't really blame the manufacturer for omitting those features.
Slashdot Mirror
Anybody who cares about & understands security certainly can anticipate this sort of the problem; in fact it's the very first thing you think of when you contemplate "making it easy to extend the web with third party plugins".
So yes, actually, the problem really is Microsoft's so-called innovation, combined with their woefully inadequate implementation, making things insecure, unstable, and unusable.
Given that most of the difficulty in writing software is not banging out code, nor even finding and fixing bugs, but rather coomunicating between, and coordinating the work of: programmers, project managers, spec writers, third party vendors, salesmen, customer representatives, etc., all mired in the shifting sands of poorly-understood and changing requirements -- how can it help to put the programmers half a world away?
For an obscure race condition, this is undoubtedly true.
Unfortunately, that's kind of the nature of software... you may never find the problem.
This is sorta true, sorta false, and definitely misleading.
I don't think that's unique to control systems or any particular vendor software.
No, it's not unique; bugs that may never be found are rampant in most varieties of software. What's false -- tragically, crushingly false -- is the presumption that these unfindable bugs are therefore inevitable. They are not.
If there's a class of bugs that's hard to test for -- and of course there are many such classes -- the prudent thing to do is to find development methodologies that skirt those bugs entirely. If you don't put in so many bugs in the first place, you obviously don't have to work so hard trying to find and fix them.
The only way to have bug-free software is to write it properly. You have to... simplify everything down to [be] easily understandable...
I know it's far easier to say it than do it, but it seems like nobody even tries to do it these days.
Hear, hear.
The current "state of the art" in software is pathetic, and unfortunately the vast majority of computer users (including, it appears, users of systems that ought to be safety-critical) have become so inured to buggy systems that they don't demand anything better, and few vendors are therefore motivated to try to do better. And yet the techniques for writing reliable, robust software have been known for decades -- but they're never as fashionable as the latest whiz-bang methodology du jour that lets you bang out a huge volume of seemingly-working code in a hurry.
I'm sorry, but this is just wrong. It's easy to avoid race conditions: don't write excessively complex, multithreaded systems that are too complicated for you or anyone else to understand. Unfortunately, it's also easy -- quite seductively easy -- to try to write excessively complex, multithreaded systems that are too complicated for you or anyone else to understand, and that's why so much code is so buggy. But it doesn't have to be that way.
"The fellow Neumann" isn't overly optimistic, he's dead-on accurate. Don't try to excuse GE's failings by claiming that "it's theoretically impossible" to find some bug. It's theoretically impossible for a bumblebee to fly, it's theoretically impossible for life to exist, yet somehow we and the birds and the bees are all here.
"People who believe a thing to be impossible should not stand in the way of those who are doing it." I fervently wish all the apologists for bad code would get out of the way, so that we could start raising the bar a little and get software out of the Dark Ages it's currently mired in. Again, it doesn't have to be that way.
You may have been joking, but in case someone takes you seriously, I'll respond seriously.
Yes, a bug that has not been triggered is absolutely a bug. Real-world software gets used under evolving circumstances, and ought to be able to respond at least somewhat robustly to circumstances beyond those for which it was explicitly tested.
If you believe that bugs that haven't shown themselves don't exist, it's easy to get into a sloppy mindset where you code for the end of the day, relying on your QA department to catch your mistakes, and imagining that the code is somehow "perfect" if it passes its test cases. (But what about the test cases that the QA department hasn't written yet?)
If, on the other hand, you can figure out ways of writing code that's initially and inherently bug-free, not because someone found and reported each bug and you fixed it, but rather because you were careful right from square one, and imagined and coded for all the cases that could come up (not just the ones that seemed important), you'll end up with code that is robust, that doesn't fall over every time something unexpected happens...
Don't let anyone tell you that this is impossible -- it can be done, and with practice it's even easy.
Some days it's seemed to me that there's so much unnecessarily machine-specific code about (i.e. that so many programmers have succumbed to the temptation) that learning assembler should be discouraged. Other days it seems that you're doomed to writing cripplingly inefficient bloatware if all you know is a handholding HLL. Striking the right balance -- knowing the innards, but using that knowledge only for good, not evil -- is tough.
Wait a minute -- you mean they got a freaking patent on the kludges they used to work around the fact that they used a horribly misguidedly limited filename format in the first place? What ineffable cheek!
Maybe I'm just a grumpy old curmudgeon, but I don't see what there is to celebrate here, or what is about these little bits of code that's so "marvelous".
Unfortunately, Yossarian's reply applies here:
"Then I'd certainly be a fool not to."
Now, for Bill to say "You don't need" instead of "we'll never have" is certainly a rather underhanded piece of spin control, because responsible vendors have to at least try to get it right, and the fact that we're busy putting processes in place to pick up the pieces when they blow it doesn't absolve them of that responsibility.
Nicely argued. Ayn would be proud.
Why would you be a starving actor or artist, working poor-paying jobs to live on and doing what you love in your "spare time"?
Programming -- good programming, anyway -- is a creative process, and creative people love what they do, and will do it whether or not they get paid to do it. Heck, they'll do it even if it costs them.
Simply put, open-source programmers program for love rather than money. And it turns out that this has a whole lot to do with the quality of open-source software.
Conventional wisdom suggests that the people who had been paid more would be more apt to change their minds, but actually, the reverse was true. The explanation is that the people who were paid could resolve the conflict in their mind between the beliefs they held and the contradictory statements they were writing by saying "heck, I still don't believe this, I'm not writing it because I believe it or anything, I'm writing it because I'm being bribed to." But the people who didn't have that "out" had to resolve their own cognitive dissonance another way, and for some of them, at least, the way was to realize that maybe there was something to the counterargument, after all.
Anyway, the reason I bring this up is that I was eerily reminded of it while reading Ballmer's arguments that Microsoft's commercial software is "obviously" better because it's written by professional programmers who are paid for it.
But if you're getting paid to write code, and the code is (for whatever reason) crap, that you can't take pride in, you can at least feel good about all the lovely $$$ you're being paid. The open source programmer, on the other hand, who is doing it for love rather than money, doesn't have that out, so has a much higher incentive to write code that's not crap, because feeling good about it is the only reward.
Yup. But if you've got problems with a brittle network like that, you've got problems, period. Putting your fingers in your ears, pretending the open networking standards don't exist, stubbornly sticking with the one devil that you do know, come hell or high water, may seem to give you stability and security, but look at how many other problems it causes (and how unstable and insecure it can be, anyway).
That's the main reason our IT dept... has been pushing for a single os. It is not because of ignorance, but because of a drive towards simplification.
Or towards stagnation. (But Microsoft, along with the legions of virus authors out there, love you for it...)
Everything is supposed to work out-of-the-box...
Supposed to, and does.
Go ahead mod me down....
Not at all!
+1 insightful. You got it just right.
The author simply reinforces the the stereotype of the righteous Mac user with low knowledge and big attitude.
Whereas you, I see, have no attitude at all...
Believe it. Obviously there's something important going on here. The commentary, tons of it, here, and on osviews, and probably a bunch of other places, is fascinating, partly for what it's saying and partly by its sheer volume. It looks like some nerves -- more than a few -- have been touched.
That this user was willing to go through "all of that trouble" (e.g. running Office inside VPC inside Mac) shows, not that he's an idiot, but rather, how phenominally poor the Windows environment was, and how vastly more pleasant the Mac is, at least for him.
Even more informative is the chest-thumping from the big-stick "IT" folks who find all this variously unthinkable if not downright heretical. I understand their concerns about stability and supportability, but obviously they have no clue about how productivity-sapping a clumsy (even if officially supported) computing environment can be, and how liberating a good one can be, especially to creative types like artists and programmers.
(And what's with all the nonsensical backlash against this guy for "just wanting to shout `I'm different!'"?! Don't we -- shouldn't we -- all want to shout that? Do you expect me to agree that it's a Good Thing if some corporation's work ethic, or its "IT" goons, feel the need to try to quash it?)
"The author of this page" is none other than Dennis Ritchie, who knows a thing or two about Unix. He's had that page quietly sitting there for a year or two. I don't think he deserved this...
Get yourself a proper filter, bub!
No one -- especially someone you don't know -- should be able to force you to do that kind of manual labor.
(But I do sympathize -- I tried to deal with SoBig.F by hand for the first week, until someone pointed out what an idiot I was being. So I re-learned about procmail, and now at least the overflow-related problems of these latest viruses have gone away.)
You were being sarcastic there, right? You've just described, of course, the vast majority of "professional" software documentation...
ade:adp:bas:bat:chm:cmd:com:cpl:crt:exe:hlp:hta:i
How long before the number of kinds of attachments that can't be sent exceeds the number that can?
If you want to send someone an executable, send it to them in a zip or tar.gz.
All this does is moves the problem around. It's not a very good idea at all (though unfortunately it's a compelling one).
1. Soon enough, executable malware will shroud itself in a .zip wrapper (some of it already does),
and at the same time, "for convenience", new idiot-aligned (made by and for) email software will make it easy to open attachments inside zip attachments.
2. Meanwhile, it becomes harder and harder for the rest of us to use e-mail at all, as the number of proscribed message attributes grows and grows. I'm a Unix user, I want to send a fellow Unix user a script which I've placed in a file which I unthinkingly gave a name ending in ".scr", and though the file is not dangerous to me or my recipient or anyone else, it's filtered out on behalf of people who use an operating system which neither I nor my recipient use. Bleah.
The referenced header checks disallow 53 different filename extensions, all of which I now presumably have to remember to avoid using. (The problem is of course exacerbated by Windows' stubborn insistence that extension === file type.)
That's about the same as saying, of a car without seat belts or air bags, that it requires the driver to get into an accident in order to maim himself, so we can't really blame the manufacturer for omitting those features.
This is old, and you may have seen it already, but it's pretty compelling:. html
http://www.arancidamoeba.com/mrr/problemwithmusic