Did you check the post I was replying to? It said something like this:
And why is it a copyright violation? Because you are not abiding by the author's terms.
This presumes that breaking any restriction (including those against activities which copyright law does not address) to be in and of itself a copyright violation, a flatly wrong assertion.
That's what I was addressing, and I'm fairly sure that my post was on-topic, correct and direct. Consequently, I'm not exactly sure what you're meaning to add via your follow-up; it frankly strikes me as a bit of a non-sequiteur (and a touch inaccurate; copyright law isn't as much under what conditions one is forbidden to redistribute as what activities, redistribution among them, one is forbidden from taking without permission of the copyright holder).
Re installing Mono on Linux, you might do well to use the GARNOME packages; that way, you're building everything from source to be installed under its own prefix, and thus avoiding dependency hell.
The DRM being used in FairPlay is, actually, quite fair. You pay less for the song you want, you get less rights.
Err-hrm.
Know what my interest in PlayFair is?
My girlfriend's got a few free songs via the Pepsi promotion, but she can't download (or, presumably, use) them with her computer -- she's on an unsupported platform. Having PlayFair available provides a way around that (albiet one that requires use of a Windows box or Mac for a bit).
This is, as far as I'm concerned, a legitimate use; and anyone who wants to block it can simply go to hell. I'm happy to respect copyright (and avoid distribution, public performance, and so forth of a given piece of media w/o the approval of its author or their successor in interest) -- but this EULA sh*t throwing extra restrictions above and beyond those that copyright law grants simply has to go. (As the designer and author of the copy protection/anti-reverse-engineering mechanism for my employer's hardware/software package -- a toolkit every bit as strong as I could design it to be -- I'm fully aware of the vaguely hypocritical position this puts me in).
As for your proposal of "play nice and it won't get worse" -- BS. It'll get worse no matter what, and I intend to make reasonable use of media I have now and in the future, whether or not it does so. Preventing people from getting to information stored on their own computers is a losing battle, "trusted computing" notwithstanding, and I have every intent of fighting it.
One way they could bugger this scheme is to have a proprietary interface to the MS and not release the low level driver in source (a'la nvidia).
My understanding is that the PS/2 Linux kit's hardware access works via virtualized hardware (such that the OS drivers, which they properly release source for, don't actually interact w/ the real hardware, but rather a deeper software interface which restricts the available actions). Conceivably something along those lines could be done here as well.
It's not the memory stick itself, it's what they layer on top (Magic Gate). Your vanilla MS slot -- no problem. A Magic Gate one -- big problem. I haven't dealt with these directly, but my circle of friends includes some of the folks involved in the PS/2 Linux port, so I've heard quite a bit of indirect ranting from folks I trust to know what they're talking about.
Since Sony's goal is to sell content they have an interest in protectiong -- which ya wanna bet they're using here?
"Fad" or "guesswork" my ass. Statistics is a very well-established branch, and I'd hazard that the math involved in the specific operations we're talking about here hasn't changed appreciably since the '50s.
The slippery slope you suggest is insane, at least on its scale: 3500 members out of a set of millions isn't a statistically significant sample, so any conclusions that were drawn would have huge ranges associated. (You've seen the whole x+-n% thing? That's the kind of output one gets from statistics, where the difference between x and the _real_ value is guaranteed to be inside n%. So, what one needs to do is determine how large n can be -- half a percentage point, maybe? -- and by that determine how many people to poll. Like I said before, it's high school math, if you went to a decent high school). So yes, it's less accurate -- but you know exactly how much less accurate, and can adjust your sample size until the inaccuracy is small enough to not actually affect anything.
Anyhow, there's a reason logic classes teach "slippery slope" as a fallacy: Because people can genuinely determine Thing A from Thing B, those who can rationalize Thing A still aren't necessarily going to support Thing B, even after they've become accustomed to the former.
The "fake people" thing is a misnomer, too. There aren't counts that include fake people, there are *projections* with *error rates* which are determined through entirely deterministic means. A full report still includes things like the number of real people polled, the methods used to select them (must MUST MUST be a random selection or the output comes out horribly skewed), the results from polling those real people, etc.
If you want to do something to help make democracy more representative of the people's will, I'd advise you look into some of the alternatives to simple plurality voting -- the Borda Count, Condorcet, Instant Runoff Voting, all of these result in a better election result, mostly by letting people vote for who they really want rather than voting against whoever they want least. Adopting one of those would be much much much more of a leap forward for American democracy than having a tightly-controlled census done by modern (or even 1950s) statistical methods would be a leap back.
Maybe -- but reading Memory Stick media without Sony's software is somewhere on the scale of "monumental"; they've got some serious protection in place there. So sure, you might be able to replace whatever internal flash the thing uses and boot your own OS -- but if you can't get to the hardware, what good does it do?
See the PS/2 for an example of what I'm talking 'bout; sony has a fully GPLed release of their custom kernel source, but still nobody but them can touch the hardware.
You're familiar with this thing called "statistics", right? It's a branch of mathematics, and while it can be used to all kinds of evil voodoo if misapplied, there are a few subsets which are pretty much universally well-understood (except, perhaps, by yourself). Statistical sampling is one of these fields. It's entirely well-understood what kinds of procedure are necessary to obtain an unbiased and statistically valid sampling of a set, and what kind of determinations (with what level of error rate) can be made. This isn't rocket science -- much of it's high school math.
As a consequence, it's possible for (gasp!) 3rd parties to audit the procedures, math and output of such an operation after-the-fact, and make sure it was done in accordance with prevailing practices. A staistical-sampling-based census would certainly need to have 3rd parties overseeing and auditing it -- but even with that done, it would be a dramatic savings of otherwise-wasted cost and effort.
Yes, copyright law makes restrictions on redistribution -- in particular, it says you can't do it at all without the copyright holder's permission.
The GPL, by contrast, says you *can* redistribute -- as long as you follow certain terms.
Thus, the GPL lets you do something (redistribute) that copyright alone won't allow.
Compare to reverse engineering; copyright law says nothing about reverse engineering, only redistribution, preparation of derivative works, public perforance, etc etc. Licenses that prohibit reverse engineering are thus preventing you from doing something that copyright law would allow, as distinct from the GPL.
It's not like the money that's spent on this is taken out of circulation, no? It's just moved somewhere else -- a company that pays its employees and (presumably) its shareholders [via dividends], who it turn spend it on... well, whatever they spend it on, which may or may not include feeding starving people.
Indeed, if the people who spend money on this are the kind of people who aren't inclined to give money to feed the starving, then it's to the benefit of those who are starving that the money is now out of their hands and in someone else's.
HuguesT: I was quite substantially enjoying a discussion we were having in a different thread, which you've left idle for some time now without replying. As you don't have any email address visible via this site, and a google for your nick brings up nothing promising, I'm reduced to asking here that this thread be continued, either on this site or via private mail.
I was something along the lines of employee #17 at MontaVista Software. When I came on, we were using BitKeeper under the zero-cost license (since we were using it to work on free software and could cope with having our changelogs published to the world). Larry McVoy changed the license after that to force us (yes, this was quite explicitly aimed at us) to switch to a commercial license; instead, being a budget-constrained startup, we chose to switch back to CVS.
First, though, we put three of our best developers on a side-project of trying to clean up CVS and adding support for some couldn't-live-without features (excepting, of course, those which couldn't possibly be added due to design constraints). When that project was cancelled (post-cleanup but pre-new features), they'd put together a CVS fork with all the functionality of the original enabled -- with 25% the number of lines of code! The three people I know who are most prone to making profane remarks regarding CVS, its design and implementation, are in fact programmers with intimate knowledge of its codebase. (Want names? Mark Hatle, Mark Ferrell, Paul Mundt. Feel free to do a bit of googling to determine their bona fides, but please don't bother them on account of this thread).
So -- I wouldn't be so sure that CVS developers would be so offended by my statement that CVS is a POS; the ones I know all agree.
CVS is as bug-free as any piece of software can be.
Simply untrue. LaTeX, perhaps, is as bug-free as software can be -- but just because you aren't hitting the CVS bugs doesn't mean they don't exist.
CVS gives different paths to server-side,v files depending on which command is being called. CVS fails to quote log entries to disambiguate them from end markers, making it impossible to machine-parse output. CVS has a vast array of designed-in pserver security holes. I've seen CVS corrupt CVS/Entries files on more than one occasion -- quite a few, for that matter.
When Arch has 1% of the usage that CVS has had I'll certainly consider using it.
If people chose their operating systems that way, we'd all be running Windows.
I know very well that CVS doesn't do moves and renames nicely, but you can still do them
No, you can't -- not for any reasonable meaning of the word. When I do a version-controlled move, I expect the following to happen:
File history is preserved and contiguous
A merge between a branch which moves a file and a branch which modifies a file results in the modified file being in the new location
Historical versions keep the file available with its original name
No mechanism for attribute #1 is available which does not violate attribute #3. Attribute #2 is not available at all. Thus, for any useful definition, CVS does not support moves.
and you can still do branching
For some crippled value of "branching". Branching is vastly less useful without history-sensitive merge support, because it's impossible to apply a patch to multiple branches and then later merge them without creating tons of extra work -- so people don't do it as much, even cases where (if it were truly a low-cost operation) it would be useful.
Only a few projects really need Arch's features
Of course. If you know that renames and moves don't work well, you don't get in the habit of using them much, so you don't "need" them. If you know that branches are a hassle, you don't use them much, so you don't "need" them. If you've never had history-sensitive merge support or distributed repositories, you don't know how useful they are, so you don't appreciate how much power they give you to choose your workflow.
and very few of them should be ready at this stage to trust Arch's implementation.
Arch's implementation is one helluva lot more trustworthy than CVS is, or SVN's. Let me explain why:
Arch, unlike SVN and (optionally) CVS, has no "smart server" and no data storage format more complicated than a bunch of tarballs with patch files in them. This means that even if Arch itself were to disappear tomorrow, I could take my Arch archive, unpack the files with tar, apply the patches via a shell script (though Arch's dopatch tool is easier), and have my source control history back. These tarballs, once they're committed, are never changed -- unlike a,v file that's rewritten whenever new history is created or a database that's likewise constantly modified. This likewise means that mirroring an Arch archive is just a matter of mirroring a collection of directories and tarballs; these can be written to CD or any write-once media if need be, because history is never allowed to change!
In short, Arch's core design is far better built for trustworthy source control management than any of its competitors.
I'd love to see the proportion of software projects, free or otherwise, that use 10,000 files.
The source control repository at my workplace is quite a bit larger than that -- and we're a fairly small and new company. As for Free Software, I'd look in the direction of Emacs, Linux, the BSDs, GCC, XFree86, and quite a few other p
It's fairly plausible that CVS broke his build -- it's happened before. Think "binary files with keyword expansion", for instance. I've also had a number of users of CSCVS (a tool I maintain) run into CVS repositories with previously undiscovered corruptions in the,v files resulting in old revisions being unrecoverable. (Yes, you too could have these issues -- unless you've tried checking out a 2-year-old copy of your code recently; while BitKeeper and Arch both have integrity-checking support for old revisions, CVS has nothing of the sort).
For a piece of software which is meant first and foremost to be a safe haven for code, this is seriously bad news. Knee-jerk "it must be your problem" responses are silly -- I've seen for a fact cases where it wasn't.
I'm the maintainer of CSCVS, a tool for breaking CVS repositories into changesets, reporting on them, and importing those changsets into TLA. As such, my familiarity with CVS (and Arch) goes beyond that of the average user.
Now, about the issues that Arch is designed to fix: Revisioning renames and moves is not something that comes up only infrequently. Revisioning metadata is not something that comes up only infrequently. Mutually merged branches are not something that come up only infrequently. Taking forever to do a "cvs update" on a 10,000 file tree because the tree needs to be walked to look for updates is not something that comes up only infrequently. I've had the lead developer at work bitching in my direction because CVS is coming up with spurious conflicts that Arch would ignore.
I have a leg to stand on right now, and if you'd care to stand up and try to argue your position on its merits rather than firing off some angry rant, I'd absolutely love to do so.
One of the things I liked most about Xouvert is their use of GNU Arch for tracking their tree. As a changeset-oriented revision control system (as opposed to a snapshot-oriented revision control system like Subversion, or a POS excuse for a revision control system like CVS), Arch made perfect sense for a project that's maintaining a branch (or several branches) of a heavily-forked project: capable of providing not only the snapshotted state of each branch but also aware of (and, indeed, focused around) which patches made it in at each changeset (and therefore capable of history-sensitive merging -- applying the patches that make sense to a given branch, without trying to apply ones which have already been merged in).
I'm a bit disappointed that Xorg isn't using Arch as well, since it seems like the perfect tool for the job. *sigh*.
You're using a severely oversimplified model. It doesn't account for things like economic costs of political fallout due to such practices, losses of economies of scale in advertising and marketing activities, costs of determining pricing on a subregional scale, etc etc.
So yes: Your argument is a cheap shot, a flawed one at that, and I'm not about to dignify it by running off to find evidence. (I suppose, then, that this thread is likely at an end -- it's been fun!).
If the market will bear a mark up, you can be pretty sure you'll see that markup
Then why hasn't it happened historically? Speculation is grand and all, but when your theory provides expectations of what *should* happen that don't actually match up with what *does* happen, it's time that the theory be revised.
I don't necessarily like Wal Mart all that much (my girlfriend works there as a low-level manager, and I endlessly hear her complaining about sexism at work), but the "Wal-Mart drives out local stores and raises prices" meme needs to die unless they really, in fact, do do this.
That's a foolish argument. The parent suggested that such a thing was possible and you replied by saying "prove it with an established case".
I just went back and reread the thread in its entirety. He didn't say "$FOO could happen"; he said "$FOO happens". When speaking of Wal-Mart raising prices after driving out local competition, he didn't say "could", he said "will". When speaking of Wal-Mart lowering prices to drive out new local competitors, he didn't say "could", he said "will".
...and after a few years of "Rollback"ed prices, the consumers are paying the same.
Not really. If Wal-Mart gets too greedy and raises their prices high enough to no longer require their economies of scale to be profitable, they're opening the door for any potential competitor able to raise enough capital to go into business against them.
That doesn't really work. I'll take the example of walmart. It's a big chain that comes in and ruins most of the small towns it goes into. What happens is they sell cheap (both in price and quality) goods at "low low prices." On the surface, providing low cost goods sounds great... However, they drive out the smaller stores and then when it's not profitable they pack up and leave. What's left? Not much... walmart destroys these towns and people let it happen. I often ask people why they shop at walmart and they say "because it's cheap." I start to explain about how bad walmart is but they say I know but they have cheap stuff.
That's not necessarly such a bad thing.
People who go to Wal Mart instead of their little local store are still spending their money in large part to pay for the (locally hired) cashiers, stockers, low-level managers, etc. Does Wal Mart hire less people than all those little local stores summed up? Maybe -- that's called an "economy of scale", and it's generally considered a Good Thing, because it results in greater overall efficiency. This efficiency has real benefits: Goods that used to be expensive are now cheap. That's a Good Thing, not least of all for the area's consumers. If I make 1/2 my old pay but only pay 1/3 what I used to for general consumer goods -- this means my buying power has increased; it's a Good Thing.
I for one care about my country and I don't like seeing it's economy being hurt by things like outsourcing.
In the same sense that I care about my country, I also care about my world. A more stable world economy means greater long-term stability for my country -- and eventually my immediate community, which is the bit I really am concerned about -- as well.
Maintaining a vastly different economy in different parts of the world just isn't sustainable, particularly given recent technological changes. Outsourcing, much as it may appear to be temporarily harmful, is one element in what will eventually be a much more stable global economy than is presently in case. I'm hurting for it -- base pay in my field has dropped from about $70K to about $30K in the last several years -- but I honestly think it's for the better over the long run.
So... tell me again why Wal Mart is such an evil thing?
Slashdot Mirror
Dashboard, which not too long ago got a reference on sweetcode.
That's what I was addressing, and I'm fairly sure that my post was on-topic, correct and direct. Consequently, I'm not exactly sure what you're meaning to add via your follow-up; it frankly strikes me as a bit of a non-sequiteur (and a touch inaccurate; copyright law isn't as much under what conditions one is forbidden to redistribute as what activities, redistribution among them, one is forbidden from taking without permission of the copyright holder).
Re installing Mono on Linux, you might do well to use the GARNOME packages; that way, you're building everything from source to be installed under its own prefix, and thus avoiding dependency hell.
The DRM being used in FairPlay is, actually, quite fair. You pay less for the song you want, you get less rights.
Err-hrm.
Know what my interest in PlayFair is?
My girlfriend's got a few free songs via the Pepsi promotion, but she can't download (or, presumably, use) them with her computer -- she's on an unsupported platform. Having PlayFair available provides a way around that (albiet one that requires use of a Windows box or Mac for a bit).
This is, as far as I'm concerned, a legitimate use; and anyone who wants to block it can simply go to hell. I'm happy to respect copyright (and avoid distribution, public performance, and so forth of a given piece of media w/o the approval of its author or their successor in interest) -- but this EULA sh*t throwing extra restrictions above and beyond those that copyright law grants simply has to go. (As the designer and author of the copy protection/anti-reverse-engineering mechanism for my employer's hardware/software package -- a toolkit every bit as strong as I could design it to be -- I'm fully aware of the vaguely hypocritical position this puts me in).
As for your proposal of "play nice and it won't get worse" -- BS. It'll get worse no matter what, and I intend to make reasonable use of media I have now and in the future, whether or not it does so. Preventing people from getting to information stored on their own computers is a losing battle, "trusted computing" notwithstanding, and I have every intent of fighting it.
One way they could bugger this scheme is to have a proprietary interface to the MS and not release the low level driver in source (a'la nvidia).
My understanding is that the PS/2 Linux kit's hardware access works via virtualized hardware (such that the OS drivers, which they properly release source for, don't actually interact w/ the real hardware, but rather a deeper software interface which restricts the available actions). Conceivably something along those lines could be done here as well.
It's not the memory stick itself, it's what they layer on top (Magic Gate). Your vanilla MS slot -- no problem. A Magic Gate one -- big problem. I haven't dealt with these directly, but my circle of friends includes some of the folks involved in the PS/2 Linux port, so I've heard quite a bit of indirect ranting from folks I trust to know what they're talking about.
Since Sony's goal is to sell content they have an interest in protectiong -- which ya wanna bet they're using here?
"Fad" or "guesswork" my ass. Statistics is a very well-established branch, and I'd hazard that the math involved in the specific operations we're talking about here hasn't changed appreciably since the '50s.
The slippery slope you suggest is insane, at least on its scale: 3500 members out of a set of millions isn't a statistically significant sample, so any conclusions that were drawn would have huge ranges associated. (You've seen the whole x+-n% thing? That's the kind of output one gets from statistics, where the difference between x and the _real_ value is guaranteed to be inside n%. So, what one needs to do is determine how large n can be -- half a percentage point, maybe? -- and by that determine how many people to poll. Like I said before, it's high school math, if you went to a decent high school). So yes, it's less accurate -- but you know exactly how much less accurate, and can adjust your sample size until the inaccuracy is small enough to not actually affect anything.
Anyhow, there's a reason logic classes teach "slippery slope" as a fallacy: Because people can genuinely determine Thing A from Thing B, those who can rationalize Thing A still aren't necessarily going to support Thing B, even after they've become accustomed to the former.
The "fake people" thing is a misnomer, too. There aren't counts that include fake people, there are *projections* with *error rates* which are determined through entirely deterministic means. A full report still includes things like the number of real people polled, the methods used to select them (must MUST MUST be a random selection or the output comes out horribly skewed), the results from polling those real people, etc.
If you want to do something to help make democracy more representative of the people's will, I'd advise you look into some of the alternatives to simple plurality voting -- the Borda Count, Condorcet, Instant Runoff Voting, all of these result in a better election result, mostly by letting people vote for who they really want rather than voting against whoever they want least. Adopting one of those would be much much much more of a leap forward for American democracy than having a tightly-controlled census done by modern (or even 1950s) statistical methods would be a leap back.
Maybe -- but reading Memory Stick media without Sony's software is somewhere on the scale of "monumental"; they've got some serious protection in place there. So sure, you might be able to replace whatever internal flash the thing uses and boot your own OS -- but if you can't get to the hardware, what good does it do?
See the PS/2 for an example of what I'm talking 'bout; sony has a fully GPLed release of their custom kernel source, but still nobody but them can touch the hardware.
You're familiar with this thing called "statistics", right? It's a branch of mathematics, and while it can be used to all kinds of evil voodoo if misapplied, there are a few subsets which are pretty much universally well-understood (except, perhaps, by yourself). Statistical sampling is one of these fields. It's entirely well-understood what kinds of procedure are necessary to obtain an unbiased and statistically valid sampling of a set, and what kind of determinations (with what level of error rate) can be made. This isn't rocket science -- much of it's high school math.
As a consequence, it's possible for (gasp!) 3rd parties to audit the procedures, math and output of such an operation after-the-fact, and make sure it was done in accordance with prevailing practices. A staistical-sampling-based census would certainly need to have 3rd parties overseeing and auditing it -- but even with that done, it would be a dramatic savings of otherwise-wasted cost and effort.
And no, I'm not a Democrat.
Yes, copyright law makes restrictions on redistribution -- in particular, it says you can't do it at all without the copyright holder's permission.
The GPL, by contrast, says you *can* redistribute -- as long as you follow certain terms.
Thus, the GPL lets you do something (redistribute) that copyright alone won't allow.
Compare to reverse engineering; copyright law says nothing about reverse engineering, only redistribution, preparation of derivative works, public perforance, etc etc. Licenses that prohibit reverse engineering are thus preventing you from doing something that copyright law would allow, as distinct from the GPL.
Clear now?
It's not like the money that's spent on this is taken out of circulation, no? It's just moved somewhere else -- a company that pays its employees and (presumably) its shareholders [via dividends], who it turn spend it on... well, whatever they spend it on, which may or may not include feeding starving people.
Indeed, if the people who spend money on this are the kind of people who aren't inclined to give money to feed the starving, then it's to the benefit of those who are starving that the money is now out of their hands and in someone else's.
HuguesT: I was quite substantially enjoying a discussion we were having in a different thread, which you've left idle for some time now without replying. As you don't have any email address visible via this site, and a google for your nick brings up nothing promising, I'm reduced to asking here that this thread be continued, either on this site or via private mail.
Thanks! (And sorry, all others, for the noise).
By the way:
I was something along the lines of employee #17 at MontaVista Software. When I came on, we were using BitKeeper under the zero-cost license (since we were using it to work on free software and could cope with having our changelogs published to the world). Larry McVoy changed the license after that to force us (yes, this was quite explicitly aimed at us) to switch to a commercial license; instead, being a budget-constrained startup, we chose to switch back to CVS.
First, though, we put three of our best developers on a side-project of trying to clean up CVS and adding support for some couldn't-live-without features (excepting, of course, those which couldn't possibly be added due to design constraints). When that project was cancelled (post-cleanup but pre-new features), they'd put together a CVS fork with all the functionality of the original enabled -- with 25% the number of lines of code! The three people I know who are most prone to making profane remarks regarding CVS, its design and implementation, are in fact programmers with intimate knowledge of its codebase. (Want names? Mark Hatle, Mark Ferrell, Paul Mundt. Feel free to do a bit of googling to determine their bona fides, but please don't bother them on account of this thread).
So -- I wouldn't be so sure that CVS developers would be so offended by my statement that CVS is a POS; the ones I know all agree.
Simply untrue. LaTeX, perhaps, is as bug-free as software can be -- but just because you aren't hitting the CVS bugs doesn't mean they don't exist.
CVS gives different paths to server-side ,v files depending on which command is being called. CVS fails to quote log entries to disambiguate them from end markers, making it impossible to machine-parse output. CVS has a vast array of designed-in pserver security holes. I've seen CVS corrupt CVS/Entries files on more than one occasion -- quite a few, for that matter.
If people chose their operating systems that way, we'd all be running Windows.
No, you can't -- not for any reasonable meaning of the word. When I do a version-controlled move, I expect the following to happen:
No mechanism for attribute #1 is available which does not violate attribute #3. Attribute #2 is not available at all. Thus, for any useful definition, CVS does not support moves.
For some crippled value of "branching". Branching is vastly less useful without history-sensitive merge support, because it's impossible to apply a patch to multiple branches and then later merge them without creating tons of extra work -- so people don't do it as much, even cases where (if it were truly a low-cost operation) it would be useful.
Of course. If you know that renames and moves don't work well, you don't get in the habit of using them much, so you don't "need" them. If you know that branches are a hassle, you don't use them much, so you don't "need" them. If you've never had history-sensitive merge support or distributed repositories, you don't know how useful they are, so you don't appreciate how much power they give you to choose your workflow.
Arch's implementation is one helluva lot more trustworthy than CVS is, or SVN's. Let me explain why:
Arch, unlike SVN and (optionally) CVS, has no "smart server" and no data storage format more complicated than a bunch of tarballs with patch files in them. This means that even if Arch itself were to disappear tomorrow, I could take my Arch archive, unpack the files with tar, apply the patches via a shell script (though Arch's dopatch tool is easier), and have my source control history back. These tarballs, once they're committed, are never changed -- unlike a ,v file that's rewritten whenever new history is created or a database that's likewise constantly modified. This likewise means that mirroring an Arch archive is just a matter of mirroring a collection of directories and tarballs; these can be written to CD or any write-once media if need be, because history is never allowed to change!
In short, Arch's core design is far better built for trustworthy source control management than any of its competitors.
The source control repository at my workplace is quite a bit larger than that -- and we're a fairly small and new company. As for Free Software, I'd look in the direction of Emacs, Linux, the BSDs, GCC, XFree86, and quite a few other p
It's fairly plausible that CVS broke his build -- it's happened before. Think "binary files with keyword expansion", for instance. I've also had a number of users of CSCVS (a tool I maintain) run into CVS repositories with previously undiscovered corruptions in the ,v files resulting in old revisions being unrecoverable. (Yes, you too could have these issues -- unless you've tried checking out a 2-year-old copy of your code recently; while BitKeeper and Arch both have integrity-checking support for old revisions, CVS has nothing of the sort).
For a piece of software which is meant first and foremost to be a safe haven for code, this is seriously bad news. Knee-jerk "it must be your problem" responses are silly -- I've seen for a fact cases where it wasn't.
What have you done for Free Software?
I'm the maintainer of CSCVS, a tool for breaking CVS repositories into changesets, reporting on them, and importing those changsets into TLA. As such, my familiarity with CVS (and Arch) goes beyond that of the average user.
Now, about the issues that Arch is designed to fix: Revisioning renames and moves is not something that comes up only infrequently. Revisioning metadata is not something that comes up only infrequently. Mutually merged branches are not something that come up only infrequently. Taking forever to do a "cvs update" on a 10,000 file tree because the tree needs to be walked to look for updates is not something that comes up only infrequently. I've had the lead developer at work bitching in my direction because CVS is coming up with spurious conflicts that Arch would ignore.
I have a leg to stand on right now, and if you'd care to stand up and try to argue your position on its merits rather than firing off some angry rant, I'd absolutely love to do so.
You do realize that "by the rules, and fast" is an inherent contradition?
One of the things I liked most about Xouvert is their use of GNU Arch for tracking their tree. As a changeset-oriented revision control system (as opposed to a snapshot-oriented revision control system like Subversion, or a POS excuse for a revision control system like CVS), Arch made perfect sense for a project that's maintaining a branch (or several branches) of a heavily-forked project: capable of providing not only the snapshotted state of each branch but also aware of (and, indeed, focused around) which patches made it in at each changeset (and therefore capable of history-sensitive merging -- applying the patches that make sense to a given branch, without trying to apply ones which have already been merged in).
I'm a bit disappointed that Xorg isn't using Arch as well, since it seems like the perfect tool for the job. *sigh*.
You're using a severely oversimplified model. It doesn't account for things like economic costs of political fallout due to such practices, losses of economies of scale in advertising and marketing activities, costs of determining pricing on a subregional scale, etc etc.
So yes: Your argument is a cheap shot, a flawed one at that, and I'm not about to dignify it by running off to find evidence. (I suppose, then, that this thread is likely at an end -- it's been fun!).
If the market will bear a mark up, you can be pretty sure you'll see that markup
Then why hasn't it happened historically? Speculation is grand and all, but when your theory provides expectations of what *should* happen that don't actually match up with what *does* happen, it's time that the theory be revised.
I don't necessarily like Wal Mart all that much (my girlfriend works there as a low-level manager, and I endlessly hear her complaining about sexism at work), but the "Wal-Mart drives out local stores and raises prices" meme needs to die unless they really, in fact, do do this.
That's a foolish argument. The parent suggested that such a thing was possible and you replied by saying "prove it with an established case".
I just went back and reread the thread in its entirety. He didn't say "$FOO could happen"; he said "$FOO happens". When speaking of Wal-Mart raising prices after driving out local competition, he didn't say "could", he said "will". When speaking of Wal-Mart lowering prices to drive out new local competitors, he didn't say "could", he said "will".
Your post is pure revisionism.
Show me the evidence of Wal Mart raising prices to extract monopoly rents after driving out local competition.
Go on, I'm waiting.
...and after a few years of "Rollback"ed prices, the consumers are paying the same.
Not really. If Wal-Mart gets too greedy and raises their prices high enough to no longer require their economies of scale to be profitable, they're opening the door for any potential competitor able to raise enough capital to go into business against them.
That's sarcasm, right?
It's so hard to tell without seeing ones' face...
People who go to Wal Mart instead of their little local store are still spending their money in large part to pay for the (locally hired) cashiers, stockers, low-level managers, etc. Does Wal Mart hire less people than all those little local stores summed up? Maybe -- that's called an "economy of scale", and it's generally considered a Good Thing, because it results in greater overall efficiency. This efficiency has real benefits: Goods that used to be expensive are now cheap. That's a Good Thing, not least of all for the area's consumers. If I make 1/2 my old pay but only pay 1/3 what I used to for general consumer goods -- this means my buying power has increased; it's a Good Thing.In the same sense that I care about my country, I also care about my world. A more stable world economy means greater long-term stability for my country -- and eventually my immediate community, which is the bit I really am concerned about -- as well.
Maintaining a vastly different economy in different parts of the world just isn't sustainable, particularly given recent technological changes. Outsourcing, much as it may appear to be temporarily harmful, is one element in what will eventually be a much more stable global economy than is presently in case. I'm hurting for it -- base pay in my field has dropped from about $70K to about $30K in the last several years -- but I honestly think it's for the better over the long run.
So... tell me again why Wal Mart is such an evil thing?