Quicktime installs a handful of additional (and unnecessary) stuff. In particular, it includes an IE plug-in that not only enables viewing of Quicktime movies in the browser but also replaces handling of other media formats, including JPEG rendering. This increases the browser footprint and slows it down noticeably, or at least it did the last time I installed Quicktime (a couple years ago). Also, I'm not entirely sure if it's Quicktime or iTunes that installs Bonjour, but that definitely falls into the category of stuff I don't want a media player installing and enabling without my express consent.
The IE plug-in can be disabled using IE's add-in manager. I don't know whether Quicktime installs a Firefox plug-in as well, or not. If it does, the odds are that it is also exploitable. If not, you're probably fine unless you download the file and open it directly.
Apparently you are the one who does not understand. DEP and ASLR are features provided by the OS, but they are *NOT* universally backward-compatible features. Some apps will break if DEP is enabled. Some libraries will break if ASLR is enabled. ASLR is new enough that it's still not uncommon to find libraries which weren't coded with it in mind.
As for "not properly implementing security the features available" you *really* should take the foot out of your mouth before you choke on it. For one thing, any application running as Admin (including most software installers) can opt out of firewall (turn it off or add an exemption; *lots* of apps or their installers do this), opt out of virus scan (non-trivial, but they could add themselves to the allowed files list or simply turn off the scanner), or opt out of permissions (change the ACLs to world-writable). Of course, this assumes that you're talking about software already executing on the computer. Once you're to this point; DEP and ASLR are irrelevant; their only purpose is to try and prevent exploits and they can do nothing once the malicious code begins to execute.
However, "hackers" still have to find a vulnerability in the program that they are trying to execute. A firewall only protects network interfaces; if the software is properly secured it can't be compromised no matter what comes over the connection. A virus scanner only detects malicious software on the system; if there are no exploitable programs then the attacker has no way to get malicious software onto the computer in the first place (aside from social engineering, but you can't fix stupid). Permissions can limit the damage that malware or a compromised program does, but again if there's no way to compromise any programs that doesn't matter (and most XP users run as Admin anyhow).
If the Quicktime developers hadn't left this problem in their code, there would be no problem at all.
Malware implies code already executing on your machine. By the time you get that far, DEP and ASLR are already bypassed; their purpose is to prevent the execution of such code in the first place. There are other things one can do to mitigate the damage, such as limited permissions and sandboxing, but you're comparing apples to oranges here. DEP and ASLR make exploits more difficult. Malware is something that exploits (or stupid users) install. Malware could quite happily opt in to DEP and ASLR; it wouldn't change anything.
However, non-malicious software developers can choose to opt-in to these features in order to provide an extra layer of security against exploits. That's what DEP and ASLR are: extra layers of security, neither an absolute barrier to attack nor a "keystone of the OS Security" as you put it. They just make successful exploits much more difficult. The principle is called Defense in Depth, and if you know anything about security of any kind you'll be familiar with the notion.
As for why they're opt-in rather than opt-out (or unavoidable) the problem is that they are not completely non-breaking changes to the OS behavior. Some applications will crash or otherwise fail to work if they are run with DEP, or their libraries are loaded with ASLR. Those programs and libraries are poorly written by modern standards, but then again, if they'd been written correctly in the first place DEP and ASLR would be irrelevant because they wouldn't have security vulnerabilities in the first place.
More to the point, this attack uses ROP (which, as you say, defeats DEP) but it does it using bits fo code, called "gadgets", that are part of a library which is loaded without ASLR. Even though the browser itself is using ASLR, some of its libraries will be loaded at known locations, which is what makes this attack work. That's not exactly defeating ASLR so much as it is taking advantage of the fact that it isn't universally used yet, kind of like the way some legacy programs aren't DEP-compatible.
For the time being, ASLR is only opt-in; if a library doesn't mark itself as ASLR-compatible, the loader will put it at its preferred base address. Or at least, it will try to. The fact is that dynamically linked libraries can never guarantee that their preferred address range is available, and therefore should never assume that they are at a given location in memory. In fact, most of them don't... but they still don't have the opt-in flag, either because they're old or because the developer didn't set it. I wonder how hard it would be to simply *force* ASLR by telling each library, as it loads, that its preferred address is simply unavailable and it's going to be stuck someplace else...
Also, economies of scale don't necessarily apply. For example, moderation of the player base requires a number if people in direct proportion to the player base, and maybe even a little worse - the more players are, not only the more problem people you have but the more people each of them can piss off. That means a geometrically increasing number of complaints as the player base increases.
Not that I'm not in support of this change; I have a Silver subscription on an Xbox 360 that I got for free, and no intention of purchasing Gold any time soon, so it doesn't really affect me either way. Your post is at best misleading, however.
Ironically, MS is one of relatively few companies that enshrine the concept of the high-level, tremendously experienced individual contributer. I know a guy who has worked for the company since before MS-DOS, and these days works on "whatever he wants" but he's still working on code pretty directly, rather than managing anybody. MS certainly does also hire a lot of young people, but this acquaintance of mine, who is at least in his fifties, says he's definitely not the oldest person there.
Ageism may well exist at MS, but it's not all-pervasive. In fact, when my father comes out of his semi-retirement every few years, he often gets an offer from MS.
You're working with some seriously sub-par developers, then. Or maybe it's just their schools that suck. I'm pretty sure that all three of our relevant classes (web apps, databases, and security) teach how to avoid SQL injection (and XSS, for that matter). If you haven't taken any of those, applying for job as a developer of a public-facing web application that uses a database seems... unwise. It also brings into question just what you've spent the last few years studying that you've never encountered any such classes but haven't found a job doing something completely unrelated to web-apps.
Or perhaps you meant a developer fresh out of *high* school? At 18, I wrote a database web-app for a local startup of 6 people (not a customer-facing site, thankfully). At this time I had not yet started college, had almost no formal training in software development (although I'd informally taught myself programming in various languages over the previous 10 years), had never before written a web-app (two weeks of learning about ASP.NET from a book was all I knew), and had to look up the syntax for a SQL INSERT statement. Surprise surprise, the site was vulnerable to injection.
I returned to the same company the next summer, after taking the first few courses of my computer engineering degree. I still had no formal knowledge of databases, web-apps, or software security. However, somewhere along the line I'd heard about either SQL injection or stored procedures, and the one had led to the other. I spent about a week of that summer re-writing all the queries in that web-app to use parameters. When one of the other employees came to me saying that she was having trouble adding information for a customer named O'Toole, I told her that I had a fixed version already written and that if it passed the tests I was running on a local copy, the update would be deployed at the end of the day.
Shortly thereafter, I was assigned to develop a new (and customer-facing) feature in the next version of our flagship product. Looking back, I didn't implement that feature quite as well as I could have, but I was cautious of security implications and was complimented on a job well done by the senior developer. I've since moved on to bigger internships, advanced courses in things like security, graduation, and a full-time job doing security test. That little (but no longer exactly young) company is still doing well 4 years later.
The problem is twofold. First, every book or website I read from more than about 3 years ago gave example code that was completely vulnerable to injection. To somebody just getting started in the field, you tend to trust in that kind of thing implicitly. Second, the mental separation of data and code is occasionally somewhat blurred, especially in younger developers who may have a few years of experience with some high-level language but never before written any SQL (or encountered a printf or written an evaluation loop interpreter or done any kind of metaprogramming).
Realizing that when you add non-code user input from a web site in between pieces of a hard-coded string in a compiled app, you are giving whoever enters that non-code data the chance to modify executable code... well, it takes a bit of a leap. SQL injection isn't the only such example, XSS (and script injection in general) also suffers the same problem. Since the introductory material completely fails to teach most starters, especially from several years back, anything that will help them prepare for such a leap... are you really surprised that so many people make such a simple mistake? If the example code used parameters, I'd expect much less of that kind of thing, but but when the examples show exactly what you should *not* be doing, I'm not at all surprised that it's a mistake made so often.
I don't recall MS firing any "tech workers" as you put it. I know a few people who were laid off though, and they were all non-engineering support types (sales, marketing, legal, and in fact proabably accounting as well). By comparison, MS has never stopped hiring engineering types, including programmers, and considering how many members of my graduating class got jobs there, it looks like they're still hiring plenty of Americans. He's certainly never claimed that Americans should be losing their jobs, and only a very twisted mind could claim that in seriousness.
MS wants more H1B visas, true, but you're completely misrepresenting the reason. They aren't getting rid of US engineering jobs, they're expanding (even in a down market) faster than they can find qualified Americans to fill those jobs. Blame it on the number of American companies competing for those same people, blame it on the quality of the American education system, blame it on the American societal habit of degrading those who show interest in the STEM fields, or blame it on the fact that American birthrates aren't high enough to keep up with demand for people in these fields. The fact of the matter is that MS (and Google and quite a few of the other tech giants) are hiring a ton of Americans, and paying them very good wages. There just aren't enough qualified Americans to go around.
I suppose you could try and make an argument that MS and companies like it should lower their standards rather than push for importing more workers, but frankly, that would just make you look even less intelligent than that fountain of drivel you attached your name to above.
I tried using HTML5 (via the HTML5 opt-in site, http://youtube.com/html5 ) but it looks like the Khan Academy videos aren't available in HTML5 right now.
You don't even need to re-open the IDE. VS will happily detect when a file has changed on disk (which it is open for editing in VS) and ask if you want to load those changes into your working version. It also offers other nice things like the option of automatically converting all line endings to Windows or Unix style, or leaving them as they are.
There's this thing called a Logical Drive... considering that I use different partitions for Windows boot, Windows system, Windows data, Linux system, Linux profile/data, and Linux swap... I need at least six volumes. Actually, sometimes I triple-boot. Seven volumes, one MBR disk! Yes, it can be done.
Meh, IBM killed OS/2 themselves. Things like insisting that it run on 286 (meaning they had to keep developing 16-bit versions even after it was clear 32-bit was the future) and constantly changing the goalposts regarding features. Mind you, if not for Windows 3.x (the success of the DOS-based version, and the fact that NT had been designed from the ground up in such a way that they could easily switch from the OS/2 API to the Win16/32 APIs) it's entirely possible that MS would have put up with that and continued working on OS/2, and maybe it would have done OK. If so, though, it wouldn't have thanks to any effort on IBM's part. MS dropped out of the OS/2 "partnership" because they already had an OS that was better than the result of working for IBM would have produced.
I don't read PA regularly, but I'm going to have to ask for a citation of your claim that they are anti-used-game-sales. That's not something I've ever noticed them taking a stance on directly, but if anything I'd expect them to support it.
We'll have to wait and see what happens with it, but your post really isn't complete without mentioning Windows Phone 7. I like some of what I've seen and heard, and I don't like other things, but I can tell you this much: it's completely different from WinMo, both in the user interface and the development experience. I can see MS dropping the WinCE kernel - in fact, I'm surprised they haven't yet; it seems like porting NT would have been at worst no harder than updating CE enough to build WinPhone7 on top of it, and some of that work would have been useful in other ways too (for example, if MS wanted to develop a desktop version of Windows for ARM-based net[books|tops]). However, I think it's a lot more likely that MS will implicitly support Android development in.NET (Visual Studio is quite pluggable, so it's not like it would be hard for anybody to create a Mono/Android development environment that runs on VS) than it is that they will explicitly embrace Android in their own product lines.
That said, since WinPhone7 does use C# (with Silverlight or XNA) and the dev tools are already based on Visual Studio, I think it's fair to say that if you're developing mobile apps on VS MS would prefer that it be for their platform.
Well, for starters, there's this little issue of security. Typesafe managed code does not, and never will (no matter how badly you write it) suffer from buffer overflows, use-after-free, double free, format string vulnerabilities, or any of a large set of other common bugs. It is possible that a bug will be found in the runtime, but in that case MS (or Sun/Oracle, in Java's case) can simply issue a patch and it fixes things, with effectively no risk of introducing incompatibilities.
Implementing concurrency is another issue. It's certainly possible to get your synchronization right in C, but it's *easier* in managed languages with native support for monitors. Given how prevalent multi-core systems are these days, you can easily make up the entire performance hit of managed code, and then some, by leveraging the incredible ease of writing multi-threaded code in managed languages.
Then there's the fact that developer time is expensive. Creating equivalent programs in C and in Java or C# usually takes longer in C, and testing them (including security testing, see first point) takes *much* longer. That's a lot mroe developer salaries to pay, and it also increases your time to market, both of which will generally have a negative impact on the bottom line. Corporations aren't exactly fond of wasting money.
Object-oriented code is damn handy too. I'm somewhat surprised you picked C instead of C++; with C++ you'd at least have inheritance and objects that implicitly call their destructors when they go out of scope. Then there's the convenience of generics, although I suppose a C coder might not quite understand their awesomeness. It's not like C is a type-safe language to begin with...
Finally, there's the write once, run anywhere deal, and the issue of libraries. GTK solves a lot of the problems for both of these areas, but you still have to be careful to avoid doing things in a platform-dependent way in C; in Java or C# you have to explicitly try to make your program platform-dependent. GTK has great library code, and there's tons of other C libraries, but at the end of the day.NET and Java are generally going to all the libraries you need, and with the advantage of namespaces it's also a lot easier to keep track of them all.
I'm amused (and saddened by the fact that you appear to take yourself seriously) that you talk about how much Linux (and Windows) have advanced in one sentence, then talk about how much work you had to do on a 9-year-old version of Windows two sentences later! The fact that such blatant hypocrisy reaches +5 on/. is really annoying, sometimes.
The rest of your post is generally accurate, although an out-of-the-box Linux install is most likely still going to have more driver troubles than an out-of-the-box Windows install of the same release cycle (i.e. not XP, unless you want me to go dig up a copy of RHEL 2.1 to compare it against). Your claim about TV viewing is particularly silly for two reasons. First of all, custom-built distros aside it's far, far harder to get TV working well on Linux than it is on Windows. I've tried setting up MythTV, because it sounded cool and I wanted to compare it to Windows Media Center. Unfortunately, the process of just getting to the point of having an executable I could run took longer than the entire WMC setup (which is roughly 5 minutes). Normally, installing software on Linux is easy, but that was *not* my experience in this case.
Then, there's that driver issue. The last two laptops I've bought have TV tuner cards. I didn't buy them for that features; it was simply included and I wasn't going to turn down an already excellent deal on that basis. In both cases, Windows could find drivers for the cards quickly, and WMC would use them with no fuss. Neither one works at all under Linux, though. There's an incomplete port for the general family of one, but it doesn't work on my particular card and it requires downloading tarballs, applying patches, building, and loading a kernel module to even get to the point where it will claim to handle the hardware (although it still fails to actually work). These are AVerMedia cards, not exactly some obscure, unknown brand. Things are definitely improving, for example a few years ago wifi and webcams were both in similarly bad states of support (some worked great, some had to be coaxed, and some flat-out failed to work). These days, most don't even need coaxing anymore and for the rest, it's possible with a little effort. Seriously though, TV tuner support under Linux is not exactly something one should be highlighting as a strength right now.
, plus about 30 for the complete OS install and any extra drivers or updates to download
I don't exactly see how things like IronPython, which MS has most certainly contributed to, are "their own version... very much unlike open source" at all. The source code is available to those who want it, you can fork it if you want, it's not tied to MS in any inextricable way, and the license is now Apache v2.0, which is about as open as it gets (not that the MS Public License, also OSI approved, is much more restrictive).
There are other examples, but that one kind of stands out. It's obviously beneficial to MS, but IronPython also runs quite well on Mono, which is typically used on non-MS platforms.
Yes, yes, we've accomplished impressive things when you consider what we had to work with. That doesn't mean that we should pointlessly cripple our capabilities. The fact that we haven't accomplished more is because there are laws artifically restricting what is available to work with. Repeal or change those laws, and you'll see a great increase in "big advances" that will quickly overcome those those that are based on a needlessly difficulat starting material (partially differentiated cells).
Your post implies that both options - embryonic and non-embryonic stem cell lines - were given equal chances to produce those research advances. That is blatantly false, and I sincerely question the moral quality of somebody who would use that as an argument without explicitly acknowledging the circumstances that made what you said (as opposed to what you implied) true.
A vulnerability in a graphics-decoding library used by IE is a local exploit, but it can be used by remote attacks who embed a malicious image in a website or email. That would meet exactly the description you gave, for the way that MS words their patch notes.
Just because a vulnerability is local doesn't mean it can't be triggered remotely. It simply means that something needs to be done on the local machine - such as visiting a web page, reading an email, or running a supposedly safe command - for an exploit to occur. True remote vulnerabilities are also still found on rare occasion, but they've become extremely uncommon; external interfaces are subject to extremely heavy testing these days.
And now they've been (mostly) moved back into user-land. That's one of the things that makes the video driver interface in Vista and up so different, and is what makes it possible for the OS to recover a crashed video driver without it bringing down the whole OS (though the game might crash).
There's still a little bit of kernel-mode code, to handle things like DMA and actually writing to the GPU registers; userland Windows code still can't access the hardware directly. However, all of the actual video driver processing, the complex operations that are likely to cause crashes, were moved into userland. It does cost a little bit of performance loss (less than 5%) due to ring-level switches, but that's a fairly small price to pay for stability.
He's a troll, but that doesn't mean that there isn't a grain of truth to what he implies. Most Windows exploits are also technically local attacks, as are Trojans (by definition). Somebody thinking that they're safe (because the software runs with limited permissions) would be in for a nasty surprise if an attacker exploited this.
Even the safest APIs can be used stupidly. If the library code is correct but people are calling it in an unsafe manner, there's not a lot that can be done about that. Making changes to library code also requires an immense amount of regression testing. Some programs may be using an API unsafely, but in a non-attacker-controllable manner; those programs may technically have bugs but they run correctly (and securely) now, and if the library code were changed to prevent whatever they're doing those programs would break down.
Default posting mode for a new account is HTML, which ignores most whitespace (converts any amount of any type of whitespace into a single space, more precisely). You can either manually insert <p></p> or <br/> tags, or you can switch to Plain Old Text posting method. POT method still lets you embed HTML, but it will also auto-convert new lines in your comment "source" to new lines in the result that gets posted.
Slashdot Mirror
Quicktime installs a handful of additional (and unnecessary) stuff. In particular, it includes an IE plug-in that not only enables viewing of Quicktime movies in the browser but also replaces handling of other media formats, including JPEG rendering. This increases the browser footprint and slows it down noticeably, or at least it did the last time I installed Quicktime (a couple years ago). Also, I'm not entirely sure if it's Quicktime or iTunes that installs Bonjour, but that definitely falls into the category of stuff I don't want a media player installing and enabling without my express consent.
The IE plug-in can be disabled using IE's add-in manager. I don't know whether Quicktime installs a Firefox plug-in as well, or not. If it does, the odds are that it is also exploitable. If not, you're probably fine unless you download the file and open it directly.
Apparently you are the one who does not understand. DEP and ASLR are features provided by the OS, but they are *NOT* universally backward-compatible features. Some apps will break if DEP is enabled. Some libraries will break if ASLR is enabled. ASLR is new enough that it's still not uncommon to find libraries which weren't coded with it in mind.
As for "not properly implementing security the features available" you *really* should take the foot out of your mouth before you choke on it. For one thing, any application running as Admin (including most software installers) can opt out of firewall (turn it off or add an exemption; *lots* of apps or their installers do this), opt out of virus scan (non-trivial, but they could add themselves to the allowed files list or simply turn off the scanner), or opt out of permissions (change the ACLs to world-writable). Of course, this assumes that you're talking about software already executing on the computer. Once you're to this point; DEP and ASLR are irrelevant; their only purpose is to try and prevent exploits and they can do nothing once the malicious code begins to execute.
However, "hackers" still have to find a vulnerability in the program that they are trying to execute. A firewall only protects network interfaces; if the software is properly secured it can't be compromised no matter what comes over the connection. A virus scanner only detects malicious software on the system; if there are no exploitable programs then the attacker has no way to get malicious software onto the computer in the first place (aside from social engineering, but you can't fix stupid). Permissions can limit the damage that malware or a compromised program does, but again if there's no way to compromise any programs that doesn't matter (and most XP users run as Admin anyhow).
If the Quicktime developers hadn't left this problem in their code, there would be no problem at all.
Malware implies code already executing on your machine. By the time you get that far, DEP and ASLR are already bypassed; their purpose is to prevent the execution of such code in the first place. There are other things one can do to mitigate the damage, such as limited permissions and sandboxing, but you're comparing apples to oranges here. DEP and ASLR make exploits more difficult. Malware is something that exploits (or stupid users) install. Malware could quite happily opt in to DEP and ASLR; it wouldn't change anything.
However, non-malicious software developers can choose to opt-in to these features in order to provide an extra layer of security against exploits. That's what DEP and ASLR are: extra layers of security, neither an absolute barrier to attack nor a "keystone of the OS Security" as you put it. They just make successful exploits much more difficult. The principle is called Defense in Depth, and if you know anything about security of any kind you'll be familiar with the notion.
As for why they're opt-in rather than opt-out (or unavoidable) the problem is that they are not completely non-breaking changes to the OS behavior. Some applications will crash or otherwise fail to work if they are run with DEP, or their libraries are loaded with ASLR. Those programs and libraries are poorly written by modern standards, but then again, if they'd been written correctly in the first place DEP and ASLR would be irrelevant because they wouldn't have security vulnerabilities in the first place.
More to the point, this attack uses ROP (which, as you say, defeats DEP) but it does it using bits fo code, called "gadgets", that are part of a library which is loaded without ASLR. Even though the browser itself is using ASLR, some of its libraries will be loaded at known locations, which is what makes this attack work. That's not exactly defeating ASLR so much as it is taking advantage of the fact that it isn't universally used yet, kind of like the way some legacy programs aren't DEP-compatible.
For the time being, ASLR is only opt-in; if a library doesn't mark itself as ASLR-compatible, the loader will put it at its preferred base address. Or at least, it will try to. The fact is that dynamically linked libraries can never guarantee that their preferred address range is available, and therefore should never assume that they are at a given location in memory. In fact, most of them don't... but they still don't have the opt-in flag, either because they're old or because the developer didn't set it. I wonder how hard it would be to simply *force* ASLR by telling each library, as it loads, that its preferred address is simply unavailable and it's going to be stuck someplace else...
"20% inflation" implies that they raise the cost like this every year. They don't. They raised the price from its 2002 point.
Inflation figures according to http://data.bls.gov/cgi-bin/cpicalc.pl
$50 in 2002 = $60.59 in 2010.
Also, economies of scale don't necessarily apply. For example, moderation of the player base requires a number if people in direct proportion to the player base, and maybe even a little worse - the more players are, not only the more problem people you have but the more people each of them can piss off. That means a geometrically increasing number of complaints as the player base increases.
Not that I'm not in support of this change; I have a Silver subscription on an Xbox 360 that I got for free, and no intention of purchasing Gold any time soon, so it doesn't really affect me either way. Your post is at best misleading, however.
Ironically, MS is one of relatively few companies that enshrine the concept of the high-level, tremendously experienced individual contributer. I know a guy who has worked for the company since before MS-DOS, and these days works on "whatever he wants" but he's still working on code pretty directly, rather than managing anybody. MS certainly does also hire a lot of young people, but this acquaintance of mine, who is at least in his fifties, says he's definitely not the oldest person there.
Ageism may well exist at MS, but it's not all-pervasive. In fact, when my father comes out of his semi-retirement every few years, he often gets an offer from MS.
You're working with some seriously sub-par developers, then. Or maybe it's just their schools that suck. I'm pretty sure that all three of our relevant classes (web apps, databases, and security) teach how to avoid SQL injection (and XSS, for that matter). If you haven't taken any of those, applying for job as a developer of a public-facing web application that uses a database seems... unwise. It also brings into question just what you've spent the last few years studying that you've never encountered any such classes but haven't found a job doing something completely unrelated to web-apps.
Or perhaps you meant a developer fresh out of *high* school? At 18, I wrote a database web-app for a local startup of 6 people (not a customer-facing site, thankfully). At this time I had not yet started college, had almost no formal training in software development (although I'd informally taught myself programming in various languages over the previous 10 years), had never before written a web-app (two weeks of learning about ASP.NET from a book was all I knew), and had to look up the syntax for a SQL INSERT statement. Surprise surprise, the site was vulnerable to injection.
I returned to the same company the next summer, after taking the first few courses of my computer engineering degree. I still had no formal knowledge of databases, web-apps, or software security. However, somewhere along the line I'd heard about either SQL injection or stored procedures, and the one had led to the other. I spent about a week of that summer re-writing all the queries in that web-app to use parameters. When one of the other employees came to me saying that she was having trouble adding information for a customer named O'Toole, I told her that I had a fixed version already written and that if it passed the tests I was running on a local copy, the update would be deployed at the end of the day.
Shortly thereafter, I was assigned to develop a new (and customer-facing) feature in the next version of our flagship product. Looking back, I didn't implement that feature quite as well as I could have, but I was cautious of security implications and was complimented on a job well done by the senior developer. I've since moved on to bigger internships, advanced courses in things like security, graduation, and a full-time job doing security test. That little (but no longer exactly young) company is still doing well 4 years later.
The problem is twofold. First, every book or website I read from more than about 3 years ago gave example code that was completely vulnerable to injection. To somebody just getting started in the field, you tend to trust in that kind of thing implicitly. Second, the mental separation of data and code is occasionally somewhat blurred, especially in younger developers who may have a few years of experience with some high-level language but never before written any SQL (or encountered a printf or written an evaluation loop interpreter or done any kind of metaprogramming).
Realizing that when you add non-code user input from a web site in between pieces of a hard-coded string in a compiled app, you are giving whoever enters that non-code data the chance to modify executable code... well, it takes a bit of a leap. SQL injection isn't the only such example, XSS (and script injection in general) also suffers the same problem. Since the introductory material completely fails to teach most starters, especially from several years back, anything that will help them prepare for such a leap... are you really surprised that so many people make such a simple mistake? If the example code used parameters, I'd expect much less of that kind of thing, but but when the examples show exactly what you should *not* be doing, I'm not at all surprised that it's a mistake made so often.
I don't recall MS firing any "tech workers" as you put it. I know a few people who were laid off though, and they were all non-engineering support types (sales, marketing, legal, and in fact proabably accounting as well). By comparison, MS has never stopped hiring engineering types, including programmers, and considering how many members of my graduating class got jobs there, it looks like they're still hiring plenty of Americans. He's certainly never claimed that Americans should be losing their jobs, and only a very twisted mind could claim that in seriousness.
MS wants more H1B visas, true, but you're completely misrepresenting the reason. They aren't getting rid of US engineering jobs, they're expanding (even in a down market) faster than they can find qualified Americans to fill those jobs. Blame it on the number of American companies competing for those same people, blame it on the quality of the American education system, blame it on the American societal habit of degrading those who show interest in the STEM fields, or blame it on the fact that American birthrates aren't high enough to keep up with demand for people in these fields. The fact of the matter is that MS (and Google and quite a few of the other tech giants) are hiring a ton of Americans, and paying them very good wages. There just aren't enough qualified Americans to go around.
I suppose you could try and make an argument that MS and companies like it should lower their standards rather than push for importing more workers, but frankly, that would just make you look even less intelligent than that fountain of drivel you attached your name to above.
I tried using HTML5 (via the HTML5 opt-in site, http://youtube.com/html5 ) but it looks like the Khan Academy videos aren't available in HTML5 right now.
You don't even need to re-open the IDE. VS will happily detect when a file has changed on disk (which it is open for editing in VS) and ask if you want to load those changes into your working version. It also offers other nice things like the option of automatically converting all line endings to Windows or Unix style, or leaving them as they are.
There's this thing called a Logical Drive... considering that I use different partitions for Windows boot, Windows system, Windows data, Linux system, Linux profile/data, and Linux swap... I need at least six volumes. Actually, sometimes I triple-boot. Seven volumes, one MBR disk! Yes, it can be done.
Meh, IBM killed OS/2 themselves. Things like insisting that it run on 286 (meaning they had to keep developing 16-bit versions even after it was clear 32-bit was the future) and constantly changing the goalposts regarding features. Mind you, if not for Windows 3.x (the success of the DOS-based version, and the fact that NT had been designed from the ground up in such a way that they could easily switch from the OS/2 API to the Win16/32 APIs) it's entirely possible that MS would have put up with that and continued working on OS/2, and maybe it would have done OK. If so, though, it wouldn't have thanks to any effort on IBM's part. MS dropped out of the OS/2 "partnership" because they already had an OS that was better than the result of working for IBM would have produced.
I don't read PA regularly, but I'm going to have to ask for a citation of your claim that they are anti-used-game-sales. That's not something I've ever noticed them taking a stance on directly, but if anything I'd expect them to support it.
So... link please?
We'll have to wait and see what happens with it, but your post really isn't complete without mentioning Windows Phone 7. I like some of what I've seen and heard, and I don't like other things, but I can tell you this much: it's completely different from WinMo, both in the user interface and the development experience. I can see MS dropping the WinCE kernel - in fact, I'm surprised they haven't yet; it seems like porting NT would have been at worst no harder than updating CE enough to build WinPhone7 on top of it, and some of that work would have been useful in other ways too (for example, if MS wanted to develop a desktop version of Windows for ARM-based net[books|tops]). However, I think it's a lot more likely that MS will implicitly support Android development in .NET (Visual Studio is quite pluggable, so it's not like it would be hard for anybody to create a Mono/Android development environment that runs on VS) than it is that they will explicitly embrace Android in their own product lines.
That said, since WinPhone7 does use C# (with Silverlight or XNA) and the dev tools are already based on Visual Studio, I think it's fair to say that if you're developing mobile apps on VS MS would prefer that it be for their platform.
Well, for starters, there's this little issue of security. Typesafe managed code does not, and never will (no matter how badly you write it) suffer from buffer overflows, use-after-free, double free, format string vulnerabilities, or any of a large set of other common bugs. It is possible that a bug will be found in the runtime, but in that case MS (or Sun/Oracle, in Java's case) can simply issue a patch and it fixes things, with effectively no risk of introducing incompatibilities.
Implementing concurrency is another issue. It's certainly possible to get your synchronization right in C, but it's *easier* in managed languages with native support for monitors. Given how prevalent multi-core systems are these days, you can easily make up the entire performance hit of managed code, and then some, by leveraging the incredible ease of writing multi-threaded code in managed languages.
Then there's the fact that developer time is expensive. Creating equivalent programs in C and in Java or C# usually takes longer in C, and testing them (including security testing, see first point) takes *much* longer. That's a lot mroe developer salaries to pay, and it also increases your time to market, both of which will generally have a negative impact on the bottom line. Corporations aren't exactly fond of wasting money.
Object-oriented code is damn handy too. I'm somewhat surprised you picked C instead of C++; with C++ you'd at least have inheritance and objects that implicitly call their destructors when they go out of scope. Then there's the convenience of generics, although I suppose a C coder might not quite understand their awesomeness. It's not like C is a type-safe language to begin with...
Finally, there's the write once, run anywhere deal, and the issue of libraries. GTK solves a lot of the problems for both of these areas, but you still have to be careful to avoid doing things in a platform-dependent way in C; in Java or C# you have to explicitly try to make your program platform-dependent. GTK has great library code, and there's tons of other C libraries, but at the end of the day .NET and Java are generally going to all the libraries you need, and with the advantage of namespaces it's also a lot easier to keep track of them all.
I'm amused (and saddened by the fact that you appear to take yourself seriously) that you talk about how much Linux (and Windows) have advanced in one sentence, then talk about how much work you had to do on a 9-year-old version of Windows two sentences later! The fact that such blatant hypocrisy reaches +5 on /. is really annoying, sometimes.
The rest of your post is generally accurate, although an out-of-the-box Linux install is most likely still going to have more driver troubles than an out-of-the-box Windows install of the same release cycle (i.e. not XP, unless you want me to go dig up a copy of RHEL 2.1 to compare it against). Your claim about TV viewing is particularly silly for two reasons. First of all, custom-built distros aside it's far, far harder to get TV working well on Linux than it is on Windows. I've tried setting up MythTV, because it sounded cool and I wanted to compare it to Windows Media Center. Unfortunately, the process of just getting to the point of having an executable I could run took longer than the entire WMC setup (which is roughly 5 minutes). Normally, installing software on Linux is easy, but that was *not* my experience in this case.
Then, there's that driver issue. The last two laptops I've bought have TV tuner cards. I didn't buy them for that features; it was simply included and I wasn't going to turn down an already excellent deal on that basis. In both cases, Windows could find drivers for the cards quickly, and WMC would use them with no fuss. Neither one works at all under Linux, though. There's an incomplete port for the general family of one, but it doesn't work on my particular card and it requires downloading tarballs, applying patches, building, and loading a kernel module to even get to the point where it will claim to handle the hardware (although it still fails to actually work). These are AVerMedia cards, not exactly some obscure, unknown brand. Things are definitely improving, for example a few years ago wifi and webcams were both in similarly bad states of support (some worked great, some had to be coaxed, and some flat-out failed to work). These days, most don't even need coaxing anymore and for the rest, it's possible with a little effort. Seriously though, TV tuner support under Linux is not exactly something one should be highlighting as a strength right now.
, plus about 30 for the complete OS install and any extra drivers or updates to download
I don't exactly see how things like IronPython, which MS has most certainly contributed to, are "their own version... very much unlike open source" at all. The source code is available to those who want it, you can fork it if you want, it's not tied to MS in any inextricable way, and the license is now Apache v2.0, which is about as open as it gets (not that the MS Public License, also OSI approved, is much more restrictive).
There are other examples, but that one kind of stands out. It's obviously beneficial to MS, but IronPython also runs quite well on Mono, which is typically used on non-MS platforms.
Yes, yes, we've accomplished impressive things when you consider what we had to work with. That doesn't mean that we should pointlessly cripple our capabilities. The fact that we haven't accomplished more is because there are laws artifically restricting what is available to work with. Repeal or change those laws, and you'll see a great increase in "big advances" that will quickly overcome those those that are based on a needlessly difficulat starting material (partially differentiated cells).
Your post implies that both options - embryonic and non-embryonic stem cell lines - were given equal chances to produce those research advances. That is blatantly false, and I sincerely question the moral quality of somebody who would use that as an argument without explicitly acknowledging the circumstances that made what you said (as opposed to what you implied) true.
A vulnerability in a graphics-decoding library used by IE is a local exploit, but it can be used by remote attacks who embed a malicious image in a website or email. That would meet exactly the description you gave, for the way that MS words their patch notes.
Just because a vulnerability is local doesn't mean it can't be triggered remotely. It simply means that something needs to be done on the local machine - such as visiting a web page, reading an email, or running a supposedly safe command - for an exploit to occur. True remote vulnerabilities are also still found on rare occasion, but they've become extremely uncommon; external interfaces are subject to extremely heavy testing these days.
And now they've been (mostly) moved back into user-land. That's one of the things that makes the video driver interface in Vista and up so different, and is what makes it possible for the OS to recover a crashed video driver without it bringing down the whole OS (though the game might crash).
There's still a little bit of kernel-mode code, to handle things like DMA and actually writing to the GPU registers; userland Windows code still can't access the hardware directly. However, all of the actual video driver processing, the complex operations that are likely to cause crashes, were moved into userland. It does cost a little bit of performance loss (less than 5%) due to ring-level switches, but that's a fairly small price to pay for stability.
He's a troll, but that doesn't mean that there isn't a grain of truth to what he implies. Most Windows exploits are also technically local attacks, as are Trojans (by definition). Somebody thinking that they're safe (because the software runs with limited permissions) would be in for a nasty surprise if an attacker exploited this.
Even the safest APIs can be used stupidly. If the library code is correct but people are calling it in an unsafe manner, there's not a lot that can be done about that. Making changes to library code also requires an immense amount of regression testing. Some programs may be using an API unsafely, but in a non-attacker-controllable manner; those programs may technically have bugs but they run correctly (and securely) now, and if the library code were changed to prevent whatever they're doing those programs would break down.
Why question what they'll support in the future when you can see the support today? http://ie.microsoft.com/testdrive/Default.html Looks like their HTML5 is pretty damn good.
Default posting mode for a new account is HTML, which ignores most whitespace (converts any amount of any type of whitespace into a single space, more precisely). You can either manually insert <p></p> or <br /> tags, or you can switch to Plain Old Text posting method. POT method still lets you embed HTML, but it will also auto-convert new lines in your comment "source" to new lines in the result that gets posted.
Also, always preview before posting.