Linus Tries Out BitKeeper 248
Flammon writes: "Linus has been overloaded
with patches for a while and recently the issue started to become hot again. In an unprecedented move, Linus has started using BitKeeper, as reported by Linux Today. The benefits of BitKeeper are already showing from the large amount of detail provided in the latest unstable kernel pre-release." eirikref adds: "Read Linus' own statement and take a look at the BK web interface."
But surely (Score:1, Flamebait)
Re:But surely (Score:2, Insightful)
Re:But surely (Score:4, Informative)
if you read the recent thread on l-k, it's because in private Linus has been talking for quite a while to the bitkeeper people about what he wanted from bitkeeper before he'd use it, and the bitkeeper people have gone and implemented most of it, so Linus agreed to use it for a while.
Re:But surely (Score:3, Insightful)
Re:But surely (Score:5, Insightful)
I use CVS all the time, but I know its limitations. Linus was right when he decided not to use CVS, it simply is not reliable enough. But don't blame CVS, it is a good and useful tool; but every tool has its safe zone of "recommended use", and Linux kernel is way beyond that. I say, any project above 50 KLOCs and with 100 revisions on average would be pushing the limits.
Re:But surely (Score:2, Interesting)
That is bullsh*it!
The CVS limitation does not lie in how many KLOC or number of revisions it can handle. It handles lot more than that.
The limitations is purely functional, like how it handles branches, merging and such stuff. There it lags behind the newer systems, like Bitkeeper, arch and others.
Re:But surely (Score:2)
Re:But surely (Score:2)
The size of the code is a pretty good estimate how many people work on it, how many branches they maintain, and how much of merging they do. So if you know how large your code is, you can tell whether this or that revision control system (or any other tool, to that matter) is appropriate for the job.
Re:But surely (Score:3, Insightful)
Tell that to FreeBSD, OpenBSD, NetBSD, XFree86,
all of which are orders of magnitude larger than the linux kernel. All of them have been using CVS for the past 8-10 years (depending on how you count things). Sure, cvs has its limitations, but the Linux kernel with its small number of developers with write access isn't pushing the limits. FreeBSD has over 250 people committing to its tree right now, for example.
Re:But surely (Score:3, Interesting)
That is fine; but the most important problems would be absence of changesets (so you can't undo related groups of patches), and absence of tiered repositories (everyone goes to the same, single, central CVS server). It all can work, and it does work as we know, but the more code you write the more difficult the maintenance becomes. Like it or not, CVS is an old software, unchanged for years and full of kludges, and BK is one of new designs.
Re:But surely (Score:2, Interesting)
I think some of the SMPng and KSE work is in p4, for example.
PPC Kernel (Score:4, Informative)
Re:PPC Kernel (Score:5, Informative)
Hmm... That guy looks familiar... (Score:2, Offtopic)
Quick question ... (Score:3, Funny)
Shock! Horror! Has Linus Torvalds turned to the dark side of the code?!?!
Stay tuned for the next episode of
It's a floor wax and a dessert topping (Score:5, Informative)
Bitkeeper source is available, but it's illegal to redistribute a version of Bitkeeper with the mandatory open logging stripped out.
Bitmover Inc. wants to avoid the situation where people use bitkeeper like gcc, taking free software tools but not giving anything back. You can pay Bitmover money, or you can use a free-as-in-beer version that is suitable for software libre and unsuitable for closed-source software.
Financial backup (Score:2)
BitMover also has a clause to help free software developers in the event of the company going out of business, located here [bitkeeper.com] (Correct me if I am wrong).
It says, '5. CONVERSION TO THE GPL
The BitKeeper Software will be made available under the terms of the GPL in the event that all Open Logging servers cease to function for a continuous period of 180 days starting on or after June 1st 2000.'
This looks to be applicable to the free-as-in-beer version only, as far as I can tell, but still, it's not exactly a big problem.
Re:crappy license (Score:3, Insightful)
Maybe they did it to force you to decide if you want to be part of the Free Software/Open Source community or not. It's annoying to me as well when I can't have my cake and eat it too, but I don't complain about the people that make cakes :)
It's just like the GPL - the license is a means to form and defend the community for the good of the community. If you don't like it, that's OK too, but don't say that those community-maintaining features are the problem. They're a feature, not a bug.
Re:Quick question ... (Score:4, Funny)
Maybe I should just ask him.
Re:Quick question ... (Score:5, Insightful)
Well, Bitkeeper's license isn't GPL, nor do I think that it's been certified as an 'Open Source' license by Eric Raymond's definition. However, it's got some interesting features that are as interesting and powerful as the GPL, and that even work in the public interest.
You can get it for free (as in beer) and it says that it will revert to GPL if they go out of business (eg, their OpenLogging servers go down for more than 180 days)... which is an interesting clause that ensures that 'abandonware' becomes a public resource.
The one scary part is that you MUST submit metadata to their OpenLogging system, or pay money for a 'closed use' license. Now before you hurl, consider... all open source projects already have all their metadata (and all their source too!) out in the open!
Is this really so bad? People who don't want to share, have to pay... it sounds like it's punishing institutions that don't produce open source with Bitkeeper (individual use is exempt). Richard Stallman might be pleased!
Apart from that, the only other funny part of the license that I see, is you lose your license if you sue BitMover over intellectual property rights. I'm not sure what to make of that, I guess it's a way to cover their own butts. I'd be upset if Microsoft had it in their license, but here, it seems appropriate.
So while they aren't using the GPL or a BSD license or the Artistic license or any other common, popular OSS license, they ARE going out of their way to work with developers and users instead of exploiting them. That's a far cry from Microsoft or even 'linux-friendly' software companies like Oracle. They've found (even more) ways to write software and work with the public, without giving away the shop.
I'd say, on the whole, two thumbs up.
Re:Quick question ... (Score:2)
Re:Quick question ... (Score:3, Interesting)
There are some cases they can be, but it's usually the sort of thing where you get a bank statement that lists the new regulations and you "accept by continued use". When a company says that they can change the agreement without warning though, and it's your responsibility to check, they're lying.
One legal reform I'd *really* like is to make it illegal for companies to lie about the law. It's like a warranty where they say "You get squat - except where local law says otherwise" They shouldn't be able to say "You get squat" because in almost all countries there are lemon laws and the like. Similarly, companies shouldn't be able to tell you that you have no legal recourse when you do, or to tell you you must accept bizarre terms when those terms aren't enforceable.
BitKeeper seems quite honest, if they don't resort to this kind of trickery.
Re:Quick question ... (Score:2)
I'd suggest you read his bio(sorta) book "Just for Fun", and you can see he isn't much of a hardcore philosopher like RMS. Well, I'm not in position to give review to his book, but my impression is that his philosophy is like "I don't care, I'm just doing it for fun"
(Just my personal opinion).
Keep the terse changelogs (Score:3, Insightful)
For L-K and releases a terse format is appropriate, but I think that keeping the longer ones around somewhere can help some of us newbies understand what the heck is going on in there.
Re:Keep the terse changelogs (Score:3, Informative)
Linus not getting enough respect (Score:2, Offtopic)
It's his friggin' hobby, after all. If people don't like the way he deals with it, maybe they ought to go work for a more personable coder on another OS, like, say, Theo De Raadt.
Scary thought, hey?
Re:Linus not getting enough respect (Score:1)
Re:Linus not getting enough respect (Score:1)
Re:Linus not getting enough respect (Score:5, Funny)
not that i don't love the OpenBSD project (i have several machines running it), but to say that Theo is personable is like saying everyone needs a porcupine to snuggle up with at night.
Re:Linus not getting enough respect (Score:2, Funny)
NetBSD: Because Theo is an asshole. [cafepress.com]
Re:Linus not getting enough respect (Score:1, Insightful)
posting anonymously because slashdot editors have made it clear they don't tolerate dissent.
Re:Linus not getting enough respect (Score:2, Insightful)
I agree, he deserves respect, however the linux user and open source community cant afford to just wait until Linux gets around to reviewing everything and decides to put it in at his leasure anymore. The patches, new features, and demand is too great.
Its about time Linus got some kind of source control - however I DID note that the only one who has access to it is Linux himself, which doesnt exactly make it helpful
Heres hoping
Re:Linus not getting enough respect (Score:4, Interesting)
Um, except that NOBODY WORKS FOR LINUS! Linux isn't Linus's ball anymore to take away when he doesn't like how people are playing the game. That said, I think he's been a wonderful leader and manager, and is obviously opening up to suggestions. But it is stupid and insulting to say that people who aren't satisfied with Linus's management should just suck it and pick another OS. Linus himself would tell you that Linux is more the community's than his.
Re:Linus not getting enough respect (Score:3, Interesting)
Re:Linus not getting enough respect (Score:2)
How quickly they forget [transmeta.com]...
BitKeeper??? (Score:2, Insightful)
BitKeeper gives you the answer: (Score:4, Informative)
Allthough this is marketing poop so it should be taken with a fine grain of salt, it might answer your question.
Re:BitKeeper??? (Score:2)
Some examples (some of these don't apply to the open source world):
Perforce does not solve the number 1 complaint about CVS, file renaming. They talk about a workaround that is to branch the file so as to not lose file history, but that does not help when you do a source reorg on a major revision, and want to be able to patch fixes from the previous revisions.
Perforce forces you to use their (limited) server based diffs when comparing versions against each other.
Disconnected operations is a real pain with Perforce. It just needs to have the server around all the time.
Perforce does not have a good failover solution. You only have to your last backup, add the IP based server license to that, and the disconnected operation problems, and you will end up having some downtime if you server machine goes down. BK, to be fair, also does not seem to have a true failover system either, but it seems like you can pretty easily have a secondary system that does pulls very often, that will be ready to go at a moments notice. Also since it is built to be disconnected, having the top level repository around is not essential.
Perforces protection systems is awfully kludgey, I mean there is no seperation of administration operations to data operations, and any complex tree will have ugly ass permissions (and you can't even comment the protections file, because it's stored in some server form and recreated every time you change it, blech). Again BK also doesn't really have protections built into it, but by its design you could at least limit access to repositories through the OS level (which arguably is better anyway).
Which is Best? (Score:4, Funny)
Now I'm confused!
I've been using CVS [cvshome.org] for years and read with great interest the recent Linux Journal article [linuxjournal.com] about the Subversion [tigris.org] project to created a CVS replacement that is better than CVS.
Then I see a Slashdot story [slashdot.org]about arch [regexps.com].
Now, my FearLessLeader starts using Bitkeeper [bitkeeper.com].
Should I move from CVS and, if so, which is best?
Re:Which is Best? (Score:3, Insightful)
If CVS works for you, and you have no complaints or issues, then don't switch.
If you find yourself 1)wanting features, 2)overwhelmed by inadequacies, or 3)working too hard to accomplish default behavior in other systems (ex scripting what is handled automagically in others), then investigate changing.
Re:Which is Best? (Score:3, Informative)
> issues, then don't switch.
I really hate this kind of attitude. Along with "Use what you are most comfortable with". It kills any desire to learn and use new stuff and to impove.
I say try it out and see if it worth switching to new CM.
Re:Which is Best? (Score:2, Insightful)
Re:Which is Best? (Score:2, Informative)
That depends, of course.
But for me, the answer is Subversion (http://subversion.tigris.org/), once it is done. Its design goal is to be a replacement for CVS... and to do that, they are releasing it under a BSD-style license.
And that decision will make it useful in the *BSD's, Debian, and any other OS.
They aren't breaking new ground, just making a better CVS--and that is exactly what I need.
Eli
Re:Which is Best? (Score:3, Informative)
If you're not happy with CVS, or have been wondering why CVS doesn't do some specific things, check out some of the really different alternatives (but be prepared for some differences):
- "Aegis" supports TestFirstProgramming. In order to submit a change, you must provide a test which passes with the change, and fails to pass without the change. Furthermore, your change must not break any of the old tests. Extremely powerful for group programming, and useful for single-person programming.
- "BitKeeper" provides an attractive GUI and powerful tools, designed by a professional community. It provides very powerful support for branches, and allows you to use all the convenience of the full version-controlled repository without having to have all your checked-in changes messing up the main repository.
- "arch" may have a simpler interface right now, but it makes up for it with a very impressive model of distributed repositories. Like BitKeeper, you can make a local repository in order to make changes you want to see; unlike BitKeeper, that local repository is a full repository in its own right, and can be served independantly. It supports very sophisticated merging, so that you can merge your local repo with someone else who happened to start up their own local repo based on the same master repo; you can, of course, also merge with the master, and the master can choose to merge with your work.
I am impressed with the variety of version control systems which are now coming into their own. Very nice to see.
-Billy
Re:Which is Best? (Score:2)
So does Bitkeeper; writing a trigger script which implements this feature isn't difficult.
Making BitKeeper support TestFirst to the level that Aegis does would be quite an undertaking -- although I will say that it would only have to be done once, so perhaps someone's already done it. It wasn't mentioned while I was on the BK list. I suspect it would be worth it.
arch: "unlike BitKeeper, that local repository is a full repository in its own right"
So is Bitkeeper's. From your description, I don't see anything BK can't do.
Really? I don't remember that while I was working with BK. Maybe I missed something in the docs. If true, very cool.
What I recall was that the BK local repository was special: different from the global one. Hey, I've been wrong before.
I've always been impressed with BK (and I actually like its license a lot); the only reason I don't use it is that my company's firewall makes it impossible to even
-Billy
Re:Which is Best? (Score:2)
I respectfully disagree with you about supporting TestFirst. I agree completely that it can be done, but I believe that if you try it, you'll find that doing it
I'm glad to hear that you now support the http protocol. I shall have to try installing again; the last several times I installed it didn't work, because my stinking firewall blocked it (I really don't like our firewall). I also don't like the fact that all the Bitkeeper web-browsable repositories use a non-standard port; this means that my firewall blocks them, even though they're presumably ordinary HTML/http servers (they are, right?).
-Billy
ChangeLog detail (Score:2, Insightful)
Can it really be a bad thing to have too much information about any changes?
Re:ChangeLog detail (Score:1)
However, it should offer a taste of what he actually does to those who haven't a clue and yet feel free to explain at great length to the world how he could do it better.
Re:ChangeLog detail (Score:3, Insightful)
Yes, when the information is so detailed that you can't cut through the BS to find the meat. Some people just want a brief list to skim in order to decide if it's worth downloading or not.
Re:ChangeLog detail (Score:2)
Also, there's a lot of cruft in the changelog that just isn't relevant: changeset ids and so forth. All the details of how the changes came to be in the kernel aren't that important.
The most important point here is.. (Score:1, Offtopic)
Pine.LNX.4.31.0202051928330.2375-100000
Re:The most important point here is.. (Score:2)
-- TeknoHog (Pine.LNX.4.44)
Re:The most important point here is.. (Score:3, Insightful)
Well, at least he runs Linux...
Is Linus still working at transmeta ? (Score:2, Troll)
Would a seperate fork, with sections maintained by indiviudal groups be best ? 4 or 5 guys in charge of VM, 4 or 5 guys in charge of Hardware, they would only be responsible for review and merging.
I know ill get blasted for fork speak, but sometimes its a good thing, (While youre at it optimize for the x86...lol)
Linus is the all benevolent creator and Linux god granted, respect is due, We however are the users, the ones in need, Linux was intended to fill this need, if it reaches a point because of whatever reason, perhaps a branching, is best for it as a whole. I dont think anyone actually asked Linus if he wanted the development to consume his life (Maybe he does, I dont know, it dosent matter)
All this is an awful lot to ask of any one man, mortal or not. Perhaps Linus would welcome this as an oppurtunity to do other things.
I hope this will make Linus's life easier, Sometimes people continue on a path out of a feeling of obligation, does Linus do this now because, 1 He wants to, 2 He feels like he has to
3 Nobody else has stepped up to offer a solution.
Re:Is Linus still working at transmeta ? (Score:2, Informative)
Linux kernel uses source control (Score:5, Funny)
Re:Linux kernel uses source control (Score:2)
Re:Linux kernel uses source control (Score:2)
The next step? (Score:2, Funny)
Oh no! (Score:3, Funny)
We may have
Detail in changelog (Score:3, Redundant)
'More bug fixes for PCMCIA' or 'Patches for USB'. Doesnt really tell me if theres any hope a particular problem I am experiencing with either has been fixed -- nor does it tell me why something that used to work no longer works, and how to re-enable the 'old style' code -- or where I should look for the diff to say to the author "This used to work, since this change, it doesnt anymore
More detail means, for example, I can see from the changelog, when the USB sleep (ie. usb does not come back online automatically when you put your computer sleep, you must either do some fancy footwork beforehand (which doesnt always work), or reboot). Its a known problem, but "More USB bugfixes" doesnt tell me its fixed, or even that that part of the code has been worked on.
I'm sure theres many others out there who experience problems in specific parts of the code, (which are known problems), and have been frustrated by the changelog's lack of detail -- and dont want to upgrade your kernel to 2.5, or 2.4-pre's or even another stable 2.4, unless you know your problem is fixed, because what you got now works for everything ELSE, and you never know what a new kernel will break. I myself havnt started using 2.5 kernels, but I would probably start IF I could tell by the changelog, that my problem was solved there, so there was some benefit for me.
You fool... (Score:2, Troll)
Re:Detail in changelog (Score:2, Informative)
One other potential advantage is that it clearly presents what kind of changes Linus is interested in accepting. One reported big problem in the past is that Linus has a tendency to drop patches that change too much or have an insufficient explanation of what they do. By making it obvious what kind of changes he does accept and how the messages describing them should be written, it will make it easier for people to learn how to write a change the Linus will accept.
Downloading bitkeeper (Score:2)
Free vs. Open Source positions (Score:3, Insightful)
The Open Source Software movement says, "Use the best software. That will often be Free / Open Source software."
The devil must have had to put on a sweater (Score:5, Insightful)
I really like the new change logs, I have always hated the old change logs as being too uninformative. One of the really interesting things for me about a source code control system is that it preserves a lot more of the history of the source code than the tar balls do.
It is also really cool how it branches the source for every patch and checks in the code with the users name as the one who checked it in and the body of the email as the comment. If Linus can find a way to also check in his rejected comments on a patch then that will also be very useful. It would be interesting to capture a little bit of the why instead of just the how in the kernel development process.
To apply a patch you just have to merge the branch that contains the patch back into the main development branch, fix any conflicts, compile, fix it so it works right and then commit.
And Linus will never lose another patch again, they will be saved for all time in the source tree under a seperate branch.
Once Linux lets his inner sanctum of kernel developers all start merging approved patches into his main branch then we will see the kernel development really speed up.
Thanks!
Re:The devil must have had to put on a sweater (Score:3, Interesting)
I personally like the comment about he was only able to do 50 patches etc... (Gee Linus that's ten off from last month??) This is still about the fact that Linus is overwhelmed and refuses to delegate. The community gets up in arms about it finally, and Linus gets a CVS system instead of splitting up some work.
Well, maybe this will quiet the community until Alan C. can get back to it.
~Hammy
Re:The devil must have had to put on a sweater (Score:3, Funny)
architecture problem, not SCM problem (Score:4, Interesting)
There are lots of ways of providing such hooks. Perhaps the most compatible with the Linux kernel mindset would be something similar to Emacs-hooks: replace most kernel functions with variables holding function pointers to the actual code and provide APIs for manipulating those hooks.
Re: Catch-22 (Score:2)
No. It is the nature of big, monolithic programs that don't use modern abstraction facilities to require patches all over. Kernels are no different from word processors in that regard.
That said, your suggestion of using hooks will also require patches 'all over the kernel'.
No. You put in the hooks first, everywhere. Do it from 2.5.10 to 2.5.11. Afterwards, any module can hook just about any function anywhere in the kernel without patches.
"A Critique of the BitKeeper License" by Jack Moff (Score:5, Informative)
one of the main Ogg developers and one of the Icecast Core Developers [icecast.org]),
about some problems he had with the BK license when he was using it
for hosting Icecast:
"A Critique of the BitKeeper License" [mit.edu]
http://www.mit.edu/afs/athena/user/x/i/xiphmont/P
You might also find interesting his post on the matter to the
"Icecast Developer Discussion List":
http://www.xiph.org/archives/icecast-dev/0067.htm
I hope that he will post here his his experience using BK
in an Open/Free-source project...
Best regards
\\Uriel
P.S.: Yea, I know I'm karma whoring, but I'm sure many people will find this interesting,
specially in casse Jack dont post to this history latter
Re:"A Critique of the BitKeeper License" by Jack M (Score:2)
Sometimes it is tempting to sacrifice our rights and freedoms for convinience, but we should not do so. There are many problems with CVS and other Free source management packages, and it would be nice to move to a more robust and more well-designed tool. We are better off to repair or fix the tools which are free, or if that is not acceptable to create new free tools that preserve the the rights and freedoms we enjoy.
I encourage BitMover to adopt the minimum requirements for freedom or openness that this community has defined, but at the same time I respect their wish to preserve the business model of their choice. At the very least I would like to see the rights the BitKeeper license does grant preserved and not subject to arbitrary revocation. I do hope that they will find some way to provide the community a truly free version of their tools and still meet their business goals.
I also encourage Free Software hackers to not use or stop using BitKeeper in their own projects. It might not be as convinient to use other tools, but in the long term we should be more concerned with preserving those rights and freedoms we currently exercise and enjoy daily. I personally have stopped using BitKeeper for all projects and have moved these projects back into CVS repositories. I hope that if you or your team is considering using or currently using BitKeeper that you will think about the implications of doing so and reconsider.
I encourage the entire community to support the efforts of Free and Open Source projects in this area. Source management is complex, and the efforts of the community to support Free and Open Source projects (CVS and Subversion are two such projects) are the best way we have to improve our development infrastructure.
source: Jack Moffitt's "A Critique of the BitKeeper License" [mit.edu]
Thats a curious concept (Score:2)
So DOS the heel out off those servers and make it gpl software!
I wonder who modded that down...
Thats actually an interesting point: the intent of their license is to free the code in the case they go out of business, but the wording leaves open the possibility that an attack could make the source code GPL.
They may wish to consider modifying their license to exempt that case. (They modify the terms so frequently its not a big deal for them) Its not far fetched to imagine a ddos attack run for a few days may cause their service provider to drop them. Combine that with a bit of DNS cache poisoning, and 180 days really isnt that long.
Anyway- the license itself seems to violate some fundamental concept: its designed to look more attractive to free software programmers, yet it encourages them to hope the company doesnt succeed.
Re:Thats a curious concept (Score:2)
I wonder who modded that down...
That is not so hard. It contains the word DOS, and that triggers the "oops i am mature" nature of moderators. That is why i posted without my +1 bonus. It was meant as funny.
In the real world a 180 days DOS attack would be very hard to execute, and the GPL'ed software would not hold it's licensence into court.
Anology:
I doubt that anything you sign with a gun against your head, where you can prove you had a gun agianst you head will hold up in court.
No free alternatives? (Score:4, Interesting)
I did a superficial investigation on source control systems, and found some very interesting really free ones, like Aægis [aegis.sf.net].
Does someone know if free alternatives to BK were considered, and if so why a semi-free one was choosen? If BK was better, specifically how it compared to Aægis and other alternatives?
Re:No free alternatives? (Score:2)
Re:No free alternatives? (Score:2)
I think Aægis does all of this, but in a more disciplined manner. As I made a question, not disputing BK's capabilities but asking about alternatives, it seems you are the weenie.
BTW, what's disreputable about "free software only"? Don't you care about freedom? If you sell your freedom for some marginal funcionality, it's your choice, but please allow other people to choose freedom.
Re:No free alternatives? (Score:2)
> There is nothing disreputable about "free software only". Sometimes it is not realistic or practical.
So our task is to make it more practical, bring freedom to our reality.
> I also realize that having a dedicated company supporting a product as complicated as SCM is very important.
GNU Ada is a dedicated company supporting free software, the Cygnus division of Red Hat provides support for gcc, gdb and related tools, and there are several companies providing support for PostgreSQL, various parts and distributions of both GNU/Linux and BSD.
> you haven't tried BitKeeper, have you?
No, I haven't tried any. As I said, it was a question. I just read the descriptions, and was wondering. I don't understand why are you so upset, perhaps you have developed a conditioned reflex against principled people in general or free software advocates in particular. Just as a test, what you'd say if I state that there are no relational databases in the market?
> Claiming "I think it does this" isn't really that compelling
Also you telling Aægis doesn't do what it says it does, and that BK does, isn't any more compelling.
> It would be interesting to know why you feel that your freedom is threatened.
Because people trade off liberty for convenience. Who said that the price of liberty is eternal vigilance?
People didn't care for their freedom at other times, and what do we have now? Religious persecution, big government, restrictions to speech, movement and trade, proprietary standards, software hoarding... the list of evils is endless.
Re:No free alternatives? (Score:2)
I'm not sure about what do you mean do you mean that you have several replicating master copies? And what's the relevance of this feature? As far as I understand, it would be just all right to have a master repository and several replications of it. After all, Alan probably does not spend much time disconnected
I don't understand why I would shut up. Lots of people profit from supporting free software, like the Cygnus guys before selling out to Red Hat and the GNU Ada guys – just two examples out of the top of my mind.
I do not have direct experience with dealing with many source control systems, since I do just a light use of CVS as a source control system, but while the CVS team has been accused of being less than responsive, there are lots of alternatives out there. What data you have to support your implication that BK has a monopoly on responsiveness? And you can't really imply that CVS or Aægis or other people don't know their stuff.
Security? (Score:3, Interesting)
Basically, I'm aiming to be able to accept patches directly from email,
Does Linus use PGP sigs (for example) to verify the senders of these patches? I hope he does (being Linus and all that).
Re:Security? (Score:2, Funny)
Does this really matter? (Score:3, Insightful)
Will there be public read-only access to Linus' branch so people can keep up with the latest?
Bought damn time (Score:3, Interesting)
Now, to address what this means for Bitkeeper.....its death. Yes. Bitkeeper is now doomed. Why? Simple. The "keep this in the GPL family" movement will have someone clone the Bitkeeper method of software management, and a GPLed Bitkeeper clone will be created, it will catch up to Bitkeeper, pass it, and then Bitkeeper will have its oxygen cut off, and they will die.
Bitkeeper Rocks (Score:2)
Re:he changed his mind? (Score:2)
I don't follow it (that closely) either but it seems like you're talking about 2 different, though related, things.
There's the process of patch submissiong which is pretty much the same - send them to the maintainers, who are supposed to send them to the 'trusted few', who send them to Linus. Some of the recent discussion seems to be over the fact that the maintainers thought they had a direct line to Linus, whilst he didn't see it that way.
Then there's the tool Linus uses to organize his source tree(s). This will allow Linus to speed up the process of applying and testing patches. It will not change the protocol for submitting patches. Maybe he'll give the trusted ones write permissions if they even decide to adopt BK too.
At least that's my impression - I could be, and usually am, wrong :)
Re:I know it's off topic... but I gotta know (Score:2, Informative)
Drivers are distributed with the kernel for two reasons:
The USB drivers aren't overly entangled with the real innards of the kernel, they just happen to be shipped in the same tarball.
Re:I know it's off topic... but I gotta know (Score:3, Insightful)
I have yet to see a major new device class, file system class, or other subsystem that didn't require patching. That's a problem with the Linux kernel--it simply lacks the hooks and mechanisms for doing this. And it will only get addressed if the kernel developers start making a commitment to shipping drivers and other modules separately from the main kernel, with their own version numbers and source trees. As long as people can patch easily, they are never going to add the hooks to the kernel that will let new functionality get added without patching.
Re:I know it's off topic... but I gotta know (Score:2, Interesting)
This is because Linux has a macrokernel architecture - everything's compiled into "the kernel", which is a hassle for some people, but increases execution speed.
As I understand it, WinNT uses a microkernel architecture - the kernel proper does the bare minimum it can get away with, and the rest is handled by higher-level "services", which in theory can be worked on and upgraded without disturbing the microkernel.
Actually, Linux is somewhere between these, owing to the modules system. I agree though that it would be nice if modules were so reliant of what version of the kernel you were using. I don't know about the practicalities of this.
Re:I know it's off topic... but I gotta know (Score:2)
Using dynamically loadable modules doesn't make Linux a microkernel, and adding hooks wouldn't either. The performance penalty would be basically zero.
Re:Bad news (Score:5, Insightful)
Linus and the maintainers will still accept patches in email, so nothing's changed except Linus now has a tool that is likely to help him keep up the extremely high productivity.
And, using non-free software to manage the development of free software doesn't make the free software any less free. It's not like it could only be compiled by a non-free compiler.
Maybe this means that those who write free software will next write a tool even better than BitKeeper and the world will be once more a little better place.
Re:Bad news (Score:5, Insightful)
Why? I find it interesting.
There's is absolutely NOTHING wrong with charging for software. If you do nothing but write software for work, you have a reasonable expectation to make a living off it. The world doesn't run off charity man, nothing is free.
To me, the "pearl of Free Software" being version controlled by a commercial product is a grand statement.. that free software and commercial software can coexist peacefully.
Software "should" only be free as in speech anyways. If it's simultaneously free beer that's just icing on the cake.
Re:Bad news (Score:3, Insightful)
to say "See? Free software isn't viable on it own. The only reason it's any good at all is that is relies on commercial software"
Or the more subtle "Sure, Linux was okay before. But it only got good once they started using commercial software to develop it"
It could help reinforce the stereotype of free software as "hobby" projects - "Oh sure, you can use free software tools to develop some simple CGI script or napster clone, but if you want to make a serious software project, you need to use commercial tools"
(Not that I believe this, but that is what might be argued)
Re:Bad news (Score:2, Insightful)
I'll let that self-referential statement stand on its own merits!
Look, if I spend all of my time coming up with "ideas", I have to use them as my source of income; if I can't, I have to find some other source of income, which means I'm not spending any time coming up with those ideas anymore.
Logical. No argument with that. So you can be compensated for the time that you spend doing that through an income that is tied to your production of freely re-distributable ideas. That's the academic model. You work on producing ideas and get a secure, stable life with good benefits.
Or, you could be employed by a company like RedHat. They make money from support/service and use a portion of that to give jobs to talented hackers.
Or, working as a professional software development you can give away some of your time because it increases your standing in the community, raises your profile and in turn attracts employers who wish to pay you for proprietary, non-Free work.
In other words, for decent software to be developed at anything other than a glacial pace, people have to be able to devote time to it, and they have to be compensated for that time in a way that allows them to eat, live under a roof, etc.
In other words, there are several ways in which Free Software is already being developed and in which the developers quite rightly get the food, housing, etc. that you so rightly assert they have the right to be rewarded with. So what's the argument? I would suspect that it is that you are tilting against some fantasy windmill of communist free software.
No flame intended on my side. I just think that you don't get it and that you're arguing against some pre-conceived imaginary position.
Re:Bad news (Score:2)
I disagree that selling software is "software hoarding." Not giving away source code is software hoarding.
Sometimes I think that those of us who advocate Free Software overestimate its revolutionary credentials. I'm of the opinion that Free Software is supported by the most conservative principles that underlie intellectual property law: The creator owns the work and has the right to decide what to do with it and how it is used.
The problem with software is that compilation is tantamount to encryption. When you buy "closed-source" software, you are buying an encrypted book. That doesn't alter the author's right to restrict your rights to copy the work.
The GPL is one collection of grants and reservations of the author's inherent ownership. Other sets are equally valid and based in the same fundamental principle. Where I do agree about "software hoarding" is in the obfuscation of compilation. This creates an artificial shortage of technique.
This cuts the other way, too. When the author of a book steals a paragaph or chapter from another's book, the theft is obvious. When a software author steals a part of another author's program, thanks to the obfuscation of compilation, the theft is not obvious.
What I find funny is the notion that computer software is somehow different. It is not. Copyright, patent, plagarism. These should work the same as in any other form of publishing (I think programming is a form of literature, not a form of invention -- that's my opinion, I think this is a core question not yet settled in public opinion or law).
It is the obfuscation of compilation (provable loss of information) that makes it complex. This is why I think Stallman's definition of "Free Software" is the right one. If you got source code with everything, even if you don't agree with Stallman's particular set of grants and reservations, theft would be easily seen and thus easily prosecuted.
Software vendors think keeping the source secret protects their investment. IMHO it merely drives theft underground. Source always would make it obvious.
Questions: Are there any lawyers in the house? If I write a computer book in French, and one of the chapters is directly translated from someone else's book written in English, am I in violation of copyright? Is it harder to prosecute?
Re:Bad news (Score:2)
Since I was almost there, I'll pick up where I left off (and where you agree): namely, people have to be compensated for at least most of the time they spend writing their software.
The catch is that in order to demand compensation, you have to be able to withhold supply. There are two ways of doing this: the product method, which is that you pay me or you get no copy of the software, or the service method, which is that you pay me or I stop working on the product.
The tricky part is that once someone has the product in source form, chances are they care a lot less whether you can continue working on it or not. So giving away your source weakens your ability to demand compensation, and in effect reduces you to asking politely.
Don't get me wrong, I understand that the concept of selling Free software is relatively new, and models are being explored, and some degree of success seems to be occurring amid the many simultaneous failures. I really hope that a solid model is hit upon and proven capable of supporting software development at the same level as the closed-source models. I firmly believe that one should "free" one's code whenever possible, and successful business models built on Free software will make sharing possible more often. Everybody likes to share. (Well, not everybody, but I do.)
My objection to the post to which I originally replied lies with the idea that keeping your software closed is immoral "hoarding". Hoarding is taking a resource that was at some point available to all and collecting it and keeping it all to yourself. It's a valid view of software patents IMO (anyone could have had your idea, and still might, independently), but not of closed source in general (where there's a product of time spent laboring). It's also extremely arrogant and pretentious to descend from on high, survey the scene, and proclaim that the practice of extending an economic model developed for trade of physical items to the more ethereal world of software is "immoral". It's an outgrowth of the way trade has been conducted since the beginning, a natural extension into a new domain. It's also what's worked and continues to work, and is often very fair to all those involved.
I do get it, fully. I just find the rhetoric of "good" Free Software versus "immoral" closed software a bit short-sighted and fairly obnoxious.
Free enough (Score:2)
OK, so that's not technically free software, but isn't that close enough?
Cells don't scale (Score:2)
Re:Cells don't scale (Score:2, Interesting)
Re:change (Score:4, Insightful)
I also used to think like this. The sum extent of my source control was cp -r currrent vX.x. Source control was for wimps.
I'm of a rather different view today. I now utterly insist on using it, even in tiny little things that I think are one-offs at the time (quite often it turns out they aren't).
I think I can understand Linus' dislike. It sounds like you're less free, and as if the whole coding thing is suddenly less enjoyable. However, having gone through exactly the same feelings I can say that in my case it certainly isn't true that things are less enjoyable. In fact, in some ways it's easier as I can go wandering off in my own direction for a while, before hitting a dead end and backtracking safe in the knowledge that I have a defined state to fall back on should I need to.
Personally, I'd recommend taking the plunge. Some [cvs.org] systems [rational.com] are better than others [microsoft.com], but any system use injects a bit more organisation and confidence into the process of coding.
Cheers,
Ian
Re:Where are Open Logging Repositories stored? (Score:2, Informative)
It is not the same as openlogging, those logs are on www.openlogging.org.
I got an OK from Linus to put his trees on linux.bkbits.net,
you may go poke at them there.
Note that bkbits.net sort of looks like it might evolve into sourceforge
but that's not our intent. What we want is to provide that infrastructure
so that different people can host their own projects.
bkbits.net is a cache, you go there to fill your cache but then you have everything.
BitKeeper replicates the metadata so you are nowhere near as reliant on a centralized server
like sourceforge.