Silicon Valley is not just a place with a bunch of nerds working in an internet factory, its an ecosystem of cultural diversity built around technology, art and science.
Cultural diversity? You mean that not everybody in SV is white bread? Somewhere I heard a rumor that it's not the only place in the US like that.
Pray tell which art you speak of. I think there's a museum in SF. NYC's rumored to have more than one. Any other use of the word is hype.
Science is also not a biggie in SV. Tech yes, but not much science, other than what you'd expect to find at a couple of highly rated universities. Again, rumors abound of those places outside the province of SV.
P.S. This is an ecosystem. You're using a threadbare metaphor beloved of Bill Gates when rationalizing why he doesn't hire hit squads to take out FOSS devs.
Unless your tech company is providing services which require a physical presence, what's the appeal of NYC? Real estate prices alone are a very compelling reason to locate elsewhere.
The same is true of Silicon Valley or San Francisco, but they're "the" places. VC's only seems to recognize things within a short range of their offices, or on the other side of the planet.
I know the standard argument for SV or SF is that there's a lot of talent there, but that doesn't jibe with those who complain about how hard it is to hire people. Which is it folks? There are some very good talent pools in places like Pittsburgh, South Florida, etc., but they're not the cool places, dontchaknow.
No cutting edge tech person wants to work in Brooklyn when they can work in Manhattan.
Manhattan is where we send the rubes that don't know any better. Ed Norton got it right when he told a reporter where he lived: the garden spot of the world, Brooklyn USA!
So, it's educated middle class people in the city protesting that politicians aren't giving them stuff cheaper and that politicians are wasting their money. Remember that Brazil is under a left-wing government headed by the PT (Worker's Party). At least it's not Venezuela, where the left wing government managed to produce a shortage of toilet paper; you really don't want to have riots involving large numbers of people lacking toilet paper; it's likely to be smelly.
Of course, if Brazil had a free market kind of government, some people would be protesting against that as well because they think they aren't getting their "fair share". They'd want a left wing government that gives them "free stuff", until that left wing government predictably fails to be able to deliver, and then they protest against that. Well, as long as the stay away from fascist or theocratic government and don't run out of toilet paper, the Brazilians should still be mostly OK.
Silly question: do you actually know much about Brazilian politics and economics, or did you just use a sound bite statistic from one article to justify your generic ideological rant?
Agreed. Earlier someone wrote about India that people shouldn't be too US-centric in thinking about the motivation for their wire tapping. But now? Two countries doing the same thing is a coincidence, three is a trend. On the bright side, the USA still leads the way! Oh, hold it...
If users had write access to the black-box, then trust in it wouldn't exist, thus defeating the point of the black-box itself. You can make-up any data and put it in there, including fake video footage.
By that reasoning almost all video and photos should not be allowed as evidence. How easy do you think it is to fake video of your car getting hit? Any video or photo is much better than the fabled eyewitness testimony, which has been shown to be incredibly unreliable, even if the witness has no vested interest in the outcome.
Dashboard cams are very common in Russia. That's why so many people got good shots of the meteorites. Apparently the cams are useful when dealing with some of the local LEO's.
Get hourly updates featuring -Vague laws misinterpreted by engineers to be threats to privacy/civil liberties -The latest release of every obscure Linux distro and its shortcomings compared to 10 other distros -Factually spurious articles about the death of the IT industry. -Philosophical flame wars about the validity of alternative energy/electric cars -Mental masturbation regarding drones/macs/climate change -Hypothetical discussions of Rasberry Pi created by Arduino driven 3-D printers purchased with BitCoins. -Windows 8 trolling
You forgot Version Control Wars. 361 comments on that alone (I think I wrote about half of them).
How about a Cloud OS? A VM OS that lives in the cloud and sends screens (instead of data) to your PC, tablet, phone, etc. It will have blazing fast network access, can add cores, RAM, disk space with a click.
Yes, I believe the SVN buzzword for that is cherry picking.
Yes, that is the Git buzzword. I don't think SVN has a buzzword for it.
Normally I don't care what buzzwords people use as long as the meaning is clear. However since you make an minor issue of it, I feel free to get in touch with my inner pedant. "Cherrypicking" is the exact term used in SVN. However I spelled it as two words instead of one. Merriam-Webster lists it as a hyphenated word. We must standardize!
In fact, doing a "svn merge -r X:Y ^/project/trunk" is even part of an example in the latest documentation
I do that all the time and it's very useful. The problem (or at least the thing I'm unclear about being reliable) is "svn merge -r A:B ^/project/trunk branch1wc/" followed some time later by ""svn merge -r C:D ^/project/branches/branch1 trunkwc/" (C > B). Some would argue that you shouldn't be switching back and forth like that in the direction of selective merges, and generally I agree, but in the real world people sometimes put the fix on the "wrong" branch (whether out of sloppiness or for some good reason) and that back and forth is then difficult to deal with.
I still believe that western civ peaked in the 1960's: that was the last time in history that a project like Apollo could be sustained for 8 straight years without silliness like this happening every session of Congress.
It was funded for 8 straight years because the space race was a sideshow to the cold war and, after the USSR put both the first satellite and the first human into space, a matter of national pride. There were more Apollo missions planned originally, but they got defunded. That was idiotic considering all the sunk costs. The best chance for the US to get to Mars is if China gets to the moon.
The best way to encourage children to get STEM degrees is to create high paying STEM jobs. Pay scientists and engineers what we pay CEOs and sports stars, and you'll start to see the culture change.
How crass. If STEM people want money it means Americans are lazy and won't accept delayed gratification. That's what CEO's and their sycophantic politicians say anyway.
The House and Senate pay for things just as much as you pay for your groceries. While their income source may be my taxes and your taxes, that money is in their account to spend.
Congress can change taxes more arbitrarily than I can change my income. They can also borrow money. Me too, but when the bill comes due I'm personally responsible for it. Not so congress. I'm neither an anti-tax fanatic nor a deficit hawk, but to act as though congress were terribly constrained, or suffer the consequences for excessive government debt in the same sense I suffer for excess personal debt, is ridiculous. We taxpayers really do foot the bill.
Sending robots helps to advance robotics, sending people helps to advance humanity.
You just used targetted merges instead of a reintegration merge - e.g. specify which revisions to merge over.
Yes, I believe the SVN buzzword for that is cherry picking. I do it all the time to, for example, merge a fix in one rev of the trunk into a release branch. That's not the problem. The difficulty is when sometimes you want to do a cherry picked merge from trunk to branch, and the later do a cherry pick merge from branch into trunk. SVN gets confused about that. I admit I haven't done many experiments in that regard, since I don't want to mess up work in progress. However, it's not part of any workflows in the book, and certainly appears to violate some of the rules. Even if it works sometimes, I wouldn't want to rely on it. The only other possibility I can think of is that my understanding is messed up somehow. Frankly I doubt it, but if it's true I'd be very grateful for a correction.
Don't you like to review your changes before committing them?
Absolutely! That's why I always do hg diff (without any more parameters) before committing.
I also always do a diff before committing. Plus I build and test, then commit everything I've built. The whole idea of moving only some changes to the staging area and then doing a partial commit sounds like a real invitation to problems.
That's just working around the limitations of your tool. I use and in many ways I like SVN, but those tree conflicts can drive me nuts. Another problem with SVN is that if you make identical changes to two branches, either in the tree structure (perhaps just deleting a file) or in the source, and you try to merge those branches it complains about conflicts instead of realizing that there is no conflict if the exact same changes were made to both branches. I know you're not supposed to work that way, but sometimes it happens, and it would be nice if the tool dealt with it.
But have you ever tried what the PP was talking about? There are lots of things that should work, but you can't be sure until you've tried it. He was talking about a 1TB repository, and large binaries often don't compress or diff well (no matter how good your diff engine), so how big would your local Git repository be?
BTW, what he says about Perforce being a good choice for large binaries is something I've heard from a number of knowledgeable people. They all agree Perforce is much better for that than SVN. I don't know about Git, but I wouldn't act confident about it unless you've used it that way.
I hate this version of work......I have some coworkers who always do it. They occasionally forget to merge something back into head, which means they have to revisit the same problem in a few months.
I've found that a good way to prevent that from happening again is to summarily execute the offender and hang his or her corpse from the flag pole as a reminder to others.
There's also Murphy's Law corollary that says that no matter what your preferred workflow is, there will come a day when doing it differently is necessary or expedient. For example, trunk may be temporarily unstable, which means you wind up fixing the bug on the branch. Of course trunk is never supposed to be unstable, but there are a lot of things that aren't supposed to happen. A good tool shouldn't keep you from working differently when necessary (which is what at least pre-1.8 svn does, or makes it very difficult to do anyway).
Silicon Valley is not just a place with a bunch of nerds working in an internet factory, its an ecosystem of cultural diversity built around technology, art and science.
Cultural diversity? You mean that not everybody in SV is white bread? Somewhere I heard a rumor that it's not the only place in the US like that.
Pray tell which art you speak of. I think there's a museum in SF. NYC's rumored to have more than one. Any other use of the word is hype.
Science is also not a biggie in SV. Tech yes, but not much science, other than what you'd expect to find at a couple of highly rated universities. Again, rumors abound of those places outside the province of SV.
P.S. This is an ecosystem. You're using a threadbare metaphor beloved of Bill Gates when rationalizing why he doesn't hire hit squads to take out FOSS devs.
I think for tech companies to be located near universities is also an advantage, because it gives them access to interns and makes recruiting easier.
No shortage in NYC. Columbia, NYU and a host of smaller but often very good schools.
Unless your tech company is providing services which require a physical presence, what's the appeal of NYC? Real estate prices alone are a very compelling reason to locate elsewhere.
The same is true of Silicon Valley or San Francisco, but they're "the" places. VC's only seems to recognize things within a short range of their offices, or on the other side of the planet.
I know the standard argument for SV or SF is that there's a lot of talent there, but that doesn't jibe with those who complain about how hard it is to hire people. Which is it folks? There are some very good talent pools in places like Pittsburgh, South Florida, etc., but they're not the cool places, dontchaknow.
No cutting edge tech person wants to work in Brooklyn when they can work in Manhattan.
Manhattan is where we send the rubes that don't know any better. Ed Norton got it right when he told a reporter where he lived: the garden spot of the world, Brooklyn USA!
So, it's educated middle class people in the city protesting that politicians aren't giving them stuff cheaper and that politicians are wasting their money. Remember that Brazil is under a left-wing government headed by the PT (Worker's Party). At least it's not Venezuela, where the left wing government managed to produce a shortage of toilet paper; you really don't want to have riots involving large numbers of people lacking toilet paper; it's likely to be smelly.
Of course, if Brazil had a free market kind of government, some people would be protesting against that as well because they think they aren't getting their "fair share". They'd want a left wing government that gives them "free stuff", until that left wing government predictably fails to be able to deliver, and then they protest against that. Well, as long as the stay away from fascist or theocratic government and don't run out of toilet paper, the Brazilians should still be mostly OK.
Silly question: do you actually know much about Brazilian politics and economics, or did you just use a sound bite statistic from one article to justify your generic ideological rant?
Since this is becoming a global trend
Agreed. Earlier someone wrote about India that people shouldn't be too US-centric in thinking about the motivation for their wire tapping. But now? Two countries doing the same thing is a coincidence, three is a trend. On the bright side, the USA still leads the way! Oh, hold it ...
If users had write access to the black-box, then trust in it wouldn't exist, thus defeating the point of the black-box itself. You can make-up any data and put it in there, including fake video footage.
By that reasoning almost all video and photos should not be allowed as evidence. How easy do you think it is to fake video of your car getting hit? Any video or photo is much better than the fabled eyewitness testimony, which has been shown to be incredibly unreliable, even if the witness has no vested interest in the outcome.
"In America, you watch Television.
"In Soviet Russia, television watches YOU!!"''
This time you've got it backwards.
Dashboard cams are very common in Russia. That's why so many people got good shots of the meteorites. Apparently the cams are useful when dealing with some of the local LEO's.
Introducing the new Slashdot Phone!
Get hourly updates featuring
-Vague laws misinterpreted by engineers to be threats to privacy/civil liberties
-The latest release of every obscure Linux distro and its shortcomings compared to 10 other distros
-Factually spurious articles about the death of the IT industry.
-Philosophical flame wars about the validity of alternative energy/electric cars
-Mental masturbation regarding drones/macs/climate change
-Hypothetical discussions of Rasberry Pi created by Arduino driven 3-D printers purchased with BitCoins.
-Windows 8 trolling
You forgot Version Control Wars. 361 comments on that alone (I think I wrote about half of them).
How about a Cloud OS? A VM OS that lives in the cloud and sends screens (instead of data) to your PC, tablet, phone, etc. It will have blazing fast network access, can add cores, RAM, disk space with a click.
I believe it's called a mainframe.
So the nuts can use social networking too. Heck of a lot faster than mailing your insane manifesto to news organizations.
Would have been interesting if Twitter was around in the days of the Unabomber (and incredibly ironic if he used it).
Having the public outraged against war is what got the soldiers OUT of Viet Nam before they were all massacred.
The US won every major battle in the Veitnam war until they decided to leave. ... In the Tet Offensive, 32 NVA died for every US death ...
All true, but 58,000 US soldiers killed is more than enough for my tastes. The GP can be forgiven a little hyperbole.
Nixon got the troops out. I've always felt he didn't get the credit for that he deserved.
Maybe because he got them out years later than he could have.
This is the real damage the NSA has done in spying on the American people. Now every other country feels like they need it, because the US does.
What you call "damage" others call "export market".
Yes, I believe the SVN buzzword for that is cherry picking.
Yes, that is the Git buzzword. I don't think SVN has a buzzword for it.
Normally I don't care what buzzwords people use as long as the meaning is clear. However since you make an minor issue of it, I feel free to get in touch with my inner pedant. "Cherrypicking" is the exact term used in SVN. However I spelled it as two words instead of one. Merriam-Webster lists it as a hyphenated word. We must standardize!
In fact, doing a "svn merge -r X:Y ^/project/trunk" is even part of an example in the latest documentation
I do that all the time and it's very useful. The problem (or at least the thing I'm unclear about being reliable) is "svn merge -r A:B ^/project/trunk branch1wc/" followed some time later by ""svn merge -r C:D ^/project/branches/branch1 trunkwc/" (C > B). Some would argue that you shouldn't be switching back and forth like that in the direction of selective merges, and generally I agree, but in the real world people sometimes put the fix on the "wrong" branch (whether out of sloppiness or for some good reason) and that back and forth is then difficult to deal with.
I still believe that western civ peaked in the 1960's: that was the last time in history that a project like Apollo could be sustained for 8 straight years without silliness like this happening every session of Congress.
It was funded for 8 straight years because the space race was a sideshow to the cold war and, after the USSR put both the first satellite and the first human into space, a matter of national pride. There were more Apollo missions planned originally, but they got defunded. That was idiotic considering all the sunk costs. The best chance for the US to get to Mars is if China gets to the moon.
The best way to encourage children to get STEM degrees is to create high paying STEM jobs. Pay scientists and engineers what we pay CEOs and sports stars, and you'll start to see the culture change.
How crass. If STEM people want money it means Americans are lazy and won't accept delayed gratification. That's what CEO's and their sycophantic politicians say anyway.
The House and Senate pay for things just as much as you pay for your groceries. While their income source may be my taxes and your taxes, that money is in their account to spend.
Congress can change taxes more arbitrarily than I can change my income. They can also borrow money. Me too, but when the bill comes due I'm personally responsible for it. Not so congress. I'm neither an anti-tax fanatic nor a deficit hawk, but to act as though congress were terribly constrained, or suffer the consequences for excessive government debt in the same sense I suffer for excess personal debt, is ridiculous. We taxpayers really do foot the bill.
Sending robots helps to advance robotics, sending people helps to advance humanity.
Agreed. I vote for the robots.
It's also working around the limitation of my brain.
If you have a brain, you're in the wrong line of work.
You just used targetted merges instead of a reintegration merge - e.g. specify which revisions to merge over.
Yes, I believe the SVN buzzword for that is cherry picking. I do it all the time to, for example, merge a fix in one rev of the trunk into a release branch. That's not the problem. The difficulty is when sometimes you want to do a cherry picked merge from trunk to branch, and the later do a cherry pick merge from branch into trunk. SVN gets confused about that. I admit I haven't done many experiments in that regard, since I don't want to mess up work in progress. However, it's not part of any workflows in the book, and certainly appears to violate some of the rules. Even if it works sometimes, I wouldn't want to rely on it. The only other possibility I can think of is that my understanding is messed up somehow. Frankly I doubt it, but if it's true I'd be very grateful for a correction.
Don't you like to review your changes before committing them?
Absolutely! That's why I always do hg diff (without any more parameters) before committing.
I also always do a diff before committing. Plus I build and test, then commit everything I've built. The whole idea of moving only some changes to the staging area and then doing a partial commit sounds like a real invitation to problems.
That's just working around the limitations of your tool. I use and in many ways I like SVN, but those tree conflicts can drive me nuts. Another problem with SVN is that if you make identical changes to two branches, either in the tree structure (perhaps just deleting a file) or in the source, and you try to merge those branches it complains about conflicts instead of realizing that there is no conflict if the exact same changes were made to both branches. I know you're not supposed to work that way, but sometimes it happens, and it would be nice if the tool dealt with it.
I am aware of no sound basis for that statement.
But have you ever tried what the PP was talking about? There are lots of things that should work, but you can't be sure until you've tried it. He was talking about a 1TB repository, and large binaries often don't compress or diff well (no matter how good your diff engine), so how big would your local Git repository be?
BTW, what he says about Perforce being a good choice for large binaries is something I've heard from a number of knowledgeable people. They all agree Perforce is much better for that than SVN. I don't know about Git, but I wouldn't act confident about it unless you've used it that way.
Sounds good. Out of curiosity, are you saying these things based on the release notes, or have you tried it with a pre-release version or something?
I hate this version of work......I have some coworkers who always do it. They occasionally forget to merge something back into head, which means they have to revisit the same problem in a few months.
I've found that a good way to prevent that from happening again is to summarily execute the offender and hang his or her corpse from the flag pole as a reminder to others.
There's also Murphy's Law corollary that says that no matter what your preferred workflow is, there will come a day when doing it differently is necessary or expedient. For example, trunk may be temporarily unstable, which means you wind up fixing the bug on the branch. Of course trunk is never supposed to be unstable, but there are a lot of things that aren't supposed to happen. A good tool shouldn't keep you from working differently when necessary (which is what at least pre-1.8 svn does, or makes it very difficult to do anyway).