Hi, I'm one of the authors of the paper and an engineer at Google. I wanted to clarify some points that have come up in the comments.
First, we don't believe that failing builds are bad. We wanted to study the typical edit-compile-debug cycle that all developers (at least those writing in compiled languages) use to write code. It's perfectly fine to do something like change the signature of a method, compile, then use the compiler errors to find all places where you need to fix your code. We were interested in what kinds of compile errors people run into, how long it takes them to fix the errors, and how we can help you go from a failed to a successful build more quickly. For example, for one particular class of dependency error, we saw that people were spending too much time fixing it. So we created a tool to automatically fix the error and included the command to run the tool in the error message emitted by the compiler. After that we saw the fix time for that class of error drop significantly.
Second, this work is not related to checking in broken code. The builds we looked at are work-in-progress builds from Google developers working on their projects, so it's code in intermediate states of development, not code that has been checked in. It's possible that broken code may be checked in, but our continuous build system will catch that quickly and force you to fix the problem. So for all intents and purposes, all of the code checked into our depots builds cleanly.
Third, by dependency issues we probably don't mean what you think we mean. Within Google we use a custom build system with a custom build file format. Source code is grouped into build targets, and build targets depend on each other, even across languages. You can assume that code checked into the depot builds successfully, and that generally engineers are editing only code in their project and not in their dependencies. The dependency errors we describe in the paper usually result because someone added a source-code-level dependency without adding a matching dependency in the build file, resulting in a "cannot find symbol" error. For example, in a JUnit test you might write the code: Assert.assertTrue(foo); But if you don't add a dependency on JUnit to the build file, then you will get a compile error because the build system doesn't know where to find the Assert class. We would count that as a dependency error.
Finally, at Google there is no distinction between "builds on my machine" and "builds on someone else's machine." Our build system requires that all dependencies be explicitly declared, even environmental dependencies like compiler versions and environment variables, so that a build is reproducible on any machine. This is how we are able to distribute our builds. So it's impossible for code to build on a developer's local machine but not on the continuous build system.
I'm happy to answer further questions if people are interested.
I should temper this by saying that some of my friends loved Harvard and thought it was the perfect place for them. My wife, for example, thinks going there was one of the best decisions she ever made. A good friend who is now a software engineer also loved it. Just be aware that you need to pick what's best for you, not what some ranking system rates as the "best program."
As someone who went to one of these "prestigious universities," my advice would be to pick a university that is a good fit for you, not what U.S. News and World Report rates as the "top college" or what people think is the most prestigious. I went to Harvard for my undergrad, and I did not do well there. None of the faculty or my advisors took an interest in me, and, despite what you hear, the classes (at least the ones I took) are very hard and the students are incredibly smart. It led to me essentially giving up by my junior year and trying to coast through. And this wasn't an uncommon experience among my circle of friends. My roommate nearly failed his senior year, and another two of my friends had to take time off because of their poor grades.
I will say that I went back to Harvard for my master's, and as a graduate program I enjoyed it much more. You have closer interaction with the professors in your field, and the classes are appropriately challenging for a graduate student. I was much happier as a grad student there.
Going to a top tier school for undergrad is not that important. Go somewhere where you will be happy, and focus on getting into a good grad school.
There are several research groups doing work on distributed P2P backup systems. I know there's a group at MS doing this, as well as a group at MIT (http://catfish.csail.mit.edu/~kbarr/pstore/), and several others that don't come to mind offhand. I did a project on this in grad school, so I'm familiar with the research.
There are a lot of issues here, mostly centering around the fact that you can't trust people in an open P2P network. 1) They might look at your data. 2) They might not be online when you want your data. 3) They might delete your data, or do other malicious things to it (insert viruses, etc.). 4) They might freeload by using space on other hosts and then deleting all the data they receive. 5) If a host leaves the system permanently, you need to detect that and replicate its data somewhere else. Also, how do you know whether it's leaving permanently or just logging off for a while?
#1 is easy, just encrypt the data. #2, #3, #4, and #5 are hard because data integrity is really important in a backup solution. You end up having to replicate the data all over the place to "ensure" that it'll be available when you need it, but then you've got the problem of having to donate more space than you receive to use the system. Plus, it's still not certain that your data will be available when you need it.
Basically what I'm trying to say is that it's a hard problem.:)
The original Half-Life was built on the Quake engine. Half-Life 2 probably contains some code from Half-Life, which can explain the Quake references.
Re:Here's an idea.
on
I, Spammer
·
· Score: 2, Insightful
What's to keep a spammer from just using a known valid email address as the from address on his spam? Then the hash check will succeed and the mail will go through. The spammer doesn't have to register the address himself, he can just use any address that he knows is on the whitelist.
Yes, but Creative was sitting on it's collective ass until Aureal came along and started putting out 3d sound cards. If it weren't for Aureal's competition in that market, we'd probably all be buying Sound Blaster PCI 1024's for like $100. And we'd like it.
If you ask me, $600 is waaaaay too much for a video card, and if NVIDIA still had 3dfx to worry about, you can be sure the GeForce3 would be more reasonably priced.
Competition is good, even if a company holding a monopoly is producing a good product.
Nvidia is not in bed with Microsoft, but they're not opposed to Microsoft either. They are simply trying to make money in whatever way they can. They'll do whatever it takes to make money: make the X-Box graphics chip, release GeForce3 on Mac first, tie the DirectX 8 standard closely to their hardware, etc.
Nvidia's business practices are pretty sketchy, but damn, do they make nice video cards!
Dreamcast games are not written using WinCE. Well, the vast majority of them are not. You see, developers for the Dreamcast have the choice of using WinCE and Microsoft APIs (I think DirectX, but I might be mistaken) or Sega's proprietary APIs. Most Dreamcast developers use the Sega APIs because they give better performance.
You can tell which games use WinCE because they show the WinCE logo when they start up. And yes, Sega Rally 2 does use WinCE.
Incidentally, Dreamcast gamers avoid WinCE games like the plague, since they are generally shoddier than Sega API games.
Slashdot Mirror
Hi, I'm one of the authors of the paper and an engineer at Google. I wanted to clarify some points that have come up in the comments.
First, we don't believe that failing builds are bad. We wanted to study the typical edit-compile-debug cycle that all developers (at least those writing in compiled languages) use to write code. It's perfectly fine to do something like change the signature of a method, compile, then use the compiler errors to find all places where you need to fix your code. We were interested in what kinds of compile errors people run into, how long it takes them to fix the errors, and how we can help you go from a failed to a successful build more quickly. For example, for one particular class of dependency error, we saw that people were spending too much time fixing it. So we created a tool to automatically fix the error and included the command to run the tool in the error message emitted by the compiler. After that we saw the fix time for that class of error drop significantly.
Second, this work is not related to checking in broken code. The builds we looked at are work-in-progress builds from Google developers working on their projects, so it's code in intermediate states of development, not code that has been checked in. It's possible that broken code may be checked in, but our continuous build system will catch that quickly and force you to fix the problem. So for all intents and purposes, all of the code checked into our depots builds cleanly.
Third, by dependency issues we probably don't mean what you think we mean. Within Google we use a custom build system with a custom build file format. Source code is grouped into build targets, and build targets depend on each other, even across languages. You can assume that code checked into the depot builds successfully, and that generally engineers are editing only code in their project and not in their dependencies. The dependency errors we describe in the paper usually result because someone added a source-code-level dependency without adding a matching dependency in the build file, resulting in a "cannot find symbol" error. For example, in a JUnit test you might write the code:
Assert.assertTrue(foo);
But if you don't add a dependency on JUnit to the build file, then you will get a compile error because the build system doesn't know where to find the Assert class. We would count that as a dependency error.
Finally, at Google there is no distinction between "builds on my machine" and "builds on someone else's machine." Our build system requires that all dependencies be explicitly declared, even environmental dependencies like compiler versions and environment variables, so that a build is reproducible on any machine. This is how we are able to distribute our builds. So it's impossible for code to build on a developer's local machine but not on the continuous build system.
I'm happy to answer further questions if people are interested.
I should temper this by saying that some of my friends loved Harvard and thought it was the perfect place for them. My wife, for example, thinks going there was one of the best decisions she ever made. A good friend who is now a software engineer also loved it. Just be aware that you need to pick what's best for you, not what some ranking system rates as the "best program."
As someone who went to one of these "prestigious universities," my advice would be to pick a university that is a good fit for you, not what U.S. News and World Report rates as the "top college" or what people think is the most prestigious. I went to Harvard for my undergrad, and I did not do well there. None of the faculty or my advisors took an interest in me, and, despite what you hear, the classes (at least the ones I took) are very hard and the students are incredibly smart. It led to me essentially giving up by my junior year and trying to coast through. And this wasn't an uncommon experience among my circle of friends. My roommate nearly failed his senior year, and another two of my friends had to take time off because of their poor grades.
I will say that I went back to Harvard for my master's, and as a graduate program I enjoyed it much more. You have closer interaction with the professors in your field, and the classes are appropriately challenging for a graduate student. I was much happier as a grad student there.
Going to a top tier school for undergrad is not that important. Go somewhere where you will be happy, and focus on getting into a good grad school.
Same for me. Didn't work on either of my XP Pro SP2 boxes. I used port 135, which is open on both. No firewall either.
There are several research groups doing work on distributed P2P backup systems. I know there's a group at MS doing this, as well as a group at MIT (http://catfish.csail.mit.edu/~kbarr/pstore/), and several others that don't come to mind offhand. I did a project on this in grad school, so I'm familiar with the research.
:)
There are a lot of issues here, mostly centering around the fact that you can't trust people in an open P2P network.
1) They might look at your data.
2) They might not be online when you want your data.
3) They might delete your data, or do other malicious things to it (insert viruses, etc.).
4) They might freeload by using space on other hosts and then deleting all the data they receive.
5) If a host leaves the system permanently, you need to detect that and replicate its data somewhere else. Also, how do you know whether it's leaving permanently or just logging off for a while?
#1 is easy, just encrypt the data. #2, #3, #4, and #5 are hard because data integrity is really important in a backup solution. You end up having to replicate the data all over the place to "ensure" that it'll be available when you need it, but then you've got the problem of having to donate more space than you receive to use the system. Plus, it's still not certain that your data will be available when you need it.
Basically what I'm trying to say is that it's a hard problem.
I also have an Altima, but the '02 model. 5-speed and V6 as well. Same EPA ratings: 21 city/26 highway.
Over 26k miles, I've averaged 20 mpg in 85% city driving. Best mileage ever was 29 mpg in all highway driving, and worst mileage was 14 mpg.
The original Half-Life was built on the Quake engine. Half-Life 2 probably contains some code from Half-Life, which can explain the Quake references.
What's to keep a spammer from just using a known valid email address as the from address on his spam? Then the hash check will succeed and the mail will go through. The spammer doesn't have to register the address himself, he can just use any address that he knows is on the whitelist.
"Alumni" is the correct form of the mixed gender plural. "Alumnae" would only be used at all-female schools.
That's actually one of the big benefits of the PowerVR architecture. I believe there are some Sega arcade boards that use two or more PowerVR chips.
If you ask me, $600 is waaaaay too much for a video card, and if NVIDIA still had 3dfx to worry about, you can be sure the GeForce3 would be more reasonably priced.
Competition is good, even if a company holding a monopoly is producing a good product.
Nvidia's business practices are pretty sketchy, but damn, do they make nice video cards!
So I'm just a Slashdot newbie, but it seems to me that this post has been proven factually incorrect by all the "Incorrect!" posts following it ¥and I know it's incorrect because I took a class on Fourier methods and sampling theory© Why then is it still moderated up to a 5 while all the correct responses are down at the 1-2 level?
Dreamcast games are not written using WinCE. Well, the vast majority of them are not. You see, developers for the Dreamcast have the choice of using WinCE and Microsoft APIs (I think DirectX, but I might be mistaken) or Sega's proprietary APIs. Most Dreamcast developers use the Sega APIs because they give better performance. You can tell which games use WinCE because they show the WinCE logo when they start up. And yes, Sega Rally 2 does use WinCE. Incidentally, Dreamcast gamers avoid WinCE games like the plague, since they are generally shoddier than Sega API games.