How so? You can use BK to do work on the linux kernel just like anyone else. What does that have anything to do with your work on free RCS alternatives?
I don't qualify for the zero-cost form of the BitKeeper license. Thus, I can't use it for working on the Linux kernel, or anything else.
From everything I've seen or heard, nothing comes close to BK in terms of features or ease of use. I have been keeping an eye on the free alternatives, and so far I haven't seen any evidence that they can hold a candle to BK, except for the fact that I like the BSD/LGPL license better than BKs.
Look more closely at Arch. The only features that stand out in my mind from when I used BK that Arch doesn't have are the graphical merge tools. Personally, I don't need them -- and even so, there are folks working on alternatives.
The only large production OSS project that I know of that uses BK is Linux, and I think it would be quite hard to argue that BK is destructive in that case.
As opposed to "using no revision control", sure, using BK is a huge gain. As opposed to "using non-BK Free revision control"... well, then it's a little bit easier.
There is no cost associated with BK (ok, ok, maybe a microscopic fraction of your bandwidth costs for open logging and maybe you can count the soul-sucking email registration that they require)
That, and contractually agreeing not to work on any competing revision control system. How much that cost equates to monitarily, I suppose, depends on just how interesting of a problem you consider revision control to be.
No, I don't consider BK my competition; I'm not an Arch developer (rather, my pet VC project is CSCVS, a tool for breaking CVS repositories' history into changesets and doing nifty things with those changesets -- one such "nifty thing" being importing them into Arch).
Yes, the commercial version of the license doesn't have that restriction. Your point being? Until my employer is someone doing kernel development again, paying BM for a license isn't likely to happen, so I'm still effectively blocked from its use.
And yes, I do have an axe to grind re LMV. Personally, though, I rather think he's earned that axe.
*shrug*. I've seen folks describing Darcs as a simpler, easier-to-use Arch with worse performance characteristics, but haven't used it myself.
One plus in Arch's favor is a larger userbase (and thus the availability of tools like arch-pqm, aba, all the miscellany in Arch-contrib, and so forth). All that said, though, I haven't used Darcs, so anything I say about it is pretty much just hearsay.
Yup, SVK does have that -- they even adopted Arch's star merge algorithm.
That said, I'm not sure that the Subversion-as-backend thing makes sense, as opposed to just using Arch (with its dumb server model, cryptographically signed changesets, append-only repository format, etc).
That is, unless you've actually used anything else long enough to realize that it isn't.
No history-sensitive merging, crappy branching support, a repository format that invites corruption, no changeset support, no distributed operation support, inefficient operation w/ large file counts, a server that can't scale (look at all the issues SourceForge has)... CVS has got to go.
The CLI has gotten a lot better since 1.0; there are a lot of places where you can use 1 command now to do things that used to take 3.
Anyhow, that's a learning curve issue, not a post-learning-stage usage issue. The post-curve functionality is, IMNSHO, more than enough to justify scaling the curve.
No, the BitKeeper license is evil. Go read it sometime -- it prevents folks from working on competing systems. This means that folks working on Free revision control (like me!) are substantially hampered if we want to also do some work on the Linux kernel.
Larry has also been known to change license terms specifically to force a particular user to upgrade to a more expensive license -- I was an employee at a Linux startup (MontaVista Software) when it happened to us. He's been known to spread FUD about Arch in public, and is otherwise not a very nice person to have as a competitor *or* a supplier.
Particularly given that Free alternatives to BitKeeper with history-sensitive merging and distributed repository support (the two features that make BitKeeper so powerful) are available, using BitKeeper is arguably much more destructive than it is useful.
I can't help but wonder if similar results would not have been achieved with CVS, Subversion, or arch. Are there any features Bitkeeper has that the free alternatives do not?
BitKeeper has distributed revision control and history-sensitive merge support. Of the alternatives you mention, Arch is the only one which is comparable.
The GCC project is of comparable complexity to Linux. They use CVS with some success, don't they?
Some, largely because they have a great deal of process set up around beating CVS into submission. It's much more work and dicipline than most teams are willing to go through, though.
Mmm. There's a better one; see here for a presentation by Colin Walters (a Red Hat employee) on GNU Arch.
Incidentally, Arch is where SVK got its star-merge algorithm.
Distributed revision control is Good Stuff(tm)
on
Bitkeeper News Redux
·
· Score: 2, Interesting
That's not to say that BitKeeper is the only way to get that effect, however. GNU Arch is another distributed revision control system, and Free Software to boot.
"BitKeeper makes Linus 10x more productive" might be generalizable to "distributed revision control makes Linus 10x more productive" -- pity we don't have more sample data yet.:)
That still doesn't answer my question - what if there were changes made by someone else that are necessary to the inquisitor?
If that's happening, the inquisitor needs network services no matter what office software they're using, so I don't see why the frantic call you mention is so unique to this variety of application.
Go look up the legal requirements for a binding contract -- there's about five of them -- and decide for yourself if the last EULA you read meets them.
$10k a year might just barely rent you a studio apartment in most of LA, not including any taxes, food or utilities.
Then don't live in LA.
I've got friends who are considering moving to rural parts of the US where payments on a 15-year mortgage for a decent house are below $400! Granted, these are out in the middle of nowhere with no net connection, a loong drive to get to any decent jobs, and so forth... but damnit, don't go living in LA unless you want to get screwed on cost-of-living.
If you're single and healthy, it's easy 'nuff to live on $10K/yr in Small Town USA -- even parts of Small Town USA not quite as desolate as those mentioned above.
The issue I have has been expounded a few times tonight, but once more for the road: that the flood didn't kill all life on the planet, that the Ark held 2 of each species, and that we subsequently, in the time frame available, got the biodiversity we have now from that genetic pool.
Sure. I've never argued that. I'm arguing that the folks who call this whole expedition pseudoscience are off-base. If you agree with me on this single point, this thread's over (and should have been for a while).
They may want to find the Ark, but in practice they're looking for a big boat on the top of a mountain. That's an interesting thing, if they find one, and whatever extra expectations they may (or may not) have surrounding it, decrying the whole thing as pseudoscience (or whatnot) is throwing the baby (any legitimate results) out with the bathwater.
OTOH, I would note that the letters GPL do not in themselves constitue a license grant; they are merely an abbreviation that is usually used to refer to a specific license. In this case, however, they could just as easily stand for "Greg's Private License" (under which you don't get any rights whatsoever).
I disagree. If there's some intentional communication to the effect that "this code may be used under the GPL" and it could be demonstrated that a reasonable person would, on seeing the letters "GPL", presume that the intended meaning is "General Public License", and that Greg would be reasonably expected to know this, there's a reasonably strong case to be made that Greg would be estoppeled from preventing use which would be permitted by the GPL.
(I could go pull out my copy of West's Business Law and give better reasoning on why, but I'm supposed to be working right now. And I'm not a lawyer and this is not legal advice -- but I know contract law better than the average bird and am still pretty damn sure I'm right).
So until they start extrapolating (no, *not* interpolating -- interpolating is a different thing, and usually valid) in unreasonable ways -- ease up. Why go off on all these heated rants when all some folks are claiming to do is search for a really big boat?
Yeah, but these guys aren't going to go up a hill and find evidence for all of that. If they find evidence for anything, it'll be a really large boat (on top of a mountain). What's wrong with folks looking for evidence of a boat?
Hrm? I'm ready to believe that there genuinely exists a boat roughly the dimensions specified that the myth was based off of. Now, that this boat was used to ensure the survival of all the creatures of Earth during a giant flood -- maybe not. But that there exists a really damn big boat with an even bigger myth surrounding it? If there's reasonable evidence, I have no trouble with it.
Honestly -- would you have a problem with an expidition set off to find a really old boat if it weren't for that boat being part of Christian mythology?
Then I went to college -- and was better than 98% of the people there, and thought I knew my shit[1].
Then I went to work in the Bay Area (at an embedded Linux company with a bunch of kernel developers), and realized I didn't know jack squat.
Trust me -- you may think you know your shit, but there's always a bigger pond to play in. [2]
--- [1] Though the pre-college me wasn't nearly as good as the new me -- I'd had no knowledge of the innards of the CPU except as a black box, didn't understand database normalization, and otherwise hadn't had as deep an understanding of the things I thought I knew. [2] Of course, that's half the fun!
Ahh -- *that*'s useful information! I might have actually checked my info rather than gone off into that silly rant having heard it earlier.
That said, the code and docs are right there in the CVS repository where they're supposed to be. If you look a little more closely at the dead links, you'll find that they're nothing specific to Dashboard -- most of the GNOME web-based CVS tools are down right now, though the CVS repository itself is fine.
Or, you could even [gasp] read the webpage! Imagine! Instructions right there for pulling it from the CVS repository. Or, if not up to actually trying it yourself, you could read the mailing list archives (linked from the web page) and find out such things as what work remains before cutting a release!
Your question is silly. If the web page I link to has download instructions, of course it's downloadable. If there are non-mockup screenshots and a mailing list archive available, it's pretty damn easy to make a usability determination, too. Why are you asking strangers to determine things you could find out yourself?
(Worse, your post implicitly states that you find it unlikely, based on the provided link, that the code in question is not downloadable or usable, thus making it likely that some people will presume that for truth rather than launching their own, more competant, investigation).
Slashdot Mirror
How so? You can use BK to do work on the linux kernel just like anyone else. What does that have anything to do with your work on free RCS alternatives?
I don't qualify for the zero-cost form of the BitKeeper license. Thus, I can't use it for working on the Linux kernel, or anything else.
From everything I've seen or heard, nothing comes close to BK in terms of features or ease of use. I have been keeping an eye on the free alternatives, and so far I haven't seen any evidence that they can hold a candle to BK, except for the fact that I like the BSD/LGPL license better than BKs.
Look more closely at Arch. The only features that stand out in my mind from when I used BK that Arch doesn't have are the graphical merge tools. Personally, I don't need them -- and even so, there are folks working on alternatives.
The only large production OSS project that I know of that uses BK is Linux, and I think it would be quite hard to argue that BK is destructive in that case.
As opposed to "using no revision control", sure, using BK is a huge gain. As opposed to "using non-BK Free revision control"... well, then it's a little bit easier.
There is no cost associated with BK (ok, ok, maybe a microscopic fraction of your bandwidth costs for open logging and maybe you can count the soul-sucking email registration that they require)
That, and contractually agreeing not to work on any competing revision control system. How much that cost equates to monitarily, I suppose, depends on just how interesting of a problem you consider revision control to be.
No, I don't consider BK my competition; I'm not an Arch developer (rather, my pet VC project is CSCVS, a tool for breaking CVS repositories' history into changesets and doing nifty things with those changesets -- one such "nifty thing" being importing them into Arch).
Yes, the commercial version of the license doesn't have that restriction. Your point being? Until my employer is someone doing kernel development again, paying BM for a license isn't likely to happen, so I'm still effectively blocked from its use.
And yes, I do have an axe to grind re LMV. Personally, though, I rather think he's earned that axe.
*shrug*. I've seen folks describing Darcs as a simpler, easier-to-use Arch with worse performance characteristics, but haven't used it myself.
One plus in Arch's favor is a larger userbase (and thus the availability of tools like arch-pqm, aba, all the miscellany in Arch-contrib, and so forth). All that said, though, I haven't used Darcs, so anything I say about it is pretty much just hearsay.
Yup, SVK does have that -- they even adopted Arch's star merge algorithm.
That said, I'm not sure that the Subversion-as-backend thing makes sense, as opposed to just using Arch (with its dumb server model, cryptographically signed changesets, append-only repository format, etc).
CVS is decent
That is, unless you've actually used anything else long enough to realize that it isn't.
No history-sensitive merging, crappy branching support, a repository format that invites corruption, no changeset support, no distributed operation support, inefficient operation w/ large file counts, a server that can't scale (look at all the issues SourceForge has)... CVS has got to go.
The CLI has gotten a lot better since 1.0; there are a lot of places where you can use 1 command now to do things that used to take 3.
Anyhow, that's a learning curve issue, not a post-learning-stage usage issue. The post-curve functionality is, IMNSHO, more than enough to justify scaling the curve.
No, the BitKeeper license is evil. Go read it sometime -- it prevents folks from working on competing systems. This means that folks working on Free revision control (like me!) are substantially hampered if we want to also do some work on the Linux kernel.
Larry has also been known to change license terms specifically to force a particular user to upgrade to a more expensive license -- I was an employee at a Linux startup (MontaVista Software) when it happened to us. He's been known to spread FUD about Arch in public, and is otherwise not a very nice person to have as a competitor *or* a supplier.
Particularly given that Free alternatives to BitKeeper with history-sensitive merging and distributed repository support (the two features that make BitKeeper so powerful) are available, using BitKeeper is arguably much more destructive than it is useful.
I can't help but wonder if similar results would not have been achieved with CVS, Subversion, or arch. Are there any features Bitkeeper has that the free alternatives do not?
BitKeeper has distributed revision control and history-sensitive merge support. Of the alternatives you mention, Arch is the only one which is comparable.
The GCC project is of comparable complexity to Linux. They use CVS with some success, don't they?
Some, largely because they have a great deal of process set up around beating CVS into submission. It's much more work and dicipline than most teams are willing to go through, though.
Mmm. There's a better one; see here for a presentation by Colin Walters (a Red Hat employee) on GNU Arch.
Incidentally, Arch is where SVK got its star-merge algorithm.
That's not to say that BitKeeper is the only way to get that effect, however. GNU Arch is another distributed revision control system, and Free Software to boot.
:)
"BitKeeper makes Linus 10x more productive" might be generalizable to "distributed revision control makes Linus 10x more productive" -- pity we don't have more sample data yet.
That still doesn't answer my question - what if there were changes made by someone else that are necessary to the inquisitor?
If that's happening, the inquisitor needs network services no matter what office software they're using, so I don't see why the frantic call you mention is so unique to this variety of application.
Go look up the legal requirements for a binding contract -- there's about five of them -- and decide for yourself if the last EULA you read meets them.
$10k a year might just barely rent you a studio apartment in most of LA, not including any taxes, food or utilities.
Then don't live in LA.
I've got friends who are considering moving to rural parts of the US where payments on a 15-year mortgage for a decent house are below $400! Granted, these are out in the middle of nowhere with no net connection, a loong drive to get to any decent jobs, and so forth... but damnit, don't go living in LA unless you want to get screwed on cost-of-living.
If you're single and healthy, it's easy 'nuff to live on $10K/yr in Small Town USA -- even parts of Small Town USA not quite as desolate as those mentioned above.
The issue I have has been expounded a few times tonight, but once more for the road: that the flood didn't kill all life on the planet, that the Ark held 2 of each species, and that we subsequently, in the time frame available, got the biodiversity we have now from that genetic pool.
Sure. I've never argued that. I'm arguing that the folks who call this whole expedition pseudoscience are off-base. If you agree with me on this single point, this thread's over (and should have been for a while).
They may want to find the Ark, but in practice they're looking for a big boat on the top of a mountain. That's an interesting thing, if they find one, and whatever extra expectations they may (or may not) have surrounding it, decrying the whole thing as pseudoscience (or whatnot) is throwing the baby (any legitimate results) out with the bathwater.
OTOH, I would note that the letters GPL do not in themselves constitue a license grant; they are merely an abbreviation that is usually used to refer to a specific license. In this case, however, they could just as easily stand for "Greg's Private License" (under which you don't get any rights whatsoever).
I disagree. If there's some intentional communication to the effect that "this code may be used under the GPL" and it could be demonstrated that a reasonable person would, on seeing the letters "GPL", presume that the intended meaning is "General Public License", and that Greg would be reasonably expected to know this, there's a reasonably strong case to be made that Greg would be estoppeled from preventing use which would be permitted by the GPL.
(I could go pull out my copy of West's Business Law and give better reasoning on why, but I'm supposed to be working right now. And I'm not a lawyer and this is not legal advice -- but I know contract law better than the average bird and am still pretty damn sure I'm right).
So until they start extrapolating (no, *not* interpolating -- interpolating is a different thing, and usually valid) in unreasonable ways -- ease up. Why go off on all these heated rants when all some folks are claiming to do is search for a really big boat?
Yeah, but these guys aren't going to go up a hill and find evidence for all of that. If they find evidence for anything, it'll be a really large boat (on top of a mountain). What's wrong with folks looking for evidence of a boat?
Mmm -- that *does* make it interesting.
Well, good -- I rather like interesting. Hopefully there'll be some impartial 3rd-party verification should they find something there.
Hrm? I'm ready to believe that there genuinely exists a boat roughly the dimensions specified that the myth was based off of. Now, that this boat was used to ensure the survival of all the creatures of Earth during a giant flood -- maybe not. But that there exists a really damn big boat with an even bigger myth surrounding it? If there's reasonable evidence, I have no trouble with it.
Honestly -- would you have a problem with an expidition set off to find a really old boat if it weren't for that boat being part of Christian mythology?
GNOME is targeting themselves at people who don't want endless choices.
KDE is pretty well targeted at those who do.
Both kinds of people exist. I don't see why both kinds of desktop environments can't also.
Then I went to college -- and was better than 98% of the people there, and thought I knew my shit[1].
Then I went to work in the Bay Area (at an embedded Linux company with a bunch of kernel developers), and realized I didn't know jack squat.
Trust me -- you may think you know your shit, but there's always a bigger pond to play in. [2]
---
[1] Though the pre-college me wasn't nearly as good as the new me -- I'd had no knowledge of the innards of the CPU except as a black box, didn't understand database normalization, and otherwise hadn't had as deep an understanding of the things I thought I knew.
[2] Of course, that's half the fun!
Ahh -- *that*'s useful information! I might have actually checked my info rather than gone off into that silly rant having heard it earlier.
That said, the code and docs are right there in the CVS repository where they're supposed to be. If you look a little more closely at the dead links, you'll find that they're nothing specific to Dashboard -- most of the GNOME web-based CVS tools are down right now, though the CVS repository itself is fine.
"It's hard to compile the dependencies" and "it's not usable" are two very different things.
"Is it usable?" presumes it's already compiled.
Why not try, instead of asking me?
Or, you could even [gasp] read the webpage! Imagine! Instructions right there for pulling it from the CVS repository. Or, if not up to actually trying it yourself, you could read the mailing list archives (linked from the web page) and find out such things as what work remains before cutting a release!
Your question is silly. If the web page I link to has download instructions, of course it's downloadable. If there are non-mockup screenshots and a mailing list archive available, it's pretty damn easy to make a usability determination, too. Why are you asking strangers to determine things you could find out yourself?
(Worse, your post implicitly states that you find it unlikely, based on the provided link, that the code in question is not downloadable or usable, thus making it likely that some people will presume that for truth rather than launching their own, more competant, investigation).