Linus Tries Out BitKeeper

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."

Comments

But surely

[Ed Avis]

Shouldn't Linus at least have tried out CVS first before moving to something exotic like Bitkeeper?

Re:But surely

[AndroSyn]

I believe Linus was pretty against CVS from day one. He didn't like it at all, and wasn't a terribly huge fan of BitKeeper either. It almost seems like he is using moreso because he has been prodded in all directions regarding this.

Re:But surely

[Xzzy]

Wouldn't you think that, in the 10 or so years he's been maintaining the kernel, he already evaluated it? Just because there was never a press release doesn't mean he rejected CVS out of hand and has never tinkered with it in his spare time.

Re:But surely

[tftp]

CVS is not as powerful as BK, and definitely not as scalable. It lacks very many key features; for example, it doesn't have native changesets, and they are essential when you work on a large project and accept lots of patches from lots of people.

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

[Anonymous Coward]

The FreeBSD, NetBSD and OpenBSD projects seem to meet those criterion and are all using CVS. Sure there is stuff they wish they had, but they seem to do pretty well with CVS. Better IMNSHO than with out, very much so since I can get complete coppies of the Project repos.

Re:But surely

[tftp]

The *BSD projects seem to meet those criterion and are all using CVS.

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

[chenwah]

Some of the newer 'out-of-tree' development that is going on in FreeBSD at the moment is being done using Perforce.

I think some of the SMPng and KSE work is in p4, for example.

Re:But surely

[Skuggan]

I say, any project above 50 KLOCs and with 100 revisions on average would be pushing the limits.

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

[mindstrm]

Well yeah, that's what I took the guy to mean... he never said CVS could not handle that much code functionally, just that it was not suited to projects of that size.

Re:But surely

[Skuggan]

Yea, maybe he did not mean what he said, but then what he said was not what he meant, that is what i mean with my post.

Re:But surely

[tftp]

The CVS limitation does not lie in how many KLOC or number of revisions it can handle.

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

[Paul Jakma]

No,

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

[imp]

any project above 50 KLOCs and with 100 revisions on average would be pushing the limits.

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

[Anonymous Coward]

Shh. no fair being rational and informed in a "Linus must use CVS because I used it once for my PERL MySQL mp3 indexer and it worked great!" moron-fest.

Re:But surely

[Anonymous Coward]

Aww, AndroSyn's uninformed, inflammatory cojecture was far more entertaining than your boring old facts.

PPC Kernel

[NewbieSpaz]

IIRC, the PPC Kernel is maintained through BitKeeper, and has been for quite some time.

Re:PPC Kernel

[NewbieSpaz]

Here is some Info on it...

Hmm... That guy looks familiar...

[darylp]

I wonder if the nice people at Ask Jeeves are going to mind having their (presumably trademarked) logo swiped for this?

Quick question ...

[Noryungi]

Isn't BitKeeper a (gasp!) closed-source commercial software?

Shock! Horror! Has Linus Torvalds turned to the dark side of the code?!?!

Stay tuned for the next episode of ... TUX, Episode I: The revenge of the Borg!!

Re:Quick question ...

[mons]

If it is comercial, what is Jeeves doing on their web interface, he programmed it or something?

Maybe I should just ask him.

Re:Quick question ...

[Komodo]

(IANAL)

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 ...

[aminorex]

Bitkeeper reserves the right to revoke your license
to use their software. If they ever get a wild hare
they can stop kernel development dead.

http://bitkeeper.com/Sales.Licensing.Source.html

Read the license. Then consider: They can change
this license at will, because it is their
proprietary code.

At any momemnt, they have the ability to hold the
kernel source hostage. Will they? Unlikely, of
course. But they have the ability.

Re:Quick question ...

[Komodo]

They can modify the license at any time, sure, but once a license with a particular user has been established, they can't arbitrarily rewrite the contract WITH THAT USER without some exchange of value.

Unlike a lot of service contracts with organizations out to screw the customer, they don't say 'We reserve the right to change this at any time without notice', and I don't think that they can. New users may be forced to accept the new license, and old users will be prevented from upgrading or patching their installations to newer versions, but there is no way that I can see (IANAL) that they could prevent you from checking your code out and using something else (CVS, SCCS, or whatever).

Since Linus (or someone Linus has a deal with) is now one of their customers, it appears that he's secure in the terms of that agreement even in the event of a 'wild hare'.

Like I said, I'm not a lawyer, but I am going to get an opinion on this license from an IP lawyer that I know. I'm pretty sure that in the event of a Doomsday Scenario (like MS buys Bitmover and tries to hijack the kernel), the worst that will happen is that they'll get a copy of a bunch of data they could get from ftp.kernel.org anyway, and we'll lose a few days while Linus finds something else.

Remember that Version 1 of the GPL wasn't perfect either, that's why the FSF says to use Version 2 (or later). Perhaps further development of this license will yield a similarly-useful result.

Re:Quick question ...

[Anonymous Coward]

> 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).

Maybe we can enlist a horde of SKR1P7 K1DD13Z to perform a *beneficial DDOS* ?

Re:Quick question ...

[WNight]

Actually, those contracts that say "we can change it and you're still bound by it" aren't valid.

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 ...

[Wesley Felter]

They can't "stop kernel development dead" because if they tried to screw with Linus he would just export the code from his repository and stop using BitKeeper. Linux development managed without BitKeeper before; it could do so again.

Re:Quick question ...

[Muad]

I agree that it works well in the paradigm

OpenSource/Free Software -> Free (beer) license
closed source/commercial -> $$$ license

It's used pretty much the same Way in Qt (which can be licensed as GPL, QPL (OpenSource type license) and commercially) and it seems to work well - hopefully it is an acceptable business model to let Free and Commercial live side by side.

As of RMS being happy about it (or anything else for that ) I think you are making a step a little too big... ;-)

-Muad'Dib

Re:Quick question ...

[jsse]

Haha, we always hear 'Linus is turning to dark side' whenever he has any connection to commercial, including his current job.

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

[reaper20]

Methinks that it wouldn't be trivial to continue to pipe the results in a terse format as well.

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

[reaper20]

Looks like I spoke to soon, looks like they will be maintained at http://linux.bkbits.net

Linus not getting enough respect

[wrinkledshirt]

It's high time he told the community to screw off for a bit.

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

[pnelynx]

Which OS is Theo de Raadt's?

Re:Linus not getting enough respect

[Shadowlion]

OpenBSD.

Re:Linus not getting enough respect

[hardcode]

OpenBSD http://www.openbsd.org

Re:Linus not getting enough respect

[Stochi]

personable? Theo? Good God! he's like a living godzilla spewing white hot embers of death everywhere...

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

[Anonymous Coward]

It's not a hobby when you get paid to do it. It's part of his job, and I'm glad to see he's finally realizing that his old method of patching doesn't work anymore. Thanks Linus!

posting anonymously because slashdot editors have made it clear they don't tolerate dissent.

Re:Linus not getting enough respect

[Anonymous Coward]

psst ... turn on the sarcasm detector!

Re:Linus not getting enough respect

[srealm]

As soon as Linux started getting used by as many people as it is now, and started gaining momentum and more developers writing drivers, features, patches, etc -- Linux ceased having the luxury of it being just a hobby -- now he has dependants.

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 ... however I'm hoping that will eventually change, and we might actually end up with a group of people 'blessed' enough to review patches and put them in (ie. the 'all-stars' you see in every changelog), and a much faster moving patch and update scheme.

Heres hoping ...

Re:Linus not getting enough respect

[srealm]

Before anyone decides to flame, scrap that 'linux is only one who has access' comment, I was looking at the wrong branch of code.

Re:Linus not getting enough respect

[Hard_Code]

"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."

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

[Anonymous Coward]

"to say that Theo is personable is like saying everyone needs a porcupine to snuggle up with at night."

Please don't trash our friends the porcupines.

Re:Linus not getting enough respect

[mark_lybarger]

There's a point where a kernel development becomes a little more than a hobby. I would have to say Linus has crossed that line long ago. He may or may not recieve DIRECT monetary incentives to keep up the good work, but regardless, the line is crossed. It's now a profession. Linus is a professional Linux developer. Until he takes a professional position that does not allow him to spend as much time on kernel development, it's his profession, and as such no longer a hobby.

Re:Linus not getting enough respect

[Anonymous Coward]

Linux is only half his job at Transmeta, the other half he is doing development of their closed source software CPU emulaition thingie.

Re:Linus not getting enough respect

[wrinkledshirt]

Linux isn't Linus's ball anymore to take away when he doesn't like how people are playing the game.

Actually, it is.

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.

Stupid and insulting how, exactly? Free software gives us a lot of rights, but badgering a lead developer to change his work habits for our piece of mind isn't one of them.

Linus himself would tell you that Linux is more the community's than his.

Except the expectations aren't piling up on the community, they're piling up on him. And when he burns out, we'll all be right fucked, won't we?

Stupid and insulting indeed. Perhaps some people still need reminding that he's given over 10 years of his life to this project. Show a little respect.

Re:Linus not getting enough respect

[Syberghost]

He may or may not recieve DIRECT monetary incentives to keep up the good work, but regardless, the line is crossed.

How quickly they forget...

Re:Linus not getting enough respect

[BluKnight]

If you follow this sentiment, you should really enjoy the products...

NetBSD: Because Theo is an asshole.

Re:Linus not getting enough respect

[jo42]

Tell that to IBM and all the other big name companies that have sunk so much money into Linux solutions.

Re:Linus not getting enough respect

[jo42]

Except he's the only one controlling the main kernel tree. All those millions of Linux users depend on one wanker!

Heil Linus!

BitKeeper???

[Anonymous Coward]

Why would somebody choose BitKeeper over Perforce? Perforce offers free licenses for Open Source software and is IMHO 1000% better and more powerful than CVS. Anybody wants to clarify what makes BitKeeper the tool of choice?

Re:BitKeeper???

[Anonymous Coward]

Yes. They choose BitKeeper because Al Viro (devfs maintainer) developed it.

Re:BitKeeper???

[smurfi]

... except that BK is developed by Larry McVoy.

I haven't seen Al's name in any of the BK changes.

Re:BitKeeper???

[casret]

I've used Perforce and CVS extensively, and played around alot with BK. Perforce, while definetely nicer that CVS, is IMHO inferior to BK. Some of this are inherent limitation of the strongly server-client architecture of perforce, others has to do with some bad design decisions.

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).

change

[Anonymous Coward]

I don't know if it's a good thing linus is changing how he works. If in the end it helps him become more productive, than great. If this ends up wasting tons of time and make him less productive overall, than he should tell people to take a long walk off a short bridge. Here's to hoping using source control leads to higher productivity. Not everyone works well with source control, so chances of it succeeding is 50/50.

Re:change

[Ignominious Cow Herd]

OT Warning That's pier, not bridge. A long walk off a short bridge puts you on the other side of the river or whatever. Clearly, Linus' personality is strong enough that he will tell everyone to go screw if he finds that BK isn't cutting it for him. I'm guessing that he has agreed that there is a problem. I applaud the idea that he is trying this despite his long and loud protests in the past.

Re:change

[mccalli]

I don't know if it's a good thing linus is changing how he works.

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 systems are better than others, but any system use injects a bit more organisation and confidence into the process of coding.

Cheers,
Ian

Which is Best?

[4of12]

Now I'm confused!

I've been using CVS for years and read with great interest the recent Linux Journal article about the Subversion project to created a CVS replacement that is better than CVS.

Then I see a Slashdot story about arch.

Now, my FearLessLeader starts using Bitkeeper.

Should I move from CVS and, if so, which is best?

Re:Which is Best?

[banky]

There is no need to be confused.

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?

[Anonymous Coward]

Why don't you decide for yourself what needs you have and which product best fullfills that need before you start blindly following others?

Think for yourself, man!

Re:Which is Best?

[Anonymous Coward]

CVS has a lot of limitations. I use it but I still take a look at replacements.

Subversion is not yet finished.

I have never heard about arch before and it seems there is a long way before this tool until it is really useful.

Re:Which is Best?

[eli173]

> Should I move from CVS and, if so, which is best?

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?

[krokodil]

> If CVS works for you, and you have no complaints or
> 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?

[William Tanksley]

If you're happy with CVS, stay with it at least until Subversion is finished -- svn is designed to be a replacement for CVS which fixes all the annoying oddities.

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?

[smurfi]

> Aegis supports TestFirstProgramming
So does Bitkeeper; writing a trigger script which implements this feature isn't difficult.

- 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.

Re:Which is Best?

[tsprad]

I hate this attitude! Life is too short to evaluate everything that's announced on Freshmeat. Why can't you honestly share your experience?

Re:Which is Best?

[lm]

Arch is a subset of BitKeeper. Mr Perens claimed that arch is 'revolutionary" and that is nonsense.
The model that arch attempts to emulate was first seen by me back at Sun more than 10 years ago, I
implemented the prototype which became teamware
and it had distributed repositories. BitKeeper is largely an outgrowth of that effort.

Re:Which is Best?

[William Tanksley]

Aegis supports TestFirstProgramming
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 /experiment/ with BK.

-Billy

Re:Which is Best?

[lm]

Making BK support TestFirst is trivial, it's done with a pre-incoming trigger in the integration repository.

You're recollection of BK repositories is mistaken, there is *zero* difference between your repository and the so called global repository.

As to the firewall issue, we've supported sync over the http protocol for a long time now.

Enjoy,

--lm

Re:Which is Best?

[Anonymous Coward]

It's just a shame that Subversion is such a prick to install.

There's good reasons why not everybody uses WebDAV, why not everybody uses Apache 2.0.

Re:Which is Best?

[William Tanksley]

Thanks, Larry. I'm glad to hear that BK has all the abilities of Aegis (and therefore my recollection is mistaken); I've been eagerly following it for a long time, and have been on the bk-users mailing list since the beginning. It's a great looking product.

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 /right/ is a substantial task. See Aegis for more information. This isn't a shortcoming of Bitkeeper, of course; it's merely the nature of good tools (i.e. a good tool takes some effort to get right).

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

[Mattygfunk]

It's interesting to note that Linus feels the ChangeLog for the 2.5.4-pre1 kernel is too detailed.

Can it really be a bad thing to have too much information about any changes?

Re:ChangeLog detail

[h2odragon]

"yes", probably.

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

[rlowe69]

Can it really be a bad thing to have too much information about any changes?

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

[iabervon]

Actually, he feels the Changelog is too detailed for posting to linux-kernel. It's generally best to keep announcements relatively brief. Additionally, prepatch Changelogs are since the last real release, which means that -pre10 would be 10 times as big, and contain 90% old information. A much smaller changelog would be preferable for putting in announcements, with the full changelog available on the web for those who are interested.

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.

Re:ChangeLog detail

[TMLink]

Some people just want a brief list to skim in order to decide if it's worth downloading or not.

You have a good point...but why do we have to have to be limited to one option or the other? Wouldn't it be possible for Linus to release a miniscule and a detailed version of the changelogs, so that we can find out the heaftier details if we want to? With BK automatically making the heaftier changelogs, wouldn't that be rather simple to include that one as well as Linus's shortened one?

The most important point here is..

[QuantumG]

Linux uses pine! Look at the selm tag!


Pine.LNX.4.31.0202051928330.2375-100000

Re:The most important point here is..

[TeknoHog]

Gee, that's an old pine, must be one of the old giants at yellowsnow park.. how can we trust the creator of our shiny new kernels if his MUA is years old?

-- TeknoHog (Pine.LNX.4.44)

Re:The most important point here is..

[tftp]

Pine.LNX.4.31.0202051928330.2375-100000

Well, at least he runs Linux...

Re:The most important point here is..

[WeedMonkey]

If he didn't, he'd be in trouble round here. "I don't care *who* he is, if he's not using Linux, his opinion doesn't count".

Is Linus still working at transmeta ?

[CDWert]

How much time does Linus have to dedicate to all these patches that get submitted ?

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 ?

[gmack]

There are seperate forks: 2.2.x and 2.4.x. Neither are maintained by Linus.

It's a floor wax and a dessert topping

[Anonymous Coward]

Bitkeeper is available under two licenses. The commercial license costs money and comes with support. The non-commercial license does not cost money., but it has a requirement that all your ChangeLogs must be sent to a world-readable server controlled by BitMover.

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.

Re:It's a floor wax and a dessert topping

[SurfsUp]

Bitkeeper is available under two licenses. The commercial license costs money and comes with support. The non-commercial license does not cost money., but it has a requirement that all your ChangeLogs must be sent to a world-readable server controlled by BitMover.

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.

Hi Larry ;-)

Re:It's a floor wax and a dessert topping

[Rooktoven]

Great pie! And look at that shine!

Seriously, isn't this very much like what Trolltech is doing with QT?

Re:It's a floor wax and a dessert topping

[jsse]

but it has a requirement that all your ChangeLogs must be sent to a world-readable server controlled by BitMover.

I don't know about others, but it's the most embarrassing thing on earth for me. :P

he changed his mind?

[Anonymous Coward]

I am not following the lkml so I wonder when Linus changed his mind? Didnt he say that everybody should send patches to maintainers and stop bothering him?

Re:he changed his mind?

[RatFink100]

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 :)

crappy license

[Anonymous Coward]

Bitmover has thow worst of both worlds, it gives you the source but you arent allowed to modify it to remove the one thing you dont want.

I think they did it just to annoy people.

Re:crappy license

[ethereal]

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:crappy license

[Anonymous Coward]

No, it doesn't give you the source.

BitKeeper gives you the answer:

[Otis_INF]

http://bitkeeper.com/Products.Comparisons.Perforce .html

Allthough this is marketing poop so it should be taken with a fine grain of salt, it might answer your question.

Re:BitKeeper gives you the answer:

[Anonymous Coward]

The BK site seems to be unavailable now (wonder why?) so I can't check the revision date on that page, but I can tell you that a friend of mine who knows Perforce and CVS and Clearcase and a bunch of other revision control systems wrote the BK guy and disagreed with more than half of the stuff on that page.

He got a fairly unprofessional response.

I've used Sun's source control tool, and it was so awful that I've wiped its name from my memory. It locks the entire repository to do anything! So updating a source tree over an ISDN line (which took about 40 minutes where I was working) prevents anyone else from checking anything in until you're done. That doesn't save much time, let me tell you, and it really pissed off the other developers.

And guess what, the BK guy wrote that too, and thinks the locking is a feature.

Maybe that's changed by now. Check it out, but watch for 'features' like this one.

Re:BitKeeper gives you the answer:

[smurfi]

Oh boy.

> He got a fairly unprofessional response.
If you write a note to Linus (who has never heard zilch from or about you) and state that his ideas about this, that and the other advantage of Linux over Windows are Wrong, you'll be getting a fairly unprofessional-sounding response too. Even if you happen to be somewhat or mostly correct. That's a fairly universal pattern of human social interaction, I'm afraid.

> 40 minutes over an ISDN line
So the heap of changes either was damn large, or the wire format was damn inefficient.

Surprise: you cannot do anything about the former, and there wire format BK uses is really compact (and THEN it's zipped while transmitting), so that's a non-argument.

> locking
How else are you going to make sure that every change will be applied to a consistent repository AND that every change leaves the repo in a consistent state?

If transmitting your changes takes too long, you can easily write a small script which transmits your changes and applies them on the server. Don't forget to make sure that nobody else will check in any of their changes while you've been sending yours. Oops, if you want to prevent this from happening you need a lock. What a surprise...

Re:BitKeeper gives you the answer:

[lm]

That response was probably me and I'm sorry if you didn't like it.

As to your comments about teamware, I agree with them and we fixed them in BitKeeper.
For example, a null update of 15MB tree over a modem takes a second or less.
An update which contains 50K of diffs to 50 files will take about 4 seconds.
One of the primary BK developers is stuck behind a modem, that's his only access.
BK is blazingly fast over a modem, I'll give $100 to the first person who shows me a system which
can do the same basic hack/checkin/commit operation faster over a slow speed link.

As for locking, we only lock the tree when doing tree operations, such as an update from another tree.
And those operations are pretty fast. We do run an integrity check over the tree after updates, which takes
90% or more of the update most time.

Re:BitKeeper gives you the answer:

[akushner]

My guess is that you are referring to Zenin/Byron.

I'm making that guess since we've only had one person argue with the content of the comparison page in the last three years.

As to giving an unprofessional response, the person in question sent us an email stating that "our website was either done by idiots or liars."

Do you think that is a professional way to ask a question?

He then went on to make claims such as "CVS rename support is as good as BitKeeper", "ClearCase will run on a pentium 200 without any problems", "RCS doesn't have any limitations", etc.

While he claimed to know all of the other SCM systems, he didn't come off as the sharpest tool in the shed and he was particularly abusive in his tone.

Obviously, disregard if you are referring to someone else...

Re:BitKeeper gives you the answer:

[Anonymous Coward]

"ClearCase [...] is no longer being developed."

Liars.

Linux kernel uses source control

[leshert]

In other news, demons all over Hell were seen lacing up their skates for the upcoming hockey match against the U.S. National team.

Re:Linux kernel uses source control

[binner1]

I don't usually do this, but here goes:

<troll>That wouldn't be much of a game...try the Canadian Nation Hockey team</troll>

-Ben

PS: Don't take offence, just a little national pride!

Re:Linux kernel uses source control

[Pyrosz]

In other news, demons all over Hell were seen lacing up their skates for the upcoming hockey match against the U.S. National team.

Thats not Hell! Thats Canada!

oh, wait..

Re:Linux kernel uses source control

[Anonymous Coward]

What? Hell's frozen over?

Re:Linux kernel uses source control

[NonSequor]

If you take Dante's Inferno to be an accurate description of Hell, then the innermost circle of Hell, reserved for traitors, has always been frozen over.

Re:Linux kernel uses source control

[sharkey]

And those damn pigs keep breaking the windows in our 8th floor office.

Re:Linux kernel uses source control

[MobyTurbo]

In other news, demons all over Hell were seen lacing up their skates for the upcoming hockey match against the U.S. National team.

New Jersey already has a hockey time called the Devils! :-)

I feel better.

[Anonymous Coward]

I still use it, too. That and Mozilla mail.

2.4 and general kernel development

[Dacmot]

On the BitKeeper website, they aslo say that 2.4 (as well as 2.5) is hosted by BitKeeper.

Seems to me like a good idea to speed up the kernel development pace while still keeping control. And it seems to make Linus happy :o) Looks like he's having fun playing with it.

-Dacmot

I think Arch would be better

[Anonymous Coward]

For much of the same reasons it is better than
Subversion:

http://www.regexps.com/src/src/arch/=FAQS/subver si on

Re:I think Arch would be better

[Anonymous Coward]

/. inserted a space into the URL for some reason.
Here it is again:

"http://www.regexps.com/src/src/arch/=FAQS/subve rs ion"

Hmm, /. is still inserting the space in "subversion".
Strange...even placing it in quotes didn't help
in the URL.?

Re:I think Arch would be better

[ethereal]

/. inserts a space in any string over a certain size to prevent attacks where someone posts a huge string and forces the display to be a mile wide.

If you make the URL a link like this (which is common courtesy anyway) then /. doesn't break the URL.

The next step?

[Kopretinka]

So soon we'll start hearing that BitKeeper doesn't scale, right?8-)

Oh no!

[L3WKW4RM]

Hopefully they don't keep the repository on the same machine that hosts their website...

We may have /.'ed the kernel!

Detail in changelog

[srealm]

I must say, I *LIKE* all the detail in the changelog now. For a LONG time, I've thought the changelogs for linux have been too understated.

'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 ... X hardware, X version, etc"

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.

Re:Detail in changelog

[Dan D.]

One of the advantages I see of this kind of detail is that a newbie (or me, really) can follow the changes and start to figure out where things in the kernel actually are. This could be good for the learning process.

Re:Detail in changelog

[rgmoore]

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.

Re:Detail in changelog

[Anonymous Coward]

It would be really nice if Linux moves to using a defect tracking system such as BitMover's BugManager or Bugzilla. The changelog would then have tracability into reported defects and enhancements. It would also kernel development team to better coordinate their work and imporve the ability of the community to communicate with the kernel development team. The only way I personally know of to report a potential defect in the kernel is to subscribe the kernel developer mailing list, which I have absolutely no interest in mucking with. Furthermore, if I reported a defect on the list, how could I know if and when it was fixed? As an example, I reported a defect to Sun about Java, and got an email when it was corrected. Granted, it took them about a year, but I had tracability into the problems. As another aside, users could also be allowed to vote on the most important defects.

Therefore, I too applaud the added detail in the changelog, but I would like to see Linus and Co. take it one step further by allowing members of the Linux community to better track their issues.

Downloading bitkeeper

[heroine]

Signing up for the mailing list in order to gain access to the bitkeeper download can be a bitch.

Free vs. Open Source positions

[Lumpish Scholar]

The Free Software movement says, "Use the software that's the most free. If you still have a choice, use the best software."

The Open Source Software movement says, "Use the best software. That will often be Free / Open Source software."

Re:Free vs. Open Source positions

[efgbr]

What the heck are you talking about?

Your comment doesn't reflect the opinions of the Free Software Foundation. A software is either free software or not.

If this was true, FSF would be recommending you a *BSD, not the GNU system.

Re:Free vs. Open Source positions

[10am-bedtime]

the "free software movement" actually says something simpler: write free software. (simply using stuff does not move anything anywhere.)

Bad news

[AirLace]

It's somewhat sad that Linux, which has often been referred to as the pearl of Free Software, will now be developed using non-free software.

One of the immediate consequences I can see from this move is that Debian users will no longer be able to participate in active (ie. more than just sending in patches) kernel development, as Debian policy states that Debian can only include Free Software. Of course, they can install the proprietary BitKeeper from an unoffical non-free apt source, but I doubt most Debian users will be willing to do this. Judging by what I've seen, several leading kernel developers, notably Ben Collins, are Debian users. A resolution must be found to this problem, even if it involves one of the bigger companies purchasing BitMover just to set the code free. In the long term, judging by the fervent vigilance of the Free Software community, I could forsee that this could be a very nice excuse for a fork of the Linux kernel which will be developed using Free Software only, such as CVS.
Of course, there's also the "laughing stock" factor. Whilst it may not be so bad for the Linux community, the Free Software community (if they can be set apart) will have less to be proud about when it comes to the kernel.
For sure, this has made kernel development somewhat less accessible to a large group of Linux users. I've always believed that revision control could help Linus, but surely the Free Software community has something at least as good as, if not better than the propretary offerings? Otherwise, we're no better off than using Microsoft SourceSafe.
Slashdotters should know better than most the difference between free beer and free speech.

Re:Bad news

[Anonymous Coward]

Just because BitKeeper isn't "Open Source(tm)" or "Free/Libre via GPL(tm)", doesn't mean it isn't free software. You can still get the source and develop free software with it.

Re:Bad news

[josh crawley]

OH NO!! We're using NON-FREE software in our Kernel project!

I'll take the "public Humilation" by using a kernel produced by what seems a better way of maintaining patches. If that means the linux compiles crash less ( usually due to me not finding THAT correct patch), I don't care. And to address those debian people: If you want to break off the rest of the crowd, go ahead. Just don't come crawling back when you go the way of FreeBSD.

The only "laughing stock" is you rambling on how this will destroy the linux community..

Josh Crawley

Re:Bad news

[elandal]

How does Linus using BitKeeper make kernel development harder for those who don't have it (can't afford, won't use non-free software, whatever)?
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

[josh crawley]

"If that means the linux compiles crash less ( usually due to me not finding THAT correct patch), I don't care."

I meant Linux Kernel compiles. If I didn't fix my little mistake, some anonycoward would jeer at me.

Josh Crawley

Re:Bad news

[Anonymous Coward]

More Bad news:
Someone should start porting BIB isn't BitKeeper to Free Software, before RMS decides that it should be called GNU/BIB. Linus may switch to BIB when it scales better. In the news several years later, Miguel decides that the future API of BIB is BIB .Net

Re:Bad news

[Xzzy]

> It's somewhat sad that Linux,

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

[Skuggan]

Before Bitkeeper developers on Debian sent email's with patches to Linus.

After Bitkeeper developers on Debian sends email with patches to Linus.

What is the difference?

Re:Bad news

[Chris Pimlott]

The argument that some people will use is
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

[crush]

There's is absolutely NOTHING wrong with charging for software.

That depends on what ethical and moral framework you are evaluating RIGHT/WRONG within. From some points of view withholding ideas that have zero cost for reproduction is an immoral attempt to exert power over others by software hoarding. They would further argue that this proprietary framework retards development and stifles innovation.

If you do nothing but write software for work, you have a reasonable expectation to make a living off it.

Most of the "Free" and "Open" software world has been arguing about this precise point since the success of Free Software in the form of GNU and Linux. The mantra used to be that one could make a living off service/support. That is what RH etc. are trying to do. There's a big difference between that and hoarding the actual product and charging per-seat licenses for each new version. Bitkeeper tried to find a middle way with allowing a dual-license: free,non-Free for those that surrender privacy, non-free,non-Free for commercial users that want to cloak their activities. This license is discussed here. This is an interesting idea and it is good software, but it is not Free.

The world doesn't run off charity man, nothing is free.

On the contrary, most of human activity is free. However, in this whole discussion you are missing the contentious part. Most GNU users are concerned about Freedom, not cost. This is an OLD argument!

Re:Bad news

[dangermouse]

That depends on what ethical and moral framework you are evaluating RIGHT/WRONG within. From some points of view withholding ideas that have zero cost for reproduction is an immoral attempt to exert power over others by software hoarding. They would further argue that this proprietary framework retards development and stifles innovation.

Most sane people consider this idea absurd. 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.

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.

This is the same reason carpenters don't just walk around building houses for free. You can argue bits vs. atoms all day long, and babble about true cost of replication as much as you want, but the fact is it's the time spent that has to be paid for.

I'm all for freeing software whenever possible, but sometimes it just isn't reasonable to expect someone to give away their work.

Flame on... I'll check in later.

Re:Bad news

[rootmonkey]

So since Linus uses a tool he paid for to help manage the source we should aviod it? Thats pretty lame. I'm sure he paid for his computer that he develops on, should we botcott that too. Its a tool, if it helps him and he wants to buy and use it let him, whats the big deal. It is not wrong to buy/sell software.

Re:Bad news

[crush]

Most sane people consider this idea absurd
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

[Anonymous Coward]

We do that anyway, you worthless sack of shit.

Re:Bad news

[evilpenguin]

While I'm automatically suspicious of phrases like "Most sane people," I must say both of you have a point.

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

[crush]

I disagree that selling software is "software hoarding." Not giving away source code is software hoarding.

Correction conceded and accepted gratefully

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?

I hope someone answers this, it's a great question.

Re:Bad news

[RustyTaco]

This is the same reason carpenters don't just walk around building houses for free.

So Habitat for Humanity is just a figment of my imagination?

- RustyTaco

Re:Bad news

[josh crawley]

Funny... now FUCK off

Re:Bad news

[Anonymous Coward]

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.

Wait a second here! By your logic, people would use MS-Windows/IE/AOL to see slashdot for the first time, find out how they're being manipulated, and then seek alternatives that comply to open standards.

(Grumble grumble.)

Yeah. By your logic, people would use something like, say, a filesystem from a payware/open source teaching tool and then create an operating system that eventually makes even that filesystem optional.

Can't happen. ;-)

Re:Bad news

[Anonymous Coward]

Do you actually think that that (And by extension Open Source) will every about to more than .01% of the housing (software) space under that model? Habitat for humanity does essentially nothing in the scope of all housing needs. It is an abberation. Just as O.S. is. To claim it is anything more is to be completely out of your mind.

Re:Bad news

[dangermouse]

Sorry... I realized right after I submitted that I'd left out the actual point of my post, and then I had to go to work (writing software, incidentally). ;)

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.

Re:Bad news

[jo42]

And the kernel is still a rancid ball of mud.

The devil must have had to put on a sweater

[buckrogers]

I am very thankful that Linus finally "saw the light" and started using a source code control system.

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

[HamNRye]

And then Linus complains and complains....

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

[TeknoHog]

You mean, the Berkeley Software Devil?

Re:The devil must have had to put on a sweater

[Anonymous Coward]

And Linus will never lose another patch again, they will be saved for all time in the source tree under a seperate branch. Once [Linus] 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.

The next thing you know, people will buzz around those "unvetted" branches, tuning things and messing with things, Bizaar style, and by the time Linus gets around to seeing something, the peer-review will have already improved quality.

Now just because that is a happy analysis, I challenge you, reader, to poke holes in what I just said. Why would this not be the case?

Doncha just love hypocrites?

[Anonymous Coward]

"I'd be upset if Microsoft had it in their license, but here, it seems appropriate. "

If Microsoft promised to refund your money within 30 days if you were unsatisfied with the product you would be whining that it wasn't 45 days.

Re:I know it's off topic... but I gotta know

[ethereal]

Drivers are distributed with the kernel for two reasons:

• It's convenient for users to get it all in one package
• It's convenient for developers to keep it all together so that if the core interfaces change, the driver change will happen quickly.

The USB drivers aren't overly entangled with the real innards of the kernel, they just happen to be shipped in the same tarball.

architecture problem, not SCM problem

[markj02]

The problem with Linus getting overloaded is not a problem with SCM, it's a problem with the Linux kernel itself: too many kernel enhancements and bug fixes (apparently) require patches all over the kernel. What we really need is a more flexible way for extensions to hook into the kernel and override existing kernel functionality.

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.

structures: Cathedral, Congregation, Cell

[kurisudes]

When I think about the orginizational movements and changes that are going on in the kernel developor I can't help but feel a similarity to the orginizational transformations within various parts of the Christian church... I mean the word catherdral which all understand as being that a small closed group are speaking and therefore are being heard well. The next step congregation (or bazaar if you prefer) is many people being opened to speaking but with no way for all of them to be heard well and so many get lost without a minister (maintainer) to listen to them, which results in people losing personal care and leaving the project. The next step which some churches have moved to is the cell model.

In this model there are many small groups (trees) within the church and everyone is part of one. These small groups are miniature churches that do all the things that a large size church does and when they get too large to incorporate everybody they split into two groups. They also come together in a larger community where the things the small groups do are brought together with common vision and direction. Under this model, all speak and all are heard. Nobody is lost and all ideas etc. can become part of the whole.

I think Linus is moving towards this whether he knows it or not. He already recommends the different trees to develop and people to become a part of a smaller network of maintainers etc. that pass on to other developers until it reaches him.

Re:structures: Cathedral, Congregation, Cell

[Anonymous Coward]

After seeing the Chris Wong "subthread", I pipe in that an effective organizational allegory would be federalism. You see it in politics throughout the world with varying levels of effectiveness.

Political power in the U.S. is distributed like DNS and is so explicit that the 10th Amendment forbids the "top level domain" to administer subdomains (states, eg, New Jersey) (except for purposes of commerce, etc, which was the reason the Founding Fathers drafted the original "RFC", the Federalist Papers, which, upon ratification, became "Constitution 1.0").

In the political power "DNS system" of the Western Hemisphere, when you go above the U.S. domain you see looser confederation, eg Organization of American States, NAFTA (which is like the 10th Amendment on steroids) and the like. There is practically no power to tax, defend, etc.

Without digressing too far from allegorically useful discussion, it is worth mentioning that the squeaky tight bilateral arrangement between Canada and the U.S. is so cozy that arguably the strongest military fortress ever built has co-commanders loyal to the Canadian and U.S. governments, respectively.

In this system, there are also strong loyalties that "cross the pond" (NATO, recent anti-terrorism policy coordination) and go further yet (UN Charter, ABM Treaty, Kyoto Protocol, UNHRC, and other things so easily dismissed by U.S. policy makers after getting power within their own domain).

The nation state--most notably the U.S.--is still the unit of governance that retains the most political power. For that reason, confederations like the EU and the fiscal/banking coordination system that gave (SOLD :-)) the world the Euro are not as powerful politically. Such federations (confederations?) are like a mutually confident handshake compared to a constitutional contract.

Ok then. Linus Torvalds has been a POSIX fetishist since day one. POSIX is the weak "top level domain" or the "UN". Microsoft gives nods to POSIX (and Cygnus-gone-Red-Hat keeps 'em honest on it).

Still, the power of significance is Linus--more to the point, the significant power is Linus's editorial judgment in code. There are confederations and treaties that enable interoperation of userland software like elm on BSD and Linux alike. Even bash and the scripts it triggers can work in Mac OS and MS Windows and the more sincerely POSIX-compliant "countries", eg, QNX, Solaris, SCO, Irix. This is like fixing currency conversion and ultimately issuing out Euros. It is technically strong, politically weak.

Now that Linus is hastening the archiving--refusing to drop proposed patches "on the floor"--his quantity of power would likely remain steady throughout the transition. However, by a sort of "First and Tenth Amendments", he/we has/have leveraged the GPL to encourage Cathedral-like work to occur in subdomains. The proposed patches get registered so that people do not need to pour over reams of disorganized mailing list and Usenet archives to see and to improve code under development (which used to be the implicit status quo of a "dot odd" kernel, i.e., nearly indistinguishable from unmitigated chaos). In a sense, his policy shift solidifies things. It is as if a constitution has been drafted and ratified and amended to assure the citizenry the right to deal with code before Linus gets the time to see it. Patches that are "pre-Linus scrutinized" are in reserve.

Here is the Tenth Amendment to the U.S. Constitution in full: The powers not delegated to the United States by the Constitution, nor prohibited by it to the states, are reserved to the states respectively, or to the people.

My guess is that this traditional Linux kernel development organization will evolve to use development culture in subdomains. That's why I like the church allegory above this thread. (Thanks for sharing the idea. :-)) However, the allegories of churches don't seem to be quite as illustrative as the politics. It's always a matter of balancing between chaos and order, which is the aim of liberal states throughout the world and throughout history. With or without a decisive liberal revolution, with or without a king, liberal policy (the aim toward democracy) has always been the cure for the ills of chaos and centralized tyranny. Whenever liberal systems get put into place, what results approximates federalism, a domain system of sorts. It balances self determination with hierarchical order.

I reserve copyrights and license this for noncommercial purposes.

Wanting to be different?

[RinkSpringer]

Whoa, this is the first time I've ever heard of Bitkeeper... I do use a lot of open-source software, and this is the first time the name Bitkeeper came up...

Is it just me or does it look like they want to show once again that Linux is different from all other projects?

I mean Linus is still in charge of Linux... and now, he uses some exotic software program which now suddently everyone hears of. I wish my company made that program, that'd get me some licenses! :)

Re:Wanting to be different?

[daveman_1]

Check the kernel archives. This has been discussed for a long time. Bitkeeper is not new.

Re:Wanting to be different?

[osu-neko]

Whoa, this is the first time I've ever heard of Bitkeeper... I do use a lot of open-source software, and this is the first time the name Bitkeeper came up...

Either you live under a rock or have no need for/have never investigated CVS alternatives. Anyone who has has known about Bitkeeper for years...

Is it just me or does it look like they want to show once again that Linux is different from all other projects?

It's just you... and possibly a few other people who've been living under rocks for the last few years...

and now, he uses some exotic software program

Nothing terribly exotic about it.

which now suddently everyone hears of. I wish my company made that program, that'd get me some licenses! :)

Anyone likely to have a use for this sort of program has probably heard about it long before. OTOH, being adopted by Linus will probably cause some people to give it a closer look, which will probably get some more licenses...

Re:Wanting to be different?

[Anonymous Coward]

as I use Linux/PPC I heard about BitKeeper a
long long time ago.

surely you've heard of it before?

now to get my 2.5.4 from BK ;-)

"A Critique of the BitKeeper License" by Jack Moff

[CondeZer0]

I found very interesting a document from Jack Moffitt (of xiph.org fame,
one of the main Ogg developers and one of the Icecast Core Developers),
about some problems he had with the BK license when he was using it
for hosting Icecast:

"A Critique of the BitKeeper License"
http://www.mit.edu/afs/athena/user/x/i/xiphmont/Pu blic/critique.html


You might also find interesting his post on the matter to the
"Icecast Developer Discussion List":

http://www.xiph.org/archives/icecast-dev/0067.html

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

You fool...

[rho]

/* you are not expected to understand this */

No free alternatives?

[leandrod]

I did a superficial investigation on source control systems, and found some very interesting really free ones, like Aægis.

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?

[Pjotr]

Bitkeeper, from early days, aimed to support Linus' way of working. It has been on the books for years. I am surprised the move did happen ;-).

If it is good for Linux it is good to support the bitkeeper developers.

Re:No free alternatives?

[leandrod]

Freedom is more important. Specially if there are alternatives.

Re:No free alternatives?

[smurfi]

From a cursory look at their front page, Aegis cannot do at least one thing which Bitkeeper can: true peer-to-peer interaction. Aegis still has the idea that there's a master repository you integrate changes into. With Bitkeeper, there isn't any (or rather, the system doesn't force you to have one) -- if you want Alan or whoever to check out your nifty patch, you just mail it to him.

Bitkeeper can do some other things really well. Check out their Web site if you want' I'm not going to type a BK commercial here.

Yeah, Bitkeeper isn't open-source-purist-free. So what. It's a great piece of software, and anybody can use it for free, and the people involved need to eat. Give them a better business model which is proven to work (theirs does work, according to Larry), or shut up please.

IMHO, the best selling point for BK is that it's written by a bunch of people who really know their stuff and who are willing to listen to what other people need. I speak from experience here; they did a whole lot of heavy-duty bug chasing for me, and I'm not even a paying customer.

Re:No free alternatives?

[leandrod]

Sorry, sir, no open source purists here. We stand for freedom.

Re:No free alternatives?

[fremiste]

There are no free alternatives to BitKeeper. (even Clearcase and perforce come up lacking compared to bitkeeper)

Please tell me what GPL/BSD revision control systems support:

ChangeSets

Distributed repositories

Data integrity checks (and no, Subversion and arch don't do checksums). Look on the Subversion mailing list to see how the lack of checksums bit them when they were experiencing network corruption.

No loss of information when merging

Useful GUI tools -- checkout bk's revtool and fm3tool

In other words, you haven't seem to have done any homework. You are just another "free software only" weenie.

signed,
Just a happy bitkeeper user for the last two years.

Re:No free alternatives?

[dlakelan]

Aegis does all of those.

The main thing about Aegis is that it enforces a process. I doubt Linus would conform to the Aegis process if he just now got version control.

Re:No free alternatives?

[leandrod]

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?

[leandrod]

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.

Re:No free alternatives?

[fremiste]

There is nothing disreputable about "free software only". Sometimes it is not realistic or practical. I love free software, but I also realize that having a dedicated company supporting a product as complicated as SCM is very important. Also, there isn't just a "marginal" improvement as you imply. But then again, you haven't tried BitKeeper, have you?

"I think Aegis does all of this". Are you sure? Have you tried Aegis? Really put it to use? Compared it to Bitkeeper? Tried using it for code projects as well as documentation and sysadmin projects (i.e. where test cases don't apply). If you have and like Aegis better, then more power to you. Claiming "I think it does this" isn't really that compelling....

No one is forcing you to do anything. It would be interesting to know why you feel that your freedom is threatened.

Re:No free alternatives?

[leandrod]

> 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:I know it's off topic... but I gotta know

[markj02]

Either kernel additions like USB can be distributed without patching the kernel or they can't. If they require patching, it's a burden on Linux, on packagers, and on users. Whether it requires a little patching or a lot of patching doesn't make a difference.

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.

Cells don't scale

[ChrisWong]

No not "all are heard" in a cell model. It is essentially a partitioning that makes groups more personable, more anarchic and cosy, but does not scale. Think about it: you talk about cells coming together in a larger community so all can be heard. That's fine for smaller groups, but what happens when a church grows to, say, a million or a billion in number? Linux development is more so: communication is intense and data-heavy. The model, as it is now and continues to be, is the traditional hierarchy. Linus trusts a select few, who maintain their own hierarchies. The classic hierarchy is the only structure that works for large groups that need strong direction: armies, nation-states, and yes, some churches.

Re:Cells don't scale

[kurisudes]

Actually, a further look at a cell model style shows that it does scale very well... a cell model generally has a leader for every 5 cells and a group of 5 of those are a leadership cell... and over every five of those there is a leader and so on and so on... The largest church in the world, Yoido Full Gospel in Seoul, Korea (with a membership of several 10s of thousands) is cell based from the bottom up.

Re:Cells don't scale

[ChrisWong]

I don't see how you can count a Yoido Full Gospel as the "largest church in the world". The Orthodox number approximately a quarter billion. The Catholic Church numbers about a billion. And yes, they are hierarchical. There is nothing wrong per se with cell groups, since even hierarchies like the Catholic Church have cell groups as a parallel structure. Cells certainly have advantages. But software development, like armies, need clear, solid direction, discipline and communication. Once you build a leadership structure into a cell structure, you pretty much have a classic hierarchy tree and the cell/hierarchy distinction is meaningless. I suspect that one could say the church that you described may be "cell based from the bottom up", but also simultaneously hierarchical from the top down.

Re:Cells don't scale

[kurisudes]

What I meant was the largest single congregation in the world. Also while cells do have a top down heirarchy the more important focus in this sense is the CELLS from the bottom up. Often a cell will be involved in its own focus and while the top might decide on things like a statement of beliefs, the cells often are self directed to a large extent. Bringing this back to programming the leaders may decide on some overarching specifications (which the cells would follow for compatability) but the "kernel cells" would be able to choose to move their trees fairly independantly as far as patching and changes etc.

The important distinction from what's happening now is that in cell based development, all the development would happen in these sub-trees and all developers would belong to a tree, whose seperate mailing list would be their main place for discussion etc. Meanwhile the overarching development would be going on by the leaders of the leaders (or whatever) for bringing together the development done in these smaller groups...

Free enough

[Chaostrophy]

No charge if you let it send your change logs back to bitkeeper for public display, and you get the source, under basically the GPL, with the one restriction that it pass the regression tests (essentailly, you have to let it send the change logs back).

OK, so that's not technically free software, but isn't that close enough?

Security?

[Quixote]

From Linus' email, mentioned above:
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?

[briansmith]

I assume that he would _read_ the email first. Otherwise, how will he screen the PGP-signed "Cum_To_My_WebSite.diff" messages that are likely already flooding his inbox?

Re:Security?

[Anonymous Coward]

The point is that Linus reads the patches before he accepts them...

That's why he's in charge.

Re:Security?

[Anonymous Coward]

Your already small penis shrivels ever closer to oblivion with each passing moment.


Your


penis


is


shrinking


down


as


I


type


this


lovely


post.


Do


you


like


ham


dickwads?


Guzzle


sheep


skin


vaginal


excretions.


And again I say, propz to all dead homiez. I worship the godz of trolls past. You are not worthy of my bitchin' poster mad skillz, you odd jar of mustard.

The rest of this post is just to get the words per line count up to a tolerable level, so all the Slashdot world can view my mighty Trolaxor-like abilities in the fine art of mad posting.

Re:I know it's off topic... but I gotta know

[roryh]

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.

Odd...

[Anonymous Coward]

Geeks tend to laugh at people for wearing shoes, etc. because a sports figure endorses them.

This looks vaguely remeniscent of that; does it not?

BitKeeper License

[leuk_he]

n the event that the Open Logging servers cease to function for 180 days,
BitMover has written into the license that the software shall be licensed under the GPL.

So DOS the heel out off those servers and make it gpl software!

CVS has limitations

[mrm677]

I don't blame Linus for trying out Bitkeeper. After using Rational (formerly Atria) Clearcase for several years, and then working on a project using CVS, I can't believe that CVS is hyped the way it is. Sure, it works for small projects.

Why nothing can beat Clearcase:

1. Clearcase is integrated into the OS and the repositories are actual filesystems. I create a "config_spec" that lists all of the branches and labels that I want to see. I don't have to checkout stuff, and copy a large project into a private directory. If I want to see another developer's change to a small set of files, I just add his/her branch to my config_spec. No recopying or anything like that.

2. Clearmake. If someone else in my organization builds the same object file (from the exact same version of the source file), I don't have to rebuild it. I love typing "clearmake" of something huge that I've never built before, and it is done in no time!! If something does have to be rebuilt, builds are distributed across a dozen or so machines.

3. Real branches. When I am developing something, I make a temporary branch on all the files. If I want to be able to let someone else use my "development" branches, I just let them know what the branch name is. When it is production-ready, we just merge the development branch into the main branch. No such thing as patch files in Clearcase world.

There is a reason that Clearcase is expensive and proprietary.

Re:CVS has limitations

[Grapes4Buddha]

Unfortunately, ClearCase is not appropriate for most free software / open source projects because it is not architected well for distributed development teams, not to mention that you need to purchase licenses at several thousand dollars a pop for each concurrent user of the repository.

Re:CVS has limitations

[Ed Random]

I've been a ClearCase administrator for a couple of years, and I really liked ClearCase. But there are some drawbacks to the points you bring up:

1. Clearcase is integrated into the OS and the repositories are actual filesystems

...Which makes life hell if you need to upgrade the OS. Our production servers should be kept on the same OS and patch level as a matter of policy. With all these different OS/Patch requirements for applications like ClearCase, keeping your environment sane becomes a major nightmare.

Furthermore, there are serious performance issues which have prompted some development teams to use Snapshot views instead, negating many of the advantages ClearCase brings (through the MVFS).

2. Clearmake

ClearMake is nice when people work on relatively dynamic code which is shared 'early and often'. The DO Config Record lookups can swamp your DB-server though.

I liked the "automatic dependency generation" in ClearMake (config records). No more 'make deps' ;)

Again, with Snapshot views ClearMake loses its charm.

3. Real branches

ClearCase is definitely not the only tool supporting "Real branches" ;)

Just my 0.01 (that would have been 2.20371 cents in ye olde days...)

--
Gxis!
Ed.

Re:CVS has limitations

[Anonymous Coward]

I use clearcase as well. It's pretty good when it works, which is most of the time. I really like delivering an activity versus manually checking in 25 RCS files. But there are also some limitations:

1. If you don't use clearmake, then you have to be careful with dynamic views. Regular make looks at time stamps; clear make does not. A dynamic view can confuse "make". Our company uses features of gnu make that preclude using clearmake.

2. I'm not sure about using somebody else's .o files -- but what if they compile with optimization and you don't? What if you compile with -DDEBUG and they don't?

3. CC can create a lot of busywork. Our company's productivity grinds to a halt when a new baseline is declared and we have to recompile everything from scratch. And then recompile on delivery to integration.

4. CC has stability problems under load, particularly for dynamic repos.

5. Automatic merges can provide some nasty surprises.

6. The GUI on solaris.

All that being said, I still prefer clearcase to everything else I have tried.

Re:CVS has limitations

[Lord Hugh Toppingham]

it is not architected well for distributed development teams

BS.

Re:CVS has limitations

[wscott]

I know it is off topic, but you mentioned clearmake. Open source projects should really try CONS. When you use the drived object cache it will automaticly grab any objects that someone else created and you know they are right. It has automatic dependancy scanning and doesn't use file timestamps so builds are MUCH more reliable.

And when it is fully cooked, SCONS will also be a good choice.

Karma Whoring

[Amazing Quantum Man]

That comment really is there in the old V6 source. I went looking for it.

Getting the debate all wrong ...

[kiris]

The whole reason we have free software is to improve the quality of all the software we use. The biggest problem of proprietary software is that there are usually tons of bugs that never get fixed. However, with free software(as in speech) those changes can be made by anyone who sees fit and perhaps send a patch to the original programmer. That's why linux was originally developed with an open-source model, because Linus wanted the feedback. Besides, Debian users will have no problems with using this commercially-_housed_ Linux. The DFSG only applies to the source code of the packages they themselves distribute. Since bitkeeper is only a tool, it has no bearing on the _freeness_ of the kernel.

Ehh short answer, whatever scratches your itch. If commercial software works, then why not use it?

Re:Fist Sport!!!

[Anonymous Coward]

DUDE!!!!

I could kiss you. If I had mod points you would have all five (even being an AC)

Off-topic MY ASS!

cheers

Re: Catch-22

[SpaceLifeForm]

It is the nature of a kernel that mods may require patches 'all over the kernel'.

That said, your suggestion of using hooks will also require patches 'all over the kernel'.

Where are Open Logging Repositories stored?

[Anonymous Coward]

If you go to bkbits.net, it looks like the projects are stored there. That would mean if you were okay with having your changelogs stored in the open, that you woudl also get free hosting for your project.

That seems kind of wrong. Is bitkeeper just giving you free storage/band width with the open logging.

It seems more likely they are just storing the change log, but then where is the project itself?

Re:Where are Open Logging Repositories stored?

[lm]

www.bkbits.net is a free hosting service we provide.
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.

Re:Fist Sport!!!

[Anonymous Coward]

nope, try the trick mentioned above, it makes the widener post sooooo thin... they still lenghten a bit tough.

MOD THAT UP!

BitKeeper? Feh!

[J'raxis]

Linus should read Slashdot.

Re:BitKeeper? Feh!

[fremiste]

And you point is what? That linus should use arch? Have you actually tried using arch? arch is not ready for prime time and it certainly is not as useful as bitkeeper.

Re:BitKeeper? Feh!

[fremiste]

(forgot to post this part)

Do you have any technical problems with BitKeeper or are you just a "it must be GPL" weenie?

And yes, I've been using BitKeeper for 2 years and have been very pleased with it.

Financial backup

[twilight30]

Sorry about the headline, I couldn't think of a short-enough one that'd fit.

BitMover also has a clause to help free software developers in the event of the company going out of business, located here (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.

Does this really matter?

[Z4rd0Z]

What does it matter if Linus is using a source control system if no one else has access to it? I think that's really the whole point of using such a system, isn't it? So that multiple developers can check their code in manageably? As it stands now, everything still goes through Linus' inbox. It doesn't appear that the situation has changed very much.

Will there be public read-only access to Linus' branch so people can keep up with the latest?

Re:Does this really matter?

[smurfi]

Anybody can download Bitkeeper, and anybody can sync from the public kernel repository, so where do you get the "no one else has access to it" part from?

There's even a *shudder* Windows version.

Re:Does this really matter?

[StrawberryFrog]

What does it matter if Linus is using a source control system if no one else has access to it? I think that's really the whole point of using such a system, isn't it? So that multiple developers can check their code in manageably?

Nope. Version and revision tracking are also very important.

Re:Does this really matter?

[jo42]

Write access, you Linux tosser.

Bought damn time

[Anonymous Coward]

Linus has finally moved from chaos to order. One of the major complaints about the Linux VS BSD development model (a lack of a control system) has been fixed.

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.

Re:Bought damn time

[fremiste]

Do you have five or six years to wait for a GPLed replacement of bitkeeper? Do you really think that it is easy to create a sophisticated version control system? The Subversion folks have several full-time developers and have been working for two years on their VC system and all they are trying to do is to replace CVS (and Subversion is a BSD license, by the way and not GPL)

And by the way, it is 'bout and not Bought.

Re:Bought damn time

[Anonymous Coward]

It happened to me once...

I went to Silicon Valley loaded with cash. I wanted to make a dot.com because I was told I could increase my capital x10 in the *worst* case. I bought many servers from Sun, Compaq and printers from HP and internet connections from AOL. I wasn't afraid of spending.

Then I hired two programmers who had a degree in computer science and they seemed really good students. They said they wrote about 500 lines of Java code before graduation. So I payed then very good salaries because you get back x10 what you spend. We made a calculator program. Additions, subtractions, multiplications, divisions, even square roots and integrals.

But then some freaks provided a free one with open source under GPL on the internet. And then it was the dot.com boom.crash phenomenon. I really am unlucky. I'm going back to my village to grow eggplants....

Re:Bought damn time

[Lord Hugh Toppingham]

Linus should be using Rational Clearcase Multisite. It KICKS ASS.

pure flame, don't read if you value your time...

[Anonymous Coward]

Don't want to offend you, slashinux people, but you've got to get a clue some day... Second largest miracle after Windows getting popular: Linux became popular too! I honestly pity those people who got on the wrong track since the beginning and now can not get out of there.

Nobody in their right mind should even dare comparing Linux itself and it's development model to FreeBSD, and yet, the Linux crowd is God knows how many times larger... This is even more upsetting than situation with Windows - at least Windows users are not afraid to admit that Windows sucks.

By the way, Theo de Raadt is a very "personable" coder, you just don't know him.

The biggest problem is that the process of getting a clue is very long and painful if you grew up in a screwed up Linux world - BSD developers got sick and tired of such people years ago. Yes, they can be rude (occasionally) to lazy and stupid individuals who refuse to learn something new because of their religious beliefs in the tremendous power of Linux.

You've got to get out of there! For your own good! It WILL be hard in the beginning and only few of you can make it, but then you will never want to use Linux again. Ever. Then again, those who don't make it will hate all the BSDs for the rest of their lifes. Well, at least they will be welcome to the army of unfortunate stubborn Slashdot loosers who just were not meant to be smart when their parents made them.

Yack, my hands feel dirty after typing something to post in this public toilet...

To sum it up:
People, dare to break the clue barrier!

Re:I know it's off topic... but I gotta know

[Anonymous Coward]

"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."

That functionality, according to Linus, is "bloat", so you won't see it.

The problem is that when you publish a device driver interface, you then need to maintain it through the major release, and maybe even the next release.

This is a huge problem in the closed-source world that Linus wants to avoid. (for example the whole point of Windows 95 was to be able to run modern Win32 programs on top of DOS and Win 3.1 drivers)

Did you use pine in the nice days of Pine-1.1?

[john wave]

... when men were men and wrote or did not write their own device drivers?

Re: Catch-22

[markj02]

It is the nature of a kernel that mods may require patches 'all over the kernel'.

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.

Re:I know it's off topic... but I gotta know

[markj02]

Sorry, but you are confused about microkernels. Microkernels consist of separate servers that communicate with each other. Microkernels (like Mach) pay a speed penalty because they use more costly communications and protection mechanisms.

Using dynamically loadable modules doesn't make Linux a microkernel, and adding hooks wouldn't either. The performance penalty would be basically zero.

Bitkeeper Rocks

[szyzyg]

I used this for a couple of years at my last job and it's an excellent product. I used to hate source control systems - especially CVS, but Bitkeeper works excellently.

Bugzilla maybe?!?

[Shwag]

What about Bugzilla? Isn't that a great tool? What about all the tools that the Mozilla project uses?

Re:Bugzilla maybe?!?

[Anonymous Coward]

Bugzilla is overly complex and complicated, and worthless to all non-unix-zealots.

Re:theo

[rifter]

Actually, this is precisely why I use OpenBSD. Think about it. Microsoft adds all kinds of insecurity to their OS because they are afraid of losing customers and developers if they leave out "features," whereas Theo's response to such whining would be something on the order of "tough titty."

When security is a concern, having a paranoid asshole at the helm is beneficial, because he is not going to take in any crap. Honestly, though, it seems to me from reading Theo's posts he is not an asshole in a general way, he isn't just cruel to people for no reason. But he is an asshole when it counts, when it comes to making sure that code quality, security, and technical perfection are there.

A good example is the recent IP Filtering debacle. When the maintainer of the IP filtering system used by OpenBSD tried to cause licensing problems, Theo said "no way" and was not afraid to take it out completely even though he knew most people using OpenBSD were using it for firewalling and would be using the filter. But he would rather rewrite the whole thing than allow the project to be held hostage or allow bad design decisions and licensing problems into the project.

Of course people said "There he goes, again. What an asshole!" And I say they were absolutely right. Thank you , Theo, for not being afraid to be an asshole when it really counted. :)

theo as godzilla

[Anonymous Coward]

http://www.winternet.com/~mikelr/flame67.html (field guide to flame warriors, hilarious reading) And, yeah, I think theo's probably abrasive personally, but then most highly skilled craftsmen are like that...

insightful?!?

[Anonymous Coward]

jebus, I don't know who is more retarded, the original fucktard or the drooling knuckledraggers who moderated the comment.

Thats a curious concept

[Srin Tuar]

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

[lm]

Bob Young (redhat) once pointed out that he loved our license because

"If all the software in the world were developed out the open,
noone would give you any money. So you are encouraging the right thing".

That's true. If the world is 100% free software, noone will pay us and that's fine.
There is enough commercial software out there that we can survive.
If we ever hit the "no more customers" problem, we'll find something else to do.

Re:Thats a curious concept

[fiber_halo]

>>So DOS the heel out off those servers and make it gpl software!
>I wonder who modded that down...

What? I hope you don't think a Denial of Service is a good thing. DOSing is never a good idea.

I understand you were picking up on the point that there may be other interpretations to their license, but I don't think it's unreasonable that someone modded down a post that instructs people to launch a DOS...

Re:Thats a curious concept

[leuk_he]

So DOS the hell out off those servers and make it gpl software!
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.

Re:Fist Sport!!!

[Anonymous Coward]

Man, you're an annoying little fuckhole. Is it sleeting where you live? If so, please go play at skating on the cement at bus stops a lot until you accidentally fall underneath the wheels.

Thank you.

Redundant

[Anonymous Coward]

... you lose your license if you sue BitMover over intellectual property rights. I'm not sure what to make of that, ... I'd be upset if Microsoft had it in their license, but here, it seems appropriate.

Nuff said

nice...

[aCC]

I like especially the new openness that's achieved with this.

It's exciting to see what's being done to the kernel Right Now: ChangeSet Summaries for kernel 2.5

Before this it always seemed to be a miracle of when and how the kernel evolves and why this Linus guy is doing the releases... ;) (joke, Laugh Now!)

Re:"A Critique of the BitKeeper License" by Jack M

[Khopesh]

quote from conclusion that sums up the essay (and told me everything I needed to know about the license/product):

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"