Using raid 5 I lose 20-33% of the potential space while using raid 1+0 or 0+1 (aka raid 10) I lose 50%.
Yeah, but in a world of $189 1TB drives... *who cares*? RAID5 is slower, harder to grow, has silent failure conditions, and it's one advantage is that it's 20% more space efficient, in a world where the $/GB ratio is so ridiculously low it's not even worth thinking about.
If you have one RAID5 box, just build another one that replicates it.
Or just use something more reliable, like RAID 10, and toss out all of RAID5's performance problems along with it. As you say, storage is cheap, and the chief advantage that RAID5 offers (storage efficiency) seems like a minor concern compared to it's disadvantages.
Personally, I believe the correct answer to ensuring data recoverability is RAID together with real-time replication.
Like, say, RAID-1?:)
Honestly, given the cost/GB ratios these days, the space advantages of RAID-5 seem pretty silly compared to the reliability and performance issues. Why not just go with something like RAID-10 and be done with it?
No. I think they'll stop doing "charitable work" like updating OpenOffice and other hobbyist projects.
Umm... that's *not* charitable work, any more than writing a novel or a piece of music is charitable work. They do it (and I do it) because they want to, not out of some selfless sense of altruism. OSS isn't about selfless giving. It's about having fun doing what we love, and giving away the results of our efforts because we want to share it with the world.
Judging from your comments, like the blog author, you, too, don't understand this. That's fair, you're probably not an OSS developer. But rest assured, you're quite mistaken.
Therefore they might not be able to pay their bills, and their priority will be survival
So, let me guess, you also think people will stop watching TV, playing music, painting, writing, etc, because they will, 24/7, be too busy working on "survival"?
In short: The problem is the results of reducing emissions, and then waiting for atmospheric CO2 concentrations to drop, might arrive too late to save us from, say, catastrophic destruction of coastal cities, even if we put the breaks on CO2 emissions growth today. Geoengineering might provide a complementary, short-term risk mitigation component to a long-term, pollution reduction strategy.
Unfortunately, you're spot on about the moral hazards involved with this approach.
My experience has been to target the common path rather than the exception. If you branch and merge with every change, regardless of scale, then you have to branch and merge every time you make a change and will need to resolve conflicts regularly.
Why? My working copy is effectively a small branch. Every day, I do an "svn update" which merges my working copy with what is in HEAD. And 99.99999% of the time, I never have a merge problem. So why would this magically become an issue with real, honest-to-god branches within the SCM itself?
I prefer to hire developers that don't commit broken code
I never said broken. I said in progress. Why you keep assuming the latter implies the former, I have no idea. Have you never wanted to check in partially-complete code so that another person could work with it? Or so that it's not sitting there on your desktop, waiting for a drive failure to render your work non-existent? Or so you could check in the solid stuff you have, now, so that you could experiment with an idea you had?
And I'm not totally against branching and merging, just saying that the majority of the time it is unnecessary overhead.
Only because you're biased against the process, probably because you've used tools that make it more difficult than it needs to be.
just saying that distributed SCM seems to be a solution looking for a problem that just doesn't exist.
If that were true, we wouldn't have projects moving to them.:)
Besides which, branch-and-merge workflow need not be unique to distributed SCMs. It's just that many of the centralized SCMs suck at it (although my wife, working at Nortel, used this exact workflow many years ago using ClearCase, IIRC, and it worked quite well... and in that case, they used it specifically so they could facilitate code review and a change gating process).
I'm not afraid of the command line, but I'll be damned if I'm going back to IDE-less development for any project more complex than a simple webapp.
Uhh... you know, you *can* do both. I use TortoiseSVN + Visual Studio at work (yeah yeah...:), and it works just fine. I have absolutely no compulsion to use an SCM within my IDE... in fact, I would contend that a specialized tool designed to work specifically with the SCM is going to inevitably be more effective than something tacked on to my IDE.
I agree that's popular, but I don't think it's a good idea. Wouldn't it be better to have every check-in be stable?
Rose-coloured-glasses, much?
Besides, believe it or not, sometimes features are developed by *multiple* people. And those people need to work together and share their in-progress, possibly not-completed work through some mechanism. Some sort of... management system, if you will, for their source code.
I solve that by not having a ton of half-finished code. Ship early, ship often, I say.
Sorry, but some corporate clients are *not* happy with you dropping a new release every week. And this is doubly true if you work in the area of high-availability software. The idea that our company could just throw out a new code drop for every little feature is, quite frankly, laughable, given our product has to go through a third-party certification process.
And that's ignoring the case of large features developed by multiple people that are more than a few man-months worth of effort, which is also a common reality in the software world (not everyone is in the maintenance game).
Admittedly my code is rarely ever rolled back, but when I do have to it's as easy as choosing the commits included and in that piece of code and removing them.
Which is non-trivial when multiple people are working on the same codebase. It's the precise reverse of the merge problem. Although I would contend it's actually conceptually harder. It's much easier to look at a pair of changes and merge them, either automatically or manually. But trying to unwind two sets of intertwined changes is not my idea of a fun time.
I'm not against distributed SCM in anyway, but I will say that from everything I have read distributed SCM does not alleviate the need for manual conflict resolution in anyway shape or form
I never said it did. What I said was that users of distributed SCMs have discovered that conflicts simply aren't that big of a problem in everyday use.
Why do you have broken code in your working copy?
I don't have broken code in my working copy. I have in-progress code in my working branch. Why do I have that? Because the SCM exists to hold my code. It allows me to compare my code against mainline so I can review my changes. It allows me to incrementally update and revert my work as I go along. It allows me to ensure that all my changes are in an SCM which is backed up daily, so that I don't have to worry if my desktop crashes. It allows me to work in multiple locations on the same codebase. In short, it lets me use the SCM to manage my sourcecode, both my in-progress, working efforts, as well as the stable, in-production codebase.
Besides which, you seem to have this rosey picture that every commit is a good one. Believe it or not, people make mistakes. And when the guy down the hall accidentally breaks the database because his upgrade script is slightly b0rked, I don't want to waste time while they get their shit together.
And why is anyone committing code that either does not compile or does not pass your unit test suite?
Because no test suite covers all bases. And because people simply make mistakes.
Honestly, have you actually developed in the real world?
Huh? Why revert or delay anything.
I see you've completely missed the point. Here, let me be more explicit:
1. Project X has a deadline looming. In project X, management has scheduled features 1, 2, and 3 to be included. 2. A month before the deadline hits, the developers for feature 3 report that they are behind schedule and that feature 3 will have to be excluded from the release. 3. ?
The question is, what do you do at step 3. If you believe that all development should happen in trunk, then the developers now have to find a way to revert all the changes that make up feature 3 (naturally they've been using the SCM to interact amongst themselves). This could be an extremely non-trivial task depending on the complexity of the change.
Or, if you believe that all major development such as this should happen in branches, then the managers need only decide not to incorporate the changes from feature 3 into trunk.
And if you've never encountered this situation, I strongly question your experience, as this is pretty typical (just ask Microsoft about how WinFS is going).
Branch out only the stable code into your release branch.
Ha ha ha. Okay, now you're just being funny, right? What, you think you can just cherrypick changesets and build a release? Have you never built a large, non-trivial application with multiple developers? Or a database driven application where multiple, interlinked changes need to be made to the schema? Sorry, but the interdependency between changesets means that's just unrealistic in practice. And I've seen it tried... it ain't pretty, to say the least. Just the process of trawling through the changelog to identify all the mods that went into some feature, so that you can revert them, is an absolute frickin' nightmare. And that's ignoring the process of actually revertin
Are you saying your SCM doesn't let you revert/rollback without branching?
Are you saying that you enjoy having mainline broken while people are incrementally working on major code changes? Ignoring the fact that reverting changes can be a pain in the ass when multiple people are working on the same codebase.
Since it's merging that is the problem and not branching,
It is? Funny, I've never had that problem. Perhaps you should mention it to all those distributed SCM users. Even with subversion, merge management isn't that tough, as long as you're diligent and keep your working branch in sync with the eventual merge target.
. Branch of your release code, that should not have any significant work done on it, and do all you work in your main line,
So that my code can become broken while another developer incrementally works on a major change? Thanks but no thanks. I've experienced that, and it is, to say the least, really *really* annoying.
Not to mention the case where developer X is working on some major feature, and then scheduling restrictions force the team to push said feature out, into the next release. Which is easier? Delaying the merge, or reverting all the changes?
How people get anything done with their convoluted source control management totally amazes me sometimes.
Convoluted? How? I'm about to create new major feature X. I create a branch myproduct-feature-X. I work on that branch. When it's done, perhaps I send out a code review request, including the branch name. When I'm done, I instruct my SCM to merge from the branch back to trunk.
This is a *far* more sane way to manage major changes. It facilitates code review, makes it easy to gate changes through a change control system, and allows developers to use the full power of an SCM for incremental development. It's only convoluted to those who don't understand basic source control concepts.
Solution: stop checking in stuff that doesn't work.
You completely missed the point, didn't you? I said *large* features. You know, the kind where you have multiple developers working on various aspects of the problem, in which case it's most natural for them to interact through the SCM. Branches are the only sane way to handle this.
I don't have anything against local copies. It's kinda hard to change the code if you can't change the code.
Again, missed the point. Specifically, all the SCM bells and whistles. Local copies are a poor man's SCM. Better to just use a real SCM and get all the advantages that come with it.
This is true only if you're willing to pay the cost of slower code review. Longer feedback loops inevitably create greater waste than shorter ones.
*Slower* code review? What? How is being able to say "Do a diff of branch X against HEAD", or "check out X", not *faster* than manually handing out the code for review?
True. I use an IDE with undo for small cases of this, and reversion to head for large versions. But I think a better solution is to find mistakes early, so that screwing up is easy to fix.
Well of course. I never advocated otherwise. But in those cases where you *do* screw up, and I assume you screw up on occasion, using the SCM for what it was built for, changing tracking and control, makes it easier to revert broken code, etc.
I have never seen that not be the road to maintenance hell.
I never said it wasn't. But it's the reality for some companies.
I don't remember saying I've never seen the need for that. Perhaps you replied to the wrong post?
No, you said "So again, branching is what you do when a group fails to work effectively as a team." Or, to put it another way, people only advocate branching because their organization is broken. My point is, that's wrong.
When I'm building a unified product, what need would I have of branching and merging? If I'm not sure if something is a good enough idea to build, I don't build it. Or I build a quick, throw-away implementation to check an idea out. And then I throw it away.
So you've never implemented something and then wished you could revert a change that didn't work out? Or have never wanted to incrementally implement something without incorporating it into the final product until it was fully complete? Really?
It's because people have trouble forming teams and maintaining strong relationships in large groups.
No, it's because:
1) Software companies often need to create large, new features, and don't wish to destabilize the core product.
2) Or it's because it's *far* easier for developers to be able to branch pieces of code, work on feature or bugfix development in their own little playpen with all the SCM bells and whistles (being able to revert a messed up piece of code is awfully handy, even if you're the only one working on the codebase), and then merge those changes when they're ready. This also facilitates easier code review (just check out the branch) and change control as a nice added bonus.
3) Or because, in a more contract-oriented world, they might need to build customized applications for customers, and branch-and-merge strategies make that kind of code management possible.
Honestly, if you've never seen the need to branch-and-merge, you've never worked on a large project. Period.
Something tells me that any business interested in providing for-pay cloud computing services (you know, the only ones where you should expect any guarantee of data integrity) would handle a situation like this *far* better than Yahoo seems to have.
Re:Wouldn't be so sure about the correlation thing
on
The Quietest Sun
·
· Score: 1
All you can credibly say is that based on the correlation detection functions you have used
Umm... "detection functions"? We're not talking about mystical heuristics, here. Computing correlation between two variables is, quite literally, basic statistical science.
Because C and D are completely random, whether you push A or not push A to you has absolutely no effect on the light as there is no correlation to it. But, inside the box, A is most certainly controlling the light.
All you're doing is introducing noise into the system. But over a long enough period of time, you can detect the signal, the correlation, in the noise. It's pretty easy, too. Leave the box for a year. Two years, without pressing the button. Then press it and hold. Why, lo and behold, the light starts going on and off. It's random, to be sure, but it starts happening.
But, you say, perhaps the first two years were just luck, and the light just happened not to blink that whole time. Well, sure, that may be, but statistically, given the rate of blinking after you push at, you can pretty safely surmise that pressing the button correlates to the light turning on and off. And by graphing the data you can demonstrate, quite trivially, that the probability of the light going on and off increases when the button is pressed. Guess what that is? *Correlation*.
But ignoring all this, the scenario you posit is "tricky" because the indicator, the light going on and off, has a lot of noise to it, thanks to the random behaviour. In the case of GW and sunspots, we're not talking about a system with a great deal of noise. We're talking about a steady trend that's clearly obvious in the temperature graphs. With that kind of data, it's absolutely trivial to demonstrate that the frequency of sunspots has absolutely no correlation to the data, as while the rate of sunspots increases and decreases on an 11-year cycle, the global temperature has steadily trended upward.
Re:Wouldn't be so sure about the correlation thing
on
The Quietest Sun
·
· Score: 1
Daily Green : Gore calls for 90% CO2 Reduction
And Gore represents the entirety of the anti-pollution movement?
I think you need to do better than that.
Most hard core enviros
Right, wackos. So? Last I checked, they don't represent anything but the fringe environmentalists.
By this logic, I should rule out all of conservatism because of right-wing nutters like Rush.
Correlation is only good if you think you have all the variables involved.
What the hell are you talking about? If you're trying to prove that A causes B (in this case, sunspots cause GW), and you discover that there is no correlation between A and B, then A *cannot* be causing B. Period. End of story.
The case I came up with here might actually be not good, but I should think that for any given correlation detection algorithm, a case can be constructed that allows a genuinely causal relationship to escape it.
Uhh, no, you can't. If two events aren't correlated, then one *can't* be causing the other. That's part of the very fucking definition of causation. In order for A to cause B, there must be a correlation between the change in A and the change in B. Otherwise, there is no relationship between A and B, and therefore A does not cause B.
From what I gather from your responses, you encourage drivers to:
From what I gather from this response, you're about to set up a strawman.
1. pass on the right (speaking US streets)
2. slower traffic move left (into the passing lane)
3. not pay attention to traffic around
4. not be courteous to other drivers
Yup, there it is! Oddly, you don't try to knock it down, though, so I'm not sure what the point was.
Because without it, you wind up being limited by the weakest link in the immediately surrounding traffic. When this is a nonsensical & discourteous individual who doesn't pay attention to the cars around him/her, people must resort to nonsensical solutions to cater to that individual.
Ever heard the phrase, two wrongs don't make a right? Just because someone else is driving poorly, doesn't mean you have to be an aggressive jackass in response. All you're doing is aggravating an already dangerous situation.
But, you go right ahead... I'm sure you'll feel very smug and self-satisfied after your next car accident.
Of course it is. That's because the authorities are educated on the topic, and thus have opinions, along with theories and evidence to back them up, that should be weighed more heavily than baseless comments from ignorant commenters on Slashdot, such as yourself.
So, I assume you're an award winning economist, then? Because most of *them* disagree quite strongly with your supposition, so I can only assume you have credentials to back up your, frankly, absurd suggestion.
I will, however, get up on the bumper of an asshole not paying attention to the road and those around him
Yes, excellent strategy. That way, they can not pay attention to you while you're riding their bumper. And then, when they slam on their breaks because something unexpected happens, they can not notice you're back there when you run into them at highway speeds.
Slashdot Mirror
Using raid 5 I lose 20-33% of the potential space while using raid 1+0 or 0+1 (aka raid 10) I lose 50%.
Yeah, but in a world of $189 1TB drives... *who cares*? RAID5 is slower, harder to grow, has silent failure conditions, and it's one advantage is that it's 20% more space efficient, in a world where the $/GB ratio is so ridiculously low it's not even worth thinking about.
If you have one RAID5 box, just build another one that replicates it.
Or just use something more reliable, like RAID 10, and toss out all of RAID5's performance problems along with it. As you say, storage is cheap, and the chief advantage that RAID5 offers (storage efficiency) seems like a minor concern compared to it's disadvantages.
Personally, I believe the correct answer to ensuring data recoverability is RAID together with real-time replication.
Like, say, RAID-1? :)
Honestly, given the cost/GB ratios these days, the space advantages of RAID-5 seem pretty silly compared to the reliability and performance issues. Why not just go with something like RAID-10 and be done with it?
No. I think they'll stop doing "charitable work" like updating OpenOffice and other hobbyist projects.
Umm... that's *not* charitable work, any more than writing a novel or a piece of music is charitable work. They do it (and I do it) because they want to, not out of some selfless sense of altruism. OSS isn't about selfless giving. It's about having fun doing what we love, and giving away the results of our efforts because we want to share it with the world.
Judging from your comments, like the blog author, you, too, don't understand this. That's fair, you're probably not an OSS developer. But rest assured, you're quite mistaken.
Therefore they might not be able to pay their bills, and their priority will be survival
So, let me guess, you also think people will stop watching TV, playing music, painting, writing, etc, because they will, 24/7, be too busy working on "survival"?
Please.
but seeing how I'm experiencing almost record cold temperatures now for this time of year in my area
Weather != climate. Clearly, you need to educate yourself further.
So, just as the Earth enters a significant cooling trend
Uhh... there is no "trend" if the Earth just "[entered]" it... that's kinda the definition of "trend". It requires data. Which you conveniently lack.
As has been noted, geo-engineering requires massive amounts of hubris and luck.
As has been noted by you, you mean? Way to sleazily reference your own blog in order to "support" your point.
Or we could just pollute less?
Watch the TED talk that was posted here.
In short: The problem is the results of reducing emissions, and then waiting for atmospheric CO2 concentrations to drop, might arrive too late to save us from, say, catastrophic destruction of coastal cities, even if we put the breaks on CO2 emissions growth today. Geoengineering might provide a complementary, short-term risk mitigation component to a long-term, pollution reduction strategy.
Unfortunately, you're spot on about the moral hazards involved with this approach.
My experience has been to target the common path rather than the exception. If you branch and merge with every change, regardless of scale, then you have to branch and merge every time you make a change and will need to resolve conflicts regularly.
Why? My working copy is effectively a small branch. Every day, I do an "svn update" which merges my working copy with what is in HEAD. And 99.99999% of the time, I never have a merge problem. So why would this magically become an issue with real, honest-to-god branches within the SCM itself?
I prefer to hire developers that don't commit broken code
I never said broken. I said in progress. Why you keep assuming the latter implies the former, I have no idea. Have you never wanted to check in partially-complete code so that another person could work with it? Or so that it's not sitting there on your desktop, waiting for a drive failure to render your work non-existent? Or so you could check in the solid stuff you have, now, so that you could experiment with an idea you had?
And I'm not totally against branching and merging, just saying that the majority of the time it is unnecessary overhead.
Only because you're biased against the process, probably because you've used tools that make it more difficult than it needs to be.
just saying that distributed SCM seems to be a solution looking for a problem that just doesn't exist.
If that were true, we wouldn't have projects moving to them. :)
Besides which, branch-and-merge workflow need not be unique to distributed SCMs. It's just that many of the centralized SCMs suck at it (although my wife, working at Nortel, used this exact workflow many years ago using ClearCase, IIRC, and it worked quite well... and in that case, they used it specifically so they could facilitate code review and a change gating process).
I'm not afraid of the command line, but I'll be damned if I'm going back to IDE-less development for any project more complex than a simple webapp.
Uhh... you know, you *can* do both. I use TortoiseSVN + Visual Studio at work (yeah yeah... :), and it works just fine. I have absolutely no compulsion to use an SCM within my IDE... in fact, I would contend that a specialized tool designed to work specifically with the SCM is going to inevitably be more effective than something tacked on to my IDE.
I agree that's popular, but I don't think it's a good idea. Wouldn't it be better to have every check-in be stable?
Rose-coloured-glasses, much?
Besides, believe it or not, sometimes features are developed by *multiple* people. And those people need to work together and share their in-progress, possibly not-completed work through some mechanism. Some sort of... management system, if you will, for their source code.
I solve that by not having a ton of half-finished code. Ship early, ship often, I say.
Sorry, but some corporate clients are *not* happy with you dropping a new release every week. And this is doubly true if you work in the area of high-availability software. The idea that our company could just throw out a new code drop for every little feature is, quite frankly, laughable, given our product has to go through a third-party certification process.
And that's ignoring the case of large features developed by multiple people that are more than a few man-months worth of effort, which is also a common reality in the software world (not everyone is in the maintenance game).
Admittedly my code is rarely ever rolled back, but when I do have to it's as easy as choosing the commits included and in that piece of code and removing them.
Which is non-trivial when multiple people are working on the same codebase. It's the precise reverse of the merge problem. Although I would contend it's actually conceptually harder. It's much easier to look at a pair of changes and merge them, either automatically or manually. But trying to unwind two sets of intertwined changes is not my idea of a fun time.
I'm not against distributed SCM in anyway, but I will say that from everything I have read distributed SCM does not alleviate the need for manual conflict resolution in anyway shape or form
I never said it did. What I said was that users of distributed SCMs have discovered that conflicts simply aren't that big of a problem in everyday use.
Why do you have broken code in your working copy?
I don't have broken code in my working copy. I have in-progress code in my working branch. Why do I have that? Because the SCM exists to hold my code. It allows me to compare my code against mainline so I can review my changes. It allows me to incrementally update and revert my work as I go along. It allows me to ensure that all my changes are in an SCM which is backed up daily, so that I don't have to worry if my desktop crashes. It allows me to work in multiple locations on the same codebase. In short, it lets me use the SCM to manage my sourcecode, both my in-progress, working efforts, as well as the stable, in-production codebase.
Besides which, you seem to have this rosey picture that every commit is a good one. Believe it or not, people make mistakes. And when the guy down the hall accidentally breaks the database because his upgrade script is slightly b0rked, I don't want to waste time while they get their shit together.
And why is anyone committing code that either does not compile or does not pass your unit test suite?
Because no test suite covers all bases. And because people simply make mistakes.
Honestly, have you actually developed in the real world?
Huh? Why revert or delay anything.
I see you've completely missed the point. Here, let me be more explicit:
1. Project X has a deadline looming. In project X, management has scheduled features 1, 2, and 3 to be included.
2. A month before the deadline hits, the developers for feature 3 report that they are behind schedule and that feature 3 will have to be excluded from the release.
3. ?
The question is, what do you do at step 3. If you believe that all development should happen in trunk, then the developers now have to find a way to revert all the changes that make up feature 3 (naturally they've been using the SCM to interact amongst themselves). This could be an extremely non-trivial task depending on the complexity of the change.
Or, if you believe that all major development such as this should happen in branches, then the managers need only decide not to incorporate the changes from feature 3 into trunk.
And if you've never encountered this situation, I strongly question your experience, as this is pretty typical (just ask Microsoft about how WinFS is going).
Branch out only the stable code into your release branch.
Ha ha ha. Okay, now you're just being funny, right? What, you think you can just cherrypick changesets and build a release? Have you never built a large, non-trivial application with multiple developers? Or a database driven application where multiple, interlinked changes need to be made to the schema? Sorry, but the interdependency between changesets means that's just unrealistic in practice. And I've seen it tried... it ain't pretty, to say the least. Just the process of trawling through the changelog to identify all the mods that went into some feature, so that you can revert them, is an absolute frickin' nightmare. And that's ignoring the process of actually revertin
Are you saying your SCM doesn't let you revert/rollback without branching?
Are you saying that you enjoy having mainline broken while people are incrementally working on major code changes? Ignoring the fact that reverting changes can be a pain in the ass when multiple people are working on the same codebase.
Since it's merging that is the problem and not branching,
It is? Funny, I've never had that problem. Perhaps you should mention it to all those distributed SCM users. Even with subversion, merge management isn't that tough, as long as you're diligent and keep your working branch in sync with the eventual merge target.
. Branch of your release code, that should not have any significant work done on it, and do all you work in your main line,
So that my code can become broken while another developer incrementally works on a major change? Thanks but no thanks. I've experienced that, and it is, to say the least, really *really* annoying.
Not to mention the case where developer X is working on some major feature, and then scheduling restrictions force the team to push said feature out, into the next release. Which is easier? Delaying the merge, or reverting all the changes?
How people get anything done with their convoluted source control management totally amazes me sometimes.
Convoluted? How? I'm about to create new major feature X. I create a branch myproduct-feature-X. I work on that branch. When it's done, perhaps I send out a code review request, including the branch name. When I'm done, I instruct my SCM to merge from the branch back to trunk.
This is a *far* more sane way to manage major changes. It facilitates code review, makes it easy to gate changes through a change control system, and allows developers to use the full power of an SCM for incremental development. It's only convoluted to those who don't understand basic source control concepts.
Solution: stop checking in stuff that doesn't work.
You completely missed the point, didn't you? I said *large* features. You know, the kind where you have multiple developers working on various aspects of the problem, in which case it's most natural for them to interact through the SCM. Branches are the only sane way to handle this.
I don't have anything against local copies. It's kinda hard to change the code if you can't change the code.
Again, missed the point. Specifically, all the SCM bells and whistles. Local copies are a poor man's SCM. Better to just use a real SCM and get all the advantages that come with it.
This is true only if you're willing to pay the cost of slower code review. Longer feedback loops inevitably create greater waste than shorter ones.
*Slower* code review? What? How is being able to say "Do a diff of branch X against HEAD", or "check out X", not *faster* than manually handing out the code for review?
True. I use an IDE with undo for small cases of this, and reversion to head for large versions. But I think a better solution is to find mistakes early, so that screwing up is easy to fix.
Well of course. I never advocated otherwise. But in those cases where you *do* screw up, and I assume you screw up on occasion, using the SCM for what it was built for, changing tracking and control, makes it easier to revert broken code, etc.
I have never seen that not be the road to maintenance hell.
I never said it wasn't. But it's the reality for some companies.
I don't remember saying I've never seen the need for that. Perhaps you replied to the wrong post?
No, you said "So again, branching is what you do when a group fails to work effectively as a team." Or, to put it another way, people only advocate branching because their organization is broken. My point is, that's wrong.
When I'm building a unified product, what need would I have of branching and merging? If I'm not sure if something is a good enough idea to build, I don't build it. Or I build a quick, throw-away implementation to check an idea out. And then I throw it away.
So you've never implemented something and then wished you could revert a change that didn't work out? Or have never wanted to incrementally implement something without incorporating it into the final product until it was fully complete? Really?
It's because people have trouble forming teams and maintaining strong relationships in large groups.
No, it's because:
1) Software companies often need to create large, new features, and don't wish to destabilize the core product.
2) Or it's because it's *far* easier for developers to be able to branch pieces of code, work on feature or bugfix development in their own little playpen with all the SCM bells and whistles (being able to revert a messed up piece of code is awfully handy, even if you're the only one working on the codebase), and then merge those changes when they're ready. This also facilitates easier code review (just check out the branch) and change control as a nice added bonus.
3) Or because, in a more contract-oriented world, they might need to build customized applications for customers, and branch-and-merge strategies make that kind of code management possible.
Honestly, if you've never seen the need to branch-and-merge, you've never worked on a large project. Period.
Something tells me that any business interested in providing for-pay cloud computing services (you know, the only ones where you should expect any guarantee of data integrity) would handle a situation like this *far* better than Yahoo seems to have.
All you can credibly say is that based on the correlation detection functions you have used
Umm... "detection functions"? We're not talking about mystical heuristics, here. Computing correlation between two variables is, quite literally, basic statistical science.
Because C and D are completely random, whether you push A or not push A to you has absolutely no effect on the light as there is no correlation to it. But, inside the box, A is most certainly controlling the light.
All you're doing is introducing noise into the system. But over a long enough period of time, you can detect the signal, the correlation, in the noise. It's pretty easy, too. Leave the box for a year. Two years, without pressing the button. Then press it and hold. Why, lo and behold, the light starts going on and off. It's random, to be sure, but it starts happening.
But, you say, perhaps the first two years were just luck, and the light just happened not to blink that whole time. Well, sure, that may be, but statistically, given the rate of blinking after you push at, you can pretty safely surmise that pressing the button correlates to the light turning on and off. And by graphing the data you can demonstrate, quite trivially, that the probability of the light going on and off increases when the button is pressed. Guess what that is? *Correlation*.
But ignoring all this, the scenario you posit is "tricky" because the indicator, the light going on and off, has a lot of noise to it, thanks to the random behaviour. In the case of GW and sunspots, we're not talking about a system with a great deal of noise. We're talking about a steady trend that's clearly obvious in the temperature graphs. With that kind of data, it's absolutely trivial to demonstrate that the frequency of sunspots has absolutely no correlation to the data, as while the rate of sunspots increases and decreases on an 11-year cycle, the global temperature has steadily trended upward.
Daily Green : Gore calls for 90% CO2 Reduction
And Gore represents the entirety of the anti-pollution movement?
I think you need to do better than that.
Most hard core enviros
Right, wackos. So? Last I checked, they don't represent anything but the fringe environmentalists.
By this logic, I should rule out all of conservatism because of right-wing nutters like Rush.
Correlation is only good if you think you have all the variables involved.
What the hell are you talking about? If you're trying to prove that A causes B (in this case, sunspots cause GW), and you discover that there is no correlation between A and B, then A *cannot* be causing B. Period. End of story.
The case I came up with here might actually be not good, but I should think that for any given correlation detection algorithm, a case can be constructed that allows a genuinely causal relationship to escape it.
Uhh, no, you can't. If two events aren't correlated, then one *can't* be causing the other. That's part of the very fucking definition of causation. In order for A to cause B, there must be a correlation between the change in A and the change in B. Otherwise, there is no relationship between A and B, and therefore A does not cause B.
From what I gather from your responses, you encourage drivers to:
From what I gather from this response, you're about to set up a strawman.
1. pass on the right (speaking US streets)
2. slower traffic move left (into the passing lane)
3. not pay attention to traffic around
4. not be courteous to other drivers
Yup, there it is! Oddly, you don't try to knock it down, though, so I'm not sure what the point was.
Because without it, you wind up being limited by the weakest link in the immediately surrounding traffic. When this is a nonsensical & discourteous individual who doesn't pay attention to the cars around him/her, people must resort to nonsensical solutions to cater to that individual.
Ever heard the phrase, two wrongs don't make a right? Just because someone else is driving poorly, doesn't mean you have to be an aggressive jackass in response. All you're doing is aggravating an already dangerous situation.
But, you go right ahead... I'm sure you'll feel very smug and self-satisfied after your next car accident.
This is what we call an appeal to authority
Of course it is. That's because the authorities are educated on the topic, and thus have opinions, along with theories and evidence to back them up, that should be weighed more heavily than baseless comments from ignorant commenters on Slashdot, such as yourself.
The only rational thing to do was nothing.
So, I assume you're an award winning economist, then? Because most of *them* disagree quite strongly with your supposition, so I can only assume you have credentials to back up your, frankly, absurd suggestion.
It's not rocket science.
Neither is not being a jackass, but that seems to have escaped you, so I think it better not to take anything for granted...
I will, however, get up on the bumper of an asshole not paying attention to the road and those around him
Yes, excellent strategy. That way, they can not pay attention to you while you're riding their bumper. And then, when they slam on their breaks because something unexpected happens, they can not notice you're back there when you run into them at highway speeds.
Good plan. Real good.