I've known mail servers which were configured to accept *everything* ('cos they forwarded to the real mail server which was behind a firewall). The technique of using RCPT TO: doesn't work very well in practice; I used to use it for email validation about 5 years ago, and gave up. The only reliable way to validate an address is to send a message containing a complex URL that the user visits.
Of course, spammers don't care. They just set the reply-to header to someone else (I've been on the receiving end of this particular spam technique. GRRR!)
But testing isn't enough, especially in a safety-critical area. How do you know that the tests are adequate? How do you know that the tests test what the customer is after? How do you know that the various unit tests imply that the system integration tests will work?
Unit testing is good, but insufficient, and writing a test suite that covers everything to a level that ensures that integration goes smoothly and no faults occur in service is in reality *at least as hard* as using a formal development process, particularly as it is very tricky to work out whether you are testing everything you ought to be testing.
(FWIW, formal software development systems such as Z are enfuriating and bureaucratic, but can really deliver the goods - and with less cost - if you need that level of QA. But word processors don't need quite the same level of quality as railway signalling systems...)
If you create for example an ArrayList of ints, the most efficient way to store these ints internally would obviously be an int[] and not an Object[]. But even though java uses templates, it still stores primitive types such as int in an Object[], so there is a huge temporary object creation overhead.
No. In Java an array of ints is an array of 32-bit values that is stored in memory as an array of 32-bit values. There are many OO purists who howl and scream about this as they'd prefer the situation you (mistakenly) outline, but that's the way it is. Now, the array itself is an Object, but so's everything else that can be passed around by reference...
Some of your other points are valid though. I'll let you guess which ones...;^)
If some code doesn't have the GPL and just has standard copyright applied to it, you don't get to use it at all. You can't copy it. You can't change it and use the changed stuff you have made. You can't do anything with it.
If some piece of source is just under copyright without some kind of license attached, you probably won't see it at all except in contexts like under an NDA. Your point is technically right, but so moot it is unfunny.
You can't sensibly say that some other programmer should have applied (eg) BSD to some code so as not to "restrict" users. If you like BSD, you apply it to your code.
I can and do say it. The main problem with the GPL is that it tries to spread itself to essentially unrelated code, and this can be a real nightmare in a large software project with components from all over the place. (I've no problem with the LGPL as that focusses on protecting the licensed code itself, though I prefer the BSD license for my own work. But then I'm happy for my code to end up in commercial contexts without remuneration; getting money back to me for what I write is a lot more awkward than it seems anyway, alas...)
Do you seriously think that the MS coders are that stupid?
Yes. Running untrusted code in anything other than the most restricted of contexts is asking for trouble. And it's not as if ways of supporting the feature are unavailable (sandboxes, digital signatures, etc.)
What you have here is almost certainly the law of unintended consequences; features that make lots of sense in one context (and which are not a problem in that situation) getting mixed together with things from another context to create something that's got a mix of these things which exceeds what the security model ought to justify. Software's secure when everything is done right; it only takes a single bozo to foul things up.
I would bet the farm that they were given the order to put such and such a feature in.
Sure, but security isn't just a check-list item.
They knew the risks but didn't have the choice to say no (which is why software engineers need to be real engineers. Ethics are a good thing).
They could have done it though and got it right. They did not. It would seem that a fair number of the programmers working on Outlook have a mental model of the use of their product that does not include malicious people and messages, especially when combined with remote software that doesn't follow the rules at all well. In security terms, you can't assume that everyone's playing the game by the rules...
MS has the money to buy the best programmers they can get their hands on, if you don't believe that you are a moron.
Hah! They must have some good people, but they've got a lot of... "differently able" programmers as well. Bound to have with that many employees by application of the Law of Large Organizations.
The way out for them would be to add an extra layer to the release process that won't let anything out the door until it passes a proper security audit. But that won't happen; the extra time added to the release cycle would send the financial people into apoplexy, and many corporate users are (lamentably) using existing security misfeatures to manage systems (a legacy of historically poor remote-access-and-admin support) and would scream loudly if they had to change anything.
All Unixes (by virtue of tools like ssh, proper virtual terminals and a network-transparent GUI) are well ahead on this last front and have been for decades.
The problem is, at root, that C arrays do not know their own length (you can think of C strings as arrays of characters, of course.) And there is a vast amount of code out there that *depends* on this for a very wide variety of (correct) optimisations. Because of that, you can't just have a drop-in replacement for strcpy() and its ilk. Because of that (and the fact that programming effort is usually spend elsewhere) there will continue to be stupid buffer overrun bugs for a long time yet.
If you want safe arrays/strings, you use Java or Perl or Python or Tcl or whatever. Most languages have the required amount of safety these days, as the designers feel that catching overrun bugs is better than cranking out that last tiny bit of performance. Usually because they've previously debugged code with buffer overruns...:^)
(Curiously, I don't use most of the C string functions in my C code; strlen() is the only exception and that's only where I'm going from the uncounted-string to the counted-string domain. Once I know the length of a string, I can use memcpy() etc at the low level and work with higher-level abstractions through the rest of the code.)
Well, all I can say for sure is that we had (and probably still have - I don't remember that one being closed) a bug in our bugdb on this matter. IIRC, the consensus opinion was that what Stow was up to was blecherous, but that might just be my memory playing up...
There's a difference between package managers and compression algorithms. Packaging is ever so much more than compressing the files in a hierarchy into one lump...
We (the Tcl core developers) have had problems in the past with Stow, mainly because it relies on being able to specify the installation process at 'make-install' time instead of normal 'make' time, leading to messed up baked-in paths...:^/
TCL has better implementation and community support, but javascript is more popular and easier to learn.
Easy. If you're going to operate inside a web-page/browser, use Javascript. Otherwise don't. Use anything else. Hell, use Java as an extension language instead of Javascript (and Java's not a good choice at all for that!)
I'm at this point where I'm finding i'm doing everything in C, Fortran or shell.
I'm reckoning that I aught to learn a language that sits in the middle.
Now that's a good instinct. You definitely ought to be looking for something to help there.
Is TCL a good option here? Or would I be better with Python or Perl. (Ruby's out - don't know anyone to ask stupid questions about Ruby to).
Long-standing arguments between language fanatics notwithstanding, you should choose whichever of the languages suits your own personal style best. After all, it's not all that hard to quickly try all of them and all of them can do the "code integration" thing. I know that the Tcl community is virtually always welcoming towards newcomers, and many people find that to be a big plus, but one of the things we always recommend is that people choose something that suits them. After all, they're the ones putting the effort in to learn something new.
If you decide that you want to progress from calling your C and C++ code as external programs to integrating it into your scripting lanugage, you should probably look at SWIG as your first step to getting the wrapper code; it doesn't do as neat a job as hand-written stuff, but it is a much quicker way to get something working.
Can anyone actually point to a really solid Python application? I've used a number of them (including both Mailman and Zope) and I've yet to see one that doesn't have stupid and annoying "features". But perhaps that's the fault of the people programming with Python and not the language. After all, we don't blame sysadmins for the idiocy of users...
Perl will do exactly as advertised
So long as the advertising doesn't include maintenance six months in the future. On the other hand, as CowboyNeal probably knows full well, a decently obscure sendmail.cf is simultaneously a well-formed Perl program, so you can save on disk space...:^)
If all you want is the source, just grab it from SourceForge. We do recommend that people download either the binaries from ActiveState or Tclkit because that saves a configure/make/make-install cycle and you can be sure that someone's actually checked that the build went right. And the people involved in both are really nice anyway.
The innovation lies in making the engine that turns markup language into a layout on your screen faster and less buggy, resulting in a better web experience.
That's not innovation, you fool. That's incremental improvement. Incremental improvement's great stuff, but shouldn't be mistaken for anything revolutionary or truly innovative.
Many years ago, I used to use systems (DECstations running ULTRIX) which didn't have dynamic linking and where everything was statically linked. Linking was slow (by the standards of the time, especially when compared with other CPU-intensive operations), binary startup was slow, and everything took many times the space that it did now. It was awful. (By contrast, SunOS4 was really nice even with its criminally-broken header files.) And is there any particular reason why everything in/usr/bin should have its own copy of a substantial fraction of the C library?
One of the main reasons that you've got lots of extra space for things nowadays is that you've got shared libraries. (And don't quote "Moore's Law" with me; software can and does grow in size faster, especially with poor programmers!)
Trust me, if you have a sufficiently large system, chances are that you'll get pounded into a whimpering pulp by incompetent "duhveloperz" and asinine management long before you have to worry about the disgruntled and malicious. Stupidity is the rule, alas...
Get with the program people! I read this story in the newspaper this morning, so stop grabbing stuff out of n-th hand sources and start reading a bit more widely...
Eugh. Not only are IDSA a corporate body, they have a really awful website that looks like it was hacked together by someone without knowledge of the issues in serious website design. For example, it is obvious that the designer did not believe that people would have large monitors. Nor did they think that anyone blind would try to access the website, as a large fraction of the images lack ALT attributes...
By contrast, WoS is a much more competently produced site. Well done guys! Keep showing the suits up as the clueless fools they are!
We're suffering from the tech slump right now. Importing IT talent when we don't really have enough decent jobs for the people who are already here is just a little bit dumb...
Slashdot Mirror
I've known mail servers which were configured to accept *everything* ('cos they forwarded to the real mail server which was behind a firewall). The technique of using RCPT TO: doesn't work very well in practice; I used to use it for email validation about 5 years ago, and gave up. The only reliable way to validate an address is to send a message containing a complex URL that the user visits.
Of course, spammers don't care. They just set the reply-to header to someone else (I've been on the receiving end of this particular spam technique. GRRR!)
But testing isn't enough, especially in a safety-critical area. How do you know that the tests are adequate? How do you know that the tests test what the customer is after? How do you know that the various unit tests imply that the system integration tests will work?
Unit testing is good, but insufficient, and writing a test suite that covers everything to a level that ensures that integration goes smoothly and no faults occur in service is in reality *at least as hard* as using a formal development process, particularly as it is very tricky to work out whether you are testing everything you ought to be testing.
(FWIW, formal software development systems such as Z are enfuriating and bureaucratic, but can really deliver the goods - and with less cost - if you need that level of QA. But word processors don't need quite the same level of quality as railway signalling systems...)
Some of your other points are valid though. I'll let you guess which ones... ;^)
If some piece of source is just under copyright without some kind of license attached, you probably won't see it at all except in contexts like under an NDA. Your point is technically right, but so moot it is unfunny.
You can't sensibly say that some other programmer should have applied (eg) BSD to some code so as not to "restrict" users. If you like BSD, you apply it to your code.
I can and do say it. The main problem with the GPL is that it tries to spread itself to essentially unrelated code, and this can be a real nightmare in a large software project with components from all over the place. (I've no problem with the LGPL as that focusses on protecting the licensed code itself, though I prefer the BSD license for my own work. But then I'm happy for my code to end up in commercial contexts without remuneration; getting money back to me for what I write is a lot more awkward than it seems anyway, alas...)
Yes. Running untrusted code in anything other than the most restricted of contexts is asking for trouble. And it's not as if ways of supporting the feature are unavailable (sandboxes, digital signatures, etc.)
What you have here is almost certainly the law of unintended consequences; features that make lots of sense in one context (and which are not a problem in that situation) getting mixed together with things from another context to create something that's got a mix of these things which exceeds what the security model ought to justify. Software's secure when everything is done right; it only takes a single bozo to foul things up.
I would bet the farm that they were given the order to put such and such a feature in.
Sure, but security isn't just a check-list item.
They knew the risks but didn't have the choice to say no (which is why software engineers need to be real engineers. Ethics are a good thing).
They could have done it though and got it right. They did not. It would seem that a fair number of the programmers working on Outlook have a mental model of the use of their product that does not include malicious people and messages, especially when combined with remote software that doesn't follow the rules at all well. In security terms, you can't assume that everyone's playing the game by the rules...
MS has the money to buy the best programmers they can get their hands on, if you don't believe that you are a moron.
Hah! They must have some good people, but they've got a lot of... "differently able" programmers as well. Bound to have with that many employees by application of the Law of Large Organizations.
The way out for them would be to add an extra layer to the release process that won't let anything out the door until it passes a proper security audit. But that won't happen; the extra time added to the release cycle would send the financial people into apoplexy, and many corporate users are (lamentably) using existing security misfeatures to manage systems (a legacy of historically poor remote-access-and-admin support) and would scream loudly if they had to change anything.
All Unixes (by virtue of tools like ssh, proper virtual terminals and a network-transparent GUI) are well ahead on this last front and have been for decades.
The problem is, at root, that C arrays do not know their own length (you can think of C strings as arrays of characters, of course.) And there is a vast amount of code out there that *depends* on this for a very wide variety of (correct) optimisations. Because of that, you can't just have a drop-in replacement for strcpy() and its ilk. Because of that (and the fact that programming effort is usually spend elsewhere) there will continue to be stupid buffer overrun bugs for a long time yet.
:^)
If you want safe arrays/strings, you use Java or Perl or Python or Tcl or whatever. Most languages have the required amount of safety these days, as the designers feel that catching overrun bugs is better than cranking out that last tiny bit of performance. Usually because they've previously debugged code with buffer overruns...
(Curiously, I don't use most of the C string functions in my C code; strlen() is the only exception and that's only where I'm going from the uncounted-string to the counted-string domain. Once I know the length of a string, I can use memcpy() etc at the low level and work with higher-level abstractions through the rest of the code.)
But that doesn't count, since many browsers are configured to lie about what they are to work around stupid JavaScript/Website constraints.
95.7% of statistics are meaningless.
Well, all I can say for sure is that we had (and probably still have - I don't remember that one being closed) a bug in our bugdb on this matter. IIRC, the consensus opinion was that what Stow was up to was blecherous, but that might just be my memory playing up...
There's a difference between package managers and compression algorithms. Packaging is ever so much more than compressing the files in a hierarchy into one lump...
We (the Tcl core developers) have had problems in the past with Stow, mainly because it relies on being able to specify the installation process at 'make-install' time instead of normal 'make' time, leading to messed up baked-in paths... :^/
Try looking at the Tcler's Wiki for a better solution to this.
Easy. If you're going to operate inside a web-page/browser, use Javascript. Otherwise don't. Use anything else. Hell, use Java as an extension language instead of Javascript (and Java's not a good choice at all for that!)
I'm reckoning that I aught to learn a language that sits in the middle.
Now that's a good instinct. You definitely ought to be looking for something to help there.
Is TCL a good option here? Or would I be better with Python or Perl. (Ruby's out - don't know anyone to ask stupid questions about Ruby to).
Long-standing arguments between language fanatics notwithstanding, you should choose whichever of the languages suits your own personal style best. After all, it's not all that hard to quickly try all of them and all of them can do the "code integration" thing. I know that the Tcl community is virtually always welcoming towards newcomers, and many people find that to be a big plus, but one of the things we always recommend is that people choose something that suits them. After all, they're the ones putting the effort in to learn something new.
If you decide that you want to progress from calling your C and C++ code as external programs to integrating it into your scripting lanugage, you should probably look at SWIG as your first step to getting the wrapper code; it doesn't do as neat a job as hand-written stuff, but it is a much quicker way to get something working.
So, you'd rather have Perl's paradigm of Squiggle-Factor 9? It takes all sorts, I suppose...
Can anyone actually point to a really solid Python application? I've used a number of them (including both Mailman and Zope) and I've yet to see one that doesn't have stupid and annoying "features". But perhaps that's the fault of the people programming with Python and not the language. After all, we don't blame sysadmins for the idiocy of users...
Perl will do exactly as advertised
So long as the advertising doesn't include maintenance six months in the future. On the other hand, as CowboyNeal probably knows full well, a decently obscure sendmail.cf is simultaneously a well-formed Perl program, so you can save on disk space... :^)
If all you want is the source, just grab it from SourceForge. We do recommend that people download either the binaries from ActiveState or Tclkit because that saves a configure/make/make-install cycle and you can be sure that someone's actually checked that the build went right. And the people involved in both are really nice anyway.
That's not innovation, you fool. That's incremental improvement. Incremental improvement's great stuff, but shouldn't be mistaken for anything revolutionary or truly innovative.
Many years ago, I used to use systems (DECstations running ULTRIX) which didn't have dynamic linking and where everything was statically linked. Linking was slow (by the standards of the time, especially when compared with other CPU-intensive operations), binary startup was slow, and everything took many times the space that it did now. It was awful. (By contrast, SunOS4 was really nice even with its criminally-broken header files.) And is there any particular reason why everything in /usr/bin should have its own copy of a substantial fraction of the C library?
One of the main reasons that you've got lots of extra space for things nowadays is that you've got shared libraries. (And don't quote "Moore's Law" with me; software can and does grow in size faster, especially with poor programmers!)
But I thought the USA already has the best laws and courts that money can buy...
Trust me, if you have a sufficiently large system, chances are that you'll get pounded into a whimpering pulp by incompetent "duhveloperz" and asinine management long before you have to worry about the disgruntled and malicious. Stupidity is the rule, alas...
Get with the program people! I read this story in the newspaper this morning, so stop grabbing stuff out of n-th hand sources and start reading a bit more widely...
Eugh. Not only are IDSA a corporate body, they have a really awful website that looks like it was hacked together by someone without knowledge of the issues in serious website design. For example, it is obvious that the designer did not believe that people would have large monitors. Nor did they think that anyone blind would try to access the website, as a large fraction of the images lack ALT attributes...
By contrast, WoS is a much more competently produced site. Well done guys! Keep showing the suits up as the clueless fools they are!
We're suffering from the tech slump right now. Importing IT talent when we don't really have enough decent jobs for the people who are already here is just a little bit dumb...
Stop being completely absurd. It is libertarianism and republicanism that are political philosophies. Conservativism relates to a political party.
Oh, you were referring to the US.
You forgot to use WebServices to purchase the required number of knives from an online auction site...