> If you are trying to copy BK, give it up. We'll simply follow in the
> footsteps of every other company faced with this sort of thing and change
> the protocol every 6 months. Since you would be chasing us you can never
> catch up. If you managed to stay close then we'd put digital signatures
> into the protocol to prevent your clone from interoperating with BK.
I think it would be appropriate at this point to write a free client
that talks with Bitkeeper, and for Linux developers to start switching
to that from Bitkeeper. At that point, McVoy will face a hard choice:
if he carries out these threats, he risks alienating the community
that he hopes will market Bitkeeper for him.
On Fri, 18 Jul 2003, Richard Stallman wrote:
> I think it would be appropriate at this point to write a free client
> that talks with Bitkeeper,
Maybe. I'll leave that decision to whomever decides to
invest his time and/or money in implementing such software.
> and for Linux developers to start switching to that from Bitkeeper.
That would be a bit premature. I certainly wouldn't switch
to a piece of software that doesn't exist yet. ;)
To put it more bluntly: free software would have to implement
a very significant amount of Bitkeeper's functionality before
I would ever consider switching to it.
At the moment there simply is no equivalent free alternative
to Bitkeeper, so there's nothing to switch to. Once such an
alternative exists we could continue this debate.
kind regards,
Rik
--
Great minds drink alike.
On Fri, 2003-07-18 at 15:51, Richard Stallman wrote:
> > If you are trying to copy BK, give it up. We'll simply follow in the
> > footsteps of every other company faced with this sort of thing and change
> > the protocol every 6 months. Since you would be chasing us you can never
> > catch up. If you managed to stay close then we'd put digital signatures
> > into the protocol to prevent your clone from interoperating with BK.
>
> I think it would be appropriate at this point to write a free client
> that talks with Bitkeeper, and for Linux developers to start switching
> to that from Bitkeeper. At that point, McVoy will face a hard choice:
> if he carries out these threats, he risks alienating the community
> that he hopes will market Bitkeeper for him.
I can't believe I am going to do this. Especially, where most of my
contributions to OSS/Free Software are not known on this list and the
argument is stupid.
McVoy, changing the protocol would be extremely stupid. However, it is
your product, so do as you wish.
Stallman, believe it or not, you used to be someone I looked up to a
great deal. I still think some of your ideas are great and I would love
to see the entire world as open source. However, to encourage people to
do things that are known to antagonize others is crazy. CVS is crap. I
haven't used Bitkeeper but I have tried a lot of others, and they are
junk. So, if Bitkeeper is as good as Linus et al think it is, then it
would be insane to do anything to ruin the relationship they have with
Bitkeeper. Ideology is great, but it does have to be tempered and meted
out so that it can be implemented in a way that brings the most good to
everyone. At this point, ticking off McVoy will likely do the opposite.
McVoy, thank you for helping Linus, Cox, Miller et al scale better. As
I have said before, I hope there is some way your software can become
more open, but I will leave that up to you and your team to figure out
when and how.
Have a good one everyone.
Trever
--
"All this technology has somehow made you a stranger in your own land."
-- Robert M. Pirsig
How about all of you take a much nicer tilt on this, and ask McVoy (who's
already giveing you the software free) his price to GPL bitkeeper.
Nick
On Fri, 18 Jul 2003, Rik van Riel wrote:
> On Fri, 18 Jul 2003, Richard Stallman wrote:
>
> > I think it would be appropriate at this point to write a free client
> > that talks with Bitkeeper,
>
> Maybe. I'll leave that decision to whomever decides to
> invest his time and/or money in implementing such software.
>
> > and for Linux developers to start switching to that from Bitkeeper.
>
> That would be a bit premature. I certainly wouldn't switch
> to a piece of software that doesn't exist yet. ;)
>
> To put it more bluntly: free software would have to implement
> a very significant amount of Bitkeeper's functionality before
> I would ever consider switching to it.
>
> At the moment there simply is no equivalent free alternative
> to Bitkeeper, so there's nothing to switch to. Once such an
> alternative exists we could continue this debate.
>
> kind regards,
>
> Rik
> --
> Great minds drink alike.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
To add to this, why?
I don't mean to jump on anyone, but so long as someone can pull all the
BK data out if Larry gets unreasonable (via the active and existing SVN
or CVS gateways) who the frig cares if there's a BK clone??? If things
got nasty, pull the data and switch unceremoniously switch to SVN or
whatever.
Are there folks out there today with current SVN repos which have all
the BK metadata everyone keeps pissing on about?
On Fri, 2003-07-18 at 15:06, Rik van Riel wrote:
> On Fri, 18 Jul 2003, Richard Stallman wrote:
>
> > I think it would be appropriate at this point to write a free client
> > that talks with Bitkeeper,
>
> Maybe. I'll leave that decision to whomever decides to
> invest his time and/or money in implementing such software.
>
> > and for Linux developers to start switching to that from Bitkeeper.
>
> That would be a bit premature. I certainly wouldn't switch
> to a piece of software that doesn't exist yet. ;)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Friday 18 July 2003 21:51, Richard Stallman wrote:
> > If you are trying to copy BK, give it up. We'll simply follow in the
> > footsteps of every other company faced with this sort of thing and
> > change the protocol every 6 months. Since you would be chasing us
> > you can never catch up. If you managed to stay close then we'd put
> > digital signatures into the protocol to prevent your clone from
> > interoperating with BK.
>
> I think it would be appropriate at this point to write a free client
> that talks with Bitkeeper, and for Linux developers to start switching
> to that from Bitkeeper. At that point, McVoy will face a hard choice:
> if he carries out these threats, he risks alienating the community
> that he hopes will market Bitkeeper for him.
Hi Richard.
You're ready for a small flame-war with Larry? 8-)
First I think, this list isn't the correct place for starting
a bk-flame again.
But I also share your opinion, that it's time to write even a
free client.
But how hard will it be? How big is the knowlege of the
protocols bk uses? It'll be not easy, but for sure very interesting.
- --
Regards Michael Buesch
http://www.8ung.at/tuxsoft
Penguin on this machine: Linux 2.4.21 - i386
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE/GFjZoxoigfggmSgRAs7XAJ4tZybSXfPTdk7I9cSIuUYSM72xXACfaeOZ
k2QsR3KsL6HxXXj1y/ECdn0=
=2Wzr
-----END PGP SIGNATURE-----
In my mind it's absolutely not worth it. I believe there are
non-commercial protocol gateways from which a copy of linux (complete
with historical BK metadata) can be pulled and converted from.
Larry has his views whether 99.9999% of people disagree with him or not.
He can change the protocol as he sees fit, and we can pull the source
off of BK if we want.
He has stated before, it would be no skin off his balls (to paraphrase).
On Fri, 2003-07-18 at 15:30, Michael Buesch wrote:
> First I think, this list isn't the correct place for starting
> a bk-flame again.
> But I also share your opinion, that it's time to write even a
> free client.
> But how hard will it be? How big is the knowlege of the
> protocols bk uses? It'll be not easy, but for sure very interesting.
Wow, I've just totally underestimated the $$ power on this list. ;)
On Fri, 2003-07-18 at 15:22, [email protected] wrote:
> How about all of you take a much nicer tilt on this, and ask McVoy (who's
> already giveing you the software free) his price to GPL bitkeeper.
On 18 Jul 2003, Shawn wrote:
> To add to this, why?
That's a good question indeed.
> I don't mean to jump on anyone, but so long as someone can pull all the
> BK data out
You're right. There is no data lock-in, so there is no reason
at all why we (FSVO "we") would even need a free alternative to
Bitkeeper.
People who really care about Bitkeeper being non-free can work
towards making a free alternative. Some people are doing exactly
that (I bet you won't see them in this thread though, they're
too busy doing useful stuff).
I'm trying hard to stay out of this, I think Richard may be trolling,
but I need to make sure that people understand that what Richard is
suggesting is violation of our license and copyright.
On Fri, Jul 18, 2003 at 03:51:36PM -0400, Richard Stallman wrote:
> I think it would be appropriate at this point to write a free client
> that talks with Bitkeeper, and for Linux developers to start switching
> to that from Bitkeeper. At that point, McVoy will face a hard choice:
> if he carries out these threats, he risks alienating the community
> that he hopes will market Bitkeeper for him.
Our license states that you can't use BK if you are developing a similar
system, i.e., a clone. Without using BK it's impossible to reverse
engineer BK to create the clone. So your message seems to be saying
"it would be appropriate at this point to violate the BitKeeper license
in order to write a free client which talks with BitKeeper".
Are you really instructing people to go out and violate our license?
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
I second that "Ata boy!". Larry, thank you, for all the help you gave
Linus in the switch over, all the LK specific tweaks to BK, etc.
On Fri, 2003-07-18 at 15:09, Trever L. Adams wrote:
> McVoy, thank you for helping Linus, Cox, Miller et al scale better. As
> I have said before, I hope there is some way your software can become
> more open, but I will leave that up to you and your team to figure out
> when and how.
Again, to add to that, the very existence of BK2SVN and BK2CVS would
seem support the assertion that the license/copyright allow
"work-(sort-of)-alike" developers like (SVN guys) to use the protocol
gateways. It only prevents them from using BK itself.
Really, the existence of the gateways was the end-all answer to the
arguments folks had. The only thing really left is that the gateways
operate on the charity of Larry.
So, just keep those repos up to date from the gateways, and if they stop
working one day, then bitch. But understand, Larry is well within his
rights in all his assertions; he's just quite a bit right of hard line
GNU.
On Fri, 2003-07-18 at 15:44, Larry McVoy wrote:
> I'm trying hard to stay out of this, I think Richard may be trolling,
> but I need to make sure that people understand that what Richard is
> suggesting is violation of our license and copyright.
>
> On Fri, Jul 18, 2003 at 03:51:36PM -0400, Richard Stallman wrote:
> > I think it would be appropriate at this point to write a free client
> > that talks with Bitkeeper, and for Linux developers to start switching
> > to that from Bitkeeper. At that point, McVoy will face a hard choice:
> > if he carries out these threats, he risks alienating the community
> > that he hopes will market Bitkeeper for him.
>
> Our license states that you can't use BK if you are developing a similar
> system, i.e., a clone. Without using BK it's impossible to reverse
> engineer BK to create the clone. So your message seems to be saying
> "it would be appropriate at this point to violate the BitKeeper license
> in order to write a free client which talks with BitKeeper".
>
> Are you really instructing people to go out and violate our license?
On Fri, 18 July 2003 15:51:36 -0400, Richard Stallman wrote:
>
> I think it would be appropriate at this point to write a free client
> that talks with Bitkeeper, and for Linux developers to start switching
> to that from Bitkeeper. At that point, McVoy will face a hard choice:
> if he carries out these threats, he risks alienating the community
> that he hopes will market Bitkeeper for him.
I've told other people before and I'll tell you again:
Please, pretty please, leave linux-kernel for discussions about the
linux kernel and leave the bitkeeper flames for those that enjoy
electronic pyrotechnic.
Apart from that: Larry is right. Noone cared about crappy ol' cvs
until bk came alone and showed what everyone already knew. If you
didn't have to improve cvs back then, it is still as good as it was,
so thy improve it now? Pure jealousy?
J?rn
--
The cost of changing business rules is much more expensive for software
than for a secretaty.
-- unknown
> McVoy, changing the protocol would be extremely stupid.
There are problems with the current protocol which can't be fixed without
a protocol rev, problems that many of the kernel developers have asked us
to fix. Sooner or later we are going to fix them and then there will be
a protocol rev. It's possible we might do one for legal reasons but I
doubt it. I was just pointing out to Rory that if he insisted on doing
something in direct violation of our license it wouldn't do him any good
in the long run.
> McVoy, thank you for helping Linus, Cox, Miller et al scale better. As
My pleasure. At least that part of all of this has worked out pretty
well. We still think BK is nowhere near good enough, there is a lot left
to be done. I just spent the day with one of the MySQL founders talking
about tools for doing reviews, I think those could help. It might be very
cool, for example, if there was a way to distribute the review process
and have everyone looking over code, recording notes about possible
problems, etc. Then Dave could grab an espresso, hit the web site,
look over the code he cares about, see the reviews, fix it, move on.
It's sort of "attach the bug report directly to the code" rather than
have a bug report. Don't know if it will work or not but we may try it.
Stuff like that is potentially useful and part of the reason we think
we're nowhere near done.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
> Our license states that you can't use BK if you are developing a similar
> system, i.e., a clone. Without using BK it's impossible to reverse
> engineer BK to create the clone. So your message seems to be saying
> "it would be appropriate at this point to violate the BitKeeper license
> in order to write a free client which talks with BitKeeper".
> Larry McVoy lm at bitmover.com
My understanding of the relevant case law in the United States is that
these types of restrictions are not allowed under copyright law itself.
They've only been upheld when they're part of a sale contract. You can
certainly argue that a click to an 'I Agree' link constitutes acceptance of
a sale contract. But if someone sits down at a friend's computer that
happens to have BK on it, or finds a copy of BK on a CD someone left at the
lab, you would have a hard time arguing that they agreed to this contract.
See, for example, ProCD v. Zeidenberg:
"Copyright law forbids duplication, public performance, and so on, unless
the person wishing to copy or perform the work gets permission; silence
means a ban on copying. A copyright is a right against the world. Contracts,
by contrast, generally affect only their parties; strangers may do as they
please, so contracts do not create "exclusive rights." Someone who found a
copy of SelectPhone(TM) on the street would not be affected by the
shrinkwrap license - though the federal copyright laws of their own force
would limit the finder's ability to copy or transmit the application
program."
IANAL, and in any event, I don't think any court would look fondly on
someone who deliberately contrived a method to claim they're not subject to
the license.
DS
On Gwe, 2003-07-18 at 21:44, Larry McVoy wrote:
> I'm trying hard to stay out of this, I think Richard may be trolling,
> but I need to make sure that people understand that what Richard is
> suggesting is violation of our license and copyright.
Actually your license is simply irrelevant in most of thre world. You
aren't allowed to forbid reverse engineering for interoperability.
Maybe you're right, but to the point of the conversation, 'taint worth
it to fight it.
The worst thing anyone can do is go off half cocked, make a challenge,
and *poof*, the protocol gateways disappear, because now Larry is
spending his time & $$ with the lawsuit, and takes down the protocol
gateways.
So, in essence, I say pick the battles that are worth fighting, and then
only the battles that are worth winning.
On Fri, 2003-07-18 at 16:08, David Schwartz wrote:
> > Our license states that you can't use BK if you are developing a similar
> > system, i.e., a clone. Without using BK it's impossible to reverse
> > engineer BK to create the clone. So your message seems to be saying
> > "it would be appropriate at this point to violate the BitKeeper license
> > in order to write a free client which talks with BitKeeper".
>
> > Larry McVoy lm at bitmover.com
>
> My understanding of the relevant case law in the United States is that
> these types of restrictions are not allowed under copyright law itself.
> They've only been upheld when they're part of a sale contract. You can
> certainly argue that a click to an 'I Agree' link constitutes acceptance of
> a sale contract. But if someone sits down at a friend's computer that
> happens to have BK on it, or finds a copy of BK on a CD someone left at the
> lab, you would have a hard time arguing that they agreed to this contract.
>
> See, for example, ProCD v. Zeidenberg:
>
> "Copyright law forbids duplication, public performance, and so on, unless
> the person wishing to copy or perform the work gets permission; silence
> means a ban on copying. A copyright is a right against the world. Contracts,
> by contrast, generally affect only their parties; strangers may do as they
> please, so contracts do not create "exclusive rights." Someone who found a
> copy of SelectPhone(TM) on the street would not be affected by the
> shrinkwrap license - though the federal copyright laws of their own force
> would limit the finder's ability to copy or transmit the application
> program."
>
> IANAL, and in any event, I don't think any court would look fondly on
> someone who deliberately contrived a method to claim they're not subject to
> the license.
>
> DS
On Gwe, 2003-07-18 at 21:22, [email protected] wrote:
> How about all of you take a much nicer tilt on this, and ask McVoy (who's
> already giveing you the software free) his price to GPL bitkeeper.
Make Larry a clear business case and I'm sure he will. However even
though I don't agree with Larry on a lot of things I do agree that there
isn't a sane case for him to GPL that software.
Larry actually had exactly these and related discussions before he ever
went to Linus and others with the arrangement he proposed about free if
your logs are public.
If you want to make something replace bitkeeper make it better. When
Larry has customers forcing him to write bk to [whatever] convertors
you've won.
actually I think that your case for ignoring the 'no reverse engineering'
would be far better if you paid for a bitkeeper license, but when you are
being allowed to use it for free on the condition that you use it specific
ways (no reverse engineering and public access to changeset info) saying
that you will eliminate complying with those terms but still get to use it
for free isn't being very reasonable.
David Lang
On 18 Jul 2003, Alan Cox wrote:
> Date: 18 Jul 2003 22:23:30 +0100
> From: Alan Cox <[email protected]>
> To: Larry McVoy <[email protected]>
> Cc: Richard Stallman <[email protected]>,
> Linux Kernel Mailing List <[email protected]>
> Subject: Re: Bitkeeper
>
> On Gwe, 2003-07-18 at 21:44, Larry McVoy wrote:
> > I'm trying hard to stay out of this, I think Richard may be trolling,
> > but I need to make sure that people understand that what Richard is
> > suggesting is violation of our license and copyright.
>
> Actually your license is simply irrelevant in most of thre world. You
> aren't allowed to forbid reverse engineering for interoperability.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
fredag 18. juli 2003, 23:06, skrev J?rn Engel:
> On Fri, 18 July 2003 15:51:36 -0400, Richard Stallman wrote:
> > I think it would be appropriate at this point to write a free client
> > that talks with Bitkeeper, and for Linux developers to start switching
> > to that from Bitkeeper. At that point, McVoy will face a hard choice:
> > if he carries out these threats, he risks alienating the community
> > that he hopes will market Bitkeeper for him.
>
> I've told other people before and I'll tell you again:
> Please, pretty please, leave linux-kernel for discussions about the
> linux kernel and leave the bitkeeper flames for those that enjoy
> electronic pyrotechnic.
>
> Apart from that: Larry is right. Noone cared about crappy ol' cvs
> until bk came alone and showed what everyone already knew. If you
> didn't have to improve cvs back then, it is still as good as it was,
> so thy improve it now? Pure jealousy?
No, I think we'd improve CVS because bk came along and showed us what we
already knew.
Bitkeeper *is* better, but as long as the ideas those improvements are based
on don't get patented there is no reason for us not to claim them for
ourselves.
Summa summarum:
Having a Free CVS is good.
Having a useful BitKeeper is sometimes better.
Having a Free CVS with all the features of BK would be best.
- - Svein Ove Aas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE/GG4H9OlFkai3rMARAkt/AKCdvO7UCiK2AdBKZg0sSoXghmW6vgCfedcB
zKSd79Dwa/ZPwijYMtR3lO0=
=Xuj7
-----END PGP SIGNATURE-----
On Fri, 2003-07-18 at 17:23, Alan Cox wrote:
> Actually your license is simply irrelevant in most of thre world. You
> aren't allowed to forbid reverse engineering for interoperability.
Well, here in the US the right to reverse engineer may be gone. It lost
out in a recent case. Hopefully that isn't telling of the future and
future court cases.
Long live that right everywhere, even if the US sticks its legal head up
a dark, dark tunnel.
Trever
--
"Love is friendship set on fire." -- French Proverb
On Fri, 18 Jul 2003 22:23:30 BST, Alan Cox said:
> Actually your license is simply irrelevant in most of thre world. You
> aren't allowed to forbid reverse engineering for interoperability.
http://marc.theaimsgroup.com/?l=linux-kernel&m=100374609914587&w=2
2.2.20pre11
o Security fixes
| Details censored in accordance with the US DMCA
And there's the resignation letter from ALS from a certain LKML regular, too....
Now what's this about the "simply irrelevant"? Now admittedly the DMCA issues
were on the criminal side of the legal system rather than the civil side, but
the same "You land at the airport and have a chat with the sheriff's deputy"
issue still applies - it's merely a lawsuit rather than an arrest warrant...
On Fri, 2003-07-18 at 17:03, Larry McVoy wrote:
> > McVoy, changing the protocol would be extremely stupid.
>
> There are problems with the current protocol which can't be fixed without
> a protocol rev, problems that many of the kernel developers have asked us
> to fix. Sooner or later we are going to fix them and then there will be
> a protocol rev. It's possible we might do one for legal reasons but I
> doubt it. I was just pointing out to Rory that if he insisted on doing
> something in direct violation of our license it wouldn't do him any good
> in the long run.
>
Ah, sorry. I was meaning the Microsoft kind of switching is stupid.
You have tech reasons, great do them. Mr. McVoy, sorry about my blanket
statement. You obviously weren't just acting the way I thought you
were.
> > McVoy, thank you for helping Linus, Cox, Miller et al scale better. As
>
> My pleasure. At least that part of all of this has worked out pretty
> well. We still think BK is nowhere near good enough, there is a lot left
> to be done. I just spent the day with one of the MySQL founders talking
> about tools for doing reviews, I think those could help. It might be very
> cool, for example, if there was a way to distribute the review process
> and have everyone looking over code, recording notes about possible
> problems, etc. Then Dave could grab an espresso, hit the web site,
> look over the code he cares about, see the reviews, fix it, move on.
> It's sort of "attach the bug report directly to the code" rather than
> have a bug report. Don't know if it will work or not but we may try it.
> Stuff like that is potentially useful and part of the reason we think
> we're nowhere near done.
Now that is a fantastic idea, kind of like cvs meets bugzilla in one
product. I hope you are able to do it.
Anyway, please, everyone either take it private with me, or leave me out
of it. At this point everyone knows how I feel about the issue and why
I do. All of these arguments only seem to reinforce those feelings and
thoughts.
RMS thank you for the good you do. Linus and all, thank you VERY much
for all the good you do. Larry, thank you for your kind response.
Good day to you all.
Trever
--
"In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away." --
RFC1925: The Twelve Networking Truths
On Gwe, 2003-07-18 at 22:54, [email protected] wrote:
> Now what's this about the "simply irrelevant"?
"in most of the world"
If everyone spent the time replacing bitkeeper instead of beating up
Larry they'd get a lot further. I appreciate beating up Larry is more
fun but....
On Fri, Jul 18, 2003 at 02:08:32PM -0700, David Schwartz wrote:
> My understanding of the relevant case law in the United States is that
> these types of restrictions are not allowed under copyright law itself.
On Fri, Jul 18, 2003 at 10:23:30PM +0100, Alan Cox wrote:
> Actually your license is simply irrelevant in most of thre world. You
> aren't allowed to forbid reverse engineering for interoperability.
"Judge, I want to violate this license on this product that I got
for free because it's not free enough".
"Judge, we give it out for free and we also developed technology
to transfer the data out of our product and into a GPLed product,
we do that at our expense and even host the competing GPLed repos
for free and they still want to violate the license"
Who do you think is going to win that one?
Besides, have you considered that it is that license you appear to
dislike so much which provides for the product, the hosting, the free
public machines, the support, all of that? It's a pile of money and
time and I don't see RMS steppng forward with an open checkbook.
The license means we have a revenue stream. We use a significant portion
of that revenue stream to help Linux. If the revenue stream goes away
then so do the services we provide to you for free. They obviously
have value or you wouldn't be using them.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Fri, Jul 18, 2003 at 04:09:42PM -0400, Trever L. Adams wrote:
> McVoy, thank you for helping Linus, Cox, Miller et al scale better. As
One nit.
I don't think Alan is using BK. I could be wrong though.
On 07.19, Svein Ove Aas wrote:
[...]
>
> Summa summarum:
> Having a Free CVS is good.
> Having a useful BitKeeper is sometimes better.
> Having a Free CVS with all the features of BK would be best.
>
Oh, please, stop thinking BitKeeper is the best thing since sliced bread !!!
I have never used BK. I just use CVS as client. I have not looked at SVN.
BK sure surpasses every other SCM tool.
But please, stop thinking about BK clones, BK features, all BK.
As I read in some posts in this thread, people is doing useful work on
a free SCM. Could you all put your efforts on generating a list of
features/requirements you would like for a SCM system specialized for kernel
development, and send them to the developers, instead of arguing about
legal impact of reverse-engineering BK. And let the developers think about
protocols, work flow, ways to do things, and so on. They can find a way
not even similiar to the BK one, and even better...
That way perhaps in one year you could suck data from BK and at least try
a new system...
--
J.A. Magallon <[email protected]> \ Software is like sex:
werewolf.able.es \ It's better when it's free
Mandrake Linux release 9.2 (Cooker) for i586
Linux 2.4.22-pre6-jam1m (gcc 3.3.1 (Mandrake Linux 9.2 3.3.1-0.3mdk))
Trever L. Adams wrote
> Stallman, believe it or not, you used to be someone I looked up to a
> great deal. I still think some of your ideas are great and I would love
> to see the entire world as open source. However, to encourage people to
> do things that are known to antagonize others is crazy. CVS is crap. I
> haven't used Bitkeeper but I have tried a lot of others, and they are
> junk. So, if Bitkeeper is as good as Linus et al think it is, then it
> would be insane to do anything to ruin the relationship they have with
> Bitkeeper. Ideology is great, but it does have to be tempered and meted
> out so that it can be implemented in a way that brings the most good to
> everyone. At this point, ticking off McVoy will likely do the opposite.
>
> McVoy, thank you for helping Linus, Cox, Miller et al scale better. As
> I have said before, I hope there is some way your software can become
> more open, but I will leave that up to you and your team to figure out
> when and how.
You are being far too rational for this discussion.
While I may have my disagreements with Larry at times, I appreciate his
patience in granting BitKeeper to the kernel developers.
RMS is a political idealist -- a good thing, in that such people help
bring about shifts in society. But like all idealists, he's become
trapped his dogma, fixated on finding battles to fight, even in other
people's realms.
--
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing
On Gwe, 2003-07-18 at 23:17, Mike Fedyk wrote:
> On Fri, Jul 18, 2003 at 04:09:42PM -0400, Trever L. Adams wrote:
> > McVoy, thank you for helping Linus, Cox, Miller et al scale better. As
>
> One nit.
>
> I don't think Alan is using BK. I could be wrong though.
I'm not - and with the snapshots neither I or anyone else is forced to.
On Sat, 19 Jul 2003 00:50:46 +0100 (BST)
James Simmons <[email protected]> wrote:
> These threads are getting annoying :-<
I agree. As vger postmaster I think I'll start shitcanning them, but
unfortunately most of these threads startup while I'm sleeping so it's
hard for me to get a regexp in place to block the thread.
So, let me put it this way, if you start a BK flame thread it is _YOU_
who I will blacklist from posting to vger.kernel.org
Alan Cox <[email protected]> writes:
> On Gwe, 2003-07-18 at 23:17, Mike Fedyk wrote:
> > On Fri, Jul 18, 2003 at 04:09:42PM -0400, Trever L. Adams wrote:
> > > McVoy, thank you for helping Linus, Cox, Miller et al scale better. As
> >
> > One nit.
> >
> > I don't think Alan is using BK. I could be wrong though.
>
> I'm not - and with the snapshots neither I or anyone else is forced to.
For the linux kernel. The problem is the satellite projects which
adopt bitkeeper less carefully. Unless there is a general gateway I
have missed.
Eric
Larry McVoy writes:
> Who do you think is going to win that one?
>
> Besides, have you considered that it is that license you appear to
> dislike so much which provides for the product, the hosting, the free
> public machines, the support, all of that? It's a pile of money and
> time and I don't see RMS steppng forward with an open checkbook.
>
> The license means we have a revenue stream. We use a significant portion
> of that revenue stream to help Linux. If the revenue stream goes away
> then so do the services we provide to you for free. They obviously
> have value or you wouldn't be using them.
> --
> ---
Oh come on, you use Linux for testing and improving your software and
spin it in such a way that you do something charitable. From all your
mailings on this list I don't get the impression that you would do
anything that is not to improve your profit. I bet you can tax deduct
all that money you allegedly spend on linux and thereby increase your profit.
Anyway, this is no subject for the kernel list. Let those who want to
support Larry use bitkeeper and those who rather use free software use
something else.
Marcus
--
/--------------------------------------------------------------------\
| Dr. Marcus O.C. Metzler | |
|--------------------------------|-----------------------------------|
| [email protected] | http://www.metzlerbros.de/ |
\--------------------------------------------------------------------/
> If everyone spent the time replacing bitkeeper instead of beating up
> Larry they'd get a lot further.
Linux isn't the only free operating system in existance, and although
BK seems to suit the requirements of a lot of Linux developers, that
doesn't mean that it meets the requirements of other free OS
development teams.
I strongly suspect that we'll see a free SCM developed after a few
more years of HURD development, for example.
Doesn't mean we'll switch to it, though, we haven't switched to my bug
database, have we? :-).
John.
>> If everyone spent the time replacing bitkeeper instead of beating up
>> Larry they'd get a lot further.
> Linux isn't the only free operating system in existance, and although BK
> seems to suit the requirements of a lot of Linux developers, that
> doesn't mean that it meets the requirements of other free OS
> development teams.
> I strongly suspect that we'll see a free SCM developed after a few more
> years of HURD development, for example.
> Doesn't mean we'll switch to it, though, we haven't switched to my bug
> database, have we? :-).
> John.
Given that large chunks of HURD come from Linux, please refer to it as
Linux/HURD.
-----------------------------------------
This email was sent using SquirrelMail.
"Webmail for nuts!"
http://squirrelmail.org/
> >> If everyone spent the time replacing bitkeeper instead of beating up
> >> Larry they'd get a lot further.
> > Linux isn't the only free operating system in existance, and although BK
> > seems to suit the requirements of a lot of Linux developers, that
> > doesn't mean that it meets the requirements of other free OS
> > development teams.
> > I strongly suspect that we'll see a free SCM developed after a few more
> > years of HURD development, for example.
> > Doesn't mean we'll switch to it, though, we haven't switched to my bug
> > database, have we? :-).
> > John.
>
> Given that large chunks of HURD come from Linux, please refer to it as
> Linux/HURD.
What HURD code comes from Linux? GNU/Mach uses code from Linux, but
not HURD as far as I know.
John.
On Sat, 2003-07-19 at 17:03, John Bradford wrote:
> > Given that large chunks of HURD come from Linux, please refer to it as
> > Linux/HURD.
>
> What HURD code comes from Linux? GNU/Mach uses code from Linux, but
> not HURD as far as I know.
Neither to my knowledge -
GNU/HURD uses GNU/MACH as the microkernel (and GNU/MACH uses Linux 2.0
drivers), but they are actually thinking of switching to another MACH
implementation once it's stable.
Cheers,
Chris
David S. Miller wrote:
> So, let me put it this way, if you start a BK flame thread it is _YOU_
> who I will blacklist from posting to vger.kernel.org
No more horribly-offtopic RMS trolls? :)
Jeff
On Sat, Jul 19, 2003 at 04:03:55PM +0100, John Bradford wrote:
> What HURD code comes from Linux? GNU/Mach uses code from Linux, but
> not HURD as far as I know.
the networking code at least (aka pfinet)
>> >> If everyone spent the time replacing bitkeeper instead of beating
>> up Larry they'd get a lot further.
>> > Linux isn't the only free operating system in existance, and
>> although BK seems to suit the requirements of a lot of Linux
>> developers, that doesn't mean that it meets the requirements of
>> other free OS
>> > development teams.
>> > I strongly suspect that we'll see a free SCM developed after a few
>> more years of HURD development, for example.
>> > Doesn't mean we'll switch to it, though, we haven't switched to my
>> bug database, have we? :-).
>> > John.
>>
>> Given that large chunks of HURD come from Linux, please refer to it as
>> Linux/HURD.
>
> What HURD code comes from Linux? GNU/Mach uses code from Linux, but not
> HURD as far as I know.
>
Hi John!
Go take a look at their networking, and IDE code.
-----------------------------------------
This email was sent using SquirrelMail.
"Webmail for nuts!"
http://squirrelmail.org/
On Sat, Jul 19, 2003 at 02:20:31AM -0600, Eric W. Biederman wrote:
> Alan Cox <[email protected]> writes:
> > > I don't think Alan is using BK. I could be wrong though.
> > I'm not - and with the snapshots neither I or anyone else is forced to.
> For the linux kernel. The problem is the satellite projects which
> adopt bitkeeper less carefully. Unless there is a general gateway I
> have missed.
They do not provide snapshots?
As long as tar files are distributed for each minor release, there is no
true 'lock in'. If you need a gateway for a specific satellite project,
there are people that could probably hook you up with the software required,
and if there are other people in your situation, one of them probably has
enough CPU + network + disk resources to host it.
The Bit Keeper issue is entirely a philosophical one. I understand
that Linus chooses to use it, because it allows him to be more
efficient. Alan Cox chooses not to use it (I'm not clear on his
reasons, but I assume they are just as good). What more proof do we
need that Bit Keeper is not locking people in?
I don't use it, and have never used it at this point, primarily
because I happen to be in the source management field currently, and I
have chosen to respect Larry's license. I'm certain that if I ever had
a proper need in terms of kernel development, the license could be
waived or altered on a case-by-case basis.
Stallman puts himself 100% in the philosopher's chair. He seems to believe
that any variation or compromise weakens his overall position. Every few
months he starts a flame war just to satisfy his own guilt that rises from
him feeling that he isn't doing enough to 'promote' free projects, even if
the free projects don't exist yet, or are not as feature-full.
A few of us have a real love-hate relationship with Stallman. We love what he
has accomplished. We hate how he accomplishes his goals.
The bottom line of all of this, is that Stallman is preaching to the wrong
people. He should stick to press releases and such. Kernel developers just
want to get work done. Any investment into writing a new source management
system would be better served by improving the linux source code. If this
wasn't so, the kernel developers wouldn't be kernel developers. They would
be like me... source management developers... :-)
mark
--
[email protected]/[email protected]/[email protected] __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/
> Any investment into writing a new source management
> system would be better served by improving the linux source code.
What happens if somebody develops a really good versioned filesystem
for Linux, would it not get merged, because the linux kernel would
then contain SCM-like functionality?
John.
On Sat, Jul 19, 2003 at 05:00:24PM +0100, John Bradford wrote:
> > Any investment into writing a new source management
> > system would be better served by improving the linux source code.
> What happens if somebody develops a really good versioned filesystem
> for Linux, would it not get merged, because the linux kernel would
> then contain SCM-like functionality?
One day, when it happens, we'll see what ripple effects it has.
In most cases, however, I suspect that a versioned file system will never
be a replacement for a good source management system. The lines could become
blurred, but the 'good versioned file system' might take the form a kernel
module that allowed SCM systems to plug into it, at which point, Bit Keeper
might plug into it, and everybody would be happy. I doubt you want to put
merge manager functionality into the kernel, or many of the other components
of a good source management system. The storage and access is one of the
lesser concerns. Bit Keeper uses similar storage and access methods as
SCCS, does it not?
mark
--
[email protected]/[email protected]/[email protected] __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/
Hello Christian!
19 Jul 2003 17:02:41 +0200, you wrote:
> On Sat, 2003-07-19 at 17:03, John Bradford wrote:
>> > Given that large chunks of HURD come from Linux, please refer to it as
>> > Linux/HURD.
>>
>> What HURD code comes from Linux? GNU/Mach uses code from Linux, but
>> not HURD as far as I know.
> Neither to my knowledge -
> GNU/HURD uses GNU/MACH as the microkernel (and GNU/MACH uses Linux 2.0
> drivers), but they are actually thinking of switching to another MACH
> implementation once it's stable.
To be more exact:
- GNU/Hurd, the whole systems, is actually GNU tools (libc, linker,
...) on top of the GNU Hurd (set of servers) and the GNU Mach
microkernel.
- GNU Mach 1.x uses drivers from Linux 2.0.36 (IIRC)
- GNU Mach 2.0 (actually 1.9, as a beta version), uses the OSKit
framework, and such drivers from Linux 2.2.12 (but nearly any driver
for Linux 2.2 can be easily ported) or FreeBSD (I don't remember
which version, we actually use more Linux drivers).
- In the future, we'll probably use the L4 microkernel. On top of L4,
we'll have to implement user space drivers. That'ld probably take
time, so we may reuse Linux drivers with glue code as a temporary
solution.
- pfinet (our TCP/IP server) comes from Linux 2.0 IP stack, but we
need a rewrite for that (first because Linux 2.0 stack's is not the
best in the world ;) and then because kernel-space code runned in
user-space with glue code isn't either fast nor flexible).
I'm not aware of other use of Linux code inside the Hurd project, or
even inside the GNU project, but there may be.
--
Gael Le Mignot "Kilobug" - [email protected] - http://kilobug.free.fr
GSM : 06.71.47.18.22 (in France) ICQ UIN : 7299959
Fingerprint : 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA
Member of HurdFr: http://hurdfr.org - The GNU Hurd: http://hurd.gnu.org
> - GNU/Hurd, the whole systems, is actually GNU tools (libc, linker,
> ...) on top of the GNU Hurd (set of servers) and the GNU Mach
> microkernel.
Mach wasn't written by GNU, it's a BSD based kernel pried apart into chunks
by people at CMU.
> - GNU Mach 1.x uses drivers from Linux 2.0.36 (IIRC)
>
> - GNU Mach 2.0 (actually 1.9, as a beta version), uses the OSKit
> framework, and such drivers from Linux 2.2.12
>
> - pfinet (our TCP/IP server) comes from Linux 2.0 IP stack
>
> I'm not aware of other use of Linux code inside the Hurd project, or
> even inside the GNU project, but there may be.
Drivers and networking account for about 50% of the total lines of code.
The bulk of the work in any operating system is typically drivers. The
generic part of Linux (non-driver, non-file system) is tiny compared to
the rest.
If the Hurd gets its drivers from Linux then it should rightfully be called
Linux/HURD (or Linux/HURD/GNU).
work /tmp/linux-2.5$ bk -rnet cat | wc -l
326411
work /tmp/linux-2.5$ bk -rdrivers cat | wc -l
2605850
work /tmp/linux-2.5$ bk -r cat | wc -l
6618524
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Hello Larry!
Sat, 19 Jul 2003 10:23:11 -0700, you wrote:
>> - GNU/Hurd, the whole systems, is actually GNU tools (libc, linker,
>> ...) on top of the GNU Hurd (set of servers) and the GNU Mach
>> microkernel.
> Mach wasn't written by GNU, it's a BSD based kernel
Totally wrong. You're confusing the Mach operating system (with UX, a
BSD-server on top of the Mach micro-kernel) and the Mach micro-kernel
itself.
> pried apart into chunks by people at CMU.
GNU Mach is a modified version of OSF Mach which is modified version
of CMU Mach.
> Drivers and networking account for about 50% of the total lines of code.
> The bulk of the work in any operating system is typically drivers. The
> generic part of Linux (non-driver, non-file system) is tiny compared to
> the rest.
Maybe for you, an OS is drivers. For me, it's a design, an
architecture, a philosophy, and a way to defend a value that is not
important for you: Freedom.
> If the Hurd gets its drivers from Linux then it should rightfully be called
> Linux/HURD (or Linux/HURD/GNU).
Stop trolling, thank you.
--
Gael Le Mignot "Kilobug" - [email protected] - http://kilobug.free.fr
GSM : 06.71.47.18.22 (in France) ICQ UIN : 7299959
Fingerprint : 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA
Member of HurdFr: http://hurdfr.org - The GNU Hurd: http://hurd.gnu.org
On Sat, Jul 19, 2003 at 07:46:54PM +0200, Ga?l Le Mignot wrote:
> Hello Larry!
>
> Sat, 19 Jul 2003 10:23:11 -0700, you wrote:
>
> >> - GNU/Hurd, the whole systems, is actually GNU tools (libc, linker,
> >> ...) on top of the GNU Hurd (set of servers) and the GNU Mach
> >> microkernel.
>
> > Mach wasn't written by GNU, it's a BSD based kernel
>
> Totally wrong. You're confusing the Mach operating system (with UX, a
> BSD-server on top of the Mach micro-kernel) and the Mach micro-kernel
> itself.
The microkernel part of any reasonable microkernel is tiny. The QNX
microkernel used to fit in a 4K instruction cache. To say that the
microkernel is the operating system is ludicrous, that's like say
this series of 5 instructions which happen to get run a lot are the
whole program.
Without the BSD part, you had no operating system, no devices, no nothing.
What you had was a mechanism which can context switch, something that
every first year OS student has written (or should have).
I stand behind the statement and I've read all the Mach papers, all
the Mach code, and lectured on it at little places like Stanford
University. I'm pretty sure I know what I'm talking about.
> > pried apart into chunks by people at CMU.
>
> GNU Mach is a modified version of OSF Mach which is modified version
> of CMU Mach.
Whatever. That's your label. Personally, I despise this business of
taking someone else's code and renaming it. It's not GNU code, the
GNU people didn't write it.
> > Drivers and networking account for about 50% of the total lines of code.
> > The bulk of the work in any operating system is typically drivers. The
> > generic part of Linux (non-driver, non-file system) is tiny compared to
> > the rest.
>
> Maybe for you, an OS is drivers. For me, it's a design, an
> architecture, a philosophy, and a way to defend a value that is not
> important for you: Freedom.
I've got a shelf of OS texts, probably close to 90% of all the OS texts
written and I don't recall any of them teaching that you should take other
people's code, rename it, and claim it as your own in the name of freedom.
> > If the Hurd gets its drivers from Linux then it should rightfully be called
> > Linux/HURD (or Linux/HURD/GNU).
>
> Stop trolling, thank you.
Hey, you want to spout nonsense then be prepared to be challenged. I'm
just responding to something that is obviously incorrect, that's not
trolling, that's setting the record straight. I think it was Dave Miller
who told me the other night that an unchallenged incorrect statement
becomes true by default and I agree.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Fri, 2003-07-18 15:32:06 -0500, Shawn <[email protected]>
wrote in message <1058560325.2662.31.camel@localhost>:
> To add to this, why?
>
> I don't mean to jump on anyone, but so long as someone can pull all the
> BK data out if Larry gets unreasonable (via the active and existing SVN
> or CVS gateways) who the frig cares if there's a BK clone??? If things
> got nasty, pull the data and switch unceremoniously switch to SVN or
> whatever.
Have you ever used eg. cvsps with the BK->CVS gateway? I tried this and
failed because of 4 issues:
- I couldn't get the initial import patchset (2)
- I couldn't get two other patchsets
- One patchset added a file which already existed (11504)
Trying cvsps with the BKCVS gateway, you won't be able to automagically
import all these patchsets into some other SCM. I got the BKCVS->SVN
script and I'm still looking at it. Other than that, I'm to have a deep
look at cvsps if there's some hidden bug which lets it fail on mentioned
four patchsets...
However, I want to thank Larry for the BC->CVS gateway. Eventually, some
customers could make some use out of it, but it definitively tells us
that Larry is willing to do more than giving BK away (in most cases for
free (as in beer)) - he's investing in it as well as tryin' to keep us
using it (for what he offers some small presents from time to time such
as hosting service and BK->CVS).
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg
fuer einen Freien Staat voll Freier B?rger" | im Internet! | im Irak!
ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));
On Sat, Jul 19, 2003 at 07:41:23PM +0100, Christoph Hellwig wrote:
> On Sat, Jul 19, 2003 at 11:12:49AM -0700, Larry McVoy wrote:
> > The microkernel part of any reasonable microkernel is tiny.
>
> And who says Mach is a reasonable microkernel :)
Yup, more like a maxikernel :)
That was my reaction on reading the code years ago and it hasn't changed.
I used to know one of the main guys who did the QNX microkernel (Dan
Hildebrandt, RIP 1998) and he talked about how a real microkernel was
never touched by more than 3 people and each of them spent as much
time removing stuff as adding it.
Mach is kinda on the bloated side, I always questioned the wisdom of
the GNU HURD being based on Mach, seemed like a bad call. But then,
unless you have an extremely well controlled dev team, any micro kernel
is a bad call, it's going to bloat out.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Sat, Jul 19, 2003 at 11:12:49AM -0700, Larry McVoy wrote:
> The microkernel part of any reasonable microkernel is tiny.
And who says Mach is a reasonable microkernel :)
On Sat, Jul 19, 2003 at 08:42:46PM +0200, Jan-Benedict Glaw wrote:
> Have you ever used eg. cvsps with the BK->CVS gateway? I tried this and
> failed because of 4 issues:
>
> - I couldn't get the initial import patchset (2)
> - I couldn't get two other patchsets
> - One patchset added a file which already existed (11504)
Work with Ben Collins on that. I don't know what cvsps is so I can't
help you there. If you can figure out what is wrong with the tree and
explain what we should do to fix it, we'll give it a tree.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Sat, 2003-07-19 11:49:44 -0700, Larry McVoy <[email protected]>
wrote in message <[email protected]>:
> On Sat, Jul 19, 2003 at 08:42:46PM +0200, Jan-Benedict Glaw wrote:
> > Have you ever used eg. cvsps with the BK->CVS gateway? I tried this and
> > failed because of 4 issues:
> >
> > - I couldn't get the initial import patchset (2)
> > - I couldn't get two other patchsets
> > - One patchset added a file which already existed (11504)
>
> Work with Ben Collins on that. I don't know what cvsps is so I can't
> help you there. If you can figure out what is wrong with the tree and
> explain what we should do to fix it, we'll give it a tree.
Thanks fot hint'n'offer!
Basically, cvsps sucks off the rlog messages and compares any check-in
texts / times of any files to find out what has been checked-in with a
single check-in. That is then called a patchset (cvs_ps_). With some
command line arguments, it'll then output the check-in text as well as a
unified diff.
This information can then be used to feed it to other SCMs or for simple
review tasks. While doing consistency checks, I discivered the mentioned
inconsistency (at patchset 11504 IIRC) as well as some minor glitches (I
had one patchset where the check-in comment changed after I re-fetched
the patchset some days later...).
However, I'm working at spare time on it, so it'll take some time:(
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg
fuer einen Freien Staat voll Freier B?rger" | im Internet! | im Irak!
ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));
> Basically, cvsps sucks off the rlog messages and compares any check-in
Hmm. I would guess that makes rlog very happy. And sleepy :)
> texts / times of any files to find out what has been checked-in with a
> single check-in. That is then called a patchset (cvs_ps_). With some
> command line arguments, it'll then output the check-in text as well as a
> unified diff.
We're looking at getting some seperate bandwidth for bkbits.net and
turning on the patch feature of BK/Web. Then you'll be able to do a
wget http://linux.bkbits.net/linux-2.5/[email protected]
and get something like the following. I suspect this is better than
cvsps and it will work for all repositories on bkbits.net, not just
the mainline one. Is that good enough for what you want? The format
below repeats for each file in the changeset.
===== man/man1/bk-config-etc.1 1.23.1.1 vs 1.26 =====
02/05/16 13:44:09 [email protected] 1.24 +16 -0
Document 'trust_window' parameter
02/10/03 11:24:15 [email protected] 1.23.1.2 +9 -0
Docuement the BK_CONFIG environmental variable
--- 1.23.1.1/man/man1/bk-config-etc.1 Tue Sep 17 12:33:59 2002
+++ 1.26/man/man1/bk-config-etc.1 Thu Oct 3 09:24:49 2002
@@ -30,6 +30,15 @@
(/etc/BitKeeper/etc/config) then that setting will override any
matching key in local config files.
.LP
+Also configuration entries can be overridden with the
+.B BK_CONFIG
+environmental variable. That variable can contain a list of key:value
+pairs seperated by semicolons. For example:
+.DS
+.BR BK_CONFIG =\c
+.IR key1 : value2 ; key2 : value2 ; key3 : value3\c
+.DE
+.LP
Minimum content requirements for the BitKeeper/etc/config file
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Sat, 19 Jul 2003, Ga?l Le Mignot wrote:
> Maybe for you, an OS is drivers. For me, it's a design, an
> architecture, a philosophy, and a way to defend a value that is not
> important for you: Freedom.
Intriguing, quasi-religious/political OS blabbering of sorts..
> Stop trolling, thank you.
Pot .. kettle .. black. Please take this to the Hurd mailing lists,
perhaps it could spruce up the activity a bit.
--
function.linuxpower.ca
On Sat, 2003-07-19 12:05:31 -0700, Larry McVoy <[email protected]>
wrote in message <[email protected]>:
> > Basically, cvsps sucks off the rlog messages and compares any check-in
>
> Hmm. I would guess that makes rlog very happy. And sleepy :)
Well, it's not exactly fast and it takes quite some CPU cycles on my
side. However, that's a spare box (HP-PARISC B132L+, 132 MHz) which
doesn't have to do anything else:)
>
> wget http://linux.bkbits.net/linux-2.5/[email protected]
>
> and get something like the following. I suspect this is better than
> cvsps and it will work for all repositories on bkbits.net, not just
> the mainline one. Is that good enough for what you want? The format
> below repeats for each file in the changeset.
That's quite good:) Are file renames also represented as patches (ie.
one file gets removed, another one is added)?
To draw the line, that's exactly what one could wish. It someone isn't
happy with the format, it seems to be easily Perl'ed/sed'ed/...
I've not yet looked at any other trees than the linux-2.5^H6 tree, but
I'm currently spending some time to work on merging some trees to one
(read: I want to merge all the non-i386 linux ports) and that involves
quite some scripting / SCMing and up to now, I've not found the
Super-SCM to achieve that:) Tasks are to get all ports to current 2.6.x,
distribute their patches among them and pushing it (separated in small
pieces) to Linus at some far future...
If I could get perfect patches like that out of bkbits.net (at least for
the projects hosted there), that could potentially ease the task a lot:)
MfG, JBG
PS: http://lug-owl.de/~jbglaw/linux-ports/
PPS: I'm missing quite a lot of informations there - if you're a port
maintainer, please get in contact with me:)
--
Jan-Benedict Glaw [email protected] . +49-172-7608481
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg
fuer einen Freien Staat voll Freier B?rger" | im Internet! | im Irak!
ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));
> Mach is kinda on the bloated side, I always questioned the wisdom of
> the GNU HURD being based on Mach, seemed like a bad call. But then,
> unless you have an extremely well controlled dev team, any micro kernel
> is a bad call, it's going to bloat out.
If you were documenting yourself a bit instead of trolling, you'll
notice that's the GNU Hurd is not based on Mach. The GNU Hurd tries to
be micro-kernel independant, and will be ported to other microkernels,
like L4 Version 4.
And if you look a bit in the history, you'll notice that second
generation micro-kernels (like L4) were not available, or even
designed, at the time Mach was chosen as the first microkernel to make
the Hurd runs on.
--
Gael Le Mignot "Kilobug" - [email protected] - http://kilobug.free.fr
GSM : 06.71.47.18.22 (in France) ICQ UIN : 7299959
Fingerprint : 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA
Member of HurdFr: http://hurdfr.org - The GNU Hurd: http://hurd.gnu.org
> On Sat, Jul 19, 2003 at 07:46:54PM +0200, Ga?l Le Mignot wrote:
>> Hello Larry!
>>
>> Sat, 19 Jul 2003 10:23:11 -0700, you wrote:
>>
>> >> - GNU/Hurd, the whole systems, is actually GNU tools (libc, linker,
>> >> ...) on top of the GNU Hurd (set of servers) and the GNU Mach
>> >> microkernel.
>>
>> > Mach wasn't written by GNU, it's a BSD based kernel
>>
>> Totally wrong. You're confusing the Mach operating system (with UX, a
>> BSD-server on top of the Mach micro-kernel) and the Mach micro-kernel
>> itself.
> The microkernel part of any reasonable microkernel is tiny. The QNX
> microkernel used to fit in a 4K instruction cache. To say that the
> microkernel is the operating system is ludicrous, that's like say
> this series of 5 instructions which happen to get run a lot are the
> whole program.
You completly missed the point.
The part use by the GNU Hurd is only the Mach microkernel, not the
Mach operating system in a whole.
>> > pried apart into chunks by people at CMU.
>>
>> GNU Mach is a modified version of OSF Mach which is modified version
>> of CMU Mach.
> Whatever. That's your label. Personally, I despise this business of
> taking someone else's code and renaming it. It's not GNU code, the
> GNU people didn't write it.
We did it with the agreement of the original authors, and then we
changed it. Should we call our modified version with the same name
than the original one ? That would be bad, indeed !
>> Maybe for you, an OS is drivers. For me, it's a design, an
>> architecture, a philosophy, and a way to defend a value that is not
>> important for you: Freedom.
> I've got a shelf of OS texts, probably close to 90% of all the OS texts
> written and I don't recall any of them teaching that you should take other
> people's code, rename it, and claim it as your own in the name of freedom.
Stop lying. No one at the GNU project ever claimed a code to be his if
he didn't write it. Just look in any header file, and you'll se the
copyright entries intact. And we always say everywhere that GNU Mach
is a fork of OSF Mach.
>> > If the Hurd gets its drivers from Linux then it should rightfully be called
>> > Linux/HURD (or Linux/HURD/GNU).
>>
>> Stop trolling, thank you.
> Hey, you want to spout nonsense then be prepared to be challenged. I'm
> just responding to something that is obviously incorrect, that's not
> trolling, that's setting the record straight.
You're just writing a lot of incorrect statements, insulting people
(yes, you're calling the GNU project "thieves"), and not correcting
anything, since you just answer completly outside the subject.
--
Gael Le Mignot "Kilobug" - [email protected] - http://kilobug.free.fr
GSM : 06.71.47.18.22 (in France) ICQ UIN : 7299959
Fingerprint : 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA
Member of HurdFr: http://hurdfr.org - The GNU Hurd: http://hurd.gnu.org
On Sat, 19 Jul 2003 22:05:12 +0200, =?iso-8859-1?q?Ga=EBl_Le_Mignot?= said:
> Stop lying. No one at the GNU project ever claimed a code to be his if
> he didn't write it.
Oh. *NOW* I see. You don't actually *CLAIM* it's your code, you just
rename it in a misleading manner to create the impression.
"Yes, we asked the author to rename it GNU/Wombat, even though the GNU
project didn't actually do anything other than GNU/Rename it and then GNU/Borg it..."
I think you need to call the guys in Redmond, and ask if they could please
use the name 'GNU/Innovation"....
(And yes, I *used* to have a lot of respect for the GNU crew....)
Hello Mark All , (I hate continuing this thread But) A thought
just (re-)occured to me that for those people who -really- need
it . What about an SCM file system ? Thoughts , anger ,
complancency ? Twys , JimL
On Sat, 19 Jul 2003, Mark Mielke wrote:
> On Sat, Jul 19, 2003 at 05:00:24PM +0100, John Bradford wrote:
> > > Any investment into writing a new source management
> > > system would be better served by improving the linux source code.
> > What happens if somebody develops a really good versioned filesystem
> > for Linux, would it not get merged, because the linux kernel would
> > then contain SCM-like functionality?
> One day, when it happens, we'll see what ripple effects it has.
> In most cases, however, I suspect that a versioned file system will never
> be a replacement for a good source management system. The lines could become
> blurred, but the 'good versioned file system' might take the form a kernel
> module that allowed SCM systems to plug into it, at which point, Bit Keeper
> might plug into it, and everybody would be happy. I doubt you want to put
> merge manager functionality into the kernel, or many of the other components
> of a good source management system. The storage and access is one of the
> lesser concerns. Bit Keeper uses similar storage and access methods as
> SCCS, does it not?
--
+------------------------------------------------------------------+
| James W. Laferriere | System Techniques | Give me VMS |
| Network Engineer | P.O. Box 854 | Give me Linux |
| [email protected] | Coudersport PA 16915 | only on AXP |
+------------------------------------------------------------------+
On Fri, Jul 18, 2003 at 03:27:02PM -0700, Larry McVoy wrote:
> On Fri, Jul 18, 2003 at 02:08:32PM -0700, David Schwartz wrote:
> > My understanding of the relevant case law in the United States is that
> > these types of restrictions are not allowed under copyright law itself.
>
> On Fri, Jul 18, 2003 at 10:23:30PM +0100, Alan Cox wrote:
> > Actually your license is simply irrelevant in most of thre world. You
> > aren't allowed to forbid reverse engineering for interoperability.
>
> "Judge, I want to violate this license on this product that I got
> for free because it's not free enough".
>
> "Judge, we give it out for free and we also developed technology
> to transfer the data out of our product and into a GPLed product,
> we do that at our expense and even host the competing GPLed repos
> for free and they still want to violate the license"
>
> Who do you think is going to win that one?
>...
"Judge, our current German copyright law explicitely states that such a
clause is void."
> Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Sat, Jul 19, 2003 at 10:42:19PM +0200, Adrian Bunk wrote:
> On Fri, Jul 18, 2003 at 03:27:02PM -0700, Larry McVoy wrote:
> > On Fri, Jul 18, 2003 at 02:08:32PM -0700, David Schwartz wrote:
> > > My understanding of the relevant case law in the United States is that
> > > these types of restrictions are not allowed under copyright law itself.
> >
> > On Fri, Jul 18, 2003 at 10:23:30PM +0100, Alan Cox wrote:
> > > Actually your license is simply irrelevant in most of thre world. You
> > > aren't allowed to forbid reverse engineering for interoperability.
> >
> > "Judge, I want to violate this license on this product that I got
> > for free because it's not free enough".
> >
> > "Judge, we give it out for free and we also developed technology
> > to transfer the data out of our product and into a GPLed product,
> > we do that at our expense and even host the competing GPLed repos
> > for free and they still want to violate the license"
> >
> > Who do you think is going to win that one?
> >...
>
> "Judge, our current German copyright law explicitely states that such a
> clause is void."
No, it isn't. Your case law is based on a *purchase* or *lease* of a
product for *money*. If you paid us money, you'd have a point. But
you didn't. You get to use the product for free and until there is
some case law which says otherwise, we get to make any rules we like.
And our rules say you can't reverse engineer. Too bad for you if you
don't like it, I'm not exactly overflowing with sympathy for someone
who paid nothing and is now complaining that they aren't allowed to
reverse engineer and steal what they didn't pay for.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
> Stop lying. No one at the GNU project ever claimed a code to be his if
> he didn't write it.
Nonsense. Go look at the set of code actually funded by the FSF and it
is tiny. The FSF tries to get everyone to sign over their copyright to
the FSF so they can "protect" the code and then they rename it to GNU
this that or the other thing. Start reading those copyrights you are
talking about, of the set of things described as GNU something, I would
guess than less than 1% of it was paid for by the FSF. The rest of it
is all stuff they slapped their name on after convincing people to sign
over copyrights.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Sad, 2003-07-19 at 23:03, Larry McVoy wrote:
> guess than less than 1% of it was paid for by the FSF. The rest of it
> is all stuff they slapped their name on after convincing people to sign
> over copyrights.
The Master doesn't talk, he acts.
When his work is done,
the people say, "Amazing:
we did it, all by ourselves!" -- Lao-tzu
Linus great achievement was making Linux happen, not writing it. The FSF
likewise.
On Sat, Jul 19, 2003 at 02:57:40PM -0700, Larry McVoy wrote:
> On Sat, Jul 19, 2003 at 10:42:19PM +0200, Adrian Bunk wrote:
> > On Fri, Jul 18, 2003 at 03:27:02PM -0700, Larry McVoy wrote:
> > > On Fri, Jul 18, 2003 at 02:08:32PM -0700, David Schwartz wrote:
> > > > My understanding of the relevant case law in the United States is that
> > > > these types of restrictions are not allowed under copyright law itself.
> > >
> > > On Fri, Jul 18, 2003 at 10:23:30PM +0100, Alan Cox wrote:
> > > > Actually your license is simply irrelevant in most of thre world. You
> > > > aren't allowed to forbid reverse engineering for interoperability.
> > >
> > > "Judge, I want to violate this license on this product that I got
> > > for free because it's not free enough".
> > >
> > > "Judge, we give it out for free and we also developed technology
> > > to transfer the data out of our product and into a GPLed product,
> > > we do that at our expense and even host the competing GPLed repos
> > > for free and they still want to violate the license"
> > >
> > > Who do you think is going to win that one?
> > >...
> >
> > "Judge, our current German copyright law explicitely states that such a
> > clause is void."
>
> No, it isn't. Your case law is based on a *purchase* or *lease* of a
There is no case law in Germany. Case law is somethig that is only used
in England and the USA.
In Germany there are laws for _everything_. Rules like who owns the
swarm of bees when several swarms of bees unite aren't made at court,
they are explicitely written in laws.
German judges don't read 200 years old judicial decisions, they read
written laws.
Please ask a lawyer about the differences between the English/US and the
continental Europe law system if you don't believe me.
> product for *money*. If you paid us money, you'd have a point. But
> you didn't. You get to use the product for free and until there is
> some case law which says otherwise, we get to make any rules we like.
> And our rules say you can't reverse engineer. Too bad for you if you
> don't like it, I'm not exactly overflowing with sympathy for someone
> who paid nothing and is now complaining that they aren't allowed to
> reverse engineer and steal what they didn't pay for.
The current German copyright law doesn't talk about money. If you allow
someone to use a copy the law explicitely states that some kind of
contract clauses (e.g. a complete prohibition of disassembling) are
simply void.
> Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Hi,
On Sat, 19 Jul 2003, Larry McVoy wrote:
> > Stop lying. No one at the GNU project ever claimed a code to be his if
> > he didn't write it.
>
> Nonsense. Go look at the set of code actually funded by the FSF and it
> is tiny. The FSF tries to get everyone to sign over their copyright to
> the FSF so they can "protect" the code and then they rename it to GNU
> this that or the other thing.
Larry, you've proven enough now, that you don't understand the concept of
free software. You can stop now. Thanks.
bye, Roman
On Sat, Jul 19, 2003 at 07:46:54PM +0200, Ga?l Le Mignot wrote:
> > Drivers and networking account for about 50% of the total lines of code.
> > The bulk of the work in any operating system is typically drivers. The
> > generic part of Linux (non-driver, non-file system) is tiny compared to
> > the rest.
>
> Maybe for you, an OS is drivers. For me, it's a design, an
> architecture, a philosophy, and a way to defend a value that is not
> important for you: Freedom.
Heh, let's see how well your OS works in the real world without those
drivers :)
greg k-h
On Sun, Jul 20, 2003 at 12:28:38AM +0200, Adrian Bunk wrote:
> > product for *money*. If you paid us money, you'd have a point. But
> > you didn't. You get to use the product for free and until there is
> > some case law which says otherwise, we get to make any rules we like.
> > And our rules say you can't reverse engineer. Too bad for you if you
> > don't like it, I'm not exactly overflowing with sympathy for someone
> > who paid nothing and is now complaining that they aren't allowed to
> > reverse engineer and steal what they didn't pay for.
>
> The current German copyright law doesn't talk about money. If you allow
> someone to use a copy the law explicitely states that some kind of
> contract clauses (e.g. a complete prohibition of disassembling) are
> simply void.
Alan pointed out to me that the EU rules are for interoperability and they
do not allow reverse engineering for the purposes of learning how a product
works.
Since BK can export any and *all* data and metadata from a one line command,
it's awfully hard to make the argument that you are reverse engineering
for interoperability. You can get your data as flat files, diffs, unified
diffs, context diffs. You can get your checkin comments in any format you
want. It's trivial to get data in and out of BK.
You can even get all of that from a web server so you don't have to sully
your hands with evil BK software.
So where is the law that says it is OK to reverse engineer when the product
already provides everything you could possibly want for interoperability?
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Hi!
> > How about all of you take a much nicer tilt on this, and ask McVoy (who's
> > already giveing you the software free) his price to GPL bitkeeper.
>
> Make Larry a clear business case and I'm sure he will. However even
> though I don't agree with Larry on a lot of things I do agree that there
> isn't a sane case for him to GPL that software.
>
> Larry actually had exactly these and related discussions before he ever
> went to Linus and others with the arrangement he proposed about free if
> your logs are public.
>
> If you want to make something replace bitkeeper make it better. When
> Larry has customers forcing him to write bk to [whatever] convertors
> you've won.
Well, we already made him write bk to CVS convertor ;-))))))))).
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
On Sat, Jul 19, 2003 at 03:39:56PM -0700, Larry McVoy wrote:
> On Sun, Jul 20, 2003 at 12:28:38AM +0200, Adrian Bunk wrote:
> > > product for *money*. If you paid us money, you'd have a point. But
> > > you didn't. You get to use the product for free and until there is
> > > some case law which says otherwise, we get to make any rules we like.
> > > And our rules say you can't reverse engineer. Too bad for you if you
> > > don't like it, I'm not exactly overflowing with sympathy for someone
> > > who paid nothing and is now complaining that they aren't allowed to
> > > reverse engineer and steal what they didn't pay for.
> >
> > The current German copyright law doesn't talk about money. If you allow
> > someone to use a copy the law explicitely states that some kind of
> > contract clauses (e.g. a complete prohibition of disassembling) are
> > simply void.
>
> Alan pointed out to me that the EU rules are for interoperability and they
> do not allow reverse engineering for the purposes of learning how a product
> works.
>
> Since BK can export any and *all* data and metadata from a one line command,
> it's awfully hard to make the argument that you are reverse engineering
> for interoperability. You can get your data as flat files, diffs, unified
> diffs, context diffs. You can get your checkin comments in any format you
> want. It's trivial to get data in and out of BK.
>
> You can even get all of that from a web server so you don't have to sully
> your hands with evil BK software.
>
> So where is the law that says it is OK to reverse engineer when the product
> already provides everything you could possibly want for interoperability?
Current German copyright law says things like that clauses that forbit
to gather information about the ideas behind a program through normal
program usage are void.
IANAL, and we are entering an area where you need a lawyer that reads
both your licensing terms and the copyright law to tell exactly what is
allowed and what isn't allowed.
My main point is:
There are countries that have laws that are different from US laws (yes,
there's a world outside the USA...). If I download software from your
server it is possible that my local law is the one that is valid for the
contract between us (independent of whether I pay for the software or
whether you give it for free) and my local laws might be different from
the jurisdiction in the USA.
> Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Hi!
> > My understanding of the relevant case law in the United States is that
> > these types of restrictions are not allowed under copyright law itself.
>
> On Fri, Jul 18, 2003 at 10:23:30PM +0100, Alan Cox wrote:
> > Actually your license is simply irrelevant in most of thre world. You
> > aren't allowed to forbid reverse engineering for interoperability.
>
> "Judge, I want to violate this license on this product that I got
> for free because it's not free enough".
Its not free at all.
Alan is right, that parts of licence agreement are irrelevant in
Europe, and what RMS is suggesting is perfectly legal here. Like it or
not. Don't try to make "RMS suggested something ilegal" case. Thanx,
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
On Sun, Jul 20, 2003 at 01:45:19AM +0200, Adrian Bunk wrote:
> There are countries that have laws that are different from US laws (yes,
> there's a world outside the USA...). If I download software from your
> server it is possible that my local law is the one that is valid for the
> contract between us (independent of whether I pay for the software or
> whether you give it for free) and my local laws might be different from
> the jurisdiction in the USA.
Let's try and simplify this because having a legal discussion is pointless.
Our position is that we gave something out for free with an understanding
that you wouldn't reverse engineer it. Regardless of your legal rights or
lack thereof, should you attempt to reverse engineer BK we'll simply stop
giving BK out for free. See? Simple.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Larry McVoy wrote:
>On Sun, Jul 20, 2003 at 01:45:19AM +0200, Adrian Bunk wrote:
>
>
>>There are countries that have laws that are different from US laws (yes,
>>there's a world outside the USA...). If I download software from your
>>server it is possible that my local law is the one that is valid for the
>>contract between us (independent of whether I pay for the software or
>>whether you give it for free) and my local laws might be different from
>>the jurisdiction in the USA.
>>
>>
>
>Let's try and simplify this because having a legal discussion is pointless.
>Our position is that we gave something out for free with an understanding
>that you wouldn't reverse engineer it. Regardless of your legal rights or
>lack thereof, should you attempt to reverse engineer BK we'll simply stop
>giving BK out for free. See? Simple.
>
>
No, it's not simple (and this part, unlike much of the rest of this
discussion, is relevant to this list). If you stopped giving it out for
free, then it would cease to be a viable tool for Linux development.
-Tupshin
(I spared the list a couple of messages by forgetting to CC 'em....)
Larry McVoy wrote:
> On Sat, Jul 19, 2003 at 04:53:40PM -0700, [email protected] wrote:
>
>>Larry McVoy wrote:
>>
>>>So where is the law that says it is OK to reverse engineer when the product
>>>already provides everything you could possibly want for interoperability?
>>
>>Antitrust law. The purpose of antitrust law is to further competition, not
>>merely interoperability.
>
> The day I'm worried about antitrust law is the day I'm rich enough to retire.
I infer a creeping sense of humor.
-- Jim Howard <[email protected]>
On Sat, 19 Jul 2003 17:02:32 PDT, Larry McVoy said:
> Let's try and simplify this because having a legal discussion is pointless.
> Our position is that we gave something out for free with an understanding
> that you wouldn't reverse engineer it. Regardless of your legal rights or
> lack thereof, should you attempt to reverse engineer BK we'll simply stop
> giving BK out for free. See? Simple.
You know guys, Larry would spend a lot less time having to make threats
like this if people didn't start off by saying "Let's see how we can get a free
Bitkeeper". I've seen *LOTS* of philosophical posturing and arguing about
whether it's moral to rip Larry's software off, and what countries make it legal
to do so.
I've only seen *ONE* person (who's name I've forgotten but who needs to be
praised) suggest finding some *FUNDING* for Larry so he doesn't worry about his
revenue stream getting hosed.
So Larry - *IF* funding was there, would you consider a business model similar
to Hans Reiser's?
Larry McVoy wrote:
> Let's try and simplify this because having a legal discussion is pointless.
> Our position is that we gave something out for free with an understanding
> that you wouldn't reverse engineer it. Regardless of your legal rights or
> lack thereof, should you attempt to reverse engineer BK we'll simply stop
> giving BK out for free. See? Simple.
Now that *is* legal, and reasonable (in the legal sense) as well.
-- Jim Howard <[email protected]>
On Sat, 19 Jul 2003 17:10:05 PDT, Tupshin Harper said:
> No, it's not simple (and this part, unlike much of the rest of this
> discussion, is relevant to this list). If you stopped giving it out for
> free, then it would cease to be a viable tool for Linux development.
It's called "Killing the goose that lays the golden eggs".
And although Larry has his philanthropic side, if he has to decide between
"helping Linux development" and "making sure the bills get paid".....
On Sat, Jul 19, 2003 at 08:30:53PM -0400, [email protected] wrote:
> So Larry - *IF* funding was there, would you consider a business model similar
> to Hans Reiser's?
I'd consider anything which resulted in a healthy business. The choices
we've made to date have been 100% focussed on staying healthy so we can
grow as a company and continue to support Linux (and the other open
source guys, but I personally only care about Linus - he's unique),
and our commercial customers. We've been approached by investors and
companies which wished to buy us outright and I passed on both because
it was clear that they wanted one thing: money. They would have shut
down the free use of BK in less than a day after the deal was done.
The thing you need to consider is that the Linux community is not that
different than our commercial customers - both need us to be healthy so
that we can support them. Healthy costs a lot of money.
Part of the problem is that people are extremely short sighted. Until we
gave you BK nobody had any idea that a system like this was possible.
We can see a lot of problems with BK and a lot of problems in the
development process of Linux (and other systems) that maybe we can help
make easier. When people think about funding us they think about the
$$$ it would take to have a couple of guys doing bug fixes. That's not
good enough. We need the dollars to do the next thing that helps make
development work better. BK is fine but it is not the end all answer.
There is a lot of work in bug tracking, project management, review tools,
web interfaces, etc. We're not going to be interested in any business
model that means we get enough money to fix some bugs but not enough to
solve the next set of problems.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Hi folks,
On Fri, Jul 18, 2003 at 03:51:36PM -0400, Richard Stallman wrote:
> > If you are trying to copy BK, give it up. We'll simply follow in the
> > footsteps of every other company faced with this sort of thing and change
> > the protocol every 6 months. Since you would be chasing us you can never
> > catch up. If you managed to stay close then we'd put digital signatures
> > into the protocol to prevent your clone from interoperating with BK.
>
> I think it would be appropriate at this point to write a free client
> that talks with Bitkeeper, and for Linux developers to start switching
> to that from Bitkeeper. At that point, McVoy will face a hard choice:
> if he carries out these threats, he risks alienating the community
> that he hopes will market Bitkeeper for him.
I'm against Richard inflaming the situation without really helping, but since
the issue's come up again, I just thought I'd put in a good word for arch here:
The arch project is no longer just a bunch of shell scripts. Tom
Lord has rewritten it in C (and called the C version 'tla'), and it's
self-hosting. Developers are actually contributing to development using arch
itself now. These seem like very big milestones to me.
There's still quite a bit of work to do on it (and a steep learning curve), but
personally, I think it's the project with the best chance of success. Anyone
who's interested in this issue might consider contributing to arch development
instead of duking it out on lkml.
Be well,
Zack
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Zack Brown
On Sat, Jul 19, 2003 at 04:03:55PM +0100, John Bradford wrote:
> > Given that large chunks of HURD come from Linux, please refer to it as
> > Linux/HURD.
>
> What HURD code comes from Linux? GNU/Mach uses code from Linux, but
> not HURD as far as I know.
As far as I know, HURD is using ext2fs code. It should definitely be
called HURD/Linux. :-)
- Ted
Roman,
Could you correct "FREE" to "FREEDOM"?
Current trends point to FREE from CHOICE, and not FREEDOM to CHOOSE.
CannonBall! Splash!!
Andre Hedrick
LAD Storage Consulting Group
On Sun, 20 Jul 2003, Roman Zippel wrote:
> Hi,
>
> On Sat, 19 Jul 2003, Larry McVoy wrote:
>
> > > Stop lying. No one at the GNU project ever claimed a code to be his if
> > > he didn't write it.
> >
> > Nonsense. Go look at the set of code actually funded by the FSF and it
> > is tiny. The FSF tries to get everyone to sign over their copyright to
> > the FSF so they can "protect" the code and then they rename it to GNU
> > this that or the other thing.
>
> Larry, you've proven enough now, that you don't understand the concept of
> free software. You can stop now. Thanks.
>
> bye, Roman
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Did somebody mention IDE ?
Where?
Andre Hedrick
LAD Storage Consulting Group
On Sat, 19 Jul 2003, Linux Kernel Mailing List wrote:
> >> >> If everyone spent the time replacing bitkeeper instead of beating
> >> up Larry they'd get a lot further.
> >> > Linux isn't the only free operating system in existance, and
> >> although BK seems to suit the requirements of a lot of Linux
> >> developers, that doesn't mean that it meets the requirements of
> >> other free OS
> >> > development teams.
> >> > I strongly suspect that we'll see a free SCM developed after a few
> >> more years of HURD development, for example.
> >> > Doesn't mean we'll switch to it, though, we haven't switched to my
> >> bug database, have we? :-).
> >> > John.
> >>
> >> Given that large chunks of HURD come from Linux, please refer to it as
> >> Linux/HURD.
> >
> > What HURD code comes from Linux? GNU/Mach uses code from Linux, but not
> > HURD as far as I know.
> >
>
> Hi John!
> Go take a look at their networking, and IDE code.
>
>
> -----------------------------------------
> This email was sent using SquirrelMail.
> "Webmail for nuts!"
> http://squirrelmail.org/
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Sat, 19 Jul 2003, Theodore Ts'o wrote:
> As far as I know, HURD is using ext2fs code. It should definitely be
> called HURD/Linux. :-)
My understanding is that theirs is a re-implementation of ext2, not a
port.
C.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Heh,
> My understanding is that theirs is a re-implementation of ext2, not a
> port.
Who cares about the truth? It's GNU/Linux, Linux/HURD, GATES/Linux or
whatever...
*sigh*
These:
* bitkeeper (because it's a better system than anything open source) vs
cvs wars are tedious
* RMS can do what he wants to do
Why let the truth get in the way of, well, the truth?
- --
Who now has the strength to stand against
the armies of Isengard and Mordor?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE/Gpvumk7m2JX6ki4RAi2/AJ41g1N6uagkzF2qjzYynH8W7PO4wACgkaOP
FhUeFnDJrzGWGRQRRBFx6+A=
=u+ir
-----END PGP SIGNATURE-----
> * bitkeeper (because it's a better system than anything open source) vs
> cvs wars are tedious
This discussion is nothing to do with Bit Keeper, (anymore). We are
discussing what parts of the Hurd and GNU Mach contain code derived
from Linux. That's actually quite interesting, and on-topic.
John.
On Sun, Jul 20, 2003 at 09:23:19AM -0400, Charles E. Youse wrote:
> My understanding is that theirs is a re-implementation of ext2, not a
> port.
There's large part taken directly from Linux but the higher level
parts are of course totally different. Due to the GNU Obsfuc^H^H^H^H^HStyle
it's not easy to diff, though..
On Sun, Jul 20, 2003 at 03:09:05PM +0100, Christoph Hellwig wrote:
> On Sun, Jul 20, 2003 at 09:23:19AM -0400, Charles E. Youse wrote:
> > My understanding is that theirs is a re-implementation of ext2, not a
> > port.
>
> There's large part taken directly from Linux but the higher level
> parts are of course totally different. Due to the GNU Obsfuc^H^H^H^H^HStyle
> it's not easy to diff, though..
So put both through the same code beautifier to normalize
formatting. Use ed to search/replace all non-C keywords with 'xxx' if
you think variables or function names are different well.
[Cc: list chopped down to size]
John Bradford <[email protected]> said:
[...]
> This discussion is nothing to do with Bit Keeper, (anymore).
That stuff is wildly off-topic.
> We are
> discussing what parts of the Hurd and GNU Mach contain code derived
> from Linux. That's actually quite interesting, and on-topic.
Why? Are you planing to take anything from Hurd? Or complain that they
(legally!) are taking GPLed code and use it elsewhere? In the fist case,
discussion about the _technical_ merit of the code to swipe is on-topic,
all else isn't. The second case is none of your business, (unless you wrote
the code and did not GPL it).
--
Horst von Brand [email protected]
Casilla 9G, Vin~a del Mar, Chile +56 32 672616
> > We are
> > discussing what parts of the Hurd and GNU Mach contain code derived
> > from Linux. That's actually quite interesting, and on-topic.
>
> Why? Are you planing to take anything from Hurd? Or complain that they
> (legally!) are taking GPLed code and use it elsewhere? In the fist case,
> discussion about the _technical_ merit of the code to swipe is on-topic,
> all else isn't. The second case is none of your business, (unless you wrote
> the code and did not GPL it).
I'm certaily _not_ going to complain that code has been taken from
Linux - as you pointed out, that is perfectly legal.
The use of the Linux drivers in the Hurd is the closest thing[1] we've
got to a fork[2] of the Linux kernel.
So, yes, I am interested in seeing if they have done anything better
than we have, or have investigated possibilities we haven't.
John.
[1] I am _NOT_ saying that the Hurd is a fork of Linux, but that it's
about the only codebase which took Linux kernel code, and has let it
evolve separately from mainline over a number of years. OK, the Vax
port has lived outside of mainline for a number of years too, but
that's mainly architecture specific changes.
[2] OK, ELKS is a fork of the Linux kernel, but not specifically
targeted at 386+ boxes.
John.
"Charles E. Youse" <[email protected]> writes:
> > As far as I know, HURD is using ext2fs code. It should definitely be
> > called HURD/Linux. :-)
>
> My understanding is that theirs is a re-implementation of ext2, not a port.
I did the original port of ext2 to the hurd, and I definitely used the
linux code. Of course the lowest- and highest-level interfaces are all
different, so that code was replaced, but the most important `middle' part
that actually interprets the disk contents was largely the same code
(the separation is not actually so clean in practice, of course).
This is as it should be, I think...
-Miles
--
80% of success is just showing up. --Woody Allen