Re:Mitnick may be a smart guy, BUT...
on
Mitnick on OSS
·
· Score: 1
I'm actually not a huge fan of Microsoft products, but I don't really see what my software preferences have to do with anything. My favorite OS is OSX, but it's also one of the least secure (in the sense not, perhaps, that I'm most likely to be pwned--the lack of popular use of my choice OS helps prevent that--but in the sense that Apple has among perhaps the worst security response procedures in software development today. I asked you for statistics simply because you made a claim without any evidence to back it up.
I was taking issue specifically with your statement, "but in reality, it's easier to crack a proprietary box." You have a good example above. You show some open source software that's more secure than some closed source software. And I agree; open source does not inherently make one less secure. But that's not what you said; what you said was that closed source is inherently less secure--which is equally false. For example, IIS6 had 2 vulnerabilities since 2004, while Apache2 had 30 vulnerabilities since 2002.
Whether the source is available is a factor, but it's far from the only factor in how secure a product is. For one thing, good fuzzing can be as or more effective than source code analysis, so despite what Mitnick says, having access to the source doesn't always mean a whole lot. But this doesn't mean that open source is more secure, either; the benefits of the open source model can just as easily be outweighed by the costs. Open source software does indeed have many eyes, but some projects don't have many good eyes (think PHPNuke).
And aside from questions of code quality from hobbyists and non-professionals (not to mention the lack of individual accountability), there's always the possibility of intentionally vulnerable patch submissions (this was attempted with Linux a while back; for all we know it's actually happened, too).
I never said Windows was more secure (not that your Secunia statistics close the book on that discussion), but it's just one example, anyway. Your assertion was universal--that open source is always more secure than proprietary solutions, which is just clearly an indefensible position.
The only people who actually believe that are zealots. This isn't about what model I prefer or what products I use. Politics--or religious zeal--are not anywhere near my mind when I'm writing code.
And I apologize if my "put up or shut up" phrase insulted you. I was recovering from shock at the unbelievable levels of stupidity in that thread. If you're not stupid, you don't deserve my ire.
What the fuck? I knew Slashdot was a shithole, but a reasonable comment backed up by evidence from a respected third party research group, phrased in neutral and inoffensive language (avoiding profanity is, for me, quite an accomplishment) drawn to a reasonably moderate conclusion is flamebait?
Idiot.
Re:Mitnick may be a smart guy, BUT...
on
Mitnick on OSS
·
· Score: 1
Er, do you have evidence, citations, anything to back your claim? Or should we just trust you because a man named tkrotchko can't be wrong?
I've seen no conclusive (or reliable) means of measuring vulnerability statistics that show what OS is the most secure. Vulnerability rates are hard to trust, because many vendors don't report vulnerabilities the same way, nor is it always clear what vulns affect the default install, the properly locked down install, etc. (for instance, Gentoo consistently releases more advisories than RedHat because Gentoo supports a wider range of third party software). Infection rates are hard to trust, because it's not clear which systems have more capable admins, which systems are more affected by a larger install base, etc. (for instance, Linux, being free, is probably more commonly used as a server by unskilled hobbyists).
Seems possible that the correlation between open source and security is not as close as the correlation between good development practices and security. Windows (and IIS) was for a long time plagued with bad development practices; many open source projects have the same problems (even popular ones, like PHP). That, more than open/closed source, seems to be the deciding factor.
Re:Fuzzing and Obfuscation
on
Mitnick on OSS
·
· Score: 1
Aside from all the other errors already pointed out, everything past the first paragraph has nothing to do with fuzzing.
Re:What is Fuzzing?
on
Mitnick on OSS
·
· Score: 2, Interesting
Why do you say it's a waste of time? The vast majority of vulnerabilities that lead to code execution are buffer overflows resulting from malformed input--things like file parsers that don't properly parse invalid files, network stacks that don't properly parse malformed packets, and so forth. These are all exactly the sorts of things that fuzzers catch.
It may be tempting to throw out the fuzzing approach because it's not very smart; unlike things like source code analysis, fuzzing appears to be very undirected, and a single run of a fuzzer probably won't catch anything. But the advantage of fuzzing is that it can be done without any guidance; you can set up a fuzzer, let it run on the target for a day or two, and log the things that make the target crash. Those are your buffer overflows, and you found them much more easily than with automated source code analysis.
Further, source code analysis is only good for checking for very specific types of flaws; for instance, having your source code analyzer check for use of "strcpy" is fine, but why not just use a more secure function ("strncpy")? Things that can be easily added to automated source code scanners can just as easily be phased out. Fuzzing, on the other hand, has the advantage of potentially (if done right) reaching deep into the code and, because it doesn't involve checking for some predefined blacklist of bad things to do, finding problems that nobody knew existed.
And given how quickly you did your research, I'm a tad skeptical about your expertise.
No, I think he got it. That's why he said that "spyware primarily affects the machine that has the infection"--because critical vulnerabilities, which do affect other machines, are patched.
I'm not saying I agree with him--I'm not even saying he's right, although I have yet to see commercial spyware that spreads machine-to-machine--but he clearly understood your point.
You can't expect any company to be honest and just say "ok what the heck: yes we're not superhumans, the code base is huge, lots of bad decisions in the past, & we have lots of smart coders, but some less smart ones, and trying to improve on this whole bunch of stuff while remaining compatible is HELLA hard. But we're trying".
Funny. If you'd summarized Mike Nash's comments with what you wrote above, I wouldn't have blinked. He did say that in the past, MS never realized there was a business reason to care about security. He said that there were mistakes and bad decisions in the past, but rather than simply write them off as bad decisions, it's his job to figure out why they happened and how to prevent them. And if you pressed him, I bet he'd even admit that not all MS employees are geniuses--there are a few idiots in the bunch, too.
Honestly, I don't know what you want from the man. I'm not saying the process is perfect now, but he seems fairly honest about its historical failures.
Ah, I see. What you're saying is that you can use it in a way that makes it appear typesafe. That may be. Nonetheless, neither Java nor C++ are actually typesafe; C++ still allows you to do things that aren't safe and thus isn't itself typesafe (maybe I'm just arguing semantics, but it's an important distinction--any system allows you to be correct; only some systems require you to be correct).
Wow. Too bad I don't have mod points and Slashdot doesn't have a "-1, illucid" option.
I might've missed some of what you said because it's so incoherent and unformatted (yes, syntax does matter), but a few notes:
1) Language is independent of implementation. Many high level languages (Python, Ruby, Perl) are indeed interpreted or bytecode compiled (Python--and, I believe, Ruby--is bytecode compiled, which does introduce a performance gain), but they need not be. Those are simply the dominant implementations (Python has, in fact, multiple implementations, including PyPy, Jython, and Cpython).
Not only could any of those languages be re-implemented as machine-code-compiled languages, but many other languages are both high level and have native code compilation (OCaml and Haskell spring to mind).
2) Allowing people to mix styles or languages breaks type safety. If Haskell allowed inline assembly, it wouldn't be a type safe, purely functional language (some may argue this is a valid compromise; OCaml is not purely functional, but as a result it can't be lazy--you give up features).
3) Many popular languages do have profilers (which you described in great detail as if they do not exist) to determine which parts of the code are particularly compute-intensive, and many allow you to write those parts in more optimized languages. Python, Perl, and Ruby allow you to write modules in C. OCaml lets you write modules in C. Haskell lets you write modules in C, though the process is fairly involved (requiring the use of monads to maintain the above described features). C# allows managed and unmanaged code (though the latter has some serious safety implications). You get the idea.
4) The assumption that lower level languages are faster is, I think, a bit over-played. Nobody has time to optimize their entire program, so we usually want to invest in compilers and infrastructure that do that for us. Many higher level languages optimize very well, but perhaps don't optimize as well as hand-optimized C or asm. Does this mean we should do everything in C or asm? Of course not. It means we hand-optimize the really intensive parts and let the compiler worry about the rest.
It would be a mistake for someone to think that writing his entire program in C will make it faster than writing it in a higher level language, unless he truly has the time (and skill) to optimize it all by hand. For most people, for most applications, it's just better to let the compiler do it.
OK, now what I said was that there is nothing inherently wrong with mixing code. That's it. Now, that's certainly a subjective viewpoint--"wrong" is subjective--but it's one shared by myself and thousands of other developers and architects, notably those at Microsoft (not to mention those at INRIA--the guys who make OCaml--those behind CPython, those behind GHC (the popular Haskell compiler--though since Haskell is purely functional, this is a slightly more complex situation)...). I don't see how that becomes "a bunch of mistakes" or "ridiculous posts," but I'm sure you'll be more than happy to explain it to me. (If I really am wrong--factually, not ideologically--go right ahead and point it out. I'm just not interested in your ideological debate.)
Sure, this being Slashdot, we all hate MS. But while we can debate the merits of their decisions, saying "it's OK to allow bytecode to call native (not bounds- or type-checked) code" is not, like you would like me to believe, Just Plain Wrong. I did say a few other things (one being that your "proof" that there are more Java jobs than.NET jobs was just bad evidence--which you seemingly admitted, later), but that was the thrust of my main point and the one we seem to have spent the most time debating (other than which one of us is the stupider zealot).
I was responding to you, initially, because I thought you were bullying someone else over a point which you didn't really have clear--your opinion about mixing managed and unmanaged code is fine, but it's not a fact, and it's ridiculous to assert that this isn't something reasonable people can disagree on. I lost interest in this discussion posts ago because it's just you and I going at each other's throats, and you clearly have no interest in actually discussing anything (sure, I was a bit snarky, too, and sure, you and I probably deserved each other's treatment).
So, sure, I'm sorry if I hurt your feelings. I'm sorry if I didn't have the time to write multi-page treatises on this debate (it's not one I find terribly interesting). And I'm certainly sorry I started revisiting Slashdot a few weeks ago when I had a lot of free time, because now I'm just wasting it.
I might regret even this reply, though it takes but a few minutes and I am, perhaps optimistically, starting to believe (after reading a few of your other posts on Slashdot) that you might be a sane person who just got himself a little worked up in this discussion. But my counsel to you, before replying, is to reread what I said, see what you actually take issue with, see what evidence you can present that backs your opinion, leave out the vitriol and ad hominems, and then reply.
And try to keep your posts on the brief side of ginormous, OK? Thanks.
For what it's worth, I started out with the assumption that you were simply a zealot who was over-eager to apply the label of troll.
I'm having doubts. Either you're a troll--and a troll dumb enough to pay for super-wonderful-extra-good-Slashdot-membership--or your zealotry is really just beyond the pale. In any case, thank you for reminding me why I stopped coming to Slashdot (hint: it wasn't, as I'm sure you're likely to reply, because I couldn't stand to have my frequent and elementary errors corrected).
As a final suggestion--though I'm sure this will fall on deaf ears--you might want to consider this: if people (in the far-more-than-two sense) often tell you you're wrong, it may not merely be that many people are stupid and unqualified. You might, in fact, be wrong.
Not true. The badges are RFID tagged. The point is probably that while you're not supposed to allow tailgating, people do it anyway. But if they can see from your badge whether you're supposed to be there, at least it means something. (MS's security isn't highly compartmentalized; most places are open to all blue-badges.)
You'll note that I'm not responding to some of your bullet points, not because I can't, but because, as noted before, they're simply personal attacks. My degree of audacity isn't really the issue here, after all.
2) No, I don't see the problem with that. If developers will not embrace a platform that does not allow them to use legacy code, they're not going to embrace a platform that doesn't allow them to use legacy code. Since you haven't answered my question as to what you'd propose instead (force them to rewrite everything? Allow them to link to legacy code but not "promote" the practice by documenting it?), I don't know what to say. Sure, I see the problems. So does Microsoft. I never said I didn't. But while there are problems, there are also problems with many other compromises we accept every day--blindly repeating the inherent problems in using unmanaged code doesn't win your argument (though it does make you sound like a Java bigot--one who doesn't simply prefer a certain platform, but is unable to have a rational discussion about its downsides).
Rational people can disagree, of course (that doesn't mean we can). There are valid arguments for avoiding unmanaged code altogether, just as there are valid arguments for using it when forced. Ultimately, it's the circumstances of the particular implementation that decide this, which is why having the option, while allowing bad developers to shoot themselves in the foot, can also be very empowering.
Yet you don't ever say that developers shouldn't be allowed to do this, exactly. You seem to be focussed only on the "encouraging" of misuse. In other words, unless I'm misreading, your problem with.NET is not that it allows the use of unmanaged code, but that, in your mind, the documentation says it's OK to do that.
3) I don't believe I ever wrote "incidental-ness." I did say that the original poster was asking whether he should learn this language for career reasons, and that the number of jobs offered is not the sole consideration (for instance, the number of jobs offered for OCaml developers is incredibly small--far, far smaller than those offered for either C# or Java developers--yet I was recently offered a relatively lucrative position doing OCaml precisely because I had OCaml experience, unlike most other applicants).
5) The half in this post I didn't bother answer. Well, that's not fair--they're not straw men; they're just pointless.
Wow. Just, wow. Don't you have a job or something? I suppose it didn't occur to you that I simply didn't find the rest of your post interesting (as I said before, it was just filled with vitriol) and that's why I didn't bother to read it closely or reply.
So again, I'm going to reply to the excerpts from your super-long post that I think are kind of ridiculous.
"Let's talk about what makes a good troll."
Let's not. I don't care.
"[Lots of stuff about how mixing managed and unmanaged code is bad and how Microsoft knows it is bad]..."
You quote MS yourself, however, as they explain why there are advantages to being able to do this mixing--for some users, migrating code is undesirable or not an option. This is not an oversight or an accident that you can do this mixing, but by design. Now, MS, and myself, are aware of the downsides to doing so. MS says that the platform "promotes" the practice--by which, in context, they clearly mean something like "makes it easily possible," not "encourages one to do so unnecessarily or against his better judgement," as you seem to believe--but they do warn about the possible downsides. I don't see what your problem with this is--you appear to think it's better to not give the user that option, which, while a valid position to take (especially in favor of high-minded language purity) isn't really a hit out of the ballpark in your favor, so to speak.
In other words, the ability to do code mixing is a powerful tool that, while undoubtedly useful to some, may allow others to shoot themselves in the foot. Unfortunately, I see it as likely a necessary evil to promote.NET adoption; there is a segment of users who simply won't migrate to things that require a rewrite of their legacy code (Java's particular disappointments should make that clear).
I never claimed there were more jobs available to.NET programmers, merely that the raw number of available jobs is not a great indicator of whether the original poster would find the one or the other more useful. I pointed out other factors to consider that you had not dug up appropriate data on, and, this time around, I might suggest you spend some time researching that--as I would be interested to see your conclusions--rather than writing another rant in reply to my (hopefully short) post.
Anyway, you appear to be the one incapable of understanding me, since maybe half of your arguments above were straw men. So I suggest, this time around, you read again what I wrote and, this time, try to remember that I'm not the same guy as that original poster you were lambasting. I'm someone else. And I don't have to defend his positions. Get it? Good.
If the rest of your comment weren't so vitriol-filled and pointless, I might bother to read it. As is, there are two odd errors that, I think, typify your weird bias:
1) Your link shows Microsoft explaining the practice of mixing code, not promoting it. They say ".NET promotes this" to mean ".NET makes this practice easy," as in, "this is one more option if you must do it." I don't understand what your point here is--is it that this practice should not be allowed, or that the feature should be shipped but not the documentation explaining it?
2) Your TIOBE link has nothing to do with job offerings, and your Dedasys link only incidentally does. Good methodology there, buddy (not to mention that it doesn't compare things like salary or desirability, or attempt to compensate for the derivatives of job offerings--there may be few, but they may be high paying, for instance, or there may be few, but they may be growing, while Java offerings may be shrinking).
Feel free to foe list me, as well. In fact, I suspect anyone who disagrees with you is a troll.
Good thing you haven't got mod points, then. As at least one other poster noted, C# is an ECMA standard, while Java is not. C# has fully open implementations (Mono being the most common, but not the only). It would be legally impossible for MS to attack anyone who implements their open standard--they simply don't own C# or.NET IL.
If the name "Microsoft" leaves too much of a bad taste in your mouth for you to actually consider what's a better choice, you're not an engineer--you're a zealot.
Yeah. What you propose makes a bit more sense, but Google hasn't exactly moved into a model of selling things to users. Departing from free, ad-supported services would be a very big departure indeed. On the other hand, it's still a service, at least; Google clearly has really no interest in a manufacturing model, I think (exceptions being Desktop, Picassa, and Earth, simply because you can't do those without some client software). And you are right about their move towards WiFi--they did bid for the San Francisco contract, if I remember right, and they have that IPSec tunneling application.
I could see them offering some "radical, new, revolutionary" (forgive my sour grapes; I've been down on Google ever since they didn't make me a job offer;) ) service (like WiFi). But the real trick to keep their profit margins where they are is to find something that supports a lot of ad revenue (targeting ads based on traffic analysis seems a good bet) while having very low unit costs (like Web services do now). Traditional ISPs have somewhat higher unit costs, and much higher requirements in terms of initial infrastructure, so Google would have to come up with something to deal with that problem before it would be an attractive market, I think.
But I guess we'll see. The fun thing about Google is they're rich and, apparently, very optimistic, so they invest in all sorts of odd things. It's definitely fun to watch.
Eh. NetZero and Juno (and probably others) tried to do this in the US back in the nineties. They provided free dialup (in Juno's case, it was for a long time limited to e-mail) in exchange for showing banner ads on your machine. Granted, they weren't targeted, but they both flopped (Juno is now nonexistent, as far as I know, while NetZero is now a subscription service).
Running dialup is probably a good deal cheaper than broadband, but can you see Google getting into dialup? I can't. And doing broadband based off of ads, even targeted ones, seems like a pretty unlikely proposition as well.
But my point wasn't that ISPs don't often provide Web services. Nearly all provide at least e-mail, and probably most provide some limited hosting. My point was just that that's not really a key offering of the ISP, and in fact that with broadband provided by telecoms, it appears more and more to just be a token offering not even used by many customers (sure, you may use Comcast or Verizon DSL or whatever the German equivalents are, but you use Hotmail or GMail or whtaever for e-mail). So what I was concluding was just that the synergy is pretty much imagined--there's nothing really to be gained by getting your e-mail or hosting or IM service from the same person providing your actual connection (this is, of course, one of the big benefits of an open architecture end-to-end system like the Internet). There's just not really any value.
Sure, Google has something to gain by moving into stickier businesses where a customer base can't evaporate overnight (unlike search), but doing so at the cost of their image as innovative and at the cost of high profit margins just doesn't make sense to me.
I should clarify that I wouldn't be all that surprised if Google wanted to enter a largely unexplored market--as with their bid for providing wifi to San Francisco. But there's not really any good reason for them to want to go into the already-crowded traditional ISP market, I don't think, for the reasons cited above (and the lack of last-mile infrastructure).
More than likely, in my mind, the dark fiber and instant datacenter thing are just ideas being explored to cope with Google's existing infrastructure demands--we don't need to speculate on any particularly odd projects to explain why Google would want this.
And the stake in AOL is presumably for advertising and AOL's web services users. Again, no huge mystery.
I believe the profit margins are in fact quite a lot lower in the ISP business than they are in the search engine business. That doesn't mean they won't do this, to be sure; ISPs generally have a little bit more lock-in than search engines do. But I don't see it happening, either; the most successful ISPs right now seem to be the ones that are part of traditional telecoms--cable companies, satellite TV companies, phone companies--not Web services companies (AOL, MSN). Sure, you could say that's because AOL and MSN offer too big (and too expensive) a package, but that's the whole point: telecoms offer what is essentially Bring Your Own Services--paired with Bring Your Own Connection services like free Web mail (GMail), free IM (Google Talk), free hosting (Blogger, Flickr, etc), and, well, you get the idea.
In other words, the best ISPs offer just one thing--connectivity. And the best web services offer just one thing--services. AOL and MSN, which force you to buy both (and make you give up your e-mail address if you want a different ISP, or make you give up your ISP if you don't want to pay for their Web services) are too big, too bloated, too expensive. Why would Google want to do that? Especially when the profit margins are lower.
Two things. First, what you said is, I'm afraid, logically wrong; second, his references did not back up what he said.
First things first. The third possibility, and the one that I believe is most accurate is that the certification is meaningful and valid even with said vulnerability. One of the criteria required is not to be vulnerability free; if you read the common criteria specification you will not find, anywhere, that common criteria certified OSes are not allowed to have vulnerabilities (otherwise SuSE and RHEL wouldn't get certified, either). So while Windows does have a vulnerability (or many), it may still conform to the requirements of the common criteria certification without that certification being meaningful (as explained elsewhere, CC certifies a range of security features and implementations).
Second, what he said was that MS bought the certification through bribery. And even if we were to accept your reasoning above (which is specious), that wouldn't be a fair conclusion; it could be far more likely that CC certification is meaningless than to think that MS bribed an independent certifier.
Sure, yes, it's Microsoft, and we all know they're evil. But meaningless, unsubstantiated charges of bribery are just that: meaningless and unsubstantiated.
If I remember right, there is a certification fee. Of course, that makes sense, since certifying an OS costs the certifier. But you're not saying that; you're implying that MS payed a bribe to get certified.
Care to back that up with references? Or is this just typical Slashdot trolling?
Ballmer is a moron. I wouldn't say to disregard his opinion, because unfortunately his opinion does shape the company, but I'm generally relieved to know MS is more than a bunch of little Ballmers.
And yeah, it goes both ways. I know of one or two incidents of the reverse--people getting upset to see competitors' schwag on employees, upset to see employees using or suggesting other products, etc. But I think any company is like that, and in a way, any company should be like that--not blind to the good in competitors' products, and not angry at competitors, but passionate about their own.
Hell, Googlers all seem to believe they're too smart to even bother talking to, let alone taking notes from, the competition. The level of arrogance in that company, I think, far exceeds anything you'll find (in aggregate) at Microsoft.
Slashdot Mirror
I'm actually not a huge fan of Microsoft products, but I don't really see what my software preferences have to do with anything. My favorite OS is OSX, but it's also one of the least secure (in the sense not, perhaps, that I'm most likely to be pwned--the lack of popular use of my choice OS helps prevent that--but in the sense that Apple has among perhaps the worst security response procedures in software development today. I asked you for statistics simply because you made a claim without any evidence to back it up.
I was taking issue specifically with your statement, "but in reality, it's easier to crack a proprietary box." You have a good example above. You show some open source software that's more secure than some closed source software. And I agree; open source does not inherently make one less secure. But that's not what you said; what you said was that closed source is inherently less secure--which is equally false. For example, IIS6 had 2 vulnerabilities since 2004, while Apache2 had 30 vulnerabilities since 2002.
Whether the source is available is a factor, but it's far from the only factor in how secure a product is. For one thing, good fuzzing can be as or more effective than source code analysis, so despite what Mitnick says, having access to the source doesn't always mean a whole lot. But this doesn't mean that open source is more secure, either; the benefits of the open source model can just as easily be outweighed by the costs. Open source software does indeed have many eyes, but some projects don't have many good eyes (think PHPNuke).
And aside from questions of code quality from hobbyists and non-professionals (not to mention the lack of individual accountability), there's always the possibility of intentionally vulnerable patch submissions (this was attempted with Linux a while back; for all we know it's actually happened, too).
I never said Windows was more secure (not that your Secunia statistics close the book on that discussion), but it's just one example, anyway. Your assertion was universal--that open source is always more secure than proprietary solutions, which is just clearly an indefensible position.
The only people who actually believe that are zealots. This isn't about what model I prefer or what products I use. Politics--or religious zeal--are not anywhere near my mind when I'm writing code.
And I apologize if my "put up or shut up" phrase insulted you. I was recovering from shock at the unbelievable levels of stupidity in that thread. If you're not stupid, you don't deserve my ire.
What the fuck? I knew Slashdot was a shithole, but a reasonable comment backed up by evidence from a respected third party research group, phrased in neutral and inoffensive language (avoiding profanity is, for me, quite an accomplishment) drawn to a reasonably moderate conclusion is flamebait?
Idiot.
Er, do you have evidence, citations, anything to back your claim? Or should we just trust you because a man named tkrotchko can't be wrong?
I've seen no conclusive (or reliable) means of measuring vulnerability statistics that show what OS is the most secure. Vulnerability rates are hard to trust, because many vendors don't report vulnerabilities the same way, nor is it always clear what vulns affect the default install, the properly locked down install, etc. (for instance, Gentoo consistently releases more advisories than RedHat because Gentoo supports a wider range of third party software). Infection rates are hard to trust, because it's not clear which systems have more capable admins, which systems are more affected by a larger install base, etc. (for instance, Linux, being free, is probably more commonly used as a server by unskilled hobbyists).
Show me the evidence or shut up.
Get real... Apache's an appealing target. Which web server has more exploits for it? IIS.
You sure about that?
IIS6: 2 vulnerabilities since 2004 Apache2: 30 vulnerabilities since 2002
Seems possible that the correlation between open source and security is not as close as the correlation between good development practices and security. Windows (and IIS) was for a long time plagued with bad development practices; many open source projects have the same problems (even popular ones, like PHP). That, more than open/closed source, seems to be the deciding factor.
Aside from all the other errors already pointed out, everything past the first paragraph has nothing to do with fuzzing.
Why do you say it's a waste of time? The vast majority of vulnerabilities that lead to code execution are buffer overflows resulting from malformed input--things like file parsers that don't properly parse invalid files, network stacks that don't properly parse malformed packets, and so forth. These are all exactly the sorts of things that fuzzers catch.
It may be tempting to throw out the fuzzing approach because it's not very smart; unlike things like source code analysis, fuzzing appears to be very undirected, and a single run of a fuzzer probably won't catch anything. But the advantage of fuzzing is that it can be done without any guidance; you can set up a fuzzer, let it run on the target for a day or two, and log the things that make the target crash. Those are your buffer overflows, and you found them much more easily than with automated source code analysis.
Further, source code analysis is only good for checking for very specific types of flaws; for instance, having your source code analyzer check for use of "strcpy" is fine, but why not just use a more secure function ("strncpy")? Things that can be easily added to automated source code scanners can just as easily be phased out. Fuzzing, on the other hand, has the advantage of potentially (if done right) reaching deep into the code and, because it doesn't involve checking for some predefined blacklist of bad things to do, finding problems that nobody knew existed.
And given how quickly you did your research, I'm a tad skeptical about your expertise.
No, I think he got it. That's why he said that "spyware primarily affects the machine that has the infection"--because critical vulnerabilities, which do affect other machines, are patched.
I'm not saying I agree with him--I'm not even saying he's right, although I have yet to see commercial spyware that spreads machine-to-machine--but he clearly understood your point.
You can't expect any company to be honest and just say "ok what the heck: yes we're not superhumans, the code base is huge, lots of bad decisions in the past, & we have lots of smart coders, but some less smart ones, and trying to improve on this whole bunch of stuff while remaining compatible is HELLA hard. But we're trying".
Funny. If you'd summarized Mike Nash's comments with what you wrote above, I wouldn't have blinked. He did say that in the past, MS never realized there was a business reason to care about security. He said that there were mistakes and bad decisions in the past, but rather than simply write them off as bad decisions, it's his job to figure out why they happened and how to prevent them. And if you pressed him, I bet he'd even admit that not all MS employees are geniuses--there are a few idiots in the bunch, too.
Honestly, I don't know what you want from the man. I'm not saying the process is perfect now, but he seems fairly honest about its historical failures.
Ah, I see. What you're saying is that you can use it in a way that makes it appear typesafe. That may be. Nonetheless, neither Java nor C++ are actually typesafe; C++ still allows you to do things that aren't safe and thus isn't itself typesafe (maybe I'm just arguing semantics, but it's an important distinction--any system allows you to be correct; only some systems require you to be correct).
Wow. Too bad I don't have mod points and Slashdot doesn't have a "-1, illucid" option.
I might've missed some of what you said because it's so incoherent and unformatted (yes, syntax does matter), but a few notes:
1) Language is independent of implementation. Many high level languages (Python, Ruby, Perl) are indeed interpreted or bytecode compiled (Python--and, I believe, Ruby--is bytecode compiled, which does introduce a performance gain), but they need not be. Those are simply the dominant implementations (Python has, in fact, multiple implementations, including PyPy, Jython, and Cpython).
Not only could any of those languages be re-implemented as machine-code-compiled languages, but many other languages are both high level and have native code compilation (OCaml and Haskell spring to mind).
2) Allowing people to mix styles or languages breaks type safety. If Haskell allowed inline assembly, it wouldn't be a type safe, purely functional language (some may argue this is a valid compromise; OCaml is not purely functional, but as a result it can't be lazy--you give up features).
3) Many popular languages do have profilers (which you described in great detail as if they do not exist) to determine which parts of the code are particularly compute-intensive, and many allow you to write those parts in more optimized languages. Python, Perl, and Ruby allow you to write modules in C. OCaml lets you write modules in C. Haskell lets you write modules in C, though the process is fairly involved (requiring the use of monads to maintain the above described features). C# allows managed and unmanaged code (though the latter has some serious safety implications). You get the idea.
4) The assumption that lower level languages are faster is, I think, a bit over-played. Nobody has time to optimize their entire program, so we usually want to invest in compilers and infrastructure that do that for us. Many higher level languages optimize very well, but perhaps don't optimize as well as hand-optimized C or asm. Does this mean we should do everything in C or asm? Of course not. It means we hand-optimize the really intensive parts and let the compiler worry about the rest.
It would be a mistake for someone to think that writing his entire program in C will make it faster than writing it in a higher level language, unless he truly has the time (and skill) to optimize it all by hand. For most people, for most applications, it's just better to let the compiler do it.
It's "more typesafe" than Java or C#? How?
OK, now what I said was that there is nothing inherently wrong with mixing code. That's it. Now, that's certainly a subjective viewpoint--"wrong" is subjective--but it's one shared by myself and thousands of other developers and architects, notably those at Microsoft (not to mention those at INRIA--the guys who make OCaml--those behind CPython, those behind GHC (the popular Haskell compiler--though since Haskell is purely functional, this is a slightly more complex situation)...). I don't see how that becomes "a bunch of mistakes" or "ridiculous posts," but I'm sure you'll be more than happy to explain it to me. (If I really am wrong--factually, not ideologically--go right ahead and point it out. I'm just not interested in your ideological debate.)
.NET jobs was just bad evidence--which you seemingly admitted, later), but that was the thrust of my main point and the one we seem to have spent the most time debating (other than which one of us is the stupider zealot).
Sure, this being Slashdot, we all hate MS. But while we can debate the merits of their decisions, saying "it's OK to allow bytecode to call native (not bounds- or type-checked) code" is not, like you would like me to believe, Just Plain Wrong. I did say a few other things (one being that your "proof" that there are more Java jobs than
I was responding to you, initially, because I thought you were bullying someone else over a point which you didn't really have clear--your opinion about mixing managed and unmanaged code is fine, but it's not a fact, and it's ridiculous to assert that this isn't something reasonable people can disagree on. I lost interest in this discussion posts ago because it's just you and I going at each other's throats, and you clearly have no interest in actually discussing anything (sure, I was a bit snarky, too, and sure, you and I probably deserved each other's treatment).
So, sure, I'm sorry if I hurt your feelings. I'm sorry if I didn't have the time to write multi-page treatises on this debate (it's not one I find terribly interesting). And I'm certainly sorry I started revisiting Slashdot a few weeks ago when I had a lot of free time, because now I'm just wasting it.
I might regret even this reply, though it takes but a few minutes and I am, perhaps optimistically, starting to believe (after reading a few of your other posts on Slashdot) that you might be a sane person who just got himself a little worked up in this discussion. But my counsel to you, before replying, is to reread what I said, see what you actually take issue with, see what evidence you can present that backs your opinion, leave out the vitriol and ad hominems, and then reply.
And try to keep your posts on the brief side of ginormous, OK? Thanks.
For what it's worth, I started out with the assumption that you were simply a zealot who was over-eager to apply the label of troll.
r your zealotry is really just beyond the pale. In any case, thank you for reminding me why I stopped coming to Slashdot (hint: it wasn't, as I'm sure you're likely to reply, because I couldn't stand to have my frequent and elementary errors corrected).
I'm having doubts. Either you're a troll--and a troll dumb enough to pay for super-wonderful-extra-good-Slashdot-membership--o
As a final suggestion--though I'm sure this will fall on deaf ears--you might want to consider this: if people (in the far-more-than-two sense) often tell you you're wrong, it may not merely be that many people are stupid and unqualified. You might, in fact, be wrong.
Not true. The badges are RFID tagged. The point is probably that while you're not supposed to allow tailgating, people do it anyway. But if they can see from your badge whether you're supposed to be there, at least it means something. (MS's security isn't highly compartmentalized; most places are open to all blue-badges.)
You'll note that I'm not responding to some of your bullet points, not because I can't, but because, as noted before, they're simply personal attacks. My degree of audacity isn't really the issue here, after all.
.NET is not that it allows the use of unmanaged code, but that, in your mind, the documentation says it's OK to do that.
2) No, I don't see the problem with that. If developers will not embrace a platform that does not allow them to use legacy code, they're not going to embrace a platform that doesn't allow them to use legacy code. Since you haven't answered my question as to what you'd propose instead (force them to rewrite everything? Allow them to link to legacy code but not "promote" the practice by documenting it?), I don't know what to say. Sure, I see the problems. So does Microsoft. I never said I didn't. But while there are problems, there are also problems with many other compromises we accept every day--blindly repeating the inherent problems in using unmanaged code doesn't win your argument (though it does make you sound like a Java bigot--one who doesn't simply prefer a certain platform, but is unable to have a rational discussion about its downsides).
Rational people can disagree, of course (that doesn't mean we can). There are valid arguments for avoiding unmanaged code altogether, just as there are valid arguments for using it when forced. Ultimately, it's the circumstances of the particular implementation that decide this, which is why having the option, while allowing bad developers to shoot themselves in the foot, can also be very empowering.
Yet you don't ever say that developers shouldn't be allowed to do this, exactly. You seem to be focussed only on the "encouraging" of misuse. In other words, unless I'm misreading, your problem with
3) I don't believe I ever wrote "incidental-ness." I did say that the original poster was asking whether he should learn this language for career reasons, and that the number of jobs offered is not the sole consideration (for instance, the number of jobs offered for OCaml developers is incredibly small--far, far smaller than those offered for either C# or Java developers--yet I was recently offered a relatively lucrative position doing OCaml precisely because I had OCaml experience, unlike most other applicants).
5) The half in this post I didn't bother answer. Well, that's not fair--they're not straw men; they're just pointless.
Wow. Just, wow. Don't you have a job or something? I suppose it didn't occur to you that I simply didn't find the rest of your post interesting (as I said before, it was just filled with vitriol) and that's why I didn't bother to read it closely or reply.
.NET adoption; there is a segment of users who simply won't migrate to things that require a rewrite of their legacy code (Java's particular disappointments should make that clear).
.NET programmers, merely that the raw number of available jobs is not a great indicator of whether the original poster would find the one or the other more useful. I pointed out other factors to consider that you had not dug up appropriate data on, and, this time around, I might suggest you spend some time researching that--as I would be interested to see your conclusions--rather than writing another rant in reply to my (hopefully short) post.
So again, I'm going to reply to the excerpts from your super-long post that I think are kind of ridiculous.
"Let's talk about what makes a good troll."
Let's not. I don't care.
"[Lots of stuff about how mixing managed and unmanaged code is bad and how Microsoft knows it is bad]..."
You quote MS yourself, however, as they explain why there are advantages to being able to do this mixing--for some users, migrating code is undesirable or not an option. This is not an oversight or an accident that you can do this mixing, but by design. Now, MS, and myself, are aware of the downsides to doing so. MS says that the platform "promotes" the practice--by which, in context, they clearly mean something like "makes it easily possible," not "encourages one to do so unnecessarily or against his better judgement," as you seem to believe--but they do warn about the possible downsides. I don't see what your problem with this is--you appear to think it's better to not give the user that option, which, while a valid position to take (especially in favor of high-minded language purity) isn't really a hit out of the ballpark in your favor, so to speak.
In other words, the ability to do code mixing is a powerful tool that, while undoubtedly useful to some, may allow others to shoot themselves in the foot. Unfortunately, I see it as likely a necessary evil to promote
I never claimed there were more jobs available to
Anyway, you appear to be the one incapable of understanding me, since maybe half of your arguments above were straw men. So I suggest, this time around, you read again what I wrote and, this time, try to remember that I'm not the same guy as that original poster you were lambasting. I'm someone else. And I don't have to defend his positions. Get it? Good.
If the rest of your comment weren't so vitriol-filled and pointless, I might bother to read it. As is, there are two odd errors that, I think, typify your weird bias:
1) Your link shows Microsoft explaining the practice of mixing code, not promoting it. They say ".NET promotes this" to mean ".NET makes this practice easy," as in, "this is one more option if you must do it." I don't understand what your point here is--is it that this practice should not be allowed, or that the feature should be shipped but not the documentation explaining it?
2) Your TIOBE link has nothing to do with job offerings, and your Dedasys link only incidentally does. Good methodology there, buddy (not to mention that it doesn't compare things like salary or desirability, or attempt to compensate for the derivatives of job offerings--there may be few, but they may be high paying, for instance, or there may be few, but they may be growing, while Java offerings may be shrinking).
Feel free to foe list me, as well. In fact, I suspect anyone who disagrees with you is a troll.
Good thing you haven't got mod points, then. As at least one other poster noted, C# is an ECMA standard, while Java is not. C# has fully open implementations (Mono being the most common, but not the only). It would be legally impossible for MS to attack anyone who implements their open standard--they simply don't own C# or .NET IL.
If the name "Microsoft" leaves too much of a bad taste in your mouth for you to actually consider what's a better choice, you're not an engineer--you're a zealot.
Yeah. What you propose makes a bit more sense, but Google hasn't exactly moved into a model of selling things to users. Departing from free, ad-supported services would be a very big departure indeed. On the other hand, it's still a service, at least; Google clearly has really no interest in a manufacturing model, I think (exceptions being Desktop, Picassa, and Earth, simply because you can't do those without some client software). And you are right about their move towards WiFi--they did bid for the San Francisco contract, if I remember right, and they have that IPSec tunneling application.
;) ) service (like WiFi). But the real trick to keep their profit margins where they are is to find something that supports a lot of ad revenue (targeting ads based on traffic analysis seems a good bet) while having very low unit costs (like Web services do now). Traditional ISPs have somewhat higher unit costs, and much higher requirements in terms of initial infrastructure, so Google would have to come up with something to deal with that problem before it would be an attractive market, I think.
I could see them offering some "radical, new, revolutionary" (forgive my sour grapes; I've been down on Google ever since they didn't make me a job offer
But I guess we'll see. The fun thing about Google is they're rich and, apparently, very optimistic, so they invest in all sorts of odd things. It's definitely fun to watch.
Eh. NetZero and Juno (and probably others) tried to do this in the US back in the nineties. They provided free dialup (in Juno's case, it was for a long time limited to e-mail) in exchange for showing banner ads on your machine. Granted, they weren't targeted, but they both flopped (Juno is now nonexistent, as far as I know, while NetZero is now a subscription service).
Running dialup is probably a good deal cheaper than broadband, but can you see Google getting into dialup? I can't. And doing broadband based off of ads, even targeted ones, seems like a pretty unlikely proposition as well.
But my point wasn't that ISPs don't often provide Web services. Nearly all provide at least e-mail, and probably most provide some limited hosting. My point was just that that's not really a key offering of the ISP, and in fact that with broadband provided by telecoms, it appears more and more to just be a token offering not even used by many customers (sure, you may use Comcast or Verizon DSL or whatever the German equivalents are, but you use Hotmail or GMail or whtaever for e-mail). So what I was concluding was just that the synergy is pretty much imagined--there's nothing really to be gained by getting your e-mail or hosting or IM service from the same person providing your actual connection (this is, of course, one of the big benefits of an open architecture end-to-end system like the Internet). There's just not really any value.
Sure, Google has something to gain by moving into stickier businesses where a customer base can't evaporate overnight (unlike search), but doing so at the cost of their image as innovative and at the cost of high profit margins just doesn't make sense to me.
I should clarify that I wouldn't be all that surprised if Google wanted to enter a largely unexplored market--as with their bid for providing wifi to San Francisco. But there's not really any good reason for them to want to go into the already-crowded traditional ISP market, I don't think, for the reasons cited above (and the lack of last-mile infrastructure).
More than likely, in my mind, the dark fiber and instant datacenter thing are just ideas being explored to cope with Google's existing infrastructure demands--we don't need to speculate on any particularly odd projects to explain why Google would want this.
And the stake in AOL is presumably for advertising and AOL's web services users. Again, no huge mystery.
I believe the profit margins are in fact quite a lot lower in the ISP business than they are in the search engine business. That doesn't mean they won't do this, to be sure; ISPs generally have a little bit more lock-in than search engines do. But I don't see it happening, either; the most successful ISPs right now seem to be the ones that are part of traditional telecoms--cable companies, satellite TV companies, phone companies--not Web services companies (AOL, MSN). Sure, you could say that's because AOL and MSN offer too big (and too expensive) a package, but that's the whole point: telecoms offer what is essentially Bring Your Own Services--paired with Bring Your Own Connection services like free Web mail (GMail), free IM (Google Talk), free hosting (Blogger, Flickr, etc), and, well, you get the idea.
In other words, the best ISPs offer just one thing--connectivity. And the best web services offer just one thing--services. AOL and MSN, which force you to buy both (and make you give up your e-mail address if you want a different ISP, or make you give up your ISP if you don't want to pay for their Web services) are too big, too bloated, too expensive. Why would Google want to do that? Especially when the profit margins are lower.
Two things. First, what you said is, I'm afraid, logically wrong; second, his references did not back up what he said.
First things first. The third possibility, and the one that I believe is most accurate is that the certification is meaningful and valid even with said vulnerability. One of the criteria required is not to be vulnerability free; if you read the common criteria specification you will not find, anywhere, that common criteria certified OSes are not allowed to have vulnerabilities (otherwise SuSE and RHEL wouldn't get certified, either). So while Windows does have a vulnerability (or many), it may still conform to the requirements of the common criteria certification without that certification being meaningful (as explained elsewhere, CC certifies a range of security features and implementations).
Second, what he said was that MS bought the certification through bribery. And even if we were to accept your reasoning above (which is specious), that wouldn't be a fair conclusion; it could be far more likely that CC certification is meaningless than to think that MS bribed an independent certifier.
Sure, yes, it's Microsoft, and we all know they're evil. But meaningless, unsubstantiated charges of bribery are just that: meaningless and unsubstantiated.
If I remember right, there is a certification fee. Of course, that makes sense, since certifying an OS costs the certifier. But you're not saying that; you're implying that MS payed a bribe to get certified.
Care to back that up with references? Or is this just typical Slashdot trolling?
Ballmer is a moron. I wouldn't say to disregard his opinion, because unfortunately his opinion does shape the company, but I'm generally relieved to know MS is more than a bunch of little Ballmers.
And yeah, it goes both ways. I know of one or two incidents of the reverse--people getting upset to see competitors' schwag on employees, upset to see employees using or suggesting other products, etc. But I think any company is like that, and in a way, any company should be like that--not blind to the good in competitors' products, and not angry at competitors, but passionate about their own.
Hell, Googlers all seem to believe they're too smart to even bother talking to, let alone taking notes from, the competition. The level of arrogance in that company, I think, far exceeds anything you'll find (in aggregate) at Microsoft.