Programming, yes, but computer science doesn't use C++.
Bull. At least sort of.
First, it depends in part on what your definition of computer science is. Most CS courses are taught in a C-like languages. At my undergrad institution, most of my programming assignments were done with C++. Sure, there was exposure to ML, but my impression is that most places that's mostly confined to the PL classes. (There are some notible exceptions that use ML or Scheme for intro courses.) Even at those institutions, I expect that later classes have assignments in a C-like language.
Second, there's a lot of CS that relates to C++. Compiler theory of how you implement things about it, and language design. It's not about C++ specifically, but it certainly relates.
Third, there is a fair bit of work in PL that directly relates. Not all PL is people in ivory towers coding in ML and Lisp. CCured is a very nice bit of work, though it's only C because it's built on top of the C Intermediate Language (CIL). There's early work now to create a CIL++, and I'm sure that it hasn't escaped anyone there about the potential to extend CCured to C++ once that's done. The parser for CIL++ will be something called Elsa, which was a major part of the research of one of the people there. My own research is indirectly related even. I'm looking at static analysis of binary code. Earlier work done in my group was explicitly directed to being able to find vtable pointers that C++ compilers produce.
You're right to the extent that the core of CS is really in some sense applied math, and is entirely language-neutral. However, to say that C++ has no relation to CS because it's just programming (which CS isn't about) is just wrong.
you'll probably have to be told that a "zero-day exploit" has nothing to do with severity -- it means that working exploit code was released on the same day as the vulnerability was announced.
Theoretically, a zero-day exploit is one that can be executed *right now*, before there's a chance to patch. However, considering that the advisory says it's "potentially exploitable" even though it was published some 16 days ago seems to be stretching the definition of "zero." The blog MS linked to was alarmist, and/. is downright defamatory.
That sounds to me like something could *potentially* happen, but they haven't been able to actually prove it yet. And, the date on this discovery (according to the source article) was over two weeks ago. By now, wouldn't they have concluded something with their research?
No... not at all. They're just very liberal with their definition of "zero-day"...
I'm not saying that something like this isn't exploitable, I'm just saying that the chance is extremely low.
For your plan to work: 1. The following memory would likely have to be deallocated (this depends on the malloc implementation, but assuming that it keeps track of a free list, the block that you corrupt would have to be deallocated before that address was used for anything), so the following would have to be done at the first allocation following this deallocation 2. You would have to be able to determine a valid stack address to make it point to 3. The buffer it allocates would have to be for unchecked/mischecked user input and not just internal storage that you don't have control over 4. You would have to know when you were able to write to it
Stranger things have happened in security, that's for sure, but the chances there are pretty out there.
(Furthermore, the MSVC malloc block header would have to be amenable to this attack, which it might not be.)
This is a heap buffer, assuming TFA's right. What programs execute instructions from the heap and so have the potential to be overwritten by a jump?
At absolute worst, you could do what at least one paper calls a non-control-data attack and corrupt some other piece of data that was next to it in the heap. Except every malloc implementation I know puts a header struct at the beginning of each block, so even if two pieces of heap data ended next to each other you wouldn't be able to reach the actual data with just a 4 byte overflow, and the best you could hope for is to corrupt the header. This is very unlikely to have any exploitable effects, and is just likely to kill the process.
It's a heap buffer (assuming TFA is right), which means the return address will be nowhere near it. There *could* still be neighboring security-sensitive code, but it's extremely unlikely. Worst case that's remotely likely would be that you corrupt the header that markes the beginning of the next heap block and wreak havoc with future malloc calls. Probably nothing controllable though. This *really* isn't that big of a deal, and calling it a zero-day exploit is downright libel.
Um, depending on what's in the data you overflow into, there's still *potentially* plenty you can do. (They're all very unlikely, but the potential is there.) There's other security-sensitive data besides the return address, and other buffer overflow exploits than overwriting that to jump into malicious code.
That stuff sounds kinda neat, but after reading the SLAM summary paper, it looks pretty similar to the Stanford Checker extensions to gcc, which eventually turned into Coverity. Seems like there are some differences: I don't think that the Checker has to do the rewrite to the Boolean language thing, but the whole idea of rules like "match lock with unlock" seems analagous. Recent Linux kernels have featured some reasonably neat gcc stuff that warns if you don't check return codes and the like.
It's similar in spirit, but not in execution. xgcc is intended to be a bug-hunting tool, while SLAM does verification. They're somewhat the same, but subtley different. If the Static Driver Verifier reports a violation of a rule, it's guaranteed to be an actual, executable path. Up to their assumptions about the system (notably I'm not sure if it handles concurrency, but then again neither does xgcc to my knowledge), if the SDV says that a driver is free of violations of a rule, the driver is guaranteed to be free of such violations. The catch is that SDV is not guaranteed to terminate. [I'm pretty sure about everything I said here, but not 100% positive.] Neither of the above is true of xgcc; violations that xgcc reports may be false postives, and xgcc misses violations. On the other hand, you're guaranteed to get a result, and if the output is useful, it has served its purpose.
So you're right that they're similar, but they try to tackle the problem of poor software quality in different ways. (In my mind, the Coverity approach of being a bug hunter is probably more applicable to application programs, while the SDV approach of trying to prove drivers free of the bugs they look for is more applicable to drivers, so they both seem to be in their niche.) And the methods that each use are, as far as I know, entirely different.
(I'm also not sure when they got started with that; the paper I read on it was from 2002, after SLAM got started. It looks like Engler has some other papers on related work going back to '97 though.)
You probably should have replied to the moderated-down item.
I did reply to the moderated down item! Here's the discussion tree: 1."research", MECC, 5:01 pm -- "Does that include Zune?..." 2....Re: "research", EvanED, 5:38pm -- "That's not MSR...." 3.......Re: "research", EvanED, 5:55pm -- "Ah,/...." 4.........."Huh?", spitzak, 11:21pm -- "The above comment..."
I've numbered the posts 1-4. When I posted #3, #2 was at +1, flamebait. (With two flamebait mods and one informative, plus my karma bonus.) It's only after that point that #2's score went up.
Since Zune is a major product, this statement does mean that the Zune contains something made by the Research department, unless it is "virtually no product". Thus the initial post is questioning the accuracy of this statement.
Okay, now that you word it this way, I think I see what you and the initial post were talking about. The way I interpreted it (especially with the "flame on" ending) was that he was saying "MSR contributed to the Zune and music service... wow, what innovation out of MSR </sarcasm>." I read it as a criticism of MSR of the sort that the article was saying was unfounded, not questioning the article. In this I now see I very well may have been mistaken.
(However, even if it was, it's very possible for MSR to contribute to either product, and I sorta suspect that it's not MSR who produced the idea. The poster said "How much research did it take to come up with 'We need to make our own iPod and music service'?" but that wouldn't have been what MSR did in all likelyhood.)
So I back off of what I said about the OP being troll, etc.
Moderated-up replies to stuff that is moderated down appears to migrate up to be a response to the above. Again this can make the responder look like an idiot by reversing what they are replying to. In addition it hides exactly what they are responding to.
I know what you're talking about, and I think that the solution of displaying parents of moderated-up comments is a good idea. (I don't think that they should be moderated up themselves though if that's what you meant; like if they'd be -1, flamebait now, I think they should be -1 flamebait with the fix; just that if there's a +3 reply to them the -1 post should be visible if the threshold shows the +3.)
Why did you choose pick your plan if you rarely use your phone? Pick your plan is "$x/month for up to y minutes"; what did you think you were getting into?
How can you call what I'm saying blatantly false?
Because your comment was false. You shouldn't have said "avoid cingular because they'll bill you $50/month whether you use it or not"; you should have said "avoid Cingular because if you choose the $50/month plan they'll bill you $50/month."
Now if there's something I'm still missing, like you asked for a different plan than you're being billed for, you should have just said that...
The only result of what you listed here is more stuff to wipe my ass with.
And hopefully more stable drivers in the near future.;-)
But they are playing catch-up to... Java with.NET
I don't buy this..Net's weakness is its platform specificity. If it was platform independent, including GUI toolkit, I'd take.Net over Java in a second for almost any program where I had to choose between those two languages. (Yeah, I know.Net isn't a language. C# or C++.Net or a combination. You get my point. And yeah, there's Mono, but they're behind on the GUI front (though catching up), and there's patent worries and such. It's not equal support like Java has.)
#include your rant about how pure research furthers the field and applied research is for moneygrubbing opportunists
Well, the first part is certainly true, but to be honest, I don't think that applied research is for opportunists. Some of my favorite research has very deeply immediately applicable results. (The best has a great mix of applied stuff and theory. CCured would be an example of this, though it's less applicable than some other possible examples.)
With over 20% of the DOCTORAL CANDIDATES, I would expect them to publish more good research than EVERY university.
Well, there are a few things at work that might conspire against this. First, remember that that 20% is just during the summer; 3/4 of the year they're back at universities. Of course, MSR also has a fair number of full-time employees. Second, even if you have the research to support it, I suspect it's difficult to get more than a paper or two from any given institution into some conference. Third, there's some reason to suspect that people at MSR are less eager to publish than those at universities. Grad students are eager because you need publications for a job, new faculty are eager because they need publications to get tenure, middle-aged faculty are eager because they need publications to get promoted. I'm sure there's still a lot of pressure in an industry lab, but I suspect it's less. I could be wrong about that though, I haven't experienced an industry research lab.
And finally, you shouldn't have posted AC, that's a good post. You deserve the insightful mod.;-)
I agree with most of what you said. The thing was that I was trying to defend MSR from the perception that -- unfairly -- carries over from MS Corporate about innovation. I *do* think that the perception of MS Corporate taints the perception of MSR even among people who have heard of it (as you said in the bold parts), and I do think that the taint is quite unfair when it comes to the topic at hand, innovation (which you left unanswered as to your opinion).
The problem with MSR from an outsider's perspective is that they seem to be pretty poor at translating research that goes on to products that Corporate can use. There are some exceptions to this, like the SLAM project resulting in the Static Driver Verifier, which is distributed as part of the Windows Driver Framework. And who knows, maybe in VS 2007 or 2009 you'll see results of the work with Vulcan, recording traces, and time-traveling debugging. (I for one would kill someone for that code now. Actually, on a personal note, I'm sorta miffed about this one... they scooped me by about a year. I was trying to come up with a research project for a software engineering class, read about the Java Omniscient Debugger, and thought "hey, that would be great to do for binaries" (some of my other work involves analysis of binaries so I was in that mindset), and actually did a fair bit of related work research before finding the MSR paper. And it was only released in April of this year for a conference in the Summer I think... if they had waited another year, that'd have been my project.;-)) But back to the subject at hand, I don't really know what MSR contributes to Corporate. They've got a bunch of UI researchers... but they don't seem to be using them all that much.
Maybe there is a lot of transfer going on behind the scenes, but I don't see it.
As the author of both the post you're responding to (about/.'s bias) and the post above it (the one that lists those three inventions and their papers and uses), I'd say it's you who need to read more carefully. (Though in part it's a misunderstanding because of differences in moderation states between when I wrote the second post and when you read it.) My original post (talking about SLAM, Singularity, and Vulcan) *WAS* supportive of MSR. That's the point. The post above me (still at 5) is a very cynical "How much research did it take to come up with 'We need to make our own iPod and music service'?", which is out of MS Corporate and not MSR, and so is either off topic, flamebait, troll, or, in the best case, just wrong.
At the time I began the reply about MSR's contributions, the post I was responding to was I think at +3. By the time I was done, it was at +5. If you look at its moderation history, it has 30% interesting and 70% insightful. My first moderation on the post defending MSR was flamebait. The second moderation was informative. The third was another flamebait. *This* is what spurred the comment on/.'s bias. It was only later that the comment on MSR was modded up to +5.
Where did it start? The story I heard from one of my profs was that a couple interns really started the project in 2000 at MSR. They then went back to Berkeley and wanted to continue the work, and split off the BLAST project as somewhat of a fork.
Looking at the earliest SLAM paper listed, from 2000, seems to confirm this. The authors are listed as being from MSR, and there's nothing like "continuing our earlier work..." that I noticed. In fact, the only paper cited by either of the two authors is an MSR Tech Report from earlier that year.
I only briefly read the paper but testng with "drivers" and "stubs" is covered in a 500 level SW Testing course in the university I attended.
What sort of "testing"?
SLAM isn't testing from a SE term point of view; it's static analysis. None of the driver code is being actually executed. Instead the SLAM engine is exploring all possible execution paths through symbolic execution (translation of the programs to binary decision diagrams) and something called counterexample guided abstraction refinement. Such a problem of course is undecidable in general, and in practice the static driver verifier seems to time out every dozen tests or so.
I'm not sure what you mean by it should have been present in the design "from the beginning", because this technique has only been around in its full form for a few years.
I'll just corroberate what the other poster said to this blatently false comment. I have Cingular pay-as-you-go (my only association with them) and pay about $15 a month.
Cingular pay-as-you-go gives (if you go with the simple plan) 100 minutes for $25, which expries after 90 days, and will carry over if you add more by then.
(There's also a more complicated plan that you can't really say "it will last this long" because it depends on how you use it. The way it works is if you don't use the phone on a particular day, it's free. If you do use it on a given day, it's $1 plus airtime. (Note that that's $1 per used day, not $1 per call.) Calls to other Cingular phones are free; other calls are 10c/min. The simple plan is 25c/min period.)
Not associated with Cingular except for being a relatively happy customer. (I hate cell phones in general. Also, Cingular will occasionally text you marketing stuff if you don't tell them to stop, and even though it's coming from Cingular it still costs 5 or 10 cents. I don't know if it costs the $1 if you would have otherwise not used the phone, but I suspect so. You can tell them to not send them.)
As others have said, depends on your usage pattern. I have Cingular pay-as-you-go, and almost never use my phone. I spend about $15 a month. The cheapest non-prepaid monthly plan I saw when shopping around a couple months ago was $40 a month.
What he means is that Google cannot raise their prices arbitrarily, because they do have legitimate competitors that their customers can utilize.
At a significant hit to their exposure. Remember, MS never was the *only* choice on the desktop; it was just the only *practical* choice.
It's what another poster said: the people doing searches aren't Google's customers, we're its product. We can pretty easily switch search engines with only a pretty minor hit in accuracy from what I've seen, but Google's customers are its advertisors. And if they switch it cuts their audience by, according to another poster who said that Google has 73% of searches, a factor of about 3.
Interesting that, on Slashdot, you can't use "steal" to refer to hypothetical losses by copyright holders due to infringement because it's not really stealing, but you can use "steal" to refer to hypothetical losses by competitors due to monopolistic practicies even though it's not really stealing.
Ah,/., where a disparaging comment about a Microsoft group that isn't MSR in a discussion about MSR gets "insightful" mods instead of troll, flamebait, or offtopic, and a true comment defending MSR gets modded flamebait.
BTW, by "Say what you like about MS in general, but MSR publishes more good research than many (probably even most) university CS depts" I'm not trying to disparage universities either; MSR is a lot bigger than any School CS dept., so this only stands to reason. (Also, my closest connection to MSR is that one of the other members of my research group had an internship there.)
That's not MSR. That's marketing research. (I don't know what the department that does that is named though.)
MSR's the group that came up with SLAM, which is now incorporated into the Windows driver framework. It's resulted in (over the last 5 years) two POPL papers (one of the two top-tiered programming language conferences), a PLDI paper (the other of the two), a PASTE paper, a TOPLAS paper, three TACAS papers, three CAV papers, a few workshop papers, and a spinoff project at UC Berkeley called BLAST which is doing things very similar to SLAM. (They've had their own fair share of papers, and probably a doctoral thesis or two, on it.)
MSR's the group that wrote Singularity, an experimental OS written in C#, that has an ASPLOS paper, two EuroSys papers (one of which got the best paper award), and three workshop papers.
MSR's the group that wrote Vulcan, a binary rewriter that allowed them to create a program that records the execution trace of another program and play it back later. This is useful in, for instance, temporal debugging. (Think the Omnicient Debugger for Java, except made to work on any program because it operates on binaries. Except that MSR developed two other applications for the recorded traces.) This, and other projects that MSR has done with Vulcan, have resulted in a number of other papers.
Say what you like about MS in general, but MSR publishes more good research than many (probably even most) university CS depts.
Slashdot Mirror
http://en.wikipedia.org/wiki/One_Definition_Rule
Programming, yes, but computer science doesn't use C++.
Bull. At least sort of.
First, it depends in part on what your definition of computer science is. Most CS courses are taught in a C-like languages. At my undergrad institution, most of my programming assignments were done with C++. Sure, there was exposure to ML, but my impression is that most places that's mostly confined to the PL classes. (There are some notible exceptions that use ML or Scheme for intro courses.) Even at those institutions, I expect that later classes have assignments in a C-like language.
Second, there's a lot of CS that relates to C++. Compiler theory of how you implement things about it, and language design. It's not about C++ specifically, but it certainly relates.
Third, there is a fair bit of work in PL that directly relates. Not all PL is people in ivory towers coding in ML and Lisp. CCured is a very nice bit of work, though it's only C because it's built on top of the C Intermediate Language (CIL). There's early work now to create a CIL++, and I'm sure that it hasn't escaped anyone there about the potential to extend CCured to C++ once that's done. The parser for CIL++ will be something called Elsa, which was a major part of the research of one of the people there. My own research is indirectly related even. I'm looking at static analysis of binary code. Earlier work done in my group was explicitly directed to being able to find vtable pointers that C++ compilers produce.
You're right to the extent that the core of CS is really in some sense applied math, and is entirely language-neutral. However, to say that C++ has no relation to CS because it's just programming (which CS isn't about) is just wrong.
you'll probably have to be told that a "zero-day exploit" has nothing to do with severity -- it means that working exploit code was released on the same day as the vulnerability was announced.
Um, where's the working exploit code?
TFA only says it's "potentially exploitable".
Apparently so.
/. is downright defamatory.
Theoretically, a zero-day exploit is one that can be executed *right now*, before there's a chance to patch. However, considering that the advisory says it's "potentially exploitable" even though it was published some 16 days ago seems to be stretching the definition of "zero." The blog MS linked to was alarmist, and
That sounds to me like something could *potentially* happen, but they haven't been able to actually prove it yet. And, the date on this discovery (according to the source article) was over two weeks ago. By now, wouldn't they have concluded something with their research?
No... not at all. They're just very liberal with their definition of "zero-day"...
I'm not saying that something like this isn't exploitable, I'm just saying that the chance is extremely low.
For your plan to work:
1. The following memory would likely have to be deallocated (this depends on the malloc implementation, but assuming that it keeps track of a free list, the block that you corrupt would have to be deallocated before that address was used for anything), so the following would have to be done at the first allocation following this deallocation
2. You would have to be able to determine a valid stack address to make it point to
3. The buffer it allocates would have to be for unchecked/mischecked user input and not just internal storage that you don't have control over
4. You would have to know when you were able to write to it
Stranger things have happened in security, that's for sure, but the chances there are pretty out there.
(Furthermore, the MSVC malloc block header would have to be amenable to this attack, which it might not be.)
This is a heap buffer, assuming TFA's right. What programs execute instructions from the heap and so have the potential to be overwritten by a jump?
At absolute worst, you could do what at least one paper calls a non-control-data attack and corrupt some other piece of data that was next to it in the heap. Except every malloc implementation I know puts a header struct at the beginning of each block, so even if two pieces of heap data ended next to each other you wouldn't be able to reach the actual data with just a 4 byte overflow, and the best you could hope for is to corrupt the header. This is very unlikely to have any exploitable effects, and is just likely to kill the process.
It's a heap buffer (assuming TFA is right), which means the return address will be nowhere near it. There *could* still be neighboring security-sensitive code, but it's extremely unlikely. Worst case that's remotely likely would be that you corrupt the header that markes the beginning of the next heap block and wreak havoc with future malloc calls. Probably nothing controllable though. This *really* isn't that big of a deal, and calling it a zero-day exploit is downright libel.
Um, depending on what's in the data you overflow into, there's still *potentially* plenty you can do. (They're all very unlikely, but the potential is there.) There's other security-sensitive data besides the return address, and other buffer overflow exploits than overwriting that to jump into malicious code.
Since when did a "potentially exploitable heap buffer overflow" become a zero-day exploit?
That stuff sounds kinda neat, but after reading the SLAM summary paper, it looks pretty similar to the Stanford Checker extensions to gcc, which eventually turned into Coverity. Seems like there are some differences: I don't think that the Checker has to do the rewrite to the Boolean language thing, but the whole idea of rules like "match lock with unlock" seems analagous. Recent Linux kernels have featured some reasonably neat gcc stuff that warns if you don't check return codes and the like.
It's similar in spirit, but not in execution. xgcc is intended to be a bug-hunting tool, while SLAM does verification. They're somewhat the same, but subtley different. If the Static Driver Verifier reports a violation of a rule, it's guaranteed to be an actual, executable path. Up to their assumptions about the system (notably I'm not sure if it handles concurrency, but then again neither does xgcc to my knowledge), if the SDV says that a driver is free of violations of a rule, the driver is guaranteed to be free of such violations. The catch is that SDV is not guaranteed to terminate. [I'm pretty sure about everything I said here, but not 100% positive.] Neither of the above is true of xgcc; violations that xgcc reports may be false postives, and xgcc misses violations. On the other hand, you're guaranteed to get a result, and if the output is useful, it has served its purpose.
So you're right that they're similar, but they try to tackle the problem of poor software quality in different ways. (In my mind, the Coverity approach of being a bug hunter is probably more applicable to application programs, while the SDV approach of trying to prove drivers free of the bugs they look for is more applicable to drivers, so they both seem to be in their niche.) And the methods that each use are, as far as I know, entirely different.
(I'm also not sure when they got started with that; the paper I read on it was from 2002, after SLAM got started. It looks like Engler has some other papers on related work going back to '97 though.)
You probably should have replied to the moderated-down item.
..." /. ..."
I did reply to the moderated down item! Here's the discussion tree:
1."research", MECC, 5:01 pm -- "Does that include Zune?..."
2....Re: "research", EvanED, 5:38pm -- "That's not MSR.
3.......Re: "research", EvanED, 5:55pm -- "Ah,
4.........."Huh?", spitzak, 11:21pm -- "The above comment..."
I've numbered the posts 1-4. When I posted #3, #2 was at +1, flamebait. (With two flamebait mods and one informative, plus my karma bonus.) It's only after that point that #2's score went up.
Since Zune is a major product, this statement does mean that the Zune contains something made by the Research department, unless it is "virtually no product". Thus the initial post is questioning the accuracy of this statement.
Okay, now that you word it this way, I think I see what you and the initial post were talking about. The way I interpreted it (especially with the "flame on" ending) was that he was saying "MSR contributed to the Zune and music service... wow, what innovation out of MSR </sarcasm>." I read it as a criticism of MSR of the sort that the article was saying was unfounded, not questioning the article. In this I now see I very well may have been mistaken.
(However, even if it was, it's very possible for MSR to contribute to either product, and I sorta suspect that it's not MSR who produced the idea. The poster said "How much research did it take to come up with 'We need to make our own iPod and music service'?" but that wouldn't have been what MSR did in all likelyhood.)
So I back off of what I said about the OP being troll, etc.
Moderated-up replies to stuff that is moderated down appears to migrate up to be a response to the above. Again this can make the responder look like an idiot by reversing what they are replying to. In addition it hides exactly what they are responding to.
I know what you're talking about, and I think that the solution of displaying parents of moderated-up comments is a good idea. (I don't think that they should be moderated up themselves though if that's what you meant; like if they'd be -1, flamebait now, I think they should be -1 flamebait with the fix; just that if there's a +3 reply to them the -1 post should be visible if the threshold shows the +3.)
Why did you choose pick your plan if you rarely use your phone? Pick your plan is "$x/month for up to y minutes"; what did you think you were getting into?
How can you call what I'm saying blatantly false?
Because your comment was false. You shouldn't have said "avoid cingular because they'll bill you $50/month whether you use it or not"; you should have said "avoid Cingular because if you choose the $50/month plan they'll bill you $50/month."
Now if there's something I'm still missing, like you asked for a different plan than you're being billed for, you should have just said that...
Oops, I forgot to finish what I wanted to say.
;-)
... Java with .NET
.Net's weakness is its platform specificity. If it was platform independent, including GUI toolkit, I'd take .Net over Java in a second for almost any program where I had to choose between those two languages. (Yeah, I know .Net isn't a language. C# or C++ .Net or a combination. You get my point. And yeah, there's Mono, but they're behind on the GUI front (though catching up), and there's patent worries and such. It's not equal support like Java has.)
;-)
I just wanted to address a few points:
The only result of what you listed here is more stuff to wipe my ass with.
And hopefully more stable drivers in the near future.
But they are playing catch-up to
I don't buy this.
#include your rant about how pure research furthers the field and applied research is for moneygrubbing opportunists
Well, the first part is certainly true, but to be honest, I don't think that applied research is for opportunists. Some of my favorite research has very deeply immediately applicable results. (The best has a great mix of applied stuff and theory. CCured would be an example of this, though it's less applicable than some other possible examples.)
With over 20% of the DOCTORAL CANDIDATES, I would expect them to publish more good research than EVERY university.
Well, there are a few things at work that might conspire against this. First, remember that that 20% is just during the summer; 3/4 of the year they're back at universities. Of course, MSR also has a fair number of full-time employees. Second, even if you have the research to support it, I suspect it's difficult to get more than a paper or two from any given institution into some conference. Third, there's some reason to suspect that people at MSR are less eager to publish than those at universities. Grad students are eager because you need publications for a job, new faculty are eager because they need publications to get tenure, middle-aged faculty are eager because they need publications to get promoted. I'm sure there's still a lot of pressure in an industry lab, but I suspect it's less. I could be wrong about that though, I haven't experienced an industry research lab.
And finally, you shouldn't have posted AC, that's a good post. You deserve the insightful mod.
I agree with most of what you said. The thing was that I was trying to defend MSR from the perception that -- unfairly -- carries over from MS Corporate about innovation. I *do* think that the perception of MS Corporate taints the perception of MSR even among people who have heard of it (as you said in the bold parts), and I do think that the taint is quite unfair when it comes to the topic at hand, innovation (which you left unanswered as to your opinion).
;-)) But back to the subject at hand, I don't really know what MSR contributes to Corporate. They've got a bunch of UI researchers... but they don't seem to be using them all that much.
The problem with MSR from an outsider's perspective is that they seem to be pretty poor at translating research that goes on to products that Corporate can use. There are some exceptions to this, like the SLAM project resulting in the Static Driver Verifier, which is distributed as part of the Windows Driver Framework. And who knows, maybe in VS 2007 or 2009 you'll see results of the work with Vulcan, recording traces, and time-traveling debugging. (I for one would kill someone for that code now. Actually, on a personal note, I'm sorta miffed about this one... they scooped me by about a year. I was trying to come up with a research project for a software engineering class, read about the Java Omniscient Debugger, and thought "hey, that would be great to do for binaries" (some of my other work involves analysis of binaries so I was in that mindset), and actually did a fair bit of related work research before finding the MSR paper. And it was only released in April of this year for a conference in the Summer I think... if they had waited another year, that'd have been my project.
Maybe there is a lot of transfer going on behind the scenes, but I don't see it.
As the author of both the post you're responding to (about /.'s bias) and the post above it (the one that lists those three inventions and their papers and uses), I'd say it's you who need to read more carefully. (Though in part it's a misunderstanding because of differences in moderation states between when I wrote the second post and when you read it.) My original post (talking about SLAM, Singularity, and Vulcan) *WAS* supportive of MSR. That's the point. The post above me (still at 5) is a very cynical "How much research did it take to come up with 'We need to make our own iPod and music service'?", which is out of MS Corporate and not MSR, and so is either off topic, flamebait, troll, or, in the best case, just wrong.
/.'s bias. It was only later that the comment on MSR was modded up to +5.
At the time I began the reply about MSR's contributions, the post I was responding to was I think at +3. By the time I was done, it was at +5. If you look at its moderation history, it has 30% interesting and 70% insightful. My first moderation on the post defending MSR was flamebait. The second moderation was informative. The third was another flamebait. *This* is what spurred the comment on
Where did it start? The story I heard from one of my profs was that a couple interns really started the project in 2000 at MSR. They then went back to Berkeley and wanted to continue the work, and split off the BLAST project as somewhat of a fork.
Looking at the earliest SLAM paper listed, from 2000, seems to confirm this. The authors are listed as being from MSR, and there's nothing like "continuing our earlier work..." that I noticed. In fact, the only paper cited by either of the two authors is an MSR Tech Report from earlier that year.
I only briefly read the paper but testng with "drivers" and "stubs" is covered in a 500 level SW Testing course in the university I attended.
What sort of "testing"?
SLAM isn't testing from a SE term point of view; it's static analysis. None of the driver code is being actually executed. Instead the SLAM engine is exploring all possible execution paths through symbolic execution (translation of the programs to binary decision diagrams) and something called counterexample guided abstraction refinement. Such a problem of course is undecidable in general, and in practice the static driver verifier seems to time out every dozen tests or so.
I'm not sure what you mean by it should have been present in the design "from the beginning", because this technique has only been around in its full form for a few years.
I'll just corroberate what the other poster said to this blatently false comment. I have Cingular pay-as-you-go (my only association with them) and pay about $15 a month.
Cingular pay-as-you-go gives (if you go with the simple plan) 100 minutes for $25, which expries after 90 days, and will carry over if you add more by then.
(There's also a more complicated plan that you can't really say "it will last this long" because it depends on how you use it. The way it works is if you don't use the phone on a particular day, it's free. If you do use it on a given day, it's $1 plus airtime. (Note that that's $1 per used day, not $1 per call.) Calls to other Cingular phones are free; other calls are 10c/min. The simple plan is 25c/min period.)
Not associated with Cingular except for being a relatively happy customer. (I hate cell phones in general. Also, Cingular will occasionally text you marketing stuff if you don't tell them to stop, and even though it's coming from Cingular it still costs 5 or 10 cents. I don't know if it costs the $1 if you would have otherwise not used the phone, but I suspect so. You can tell them to not send them.)
As others have said, depends on your usage pattern. I have Cingular pay-as-you-go, and almost never use my phone. I spend about $15 a month. The cheapest non-prepaid monthly plan I saw when shopping around a couple months ago was $40 a month.
What he means is that Google cannot raise their prices arbitrarily, because they do have legitimate competitors that their customers can utilize.
At a significant hit to their exposure. Remember, MS never was the *only* choice on the desktop; it was just the only *practical* choice.
It's what another poster said: the people doing searches aren't Google's customers, we're its product. We can pretty easily switch search engines with only a pretty minor hit in accuracy from what I've seen, but Google's customers are its advertisors. And if they switch it cuts their audience by, according to another poster who said that Google has 73% of searches, a factor of about 3.
Interesting that, on Slashdot, you can't use "steal" to refer to hypothetical losses by copyright holders due to infringement because it's not really stealing, but you can use "steal" to refer to hypothetical losses by competitors due to monopolistic practicies even though it's not really stealing.
/. groupthink today...)
(Sorry, I'm sorta cynical towards
Ah, /., where a disparaging comment about a Microsoft group that isn't MSR in a discussion about MSR gets "insightful" mods instead of troll, flamebait, or offtopic, and a true comment defending MSR gets modded flamebait.
BTW, by "Say what you like about MS in general, but MSR publishes more good research than many (probably even most) university CS depts" I'm not trying to disparage universities either; MSR is a lot bigger than any School CS dept., so this only stands to reason. (Also, my closest connection to MSR is that one of the other members of my research group had an internship there.)
That's not MSR. That's marketing research. (I don't know what the department that does that is named though.)
MSR's the group that came up with SLAM, which is now incorporated into the Windows driver framework. It's resulted in (over the last 5 years) two POPL papers (one of the two top-tiered programming language conferences), a PLDI paper (the other of the two), a PASTE paper, a TOPLAS paper, three TACAS papers, three CAV papers, a few workshop papers, and a spinoff project at UC Berkeley called BLAST which is doing things very similar to SLAM. (They've had their own fair share of papers, and probably a doctoral thesis or two, on it.)
MSR's the group that wrote Singularity, an experimental OS written in C#, that has an ASPLOS paper, two EuroSys papers (one of which got the best paper award), and three workshop papers.
MSR's the group that wrote Vulcan, a binary rewriter that allowed them to create a program that records the execution trace of another program and play it back later. This is useful in, for instance, temporal debugging. (Think the Omnicient Debugger for Java, except made to work on any program because it operates on binaries. Except that MSR developed two other applications for the recorded traces.) This, and other projects that MSR has done with Vulcan, have resulted in a number of other papers.
Say what you like about MS in general, but MSR publishes more good research than many (probably even most) university CS depts.