Hello,
In a few words: I prefer to spend time coding than in endless flamewars
on l-k, and I suggest everybody to do the same and to rather spend time
reading and contributing the code than in answerng this email unless
you've something technical to suggest of course ;)
If you're interested in checking out from the bitkeeper servers with an
open source program (GPLv2 actually) you can do/try it now (almost, see
below for the last trouble that I just discussed today on l-k).
http://www.us.kernel.org/pub/linux/kernel/people/andrea/openbkweb/openbkweb-0.0.tar.gz
I should thanks Aaron Swartz, since I included a GPLv2 html2text python
library for him (google found it) that makes it trivial to extract the
data.
For example to checkout bk head starting from a 2.5.59 tarball on
kernel.org the command is:
mkdir 2.5-pickle
python bkweb.py -u http://linux.bkbits.net:8080/linux-2.5 --rev=1.947.3.4 -t linux-2.5.59 -c 2.5-pickle
The number 1.947.3.4 cames from this webpage:
http://linux.bkbits.net:8080/linux-2.5/ChangeSet@-4w?nav=index.html
you'll see that 1.947.3.4 matches the release number 2.5.59. The number
1.947.3.4 tells bkweb to apply all the changesets from 1.947.3.5 to the
last one. So it's really simple.
bkweb will fetch the data, will save it in the cache directory
(2.5-pickle) and it will apply it to the linux-2.5.59 directory.
Unfortunately it doesn't work reliably when Linus merges old changesets,
the logic will be confused. The current logic thinks all changesets can
be applied in order.
the problem is that to generate bk head it may have to apply also some
changeset in the past, not only between 2.5.59 to the last one in
cronological order. That still needs a solution. One solution could be
also that nobody should send bk pull to Linus anymore, if everybody
sends patches it won't risk to reject anymore ;) but I doubt it's an
acceptable one for everybody, I assume somebody is confortable with it, if
they're using it right now. I also suspect it will be necessary to use a
different numbering and not to use the bk changeset numbers as index. The
object is to never have to rebuild the database. Currently I don't even
store persistent the ordering (not point to store it yet since it's not a 100%
reliable ordering ;).
The -c parameter tells the directory where to generate the cache. the
cache is truly the whole repository and it contains all the data and
metadata in an open form. To get it just run:
changeset = self.unpickle(revision)
where revision can be '1.947.3.5'. dir(changeset) will show you what you
can find there, it's a live class after being restored from disk (I put
only data in there to save space on disk but in theory it could contain
software too, not that I think it is useful but..).
the output looks like this
athlon:~/devel/bkweb> python bkweb.py -u http://linux.bkbits.net:8080/linux-2.5 --rev=1.947.3.4 -t ~/devel/kernel/x -c ~/devel/kernel/2.5-pickle >/tmp/x
Downloading (linux.bkbits.net:8080,/linux-2.5/) ... done.
Found 14 Changeset fallback pages.
Searching rev 1.947.3.4 ... found at CHS 6
Pending 294 revisions
Downloading changeset 1.947.3.5 ... done.
------ Changeset: 1.947.3.5
------ Author: [email protected]
------ Date: 2003-01-16 23:06:26-05:00
------ Commentary: [netdrvr e100] udelay a better way
* Bug Fix: TCO workaround after hard reset of controller to wait for TCO
traffic to settle. Workaround requires issuing a CU load base command
after hard reset, followed by a wait for scb and finally a wait for
TCO traffic bit to clear. Affects 82559s and above wired to SMBus.
------ Files: ['drivers/net/e100/e100_main.c']
patching file drivers/net/e100/e100_main.c
make distclean ... done.
Pending 293 revisions
Downloading changeset 1.947.3.6 ... done.
------ Changeset: 1.947.3.6
------ Author: [email protected]
------ Date: 2003-01-16 23:38:43-05:00
------ Commentary: [netdrvr e100] fix TxDescriptor bit setting
------ Files: ['drivers/net/e100/e100_main.c']
patching file drivers/net/e100/e100_main.c
make distclean ... done.
Pending 292 revisions
Downloading changeset 1.947.3.7 ... done.
------ Changeset: 1.947.3.7
------ Author: [email protected]
------ Date: 2003-01-16 23:40:31-05:00
------ Commentary: [netdrvr e100] standardize nic-specific stats
support
* Removed /proc/net/PRO_LAN_Adapters
* Added ethtool GSTATS support
------ Files: ['drivers/net/e100/Makefile', 'drivers/net/e100/e100.h', 'drivers/net/e100/e100_main.c']
patching file drivers/net/e100/Makefile
patching file drivers/net/e100/e100.h
patching file drivers/net/e100/e100_main.c
[..]
at the first reject it stops and writes to stdout (/tmp/x in my example)
the patch that rejected so you can analyze it. I think it never completed
successfully yet but if it works correctly it should just exit with
nothing in stdout (with stdout I really mean fd 1, not stderr of
course).
So if you run the same command twice the second time it will find
everything in the cache obviously, and the cache is trivial to
manipulate using simple python scripts, so you can automate searches on
files in the changesets or whatever (including feeding the data into CVS
or whatever) So backing up the cache effectively you save the whole
bitkeeper repository (only the main branch). Converting the cache to
something python indipendent is trivial too, I wrote this thing fast
so this was the easiest way.
My main object is to give access to data and metadata of the changesets
generated during kernel development in a very manageable form to
everybody, reliably, without proprietary licence restrictions, and to store it
somewhere (possibly mirrored) in a open standard. This had to be the
case since the first place IMHO. the cset/ directory doesn't allow
anything like that in terms of regenerating the whole tree or managing
the metadata, and it's even less reliable than bkweb. The fact I've to
fetch from the web and not from the cset/ directories on the mirrors
should tell the whole story about the completeness of the cset/
directory. cset/ is better than nothing but it doesn't obviate the need
of bkweb or bk.
I wrote the first line of this program yesterday (it's not that I've
that much time for this thing but eventually I wanted to checkout
through the bitkeeper database too), clearly it's not well tested and I
don't have much time for it.
I guess the bitkeeper network protocol could be also implemented on the
longer run, it should be much faster to fetch all the database that way,
but clearly decoding the html is been much easier and it is supposed to
run in background for me, so I don't care about the checkout speed at
the moment.
If you run it like shown above it will stop like below on
fs/jfs/inode.c.rej in changeset 1.947.6.2, removing -F1 from the patch
parameters should workaround it but I didn't even tried it since I need
to solve this problem before it is really useful.
[..]
Pending 278 revisions
Downloading changeset 1.947.9.4 ... done.
------ Changeset: 1.947.9.4
------ Author: [email protected]
------ Date: 2003-01-17 11:58:19-08:00
------ Commentary: [PATCH] USB ipaq driver ids
Added ids for the Dell Axim and Toshiba E740.
Thanks to Ian Molton and B.I.
------ Files: ['drivers/usb/serial/ipaq.c', 'drivers/usb/serial/ipaq.h']
patching file drivers/usb/serial/ipaq.c
patching file drivers/usb/serial/ipaq.h
make distclean ... done.
Pending 277 revisions
Downloading changeset 1.947.6.2 ... done.
------ Changeset: 1.947.6.2
------ Author: [email protected]
------ Date: 2003-01-17 14:17:30-06:00
------ Commentary: JFS: replace ugly JFS debug macros with simpler ones.
JFS has always used ugly debug macros, jFYI, jEVENT, & jERROR. I have
replaced them with simpler jfs_info(), jfs_warn(), & jfs_err().
------ Files: ['fs/jfs/inode.c', 'fs/jfs/jfs_btree.h', 'fs/jfs/jfs_debug.h', 'fs/jfs/jfs_dmap.c', 'fs/jfs/jfs_dtree.c', 'fs/jfs/jfs_imap.c', 'fs/jfs/jfs_inode.c', 'fs/jfs/jfs_logmgr.c', 'fs/jfs/jfs_metapage.c', 'fs/jfs/jfs_mount.c', 'fs/jfs/jfs_txnmgr.c', 'fs/jfs/jfs_umount.c', 'fs/jfs/jfs_unicode.c', 'fs/jfs/jfs_xtree.c', 'fs/jfs/namei.c', 'fs/jfs/super.c']
patching file fs/jfs/inode.c
Hunk #5 FAILED at 377.
1 out of 5 hunks FAILED -- saving rejects to file fs/jfs/inode.c.rej
patching file fs/jfs/jfs_btree.h
patching file fs/jfs/jfs_debug.h
patching file fs/jfs/jfs_dmap.c
patching file fs/jfs/jfs_dtree.c
patching file fs/jfs/jfs_imap.c
patching file fs/jfs/jfs_inode.c
patching file fs/jfs/jfs_logmgr.c
patching file fs/jfs/jfs_metapage.c
patching file fs/jfs/jfs_mount.c
patching file fs/jfs/jfs_txnmgr.c
patching file fs/jfs/jfs_umount.c
patching file fs/jfs/jfs_unicode.c
patching file fs/jfs/jfs_xtree.c
patching file fs/jfs/namei.c
patching file fs/jfs/super.c
Traceback (most recent call last):
File "bkweb.py", line 283, in ?
bkweb(sys.argv)
File "bkweb.py", line 279, in bkweb
checkout(url, rev, tree, cache, verbose)
File "bkweb.py", line 235, in checkout
raise 'FailedPatch', changeset.rev
FailedPatch: 1.947.6.2
Andrea
On Thu, Feb 06, 2003 at 03:10:29AM +0100, Andrea Arcangeli wrote:
> I wrote the first line of this program yesterday (it's not that I've
> that much time for this thing but eventually I wanted to checkout
> through the bitkeeper database too), clearly it's not well tested and I
> don't have much time for it.
Coincidentally, yesterday was the 1st anniversary[1] of Linus announcing
his usage of BK.
Dave
[1] http://www.uwsg.iu.edu/hypermail/linux/kernel/0202.0/0989.html
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
If people start using this against the bkbits.net server, we'll be
forced to shut down http access. We can't afford the bandwidth costs,
we get charged per byte after a certain amount.
I'm not saying this new code isn't the most wonderful thing since sliced
bread, I'm saying that programatic access to the http servers on bkbits is
absolutely not supported and excessive bandwidth means we shut that down.
Sorry, but getting at the data this way is very bandwidth intensive and
we can't pay for it. If you use BK to get the data it is easily 1/1000th
of the amount of bandwidth these scripts use. If someone wants to foot
the bandwidth bill, it is currently $950/month.
--lm
On Thu, Feb 06, 2003 at 03:10:29AM +0100, Andrea Arcangeli wrote:
> Hello,
>
> In a few words: I prefer to spend time coding than in endless flamewars
> on l-k, and I suggest everybody to do the same and to rather spend time
> reading and contributing the code than in answerng this email unless
> you've something technical to suggest of course ;)
>
> If you're interested in checking out from the bitkeeper servers with an
> open source program (GPLv2 actually) you can do/try it now (almost, see
> below for the last trouble that I just discussed today on l-k).
>
> http://www.us.kernel.org/pub/linux/kernel/people/andrea/openbkweb/openbkweb-0.0.tar.gz
>
> I should thanks Aaron Swartz, since I included a GPLv2 html2text python
> library for him (google found it) that makes it trivial to extract the
> data.
>
> For example to checkout bk head starting from a 2.5.59 tarball on
> kernel.org the command is:
>
> mkdir 2.5-pickle
> python bkweb.py -u http://linux.bkbits.net:8080/linux-2.5 --rev=1.947.3.4 -t linux-2.5.59 -c 2.5-pickle
>
> The number 1.947.3.4 cames from this webpage:
>
> http://linux.bkbits.net:8080/linux-2.5/ChangeSet@-4w?nav=index.html
>
> you'll see that 1.947.3.4 matches the release number 2.5.59. The number
> 1.947.3.4 tells bkweb to apply all the changesets from 1.947.3.5 to the
> last one. So it's really simple.
>
> bkweb will fetch the data, will save it in the cache directory
> (2.5-pickle) and it will apply it to the linux-2.5.59 directory.
>
> Unfortunately it doesn't work reliably when Linus merges old changesets,
> the logic will be confused. The current logic thinks all changesets can
> be applied in order.
>
> the problem is that to generate bk head it may have to apply also some
> changeset in the past, not only between 2.5.59 to the last one in
> cronological order. That still needs a solution. One solution could be
> also that nobody should send bk pull to Linus anymore, if everybody
> sends patches it won't risk to reject anymore ;) but I doubt it's an
> acceptable one for everybody, I assume somebody is confortable with it, if
> they're using it right now. I also suspect it will be necessary to use a
> different numbering and not to use the bk changeset numbers as index. The
> object is to never have to rebuild the database. Currently I don't even
> store persistent the ordering (not point to store it yet since it's not a 100%
> reliable ordering ;).
>
> The -c parameter tells the directory where to generate the cache. the
> cache is truly the whole repository and it contains all the data and
> metadata in an open form. To get it just run:
>
> changeset = self.unpickle(revision)
>
> where revision can be '1.947.3.5'. dir(changeset) will show you what you
> can find there, it's a live class after being restored from disk (I put
> only data in there to save space on disk but in theory it could contain
> software too, not that I think it is useful but..).
>
> the output looks like this
>
> athlon:~/devel/bkweb> python bkweb.py -u http://linux.bkbits.net:8080/linux-2.5 --rev=1.947.3.4 -t ~/devel/kernel/x -c ~/devel/kernel/2.5-pickle >/tmp/x
> Downloading (linux.bkbits.net:8080,/linux-2.5/) ... done.
> Found 14 Changeset fallback pages.
> Searching rev 1.947.3.4 ... found at CHS 6
> Pending 294 revisions
> Downloading changeset 1.947.3.5 ... done.
> ------ Changeset: 1.947.3.5
> ------ Author: [email protected]
> ------ Date: 2003-01-16 23:06:26-05:00
> ------ Commentary: [netdrvr e100] udelay a better way
>
> * Bug Fix: TCO workaround after hard reset of controller to wait for TCO
> traffic to settle. Workaround requires issuing a CU load base command
> after hard reset, followed by a wait for scb and finally a wait for
> TCO traffic bit to clear. Affects 82559s and above wired to SMBus.
>
> ------ Files: ['drivers/net/e100/e100_main.c']
> patching file drivers/net/e100/e100_main.c
> make distclean ... done.
> Pending 293 revisions
> Downloading changeset 1.947.3.6 ... done.
> ------ Changeset: 1.947.3.6
> ------ Author: [email protected]
> ------ Date: 2003-01-16 23:38:43-05:00
> ------ Commentary: [netdrvr e100] fix TxDescriptor bit setting
> ------ Files: ['drivers/net/e100/e100_main.c']
> patching file drivers/net/e100/e100_main.c
> make distclean ... done.
> Pending 292 revisions
> Downloading changeset 1.947.3.7 ... done.
> ------ Changeset: 1.947.3.7
> ------ Author: [email protected]
> ------ Date: 2003-01-16 23:40:31-05:00
> ------ Commentary: [netdrvr e100] standardize nic-specific stats
> support
>
> * Removed /proc/net/PRO_LAN_Adapters
> * Added ethtool GSTATS support
> ------ Files: ['drivers/net/e100/Makefile', 'drivers/net/e100/e100.h', 'drivers/net/e100/e100_main.c']
> patching file drivers/net/e100/Makefile
> patching file drivers/net/e100/e100.h
> patching file drivers/net/e100/e100_main.c
> [..]
>
> at the first reject it stops and writes to stdout (/tmp/x in my example)
> the patch that rejected so you can analyze it. I think it never completed
> successfully yet but if it works correctly it should just exit with
> nothing in stdout (with stdout I really mean fd 1, not stderr of
> course).
>
> So if you run the same command twice the second time it will find
> everything in the cache obviously, and the cache is trivial to
> manipulate using simple python scripts, so you can automate searches on
> files in the changesets or whatever (including feeding the data into CVS
> or whatever) So backing up the cache effectively you save the whole
> bitkeeper repository (only the main branch). Converting the cache to
> something python indipendent is trivial too, I wrote this thing fast
> so this was the easiest way.
>
> My main object is to give access to data and metadata of the changesets
> generated during kernel development in a very manageable form to
> everybody, reliably, without proprietary licence restrictions, and to store it
> somewhere (possibly mirrored) in a open standard. This had to be the
> case since the first place IMHO. the cset/ directory doesn't allow
> anything like that in terms of regenerating the whole tree or managing
> the metadata, and it's even less reliable than bkweb. The fact I've to
> fetch from the web and not from the cset/ directories on the mirrors
> should tell the whole story about the completeness of the cset/
> directory. cset/ is better than nothing but it doesn't obviate the need
> of bkweb or bk.
>
> I wrote the first line of this program yesterday (it's not that I've
> that much time for this thing but eventually I wanted to checkout
> through the bitkeeper database too), clearly it's not well tested and I
> don't have much time for it.
>
> I guess the bitkeeper network protocol could be also implemented on the
> longer run, it should be much faster to fetch all the database that way,
> but clearly decoding the html is been much easier and it is supposed to
> run in background for me, so I don't care about the checkout speed at
> the moment.
>
> If you run it like shown above it will stop like below on
> fs/jfs/inode.c.rej in changeset 1.947.6.2, removing -F1 from the patch
> parameters should workaround it but I didn't even tried it since I need
> to solve this problem before it is really useful.
>
> [..]
> Pending 278 revisions
> Downloading changeset 1.947.9.4 ... done.
> ------ Changeset: 1.947.9.4
> ------ Author: [email protected]
> ------ Date: 2003-01-17 11:58:19-08:00
> ------ Commentary: [PATCH] USB ipaq driver ids
>
> Added ids for the Dell Axim and Toshiba E740.
>
> Thanks to Ian Molton and B.I.
> ------ Files: ['drivers/usb/serial/ipaq.c', 'drivers/usb/serial/ipaq.h']
> patching file drivers/usb/serial/ipaq.c
> patching file drivers/usb/serial/ipaq.h
> make distclean ... done.
> Pending 277 revisions
> Downloading changeset 1.947.6.2 ... done.
> ------ Changeset: 1.947.6.2
> ------ Author: [email protected]
> ------ Date: 2003-01-17 14:17:30-06:00
> ------ Commentary: JFS: replace ugly JFS debug macros with simpler ones.
>
> JFS has always used ugly debug macros, jFYI, jEVENT, & jERROR. I have
> replaced them with simpler jfs_info(), jfs_warn(), & jfs_err().
>
> ------ Files: ['fs/jfs/inode.c', 'fs/jfs/jfs_btree.h', 'fs/jfs/jfs_debug.h', 'fs/jfs/jfs_dmap.c', 'fs/jfs/jfs_dtree.c', 'fs/jfs/jfs_imap.c', 'fs/jfs/jfs_inode.c', 'fs/jfs/jfs_logmgr.c', 'fs/jfs/jfs_metapage.c', 'fs/jfs/jfs_mount.c', 'fs/jfs/jfs_txnmgr.c', 'fs/jfs/jfs_umount.c', 'fs/jfs/jfs_unicode.c', 'fs/jfs/jfs_xtree.c', 'fs/jfs/namei.c', 'fs/jfs/super.c']
> patching file fs/jfs/inode.c
> Hunk #5 FAILED at 377.
> 1 out of 5 hunks FAILED -- saving rejects to file fs/jfs/inode.c.rej
> patching file fs/jfs/jfs_btree.h
> patching file fs/jfs/jfs_debug.h
> patching file fs/jfs/jfs_dmap.c
> patching file fs/jfs/jfs_dtree.c
> patching file fs/jfs/jfs_imap.c
> patching file fs/jfs/jfs_inode.c
> patching file fs/jfs/jfs_logmgr.c
> patching file fs/jfs/jfs_metapage.c
> patching file fs/jfs/jfs_mount.c
> patching file fs/jfs/jfs_txnmgr.c
> patching file fs/jfs/jfs_umount.c
> patching file fs/jfs/jfs_unicode.c
> patching file fs/jfs/jfs_xtree.c
> patching file fs/jfs/namei.c
> patching file fs/jfs/super.c
> Traceback (most recent call last):
> File "bkweb.py", line 283, in ?
> bkweb(sys.argv)
> File "bkweb.py", line 279, in bkweb
> checkout(url, rev, tree, cache, verbose)
> File "bkweb.py", line 235, in checkout
> raise 'FailedPatch', changeset.rev
> FailedPatch: 1.947.6.2
>
> Andrea
> -
> 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/
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Wed, Feb 05, 2003 at 07:09:08PM -0800, Larry McVoy wrote:
> If people start using this against the bkbits.net server, we'll be
> forced to shut down http access. We can't afford the bandwidth costs,
> we get charged per byte after a certain amount.
>
> I'm not saying this new code isn't the most wonderful thing since sliced
> bread, I'm saying that programatic access to the http servers on bkbits is
> absolutely not supported and excessive bandwidth means we shut that down.
>
> Sorry, but getting at the data this way is very bandwidth intensive and
> we can't pay for it. If you use BK to get the data it is easily 1/1000th
> of the amount of bandwidth these scripts use. If someone wants to foot
> the bandwidth bill, it is currently $950/month.
You may want to enable mod_deflate, and then scripts can easily make use
of gzip compressed data. May not be an end-all, but something to
consider.
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
> You may want to enable mod_deflate, and then scripts can easily make use
> of gzip compressed data. May not be an end-all, but something to
> consider.
Gzip will give 4:1 what these scripts are doing is more like 1000:1.
So gzipping the data gets you down to 250:1. That's still way more
bandwidth, way too much to be acceptable.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Wed, Feb 05, 2003 at 08:37:37PM -0800, Larry McVoy wrote:
> > You may want to enable mod_deflate, and then scripts can easily make use
> > of gzip compressed data. May not be an end-all, but something to
> > consider.
>
> Gzip will give 4:1 what these scripts are doing is more like 1000:1.
> So gzipping the data gets you down to 250:1. That's still way more
> bandwidth, way too much to be acceptable.
Larry, would it be acceptable/possible to regularly push some data/metadata
to sites like kernel.org that people already consult for kernel development ?
This way, Andrea's tool would only have to check kernel.org, and not bkbits.net.
Another solution is to fetch from a reverse proxy-cache on a high-bandwidth
site, provided that we know what to cache, of course. This could even reduce
your current HTTP usage since nearly everything should be cacheable for a very
long period.
You know, sometimes I fetch changesets from bkbits.net with my browser, and
I later convert them from html to text with a very trivial sed script. And it
happens that I remember you saying that the bandwidth costs you very much, then
I feel a bit guilty (although about once a week may not be too much) and I
wonder what would happen if everyone did the same regularly.
You may also try to cap the bandwidth from the web server, to dissuade people
from using it, but still not closing it. This could also help you not to pay
for the extra bytes.
Just some suggestions, of course. I wouldn't like your http service to be
closed since I sometimes use it.
Cheers,
Willy
remember that any bk repository will have all the info in it, so just
access that instead of bkbits.org (yes this will require someone to run
the evil propriatary software ;-), but it will avoid the load on Larry's
server)
David Lang
On Thu, 6 Feb 2003, Willy Tarreau wrote:
> Date: Thu, 6 Feb 2003 07:02:23 +0100
> From: Willy Tarreau <[email protected]>
> To: Larry McVoy <[email protected]>, Ben Collins <[email protected]>,
> Larry McVoy <[email protected]>, Andrea Arcangeli <[email protected]>,
> [email protected]
> Subject: Re: openbkweb-0.0
>
> On Wed, Feb 05, 2003 at 08:37:37PM -0800, Larry McVoy wrote:
> > > You may want to enable mod_deflate, and then scripts can easily make use
> > > of gzip compressed data. May not be an end-all, but something to
> > > consider.
> >
> > Gzip will give 4:1 what these scripts are doing is more like 1000:1.
> > So gzipping the data gets you down to 250:1. That's still way more
> > bandwidth, way too much to be acceptable.
>
> Larry, would it be acceptable/possible to regularly push some data/metadata
> to sites like kernel.org that people already consult for kernel development ?
> This way, Andrea's tool would only have to check kernel.org, and not bkbits.net.
>
> Another solution is to fetch from a reverse proxy-cache on a high-bandwidth
> site, provided that we know what to cache, of course. This could even reduce
> your current HTTP usage since nearly everything should be cacheable for a very
> long period.
>
> You know, sometimes I fetch changesets from bkbits.net with my browser, and
> I later convert them from html to text with a very trivial sed script. And it
> happens that I remember you saying that the bandwidth costs you very much, then
> I feel a bit guilty (although about once a week may not be too much) and I
> wonder what would happen if everyone did the same regularly.
>
> You may also try to cap the bandwidth from the web server, to dissuade people
> from using it, but still not closing it. This could also help you not to pay
> for the extra bytes.
>
> Just some suggestions, of course. I wouldn't like your http service to be
> closed since I sometimes use it.
>
> Cheers,
> Willy
>
> -
> 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 Thu, 6 Feb 2003, Willy Tarreau wrote:
> On Wed, Feb 05, 2003 at 08:37:37PM -0800, Larry McVoy wrote:
> > > You may want to enable mod_deflate, and then scripts can easily make use
> > > of gzip compressed data. May not be an end-all, but something to
> > > consider.
> >
> > Gzip will give 4:1 what these scripts are doing is more like 1000:1.
> > So gzipping the data gets you down to 250:1. That's still way more
> > bandwidth, way too much to be acceptable.
>
> Larry, would it be acceptable/possible to regularly push some data/metadata
> to sites like kernel.org that people already consult for kernel development ?
> This way, Andrea's tool would only have to check kernel.org, and not bkbits.net.
>
> Another solution is to fetch from a reverse proxy-cache on a high-bandwidth
> site, provided that we know what to cache, of course. This could even reduce
> your current HTTP usage since nearly everything should be cacheable for a very
> long period.
Can't all information be extracted from the bk-commits* mailing lists postings?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Andrea Arcangeli wrote:
> I guess the bitkeeper network protocol could be also implemented on the
> longer run, it should be much faster to fetch all the database that way,
Nobody (who is covered by copyright laws) is allowed to use the _free_
version of BitKeeper to reverse engineer the protocol. I may be
mistaken - perhaps the BitKeeper "anti-competition" clause would be
found unenforcable.. but I'm not interested in going there.
-- Jamie
On Thu, 13 Feb 2003, Jamie Lokier wrote:
> Andrea Arcangeli wrote:
> > I guess the bitkeeper network protocol could be also implemented on the
> > longer run, it should be much faster to fetch all the database that way,
>
> Nobody (who is covered by copyright laws) is allowed to use the _free_
> version of BitKeeper to reverse engineer the protocol. I may be
> mistaken - perhaps the BitKeeper "anti-competition" clause would be
> found unenforcable.. but I'm not interested in going there.
Reverse engineering the protocol is probably allowed, as long
as you don't create an alternative implementation yourself.
I can't see how Larry's license would stop people from writing
that alternative implementation, as long as those people don't
use bitkeeper themselves.
This is mostly because the license doesn't forbid creating an
alternative to bitkeeper (I doubt Larry would even want that,
even if the law granted that much power). All it does is not
grant the free use of bitkeeper to people working on an alternative.
cheers,
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://guru.conectiva.com/
Current spamtrap: <a href=mailto:"[email protected]">[email protected]</a>
On Thu, Feb 13, 2003 at 09:55:28AM -0200, Rik van Riel wrote:
> On Thu, 13 Feb 2003, Jamie Lokier wrote:
> > Andrea Arcangeli wrote:
> > > I guess the bitkeeper network protocol could be also implemented on the
> > > longer run, it should be much faster to fetch all the database that way,
> >
> > Nobody (who is covered by copyright laws) is allowed to use the _free_
> > version of BitKeeper to reverse engineer the protocol. I may be
> > mistaken - perhaps the BitKeeper "anti-competition" clause would be
> > found unenforcable.. but I'm not interested in going there.
>
> Reverse engineering the protocol is probably allowed, as long
> as you don't create an alternative implementation yourself.
We'd view reverse engineering the protocol as falling under the "you're
working on a competing implementation".
The general message is that you are free to use BK but you aren't free
to use BK in any way which could hurt the business which produces BK.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Le jeu 13/02/2003 ? 17:13, Larry McVoy a ?crit :
> We'd view reverse engineering the protocol as falling under the "you're
> working on a competing implementation".
>
> The general message is that you are free to use BK but you aren't free
> to use BK in any way which could hurt the business which produces BK.
If this kind of rule was enforced, lots of drivers wouldn't have
existed. You can't do much against reverse engineering.
On Thu, Feb 13, 2003 at 05:23:10PM +0100, Xavier Bestel wrote:
> Le jeu 13/02/2003 ? 17:13, Larry McVoy a ?crit :
>
> > We'd view reverse engineering the protocol as falling under the "you're
> > working on a competing implementation".
> >
> > The general message is that you are free to use BK but you aren't free
> > to use BK in any way which could hurt the business which produces BK.
>
> If this kind of rule was enforced, lots of drivers wouldn't have
> existed. You can't do much against reverse engineering.
The analogy doesn't work. Companies make money by selling the hardware,
having a free driver out there tends to just make them sell more hardware.
Furthermore, you bought one of their cards to reverse engineer the driver.
The situation here is that you have a product given to you for free. Your
right to use that product is conditional on you not reverse engineering it.
If we were 3com and we had some nifty card and we were *giving* you cards
for free, it would be well within our rights to say "here are the rules,
if you don't like these rules then you have to pay for the card".
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
> We'd view reverse engineering the protocol as falling under the "you're
> working on a competing implementation".
>
> The general message is that you are free to use BK but you aren't free
> to use BK in any way which could hurt the business which produces BK.
I don't really see the point of spending any time trying to make a set
of open source tools to access BK repositories, unless Larry decides
to make the necessary protocol information available.
That time could be better spent developing a complete alternative to
BK, which would benefit everybody - at the moment, practically all of
the innovation in source management that I can see is coming from
Bitmover. If a free alternative to BK was developed, both it's
development team and BitMover could work together on ideas, and then
go and implement them in their own ways.
Oh, and before anybody suggests that I develop free alternative to
BK myself, I am too busy working on the Kernel Bug Database and other
projects :-).
John.
On Thu, Feb 13, 2003 at 08:13:37AM -0800, Larry McVoy wrote:
>...
> We'd view reverse engineering the protocol as falling under the "you're
> working on a competing implementation".
>...
If a clause in a license forbids a licensee to use or decompile the
program to gather the information needed for independendly developed
programs to interoperate with this program current German copyright law
says that this clause is void in Germany. :-)
> 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 Thu, 2003-02-13 at 16:11, Adrian Bunk wrote:
> If a clause in a license forbids a licensee to use or decompile the
> program to gather the information needed for independendly developed
> programs to interoperate with this program current German copyright law
> says that this clause is void in Germany. :-)
In which case you would have no right to use the program, not unlimited
right. :)
But if this is true, I guess this raises a concern for German hackers
(or perhaps everyone in the EU?).
Robert Love
On Thu, Feb 13, 2003 at 10:11:27PM +0100, Adrian Bunk wrote:
> On Thu, Feb 13, 2003 at 08:13:37AM -0800, Larry McVoy wrote:
> >...
> > We'd view reverse engineering the protocol as falling under the "you're
> > working on a competing implementation".
> >...
>
> If a clause in a license forbids a licensee to use or decompile the
> program to gather the information needed for independendly developed
> programs to interoperate with this program current German copyright law
> says that this clause is void in Germany. :-)
Please show me the case law which says we have to give you our technology,
for free, and we do not have the right to say "no way unless you agree to
not reverse engineer".
Lots of law says "if you paid for this product, the seller may not impose
the following restrictions" with reverse engineering being amongst those.
I do not have any data which says that the same law applies in the case of
a no charge copy of the software, do you?
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Larry McVoy wrote:
> Please show me the case law which says we have to give you our technology,
> for free, and we do not have the right to say "no way unless you agree to
> not reverse engineer".
Correct. You do not have to give your software for free. (In
European patent terminology it is not called technology, by the way).
Correct. You have the right to say "no way unless you agree not to
reverse engineer".
> Lots of law says "if you paid for this product, the seller may not impose
> the following restrictions" with reverse engineering being amongst those.
>
> I do not have any data which says that the same law applies in the case of
> a no charge copy of the software, do you?
Someone may copy and use your software _without_ agreeing to the license.
Then you can sue them for breach of copyright.
You will win, unless their copying was fair use.
Reverse engineering for interoperability is a form of fair use in many
countries, including Germany and the UK.
Draw your own conclusion :)
-- Jamie
Jamie.
>
> Someone may copy and use your software _without_ agreeing to the license.
>
> Then you can sue them for breach of copyright.
>
> You will win, unless their copying was fair use.
>
> Reverse engineering for interoperability is a form of fair use in many
> countries, including Germany and the UK.
>
> Draw your own conclusion :)
That particular line of reasoning is even included in the infamous DMCA here
in the US... But the courts have ruled in favor of the MPAA with regards to
attempts to LEGALLY reverse-engineer CSS.
Daw your own conclusion...
Matthew D. Pitts
Guys, Larry isn't saying that you are not allowed to BUY a copy of
bitkeeper and reeverse engineer it, he is saying that you are not allowed
to get the FREE copy of bitkeeper and reverse engineer it.
if you give Larry money for a license you can reverse engineer it,
analyse it's tools, etc under all the reasoning that you give about your
legal right to something you have paid for.
but the FREE use of bitkeeper does not give you the same rights. Larry is
saying that he won't give people who are perceived as 'out to get him' a
free license for bitkeeper
so drop all this nonsense about the rights you have for purchasing
software and how evil Larry is for trying to take those rights away.
David Lang
On Fri, 14 Feb
2003, Matthew D. Pitts wrote:
> Date: Fri, 14 Feb 2003 01:02:57 -0500
> From: Matthew D. Pitts <[email protected]>
> To: [email protected]
> Subject: Re: openbkweb-0.0
>
>
> Jamie.
> >
> > Someone may copy and use your software _without_ agreeing to the license.
> >
> > Then you can sue them for breach of copyright.
> >
> > You will win, unless their copying was fair use.
> >
> > Reverse engineering for interoperability is a form of fair use in many
> > countries, including Germany and the UK.
> >
> > Draw your own conclusion :)
>
> That particular line of reasoning is even included in the infamous DMCA here
> in the US... But the courts have ruled in favor of the MPAA with regards to
> attempts to LEGALLY reverse-engineer CSS.
>
> Daw your own conclusion...
> Matthew D. Pitts
>
>
> -
> 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/
>
Le jeu 13/02/2003 ? 22:18, Robert Love a ?crit :
> On Thu, 2003-02-13 at 16:11, Adrian Bunk wrote:
>
> > If a clause in a license forbids a licensee to use or decompile the
> > program to gather the information needed for independendly developed
> > programs to interoperate with this program current German copyright law
> > says that this clause is void in Germany. :-)
>
> In which case you would have no right to use the program, not unlimited
> right. :)
>
> But if this is true, I guess this raises a concern for German hackers
> (or perhaps everyone in the EU?).
At least in France, it just means this particular clause is void. This
doesn't prevent you (err .. me) from using it.
Xav
On Fri, 2003-02-14 at 06:30, David Lang wrote:
> Guys, Larry isn't saying that you are not allowed to BUY a copy of
> bitkeeper and reeverse engineer it, he is saying that you are not allowed
> to get the FREE copy of bitkeeper and reverse engineer it.
What he says about this is not worth a sheeps fart. Most of the world
allows reverse engineering for compatibility, full stop. Often not for
cloning, so writing bk extracting tools is very different to cloning BK
Alan
Alan,
> What he says about this is not worth a sheeps fart. Most of the world
> allows reverse engineering for compatibility, full stop.
What the laws say is one thing. What the courts rule, no matter whether it
is in the UK, EU, or the US, is what matters. In my previous post on this
subject, I pointed out that US law provides for that in the DMCA, but the
courts have said that what the lawmakers wrote isn't what they meant...
Matthew
On Fri, Feb 14, 2003 at 02:41:41PM +0000, Alan Cox wrote:
> On Fri, 2003-02-14 at 06:30, David Lang wrote:
> > Guys, Larry isn't saying that you are not allowed to BUY a copy of
> > bitkeeper and reeverse engineer it, he is saying that you are not allowed
> > to get the FREE copy of bitkeeper and reverse engineer it.
>
> What he says about this is not worth a sheeps fart. Most of the world
> allows reverse engineering for compatibility, full stop. Often not for
> cloning, so writing bk extracting tools is very different to cloning BK
First of all, we've carefully maintained SCCS compat to the extent that
these tools aren't needed. Thanks very much for acknowledging that it
was nice of us to do so, Alan.
Second of all, all of those reverse engineering clauses are dependent on
you having a legal copy of the software, full stop. You can't get a
legal copy if what you want to do, now or in the future, is to reverse
engineer the software.
Third of all, you could be right, I could be wrong, and I'm still right.
We give the software away for *free*. We *own* it. If it turns out that
people want to behave like little children and not play nice, no problem,
we'll promptly fork the tree and you are stuck with whatever version you
had at the point you decided to not play nice.
I'm more than a little disgusted by this thread and the attitude of some
in it. It's all well and good to whine about the BK license, but before
you do, how about quantifying the amount of good it has done for the
kernel development process over the last year? All sorts of people have
pointed out that things are going a lot better, perhaps you want to take
that into consideration before you decide to yank this particular chain.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Fri, 14 Feb 2003, Larry McVoy wrote:
> I'm more than a little disgusted by this thread and the attitude of some
> in it. It's all well and good to whine about the BK license, but before
> you do, how about quantifying the amount of good it has done for the
> kernel development process over the last year? All sorts of people have
> pointed out that things are going a lot better, perhaps you want to take
> that into consideration before you decide to yank this particular chain.
Indeed. Linus' patch-dropping-rate has declined a lot since he started using
BK, making life easier for maintainers, and people started to write better
changelogs, making lifer easier for whoever wants to follow kernel development.
Kudos, Larry!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Fri, 2003-02-14 at 15:30, Larry McVoy wrote:
> Second of all, all of those reverse engineering clauses are dependent on
> you having a legal copy of the software, full stop. You can't get a
> legal copy if what you want to do, now or in the future, is to reverse
> engineer the software.
Go talk to an EU lawyer. These laws exist to stop people locking down
formats and its one of the reasons you actually have things like
open office
All I want is to be able to review the 3c990 patch. Right now I can't
> [[email protected]]
>
> On Fri, 2003-02-14 at 15:30, Larry McVoy wrote:
> > Second of all, all of those reverse engineering clauses are dependent on
> > you having a legal copy of the software, full stop. You can't get a
> > legal copy if what you want to do, now or in the future, is to reverse
> > engineer the software.
>
> Go talk to an EU lawyer. These laws exist to stop people locking down
> formats and its one of the reasons you actually have things like
> open office
>
> All I want is to be able to review the 3c990 patch. Right now I can't
Larry, would it be a problem to implement something like:
alan@wherever$ echo 'rq unidiff for {1.967,1.968} of typhoon/typhoon-2.4'| \
mail [email protected]
...
You have mail in /var/spool/alan.
alan@wherever$ tail -17 /var/spool/alan
diff -Nru a/include/linux/pci_ids.h b/include/linux/pci_ids.h --- a/include/linux/pci_ids.h Mon Feb 3 16:41:40 2003
+++ b/include/linux/pci_ids.h Thu Feb 13 22:42:01 2003
@@ -829,6 +829,14 @@
#define PCI_DEVICE_ID_3COM_3C905TX 0x9050
#define PCI_DEVICE_ID_3COM_3C905T4 0x9051
#define PCI_DEVICE_ID_3COM_3C905B_TX 0x9055
+#define PCI_DEVICE_ID_3COM_3CR990 0x9900
+#define PCI_DEVICE_ID_3COM_3CR990_TX_95 0x9902
+#define PCI_DEVICE_ID_3COM_3CR990_TX_97 0x9903
+#define PCI_DEVICE_ID_3COM_3CR990B 0x9904
+#define PCI_DEVICE_ID_3COM_3CR990_FX 0x9905
+#define PCI_DEVICE_ID_3COM_3CR990SVR95 0x9908
+#define PCI_DEVICE_ID_3COM_3CR990SVR97 0x9909
+#define PCI_DEVICE_ID_3COM_3CR990SVR 0x990a
#define PCI_VENDOR_ID_SMC 0x10b8
#define PCI_DEVICE_ID_SMC_EPIC100 0x0005
--
Tomas Szepe <[email protected]>
> Larry, would it be a problem to implement something like:
>
> alan@wherever$ echo 'rq unidiff for {1.967,1.968} of typhoon/typhoon-2.4'| \
> mail [email protected]
Sure, you can do it.
bk clone bk://typhoon.bkbits.net/typhoon-2.4
cd typhoon-2.4
bk export -tpatch -r1.967,1.968 | mail [email protected]
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
> [[email protected]]
>
> > Larry, would it be a problem to implement something like:
> >
> > alan@wherever$ echo 'rq unidiff for {1.967,1.968} of typhoon/typhoon-2.4'| \
> > mail [email protected]
>
> Sure, you can do it.
>
> bk clone bk://typhoon.bkbits.net/typhoon-2.4
> cd typhoon-2.4
> bk export -tpatch -r1.967,1.968 | mail [email protected]
Oh, was I asking whether *I* could do this?
Is my memory failing me so horribly?
No really, I can't see why you have decided to ignore this feature
request already in its embryo stage. It would be very useful IMHO.
--
Tomas Szepe <[email protected]>
> > Sure, you can do it.
> >
> > bk clone bk://typhoon.bkbits.net/typhoon-2.4
> > cd typhoon-2.4
> > bk export -tpatch -r1.967,1.968 | mail [email protected]
>
> Oh, was I asking whether *I* could do this?
> Is my memory failing me so horribly?
>
> No really, I can't see why you have decided to ignore this feature
> request already in its embryo stage. It would be very useful IMHO.
Because it costs money for bandwidth. I agree it would be useful, so
find someone to cough up the $15K/year for the bandwidth and you can
have the diff interface you want. The code is already written, it has
been for more than a year, it's simply a money issue.
To put this more into perspective, the real problem is that we share the
T1 line you guys use to get at bkbits.net with our voice over IP phone
system and every time one of you use the net, the phones sound like
something from a bad B movie. We've tried all sorts of traffic shaping
and it doesn't work, the phones suck when they can't get the wire.
It's bad enough now, it would be intolerable if we were a patch server.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Thu, Feb 13, 2003 at 10:56:21PM +0000, Jamie Lokier wrote:
> Larry McVoy wrote:
> > Please show me the case law which says we have to give you our technology,
> > for free, and we do not have the right to say "no way unless you agree to
> > not reverse engineer".
>...
> Correct. You have the right to say "no way unless you agree not to
> reverse engineer".
>...
Wrong.
Current German copyright law says that any contractual appointments that
disallow the allowed cases of reverse engineering are void.
> -- Jamie
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 Thu, Feb 13, 2003 at 02:05:23PM -0800, Larry McVoy wrote:
> On Thu, Feb 13, 2003 at 10:11:27PM +0100, Adrian Bunk wrote:
> > On Thu, Feb 13, 2003 at 08:13:37AM -0800, Larry McVoy wrote:
> > >...
> > > We'd view reverse engineering the protocol as falling under the "you're
> > > working on a competing implementation".
> > >...
> >
> > If a clause in a license forbids a licensee to use or decompile the
> > program to gather the information needed for independendly developed
> > programs to interoperate with this program current German copyright law
> > says that this clause is void in Germany. :-)
>
> Please show me the case law which says we have to give you our technology,
There is no case law in Germany.
I'm talking about the text written in paragraph 69g (2) of the German
"Gesetz ueber Urheberrecht und verwandte Schutzrechte
(Urheberrechtsgesetz)".
> for free, and we do not have the right to say "no way unless you agree to
> not reverse engineer".
German copyright law says that any clauses that forbid reverse
engineering for gathering data needed for independendly developed
programs to interoperate with this program are void. Full stop.
There's simply no legal possibility for you under current German
copyright law to allow anyone to use your program without allowing him
to reverse engineer your proprietary protocol.
> Lots of law says "if you paid for this product, the seller may not impose
> the following restrictions" with reverse engineering being amongst those.
>
> I do not have any data which says that the same law applies in the case of
> a no charge copy of the software, do you?
German copyright law talks about licensees, not about money. It doesn't
matter whether the licence was free or whether it costs a billion Euro.
If you don't believe me ask any lawyer who knows German copyright law.
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
Would you all please spend your time trying to screw microsoft, who's
trying their best to screw us all, rather than larry, who's just doing his
best to try to make a buck while provideing us a rather nice service?
Thanks
Nick
On Fri, 14 Feb 2003, Adrian Bunk wrote:
> On Thu, Feb 13, 2003 at 10:56:21PM +0000, Jamie Lokier wrote:
> > Larry McVoy wrote:
> > > Please show me the case law which says we have to give you our technology,
> > > for free, and we do not have the right to say "no way unless you agree to
> > > not reverse engineer".
> >...
> > Correct. You have the right to say "no way unless you agree not to
> > reverse engineer".
> >...
>
> Wrong.
>
> Current German copyright law says that any contractual appointments that
> disallow the allowed cases of reverse engineering are void.
In my view a great number of things are legal which I consider unethical.
I believe Larry has made his position fairly clear and has attempted to
construct his license language to implement that plain-spoken intent.
Whether or not people agree with the stated position, I doubt there is
anyone who doesn't understand it. Why not just do the clearly right thing
and abide by that?
Adrian Bunk wrote:
> On Thu, Feb 13, 2003 at 10:56:21PM +0000, Jamie Lokier wrote:
> > Larry McVoy wrote:
> > > Please show me the case law which says we have to give you our technology,
> > > for free, and we do not have the right to say "no way unless you agree to
> > > not reverse engineer".
> >...
> > Correct. You have the right to say "no way unless you agree not to
> > reverse engineer".
> >...
>
> Wrong.
>
> Current German copyright law says that any contractual appointments that
> disallow the allowed cases of reverse engineering are void.
Exactly. He can say it, it's up to you whether you ignore it.
-- Jamie
On Fri, Feb 14, 2003 at 11:45:17PM +0000, Jamie Lokier wrote:
> > Current German copyright law says that any contractual appointments that
> > disallow the allowed cases of reverse engineering are void.
>
> Exactly. He can say it, it's up to you whether you ignore it.
As with many things in life, you can choose to behave well or poorly and
the people you help or hurt will act according.
The slashdot kiddies, as an example, seemed to think it was OK to swap all
the music they wanted for free. The music industry responded by helping
push through the recent round of draconian laws which are much deplored on
slashdot and here for that matter.
But nobody seems willing to stand up and say "well, maybe if we hadn't been
stealing all this music these laws might not have come into existence".
I'll leave you to make the BitKeeper connection, I'm sure you are smart
enough to do so.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Hey Alan,
I noticed a typographical error in your message. I thought I'd help you
out with a correction:
s/"All I want is to be able to review the 3c990 patch. Right now I
can't"/"All I want is to be able to review the 3c990 patch. Right now I
can't be bothered to use software that is being offered to me for free
because it's far more important to get into mindless flamewars over tools
that make life easier for everyone. Oh, and Stallman is god."
Hope that helps.
-----Original Message-----
From: [email protected]
[mailto:[email protected]]On Behalf Of Alan Cox
Sent: Friday, February 14, 2003 10:56 AM
To: Larry McVoy
Cc: David Lang; Matthew D. Pitts; Linux Kernel Mailing List
Subject: Re: openbkweb-0.0
On Fri, 2003-02-14 at 15:30, Larry McVoy wrote:
> Second of all, all of those reverse engineering clauses are dependent on
> you having a legal copy of the software, full stop. You can't get a
> legal copy if what you want to do, now or in the future, is to reverse
> engineer the software.
Go talk to an EU lawyer. These laws exist to stop people locking down
formats and its one of the reasons you actually have things like
open office
All I want is to be able to review the 3c990 patch. Right now I can't
Seconded!
-----Original Message-----
From: [email protected]
[mailto:[email protected]]On Behalf Of [email protected]
Sent: Friday, February 14, 2003 2:36 PM
To: Adrian Bunk
Cc: Larry McVoy; Larry McVoy; Rik van Riel; Jamie Lokier; Andrea
Arcangeli; [email protected]
Subject: Re: openbkweb-0.0
Would you all please spend your time trying to screw microsoft, who's
trying their best to screw us all, rather than larry, who's just doing his
best to try to make a buck while provideing us a rather nice service?
Thanks
Nick
Thomas Molina wrote:
> In my view a great number of things are legal which I consider unethical.
> I believe Larry has made his position fairly clear and has attempted to
> construct his license language to implement that plain-spoken intent.
> Whether or not people agree with the stated position, I doubt there is
> anyone who doesn't understand it. Why not just do the clearly right thing
> and abide by that?
Larry's touched an open source nerve by creating what is in effect a
closed protocol, and getting it into the heart of the kernel
development process.
Blame has nothing to do with it. We _greatly_ respect Larry's
accomplishments in this area (and others), and as for the kernel
development process we might just as well say it's Linus fault for
choosing to use featureful Word 7 when unusable Abiword 0.01 was
available :)
Quite a lot of kernel trees are maintained using Bitkeeper now, btw,
which is testament to how well that vision is implemented.
It would be very *impolite* to ignore Larry's license and use the
software he developed against his express wishes. (It does _not_ give
me a good feeling even to talk about it).
On the other hand, it's widely accepted that making a program which
_interoperates_ with someone elses closed source program is socially
acceptable, and often desirable. This is so widely understood that
it's expressly written into copyright law in virtually every country
which has copyright law.
Thats how important interoperation is considered to be - it's not just
a geek thing, it's a _principle_ - something which is widely held to
be the right thing to do for the sake of the big picture.
That's why Larry gets so much flak. He is generous with a caveat
which touches a nerve. Conditional love. (Slippery slope... the GPL
is like this too :)
He gets flak precisely _because_ his software is so good that so many
people choose to use it, and accept the attached strings. (It's a
compliment, see?)
Imagine if all your friends started talking a different language,
called Binglish say. You'd want to talk to them in that language so
you could socialise and work with them. Now if they told you you must
sign a contract and join a private society, or pay significant cash,
otherwise you couldn't talk the language? If it were a few people
you'd ignore them, but if it seemed like all the really powerful
people who affect your life would just ignore you unless you talked
it, you'd be pissed off. You'd feel the playing field had become
unlevel and needed correction. You'd be tempted to either (1) cave in
and pay or join the private society, (2) learn the language and
use it anyway.
In other words, we see shades of glass ceiling for non-Bitkeeper
users. Not intentionally, it is simply an effect that occurs when
something good is limited to a subset of people - whether by choice or not.
And nobody thinks glass ceilings should be sustained, do they? Do they?
Now, if you accept that writing a program to communicate with users
who do their daily work using the BitKeeper product - in their choice
of language - is a good idea. How are you going to do that? Larry's
created a situation where the only way to do that is to analyse his
software against his express wishes.
Which is more important? Being polite to Larry, or being able to
write programs that communicate with important people in their
preferred language - levelling the playing field somewhat?
It's harsh reality, but if you create something that benefits many
people and attach conditions to your generosity, you'll get a lot of
complaints. It's true of the GPL, it's true of the BKL, it's true of
the World Bank etc.
Sometimes those complaints are based on sound principles. Sometimes
they're not.
You decide.
-- Jamie
Larry McVoy wrote:
> But nobody seems willing to stand up and say "well, maybe if we hadn't been
> stealing all this music these laws might not have come into existence".
>
> I'll leave you to make the BitKeeper connection, I'm sure you are smart
> enough to do so.
On this we agree. Point well made!
The best thing for all may be a huge whip round to pay Bitmover enough
for them to be _happy_ to open the protocol.
Anyone want to start a fund? I offer to donate US$100 (and that's 2
weeks income for me ATM).
-- Jamie
On Sat, 2003-02-15 at 00:11, [email protected] wrote:
> s/"All I want is to be able to review the 3c990 patch. Right now I
> can't"/"All I want is to be able to review the 3c990 patch. Right now I
> can't be bothered to use software that is being offered to me for free
> because it's far more important to get into mindless flamewars over tools
> that make life easier for everyone. Oh, and Stallman is god."
I think you are confused, and probably clueless. I'm not permitted to
use bitkeeper for free.
Follow ups to [email protected]
Vlad, I noticed a typographical error in your correction to Alan's message.
You wrote "...software that is being offered to me for free...".
I think you meant "...software that is being offered to me for free
(as in beer)...".
Thanks for your time.
-- Jamie "pain in the arse" Lokier ;)
[email protected] wrote:
> Hey Alan,
> I noticed a typographical error in your message. I thought I'd help you
> out with a correction:
>
> s/"All I want is to be able to review the 3c990 patch. Right now I
> can't"/"All I want is to be able to review the 3c990 patch. Right now I
> can't be bothered to use software that is being offered to me for free
> because it's far more important to get into mindless flamewars over tools
> that make life easier for everyone. Oh, and Stallman is god."
>
> Hope that helps.
>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Alan Cox
> Sent: Friday, February 14, 2003 10:56 AM
> To: Larry McVoy
> Cc: David Lang; Matthew D. Pitts; Linux Kernel Mailing List
> Subject: Re: openbkweb-0.0
>
>
> On Fri, 2003-02-14 at 15:30, Larry McVoy wrote:
> > Second of all, all of those reverse engineering clauses are dependent on
> > you having a legal copy of the software, full stop. You can't get a
> > legal copy if what you want to do, now or in the future, is to reverse
> > engineer the software.
>
> Go talk to an EU lawyer. These laws exist to stop people locking down
> formats and its one of the reasons you actually have things like
> open office
>
> All I want is to be able to review the 3c990 patch. Right now I can't
>
> -
> 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 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/
Thank you kind sir! I stand (er, sit) corrected!
-----Original Message-----
From: [email protected]
[mailto:[email protected]]On Behalf Of Jamie Lokier
Sent: Friday, February 14, 2003 6:52 PM
To: [email protected]
Cc: 'Alan Cox'; 'Larry McVoy'; 'Linux Kernel Mailing List'
Subject: Re: openbkweb-0.0
Vlad, I noticed a typographical error in your correction to Alan's message.
You wrote "...software that is being offered to me for free...".
I think you meant "...software that is being offered to me for free
(as in beer)...".
Thanks for your time.
-- Jamie "pain in the arse" Lokier ;)
On Sat, 15 Feb 2003, Jamie Lokier wrote:
> Larry McVoy wrote:
> > But nobody seems willing to stand up and say "well, maybe if we hadn't been
> > stealing all this music these laws might not have come into existence".
> >
> > I'll leave you to make the BitKeeper connection, I'm sure you are smart
> > enough to do so.
>
> On this we agree. Point well made!
>
> The best thing for all may be a huge whip round to pay Bitmover enough
> for them to be _happy_ to open the protocol.
IMHO, Larry does not even need to "open the protocol". He could simply
release a tool with limited functionalities under a different license.
Wrong ?
> Anyone want to start a fund? I offer to donate US$100 (and that's 2
> weeks income for me ATM).
You might want to pass the above text through 'sed' using s/weeks/hours/ :)
- Davide
No no no, thanks - I'm not a bridge troll... I'm a Slashdot troll... :-)
We eat less. Seriously, it's not like you can't work under the
circumstances - you just refuse to. That's your choice - one I respect.
Why try to, or even advocate limiting Larry's choices? That seems unfair
and blatantly hypocritical at best. :-(
Regards,
Vlad
-----Original Message-----
From: [email protected]
[mailto:[email protected]]On Behalf Of Alan Cox
Sent: Friday, February 14, 2003 7:51 PM
To: [email protected]
Cc: 'Larry McVoy'; 'Linux Kernel Mailing List'
Subject: RE: openbkweb-0.0
On Sat, 2003-02-15 at 00:11, [email protected] wrote:
> s/"All I want is to be able to review the 3c990 patch. Right now I
> can't"/"All I want is to be able to review the 3c990 patch. Right now I
> can't be bothered to use software that is being offered to me for free
> because it's far more important to get into mindless flamewars over tools
> that make life easier for everyone. Oh, and Stallman is god."
I think you are confused, and probably clueless. I'm not permitted to
use bitkeeper for free.
Follow ups to [email protected]
On Sat, 2003-02-15 at 01:01, [email protected] wrote:
> We eat less. Seriously, it's not like you can't work under the
> circumstances - you just refuse to. That's your choice - one I respect.
> Why try to, or even advocate limiting Larry's choices?
I'm not. I treated it just like any other document I couldn't read,
I asked for it in a sane format. The author kindly sent me it. The
rest of the thread is Larry's invention. I don't care what Larry
does with bitkeeper, any more than I care about clearcase.
The transaction is the same thing as
"A word file, can yo send me that in text"
"Thanks"
the rest is touchy people inventing sinister plots that don't exist
anyone who wants to can setup a bitkeeper server, set it to sync with
bkbits.net every 5 min and re-export the data (including the SCCS
formatted metadata) any way they want. Larry has even encouraged people to
do this.
what he is refusing to do is to pay the cash for the bandwith to support
this.
I'll volunteer to run such a server so that you purists don't have to get
your hands dirty by touching bitkeeper, as long as someone else is paying
the bandwidth and hosting costs (and I'm not requiring a colo facility,
someone's house with appropriate bandwidth is good enough for me. I'm
willing to cut any corners that can be cut to keep it cheap)
David Lang
On Fri, 14 Feb 2003, Davide Libenzi wrote:
> Date: Fri, 14 Feb 2003 17:05:08 -0800 (PST)
> From: Davide Libenzi <[email protected]>
> To: Jamie Lokier <[email protected]>
> Cc: Larry McVoy <[email protected]>, [email protected]
> Subject: Re: openbkweb-0.0
>
> On Sat, 15 Feb 2003, Jamie Lokier wrote:
>
> > Larry McVoy wrote:
> > > But nobody seems willing to stand up and say "well, maybe if we hadn't been
> > > stealing all this music these laws might not have come into existence".
> > >
> > > I'll leave you to make the BitKeeper connection, I'm sure you are smart
> > > enough to do so.
> >
> > On this we agree. Point well made!
> >
> > The best thing for all may be a huge whip round to pay Bitmover enough
> > for them to be _happy_ to open the protocol.
>
> IMHO, Larry does not even need to "open the protocol". He could simply
> release a tool with limited functionalities under a different license.
> Wrong ?
>
>
>
> > Anyone want to start a fund? I offer to donate US$100 (and that's 2
> > weeks income for me ATM).
>
> You might want to pass the above text through 'sed' using s/weeks/hours/ :)
>
>
>
>
> - Davide
>
> -
> 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/
>
actually I think Larry has offered to run such a server, and has even
ofered to pay for the hardware and electricity if others will pay for the
bandwidth.
David Lang
On Fri, 14 Feb 2003, David Lang wrote:
> Date: Fri, 14 Feb 2003 17:13:47 -0800 (PST)
> From: David Lang <[email protected]>
> To: Davide Libenzi <[email protected]>
> Cc: Jamie Lokier <[email protected]>, Larry McVoy <[email protected]>,
> [email protected]
> Subject: Re: openbkweb-0.0
>
> anyone who wants to can setup a bitkeeper server, set it to sync with
> bkbits.net every 5 min and re-export the data (including the SCCS
> formatted metadata) any way they want. Larry has even encouraged people to
> do this.
>
> what he is refusing to do is to pay the cash for the bandwith to support
> this.
>
> I'll volunteer to run such a server so that you purists don't have to get
> your hands dirty by touching bitkeeper, as long as someone else is paying
> the bandwidth and hosting costs (and I'm not requiring a colo facility,
> someone's house with appropriate bandwidth is good enough for me. I'm
> willing to cut any corners that can be cut to keep it cheap)
>
> David Lang
>
>
> On Fri, 14 Feb 2003, Davide Libenzi wrote:
>
> > Date: Fri, 14 Feb 2003 17:05:08 -0800 (PST)
> > From: Davide Libenzi <[email protected]>
> > To: Jamie Lokier <[email protected]>
> > Cc: Larry McVoy <[email protected]>, [email protected]
> > Subject: Re: openbkweb-0.0
> >
> > On Sat, 15 Feb 2003, Jamie Lokier wrote:
> >
> > > Larry McVoy wrote:
> > > > But nobody seems willing to stand up and say "well, maybe if we hadn't been
> > > > stealing all this music these laws might not have come into existence".
> > > >
> > > > I'll leave you to make the BitKeeper connection, I'm sure you are smart
> > > > enough to do so.
> > >
> > > On this we agree. Point well made!
> > >
> > > The best thing for all may be a huge whip round to pay Bitmover enough
> > > for them to be _happy_ to open the protocol.
> >
> > IMHO, Larry does not even need to "open the protocol". He could simply
> > release a tool with limited functionalities under a different license.
> > Wrong ?
> >
> >
> >
> > > Anyone want to start a fund? I offer to donate US$100 (and that's 2
> > > weeks income for me ATM).
> >
> > You might want to pass the above text through 'sed' using s/weeks/hours/ :)
> >
> >
> >
> >
> > - Davide
> >
> > -
> > 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 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/
>
How much bandwidth are we talking about here, actually? I could share SOME
of this burden.
-----Original Message-----
From: [email protected]
[mailto:[email protected]]On Behalf Of David Lang
Sent: Friday, February 14, 2003 7:14 PM
To: Davide Libenzi
Cc: Jamie Lokier; Larry McVoy; [email protected]
Subject: Re: openbkweb-0.0
anyone who wants to can setup a bitkeeper server, set it to sync with
bkbits.net every 5 min and re-export the data (including the SCCS
formatted metadata) any way they want. Larry has even encouraged people to
do this.
what he is refusing to do is to pay the cash for the bandwith to support
this.
I'll volunteer to run such a server so that you purists don't have to get
your hands dirty by touching bitkeeper, as long as someone else is paying
the bandwidth and hosting costs (and I'm not requiring a colo facility,
someone's house with appropriate bandwidth is good enough for me. I'm
willing to cut any corners that can be cut to keep it cheap)
David Lang
On Fri, 14 Feb 2003, Davide Libenzi wrote:
> Date: Fri, 14 Feb 2003 17:05:08 -0800 (PST)
> From: Davide Libenzi <[email protected]>
> To: Jamie Lokier <[email protected]>
> Cc: Larry McVoy <[email protected]>, [email protected]
> Subject: Re: openbkweb-0.0
>
> On Sat, 15 Feb 2003, Jamie Lokier wrote:
>
> > Larry McVoy wrote:
> > > But nobody seems willing to stand up and say "well, maybe if we hadn't
been
> > > stealing all this music these laws might not have come into
existence".
> > >
> > > I'll leave you to make the BitKeeper connection, I'm sure you are
smart
> > > enough to do so.
> >
> > On this we agree. Point well made!
> >
> > The best thing for all may be a huge whip round to pay Bitmover enough
> > for them to be _happy_ to open the protocol.
>
> IMHO, Larry does not even need to "open the protocol". He could simply
> release a tool with limited functionalities under a different license.
> Wrong ?
>
>
>
> > Anyone want to start a fund? I offer to donate US$100 (and that's 2
> > weeks income for me ATM).
>
> You might want to pass the above text through 'sed' using s/weeks/hours/
:)
>
>
>
>
> - Davide
>
> -
> 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/
>
Davide Libenzi wrote:
> > The best thing for all may be a huge whip round to pay Bitmover enough
> > for them to be _happy_ to open the protocol.
>
> IMHO, Larry does not even need to "open the protocol". He could simply
> release a tool with limited functionalities under a different license.
> Wrong ?
That would do nicely.
> > Anyone want to start a fund? I offer to donate US$100 (and that's 2
> > weeks income for me ATM).
>
> You might want to pass the above text through 'sed' using s/weeks/hours/ :)
No, it is weeks. I'm voluntarily doing little paid work so I can
create the best I am able to. My finances suck but I have not written
so much great code for years - and other things too. I highly
recommend the experience if you can do it. Now is a good time :)
-- Jamie
On Fri, 14 Feb 2003, [email protected] wrote:
> How much bandwidth are we talking about here, actually? I could share SOME
> of this burden.
I don't really know, the only figured mentioned is Larry's $15K/month for
the bandwidth that is probably high to begin with, but may end up being
low in the long term.
I think the only way to really tell will be to set it up and measure it.
David Lang
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of David Lang
> Sent: Friday, February 14, 2003 7:14 PM
> To: Davide Libenzi
> Cc: Jamie Lokier; Larry McVoy; [email protected]
> Subject: Re: openbkweb-0.0
>
>
> anyone who wants to can setup a bitkeeper server, set it to sync with
> bkbits.net every 5 min and re-export the data (including the SCCS
> formatted metadata) any way they want. Larry has even encouraged people to
> do this.
>
> what he is refusing to do is to pay the cash for the bandwith to support
> this.
>
> I'll volunteer to run such a server so that you purists don't have to get
> your hands dirty by touching bitkeeper, as long as someone else is paying
> the bandwidth and hosting costs (and I'm not requiring a colo facility,
> someone's house with appropriate bandwidth is good enough for me. I'm
> willing to cut any corners that can be cut to keep it cheap)
>
> David Lang
>
>
> On Fri, 14 Feb 2003, Davide Libenzi wrote:
>
> > Date: Fri, 14 Feb 2003 17:05:08 -0800 (PST)
> > From: Davide Libenzi <[email protected]>
> > To: Jamie Lokier <[email protected]>
> > Cc: Larry McVoy <[email protected]>, [email protected]
> > Subject: Re: openbkweb-0.0
> >
> > On Sat, 15 Feb 2003, Jamie Lokier wrote:
> >
> > > Larry McVoy wrote:
> > > > But nobody seems willing to stand up and say "well, maybe if we hadn't
> been
> > > > stealing all this music these laws might not have come into
> existence".
> > > >
> > > > I'll leave you to make the BitKeeper connection, I'm sure you are
> smart
> > > > enough to do so.
> > >
> > > On this we agree. Point well made!
> > >
> > > The best thing for all may be a huge whip round to pay Bitmover enough
> > > for them to be _happy_ to open the protocol.
> >
> > IMHO, Larry does not even need to "open the protocol". He could simply
> > release a tool with limited functionalities under a different license.
> > Wrong ?
> >
> >
> >
> > > Anyone want to start a fund? I offer to donate US$100 (and that's 2
> > > weeks income for me ATM).
> >
> > You might want to pass the above text through 'sed' using s/weeks/hours/
> :)
> >
> >
> >
> >
> > - Davide
> >
> > -
> > 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 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 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/
>
[email protected] wrote:
> Seriously, it's not like you [Alan] can't work under the
> circumstances - you just refuse to. That's your choice - one I respect.
> Why try to, or even advocate limiting Larry's choices? That seems unfair
> and blatantly hypocritical at best. :-(
Fwiw, even though Larry's offered to special-case Alan, (and presumed
that Alan's doesn't work for anyone other than Red Hat), in private
email Larry made it clear _I_ am not allowed to use Bitkeeper. This
is because I work on scripts which analyse repositories - and even
though I was prepared to limit the scope of that work for a time.
Now I am hardly the high-profile kernel hacker that Alan is.
But that shouldn't matter, should it?
Thanks for not using Word, Alan :)
-- Jamie
On Sat, Feb 15, 2003 at 02:00:44AM +0000, Jamie Lokier wrote:
> [email protected] wrote:
> > Seriously, it's not like you [Alan] can't work under the
> > circumstances - you just refuse to. That's your choice - one I respect.
> > Why try to, or even advocate limiting Larry's choices? That seems unfair
> > and blatantly hypocritical at best. :-(
>
> Fwiw, even though Larry's offered to special-case Alan, (and presumed
> that Alan's doesn't work for anyone other than Red Hat), in private
> email Larry made it clear _I_ am not allowed to use Bitkeeper. This
> is because I work on scripts which analyse repositories - and even
> though I was prepared to limit the scope of that work for a time.
Err, tell the whole story Jamie. You are going down the path of trying
to make CVS work as much as possible like BitKeeper. That's a perfectly
reasonable thing for you to do but we are in no way obligated to help you.
As for Alan, we aren't offering to special case him. We would do what
we have done with any and every other concerned company: we worked out
an agreement which works for both companies and move on. I could really
care less that Red Hat ships CVS and bug fixes it. Where I get unhappy
is if Alan were using BK every day and walking over to the people working
on CVS and saying "you know, BK does this really cool thing, could you
do this?".
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Larry McVoy wrote:
> > Fwiw, even though Larry's offered to special-case Alan, (and presumed
> > that Alan's doesn't work for anyone other than Red Hat), in private
> > email Larry made it clear _I_ am not allowed to use Bitkeeper. This
> > is because I work on scripts which analyse repositories - and even
> > though I was prepared to limit the scope of that work for a time.
>
> Err, tell the whole story Jamie.
As you insist :)
> You are going down the path of trying to make CVS work as much as
> possible like BitKeeper. That's a perfectly reasonable thing for
> you to do but we are in no way obligated to help you.
That seems unlikely, as I have never used Bitkeeper and have no idea
what it is like to use other than anecdotes from the LKML.
Anything I come up with comes from (a) good public ideas from many
sources including you; (b) my own experience with CVS and diff+patch.
Any resemblance to Bitkeeper is a result of "great minds think alike" :)
Besides, there is a huge gulf between browsing and monitoring, and
"going down the path" of a version control system.
My ideas are quite different from yours anyway... (Much more watching
other projects, much less tools for respository mgmt).
I said I'd hold off from considering the programs that, IMHO, are not
like BK at all but which you might not like, for a negotiable time, in
exchange for a BK protocol spec., but you didn't go for it.
(The email I sent you is copied below, for the "whole story". People
are encouraged to draw their own conclusions on whether those ideas
are like Bitkeeper. I don't know, having not used it.)
-- Jamie
Date: Sat, 18 Jan 2003 07:28:07 +0000
From: Jamie Lokier <[email protected]>
To: Larry McVoy <[email protected]>
Larry,
Thanks for your helpful response.
Larry McVoy wrote:
> How about you tell me why it is that you think that you would violate
> 3(d)
I'm working on
(a) a program like cvsview et al. for displaying changeset logs
on a web page and on the command line. It is good at computing
changesets from CVS trees, even though those have to be deduced.
(b) related to above, a program which displays the diffs of checked
in files, like cvsview et al. but it shows whole multi-file changes
(i.e. is useful) rather than singlefile diffs like all the other
CVS-display programs (i.e. not useful at all).
It is also quite pretty, in that syntax colouring and folding
appear on the web page :) You'd like it.
(c) programs which extract data from SCCS and CVS/RCS files, obviously
related to above but could be use for other purposes.
And
(d) I would like (a)-(c) above to be able to interface to a remote
bk repository, in the same way as they can analyse local SCCS/RCS
and remote CVS.
That's a bonus feature, which I expect you'd be least happy with.
It _could_ simply call out to bk itself, though I prefer not.
(You can see why knowing the BK transfer protocol would be useful for _that_)
Perhaps the bk protocol is too complex or variable to do anything
other than call bk, but I would hope not, given the simplicity of the
file format.
I'm not sure whether you'd consider these programs including the (d)
feature to compete with BK-Web or something. To be sure, you can't
actually do version control with them (because they only read, don't
write).
However one day, when I've finished about a million prerequisites for
doing it properly, and if the moon is out, I have these on my plan:
(e) definition tracking, i.e. let person A know whenever definiton of
anything related to B changes in external project C. For example,
email whoever is interested whenever the kernel's VFS locking rules
_might_ have changed, by noting when certain key definitions
have changed in the kernel tree. (That's just an example - the
idea is that a software project might end up tracking hundreds or
more little aspects of other external software projects, so it
can keep up to date with reduced human effort).
(f) patch tracking, not unlike Rusty's trivial patch handler, some
bug+fix tracking software, or any other bug/feature ticketing
system you have heard of.
At that point it's possible we are talking about direct competition
for bk, not a clone (I'm not interested in cloning) but change
management nevertheless. Btw, it's not about politics - like you I've
been thinking about s/w development management tools for years, and
have my own ideas which I simply want to try out.
Though that point is a long way off and may never happen.
So many ideas, so little time, you know how it is :)
----
> and we'll take it from there?
Ok.
[ Note that I won't agree to refrain from reverse engineering the
network protocol, as the price of using BK for free.
Chances are I'll never bother, but it's not something I'd willingly
agree to not do, because I prefer to be not allowed to use BK than to
be effectively bound by an eternal NDA. ]
However, I would be fine to agree that I'll use BK up to the point
where I start work on a certain kind of project, and then stop using
BK, if that would suit you.
An obvious stopping point would be when I wish to develop a program
that does more than just read, display and track information in a
repository. I.e. when I want to add the capability to write.
If you are into complicated agreements, I could even agree a minimum
time between stopping using BK and starting to develop the latter kind
of program.
Or I could agree anything else you can dream up. I'm open to
suggestions. There might some useful business we can do, one day; I'm
not about to throw _that_ chance away.
Thanks again for your constructive response,
-- Jamie
> > Err, tell the whole story Jamie.
>
> As you insist :)
Much as you said, I'm paying you a compliment. I'm sufficiently impressed
with your ability that I don't see it as wise to help you to compete with us.
It may be that I'm just way too worried about all this stuff. That is
probably the case. Running a company, making sure that my people get
paid, making sure we take care of our customers, all of that has made me
extremely conservative and paranoid when it comes to business.
What you guys should get is that I am you. Just a normal guy who somehow
drifted into running a company and is learning by doing. So forgive
me if I get paranoid, this is all new to me and I'm trying hard not
to screw up. The stakes are higher, if I blow it, a bunch of people
don't have jobs and I've allowed my people to live near their families,
I think we have people in 6 states at this point. If I screw up,
they are not going to get the same sort of job where they are living.
I have nice people working for me, I've met their wives, their kids,
they are great people. I screw up, they have a worse life. That's not
your problem, but it is mine and it is part of why I'm such a pain in the
ass here. I'm scared that something bad will happen to this company and
those people will suffer. I live in Silicon Valley, if I were to drop
BitMover and go to work for some other company I would triple my salary.
This isn't about me, it's about the people who work for me and I get
pretty pissed off when I see people doing things which could hurt them.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Saturday 15 February 2003 05:11, Jamie Lokier wrote:
[...]
> [ Note that I won't agree to refrain from reverse engineering the
> network protocol, as the price of using BK for free.
>
> Chances are I'll never bother, but it's not something I'd willingly
> agree to not do, because I prefer to be not allowed to use BK than to
> be effectively bound by an eternal NDA. ]
What makes you think the licence is something like an _eternal_ NDA?
Larry, I've used bitkeeper for a few months to pull linus's and rik's trees
and export them for my own use until about a month ago. I've also tried
using it in a single user repository for contest (the benchmark).
Last week, feeling tempted to dig into arch, I removed all the files from
the bitkeeper installation and I did a search-and-unlink of BitKeeper
directories, just in case.
Do you intend to sue me if I ever submit a patch for cvs/subversion/whatever
(arch kind of sucks:-) or if I feel like starting my own scm project? (while
I think this would be ridiculous I'm not trying to bash you here, it's an
honest question regarding Jamie's comment above)
Aggelos
On Sat, Feb 15, 2003 at 07:00:36AM +0200, Aggelos Economopoulos wrote:
> On Saturday 15 February 2003 05:11, Jamie Lokier wrote:
> [...]
> > [ Note that I won't agree to refrain from reverse engineering the
> > network protocol, as the price of using BK for free.
> >
> > Chances are I'll never bother, but it's not something I'd willingly
> > agree to not do, because I prefer to be not allowed to use BK than to
> > be effectively bound by an eternal NDA. ]
>
> What makes you think the licence is something like an _eternal_ NDA?
>
> Larry, I've used bitkeeper for a few months to pull linus's and rik's trees
> and export them for my own use until about a month ago. I've also tried
> using it in a single user repository for contest (the benchmark).
>
> Last week, feeling tempted to dig into arch, I removed all the files from
> the bitkeeper installation and I did a search-and-unlink of BitKeeper
> directories, just in case.
>
> Do you intend to sue me if I ever submit a patch for cvs/subversion/whatever
> (arch kind of sucks:-) or if I feel like starting my own scm project? (while
> I think this would be ridiculous I'm not trying to bash you here, it's an
> honest question regarding Jamie's comment above)
Nobody wins in a lawsuit, at least not at this level. I don't want to sue
you, that's nuts.
If you continued use BK and were working on an SCM system, yeah, we'd kick
up a fuss. Our position is that it was really hard to produce a system
which doesn't suck and it is a lot easier to copy such a system than it is
to invent one on your own. So we'd prefer you to figure it out on your
own than copy what we have done.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Aggelos Economopoulos wrote:
> On Saturday 15 February 2003 05:11, Jamie Lokier wrote:
> [...]
> > [ Note that I won't agree to refrain from reverse engineering the
> > network protocol, as the price of using BK for free.
> >
> > Chances are I'll never bother, but it's not something I'd willingly
> > agree to not do, because I prefer to be not allowed to use BK than to
> > be effectively bound by an eternal NDA. ]
>
> What makes you think the licence is something like an _eternal_ NDA?
No, no - don't take the license that way.
No, I meant that if Larry and I made an agreement separately from the
standard license, to allow me to use BK... there are some things I
wouldn't agree to. (Conversely there are other things I would).
cheers,
-- Jamie
On Saturday 15 February 2003 07:32, Larry McVoy wrote:
> On Sat, Feb 15, 2003 at 07:00:36AM +0200, Aggelos Economopoulos wrote:
> > On Saturday 15 February 2003 05:11, Jamie Lokier wrote:
> > [...]
> >
> > > [ Note that I won't agree to refrain from reverse engineering the
> > > network protocol, as the price of using BK for free.
> > >
> > > Chances are I'll never bother, but it's not something I'd willingly
> > > agree to not do, because I prefer to be not allowed to use BK than
> > > to be effectively bound by an eternal NDA. ]
> >
> > What makes you think the licence is something like an _eternal_ NDA?
> >
> > Larry, I've used bitkeeper for a few months to pull linus's and rik's
> > trees and export them for my own use until about a month ago. I've also
> > tried using it in a single user repository for contest (the benchmark).
> >
> > Last week, feeling tempted to dig into arch, I removed all the files
> > from the bitkeeper installation and I did a search-and-unlink of
> > BitKeeper directories, just in case.
> >
> > Do you intend to sue me if I ever submit a patch for
> > cvs/subversion/whatever (arch kind of sucks:-) or if I feel like
> > starting my own scm project? (while I think this would be ridiculous
> > I'm not trying to bash you here, it's an honest question regarding
> > Jamie's comment above)
>
> Nobody wins in a lawsuit, at least not at this level. I don't want to
> sue you, that's nuts.
>
> If you continued use BK and were working on an SCM system, yeah, we'd
> kick up a fuss. Our position is that it was really hard to produce a
> system which doesn't suck and it is a lot easier to copy such a system
> than it is to invent one on your own. So we'd prefer you to figure it
> out on your own than copy what we have done.
Which of course doesn't answer my question, but I guess it is only natural
that you want to keep your options open.
Let me just point out that you have given out much more information about
bitkeeper in your mails in lkml than any info one would hope to get by
using bitkeeper (except maybe by dissasembling it). I was familiar with all
the bitkeeper concepts many months before I downloaded it (it's all on the
website) and you have been arguing (successfully) for many of the design
decisions you guys made (weave vs diff, distributed vs centralized etc).
So if I (or anybody else) were to start work on a competing project, I
wouldn't even /feel/ I'm abusing your contribution to the community and
since I've stopped using bitkeeper I'm quite certain I wouldn't be
violating your licence.
Thanks for taking the time to aswer though.
Aggelos
On Saturday 15 February 2003 08:20, Jamie Lokier wrote:
> Aggelos Economopoulos wrote:
> > On Saturday 15 February 2003 05:11, Jamie Lokier wrote:
> > [...]
> >
> > > [ Note that I won't agree to refrain from reverse engineering the
> > > network protocol, as the price of using BK for free.
> > >
> > > Chances are I'll never bother, but it's not something I'd willingly
> > > agree to not do, because I prefer to be not allowed to use BK than
> > > to be effectively bound by an eternal NDA. ]
> >
> > What makes you think the licence is something like an _eternal_ NDA?
>
> No, no - don't take the license that way.
>
> No, I meant that if Larry and I made an agreement separately from the
> standard license, to allow me to use BK... there are some things I
> wouldn't agree to. (Conversely there are other things I would).
Ah, ok, thanks for clarifying.
Aggelos
On Fri, Feb 14, 2003 at 03:57:24PM -0800, Larry McVoy wrote:
> On Fri, Feb 14, 2003 at 11:45:17PM +0000, Jamie Lokier wrote:
> > > Current German copyright law says that any contractual appointments that
> > > disallow the allowed cases of reverse engineering are void.
> >
> > Exactly. He can say it, it's up to you whether you ignore it.
>
> As with many things in life, you can choose to behave well or poorly and
> the people you help or hurt will act according.
>
> The slashdot kiddies, as an example, seemed to think it was OK to swap all
> the music they wanted for free. The music industry responded by helping
> push through the recent round of draconian laws which are much deplored on
> slashdot and here for that matter.
>
> But nobody seems willing to stand up and say "well, maybe if we hadn't been
> stealing all this music these laws might not have come into existence".
>
> I'll leave you to make the BitKeeper connection, I'm sure you are smart
> enough to do so.
In Germany swapping music for free except for limited copies to friends
(for which you pay with every harddisk or CD or CD burner you buy) has
been illegal for _many_ years. The part of current German copyright law
that says that the highest penalty for copyright infringement are three
years in prison is unchanged since 1974.
Current German copyright law says you are allowed to reverse engineer
under certain circumstances a program you are a licensee of to produce
independent programs that interoperate with this proprietary program.
Otherwise it would often be impossible to develop software like Samba
that has to interoperate with proprietary products - how easy would it
be to forbid something like this in the licence terms of the proprietary
program. Since the licensee is often in a very weak position compared to
the company selling the software current German copyright law says that
any contractual appointments that disallow the allowed cases of reverse
engineering are void.
Both rules make sense to me and whether I like them or not I am smart
enough to see the difference between these two cases.
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
> Hey Alan,
> I noticed a typographical error in your message. I thought I'd help you
> out with a correction:
>
> s/"All I want is to be able to review the 3c990 patch. Right now I
> can't"/"All I want is to be able to review the 3c990 patch. Right now I
> can't be bothered to use software that is being offered to me for free
> because it's far more important to get into mindless flamewars over tools
> that make life easier for everyone. Oh, and Stallman is god."
>
> Hope that helps.
If only you'd sent it as a BK changeset... :-)
John.
On Sat, 15 Feb 2003, Adrian Bunk wrote:
> Current German copyright law says you are allowed to reverse engineer
> under certain circumstances a program you are a licensee of to produce
> independent programs that interoperate with this proprietary program.
> Otherwise it would often be impossible to develop software like Samba
> that has to interoperate with proprietary products - how easy would it
> be to forbid something like this in the licence terms of the proprietary
> program. Since the licensee is often in a very weak position compared to
> the company selling the software current German copyright law says that
> any contractual appointments that disallow the allowed cases of reverse
> engineering are void.
Adrian, the key point here is that you are allowed to reverse engineer
anything you are a licensee of.
I'll bet there are also laws preventing a company from refusing to sell a
copy of whatever to someone who would reverse engineer it.
however there's nothing that states that a company that gives free copies
of whatever to a charity they must give a free copy to people who want to
reverse engineer it.
in the case of bitkeeper the 'charity' is opensource software.
Larry will (and probably must) sell a license to whoever wants one and the
most he can do is to refuse to give you any discount above his published
standard rates. Larry does not have to give you a copy of it for free for
the purpose of you reverse engineering it.
under the law you are allowed to reverse engineer anything you have a
legal license to. unless you give bitmover money you do not automaticaly
have a legal license to use bitkeeper if you work on a version control
package or for a company that does. Larry has shown by his actions that he
is willing to make additional licenses available for free in many cases
(all the folks working for redhat who are useing bitkeeper are proof of
that).
yes Larry is being a bit paranoid, but you have to admit that judging from
the posts on the subject there are a lot of people out to get him :-)
David Lang
Larry McVoy <[email protected]> writes:
>Because it costs money for bandwidth. I agree it would be useful, so
>find someone to cough up the $15K/year for the bandwidth and you can
>have the diff interface you want. The code is already written, it has
>been for more than a year, it's simply a money issue.
Over here in "old europe", I can get 1" Rackspace with unlimited
traffic for as little as 50 euros per month. I can even get a managed
server with that for about 100 euros. I can't believe that this is not
possible in the country of "unlimited bandwith" (TM). Talk to the
people at RackShack or drop me a line, so we can arrange something
with a housing provider over here.
This is, after all, the 21st century.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[email protected] +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
On Sat, Feb 15, 2003 at 11:47:45AM +0000, Henning P. Schmiedehausen wrote:
> Linus, please consider this a request to drop BK _right now_ and
> change to another SCM for kernel development. I hate working under a
> threat.
So don't use BK. Why do you care what other people use?
Larry McVoy <[email protected]> writes:
>But nobody seems willing to stand up and say "well, maybe if we hadn't been
>stealing all this music these laws might not have come into existence".
>I'll leave you to make the BitKeeper connection, I'm sure you are smart
>enough to do so.
"If you don't play nice, I'll take the toy (Bitkeeper) away from
you". You start to sound like a quite popular american president now.
Maybe you should send inspectors to all BK users to be sure that they
don't use it to develop weapons of mass^W^W^Wnon free software.
Linus, please consider this a request to drop BK _right now_ and
change to another SCM for kernel development. I hate working under a
threat.
Larry: Sorry, I know that this posting is really rude but I try to
point out the danger of the path you're heading down to.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[email protected] +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
On Sat, 15 February 2003 11:50:22 +0000, Christoph Hellwig wrote:
> On Sat, Feb 15, 2003 at 11:47:45AM +0000, Henning P. Schmiedehausen wrote:
> > Linus, please consider this a request to drop BK _right now_ and
> > change to another SCM for kernel development. I hate working under a
> > threat.
>
> So don't use BK. Why do you care what other people use?
Before:
Linus used some homegrown scripts between releases.
People had no way to look into his machine meanwhile.
Linus accepted patches through email.
After:
Linus uses some non-free tool between releases.
Some people have no way to look into his machine meanwhile.
Linus accepts patches through email.
Don't you see how much better things were before? ;-)
J?rn
--
Courage is not the absence of fear, but rather the judgement that
something else is more important than fear.
-- Ambrose Redmoon
Christoph Hellwig <[email protected]> writes:
>On Sat, Feb 15, 2003 at 11:47:45AM +0000, Henning P. Schmiedehausen wrote:
>> Linus, please consider this a request to drop BK _right now_ and
>> change to another SCM for kernel development. I hate working under a
>> threat.
>So don't use BK. Why do you care what other people use?
Hey, I heard that before when I was still doing non-Intel platform
development. "Why do you care that all of your friends start using
Windows. Just do your own stuff and ignore everything else".
You actually might want to consider caring what the people around you
do and use because at one point it might affect you and then you can
only look back and say "if I'd only known that two years ago, I'd be
able to make a change". [1]
No, I won't pull any political or historical references in here at
that point. That's for everyone else to do.
Regards
Henning
[1] Ok, I couldn't resist. For the germans in the audience: If we'd
only known on 9/22 what we know now...
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[email protected] +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
I don't believe you (about the unlimited bandwidth)
I have to pay ?2,000 per month for unlimited bandwidth on a 10Mbps port
and a whopping ?15,000 per month (which is an awful lot of euros) for
unlimited use of a 100Mbps port
So either I'm being *very* stupid or you're wrong
Andrew Walrond
Henning P. Schmiedehausen wrote:
> Larry McVoy <[email protected]> writes:
>
>
>>Because it costs money for bandwidth. I agree it would be useful, so
>>find someone to cough up the $15K/year for the bandwidth and you can
>>have the diff interface you want. The code is already written, it has
>>been for more than a year, it's simply a money issue.
>
>
> Over here in "old europe", I can get 1" Rackspace with unlimited
> traffic for as little as 50 euros per month. I can even get a managed
> server with that for about 100 euros. I can't believe that this is not
> possible in the country of "unlimited bandwith" (TM). Talk to the
> people at RackShack or drop me a line, so we can arrange something
> with a housing provider over here.
>
> This is, after all, the 21st century.
>
> Regards
> Henning
>
On Sat, Feb 15, 2003 at 12:39:51AM +0000, Jamie Lokier wrote:
> Imagine if all your friends started talking a different language,
> called Binglish say. You'd want to talk to them in that language so
> you could socialise and work with them. Now if they told you you must
> sign a contract and join a private society, or pay significant cash,
> otherwise you couldn't talk the language? If it were a few people
> you'd ignore them, but if it seemed like all the really powerful
> people who affect your life would just ignore you unless you talked
> it, you'd be pissed off. You'd feel the playing field had become
> unlevel and needed correction. You'd be tempted to either (1) cave in
> and pay or join the private society, (2) learn the language and
> use it anyway.
nice comparison.
However my short term concern is not to speak Binglish but just to
translate from Binglish to English. We need access to the data with an
open protocol and to backup the data in a open format. so we can use it
too. And Larry is now going to provide the data in the open, IMHO only
if that didn't happen we had to research into the possibility of legally
reverse enegeneering the bitkeeper protocol. the fact he is now
providing the data out in the open avoids us to waste time.
After we can reach the data we can use any version control system we
want to manage it, I'm going to write MORE STUPID scripts to do that.
I'm been told of several giga archives with dozen thousand revisions
under subversion for istance (I know Al Viro blamed subversion code but
if the design it's good it may be a good start). subversion may not
have all the features of bitkeeper but we can certainly add them over
time, the only thing it matters to me is that we get rid of being forced
to use a proprietary protocol to fetch the data.
The kernel CVS in more than enough for my/our needs and I thank Larry
for seeing it was necessary to allow the kernel data to be open. Now
there's no reason to argue anymore with Larry or Linus, they can choose
what they can legally use and we can choose what we can legally use and
what we find more productive in the long run. I really believe in open
protocols and open source software being superior and a necessary thing
in the long run, it's not that I advocate people to use open source
products and then I change my mind and I run proprietary apps to develop
the kernel (I don't put a smile here because clearly this isn't an
obvious thought).
Andrea
On Sat, Feb 15, 2003 at 01:07:21PM +0100, J?rn Engel wrote:
> Linus uses some non-free tool between releases.
> Some people have no way to look into his machine meanwhile.
that's wrong. everyone can subscribe to the commits list, and
every one can use the snapshots on kernel.org that are generate
frequently (ever 30 minutes?, dunno..)
On Sat, Feb 15, 2003 at 12:10:24PM +0000, Henning P. Schmiedehausen wrote:
> Christoph Hellwig <[email protected]> writes:
>
> >On Sat, Feb 15, 2003 at 11:47:45AM +0000, Henning P. Schmiedehausen wrote:
> >> Linus, please consider this a request to drop BK _right now_ and
> >> change to another SCM for kernel development. I hate working under a
> >> threat.
>
> >So don't use BK. Why do you care what other people use?
>
> Hey, I heard that before when I was still doing non-Intel platform
> development. "Why do you care that all of your friends start using
> Windows. Just do your own stuff and ignore everything else".
>
> You actually might want to consider caring what the people around you
> do and use because at one point it might affect you and then you can
> only look back and say "if I'd only known that two years ago, I'd be
> able to make a change". [1]
What is the particular problem for you that some kernel developers _do_
use BitKeeper. What got worse to you over the old-style prepatches?
On Fri, 14 Feb 2003, Larry McVoy wrote:
> As with many things in life, you can choose to behave well or poorly and
> the people you help or hurt will act according.
Larry,
Aren't you tired of all this shit people are making of BK?
You will always have people bitching at you just like people are bitching at
Microsoft Word, whether those people are morons or great hackers is
irrelevant.
Be smart and put a Linux CVS repository on bkbits.net even if it costs you
some bandwidth money at first, oh and have the CVS repo to be always in sync
with the bk repo of course. This way you'll be able to tune the process,
make sure it can be fully automated, then everybody will be happy and you'll
sleep in peace for a while.
Then, to handle the bandwidth/money issue, you just need to put bandwidth
limiting on the CVS port (Linux can do that so well - just ask for help if
you can't achieve it) and issue a call for mirror sites where bkbits.net
could commit CVS changes to. Right now BitKeeper might have solved the
Linux development process scalability issue (from the community toward
Linus), but for the process to be perfect you also need to address the
opposite path i.e. the broadcasting of changes that Linus applied toward
the community, and this has to happen in real time as well.
We can agree that BitKeeper is so superior to CVS just like M$ Word format
is way more powerful than plain text [1]. The reality is that plain text
files are just so portable and universally readable that they are preferable
to the Word format, even if M$ is giving Word viewers away for free.
You can't change the Free Software world that you are so faithfully trying
to help. You still can make them happy, and for that a real-time gateway
from the Linux bk to CVS repos is the only way for the present time. CVS is
still the lowest common denominator SCM among this world and you can't
ignore it for broadcasting changes back to the community.
Nicolas
[1] this doesn't mean that I personally endorse M$ Word in any way.
All of this sounds great and is exactly what is already the plan.
There is one missing item. A consensus in the community that if we
provide BK, the CVS mirror, bkbits hosting, in return the community
agrees to leave off using BK to copy BK.
If what is being asked of us is more free service and engineering and
we are getting nothing in return, that's a non-starter.
So we'll wait to see what the community says. In this particular
instance, the open source community has a choice. We've granted people
the free use of our tools, unlike any other company. If the response
is going to be "hey, cool, now it's even easier to copy these tools"
then (a) we're idiots and (b) we're not going to follow that up with
more free services.
Make up your mind as to what you want as a community and let me know.
I know what you want is a GPLed BK. That's not on the table. You don't
have one and you can't produce one any time soon, it would take years,
ask the Subversion guys or the arch guys or anyone you like, this isn't a
matter of some perl scripts and a weekend hack. So until someone produces
a viable alternative, you can have or not have BK to use, depending on
your behaviour. I'd love to reach a compromise which leaves all parties
happy. You want free access to the data in real time, I want you to
leave us a chance to grow our business. If you want to have access to
the data in CVS and you want to be free to go clone BK and you want to
be free to go use BK without charge, that's asking way too much.
One answer, maybe the only viable answer, is to use patents to protect
our technology. To date we've been very sparing in where we have done
that, there are substantial chunks of BK without patent protection. Some
leaders in the kernel group have privately told me to not ship BK without
patent protection. That slows down how fast you get a better BK, it's not
something we can just wave our hands and make be so, it's lots of time and
money. A single patent costs more than enough bandwidth to keep all of
you happy for a year. Whatever. If you guys can't come to some sort
of consensus, then patents are the route we'll choose, even German law
respects patents.
On Sat, Feb 15, 2003 at 12:44:34PM -0500, Nicolas Pitre wrote:
> On Fri, 14 Feb 2003, Larry McVoy wrote:
>
> > As with many things in life, you can choose to behave well or poorly and
> > the people you help or hurt will act according.
>
> Larry,
>
> Aren't you tired of all this shit people are making of BK?
>
> You will always have people bitching at you just like people are bitching at
> Microsoft Word, whether those people are morons or great hackers is
> irrelevant.
>
> Be smart and put a Linux CVS repository on bkbits.net even if it costs you
> some bandwidth money at first, oh and have the CVS repo to be always in sync
> with the bk repo of course. This way you'll be able to tune the process,
> make sure it can be fully automated, then everybody will be happy and you'll
> sleep in peace for a while.
>
> Then, to handle the bandwidth/money issue, you just need to put bandwidth
> limiting on the CVS port (Linux can do that so well - just ask for help if
> you can't achieve it) and issue a call for mirror sites where bkbits.net
> could commit CVS changes to. Right now BitKeeper might have solved the
> Linux development process scalability issue (from the community toward
> Linus), but for the process to be perfect you also need to address the
> opposite path i.e. the broadcasting of changes that Linus applied toward
> the community, and this has to happen in real time as well.
>
> We can agree that BitKeeper is so superior to CVS just like M$ Word format
> is way more powerful than plain text [1]. The reality is that plain text
> files are just so portable and universally readable that they are preferable
> to the Word format, even if M$ is giving Word viewers away for free.
>
> You can't change the Free Software world that you are so faithfully trying
> to help. You still can make them happy, and for that a real-time gateway
> from the Linux bk to CVS repos is the only way for the present time. CVS is
> still the lowest common denominator SCM among this world and you can't
> ignore it for broadcasting changes back to the community.
>
>
> Nicolas
>
>
> [1] this doesn't mean that I personally endorse M$ Word in any way.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
> if you guys can't come to some sort of consensus, then patents are the
> route we'll choose, even German law respects patents.
Software is not patentable in Europe right now, much as it pisses of the
patent office of the US of A (because it lowers the value of what they
offer) and the EU patent offices (for much the same reasons).
Note that won't stop EU patent offices granting (and being paid for)
software patents *now* for people that hope they'll be worth something
later.
Please do not go the software patent route. If you think the current bk
? debate ? stinks, just wait till you put your finger in another hot
issue (which software patents *are* in Europe, 'cos lots of people don't
want the EU to follows the same braindamaged path as the USA).
You'll just shoot yourself in the foot. The shortcomings of CVS didn't
spurn any serious free alternative for years, this won't change any time
soon unless you start waving a red flag in front of everyone. Just
provide any sort of CVS gateway, and most people will go back hacking
elsewhere.
You did know creating bk would be an incentive for others to write
similar free tools didn't you ? All patents/NDAs/legal threats won't
change this fact. They'll only wipe out all the genuine goodwill you
earned in the community by helping Linus. Just look at the latest
messages, by invoquing all the stupid american legalese you've only
managed to startle people in other parts of the world.
Right now inertia is your friend. Be smart and stop making a fuss.
Regards,
--
Nicolas Mailhot
On Sat, 2003-02-15 at 18:12, Larry McVoy wrote:
> All of this sounds great and is exactly what is already the plan.
> There is one missing item. A consensus in the community that if we
> provide BK, the CVS mirror, bkbits hosting, in return the community
> agrees to leave off using BK to copy BK.
The community is an amorphous thing so thats tricky to define
For general kernel stuff I think a lot of people may not know that Rik
van Riel is generating 2 hourly diff sets between Linus tagged releases
and the head of the BK tree. So for the general "give me Linus kernel
right now case" - the big bandwidth eater its probably a lot simpler
for Larry to say "its on ftp.nl.linux.org" than waste time on code
--
Alan Cox <[email protected]>
The amazing thing to me is that I don't see Larry making any threats. It's
more like pleading "Please let us continue to do this great thing, and don't
torpedo my company out of some misguided idea that BK should be free just
because you don't want to have to pay for it."
On Sat, Feb 15, 2003 at 08:44:59PM +0000, Alan Cox wrote:
> On Sat, 2003-02-15 at 18:12, Larry McVoy wrote:
> > All of this sounds great and is exactly what is already the plan.
> > There is one missing item. A consensus in the community that if we
> > provide BK, the CVS mirror, bkbits hosting, in return the community
> > agrees to leave off using BK to copy BK.
>
> The community is an amorphous thing so thats tricky to define
You're right, I thought of that after I posted. What would probably
work best is if someone who was not particularly BK friendly but
is acknowledged as a Linux leader were to step forward and agree to
represent the community interests. Know anyone like that? Hint,
Alan, look in the mirror :)
Then I and this person try and hammer out some sort of compromise.
It's clear from the fuss this causes about every three weeks that people
don't feel safe, on either side. You're scared that we're going to do
some evil thing and we're scared that you are going to do evil thing.
Maybe it's not possible, but it would be nice if we could, operating in
good faith, work out some sort of agreement that made sense. Yeah, I
know it isn't binding, that the best you could do on the community side is
have a bunch of people stand up and say "hey, leave BitMover alone, they
are doing a good service" but I'd take that over the current mess any day.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Andrea, since the on-disk format for bitkeeper is supposed to be SCCS
would it be good enough for you to be able to get a copy of this? what
mechanism would you prefer to use to get updates (rsync, FTP, HTTP, etc)
David Lang
On Sat, 15 Feb 2003, Andrea Arcangeli wrote:
> Date: Sat, 15 Feb 2003 17:18:21 +0100
> From: Andrea Arcangeli <[email protected]>
> To: Jamie Lokier <[email protected]>
> Cc: Thomas Molina <[email protected]>, [email protected],
> Alan Cox <[email protected]>
> Subject: Re: openbkweb-0.0
>
> On Sat, Feb 15, 2003 at 12:39:51AM +0000, Jamie Lokier wrote:
> > Imagine if all your friends started talking a different language,
> > called Binglish say. You'd want to talk to them in that language so
> > you could socialise and work with them. Now if they told you you must
> > sign a contract and join a private society, or pay significant cash,
> > otherwise you couldn't talk the language? If it were a few people
> > you'd ignore them, but if it seemed like all the really powerful
> > people who affect your life would just ignore you unless you talked
> > it, you'd be pissed off. You'd feel the playing field had become
> > unlevel and needed correction. You'd be tempted to either (1) cave in
> > and pay or join the private society, (2) learn the language and
> > use it anyway.
>
> nice comparison.
>
> However my short term concern is not to speak Binglish but just to
> translate from Binglish to English. We need access to the data with an
> open protocol and to backup the data in a open format. so we can use it
> too. And Larry is now going to provide the data in the open, IMHO only
> if that didn't happen we had to research into the possibility of legally
> reverse enegeneering the bitkeeper protocol. the fact he is now
> providing the data out in the open avoids us to waste time.
>
> After we can reach the data we can use any version control system we
> want to manage it, I'm going to write MORE STUPID scripts to do that.
> I'm been told of several giga archives with dozen thousand revisions
> under subversion for istance (I know Al Viro blamed subversion code but
> if the design it's good it may be a good start). subversion may not
> have all the features of bitkeeper but we can certainly add them over
> time, the only thing it matters to me is that we get rid of being forced
> to use a proprietary protocol to fetch the data.
>
> The kernel CVS in more than enough for my/our needs and I thank Larry
> for seeing it was necessary to allow the kernel data to be open. Now
> there's no reason to argue anymore with Larry or Linus, they can choose
> what they can legally use and we can choose what we can legally use and
> what we find more productive in the long run. I really believe in open
> protocols and open source software being superior and a necessary thing
> in the long run, it's not that I advocate people to use open source
> products and then I change my mind and I run proprietary apps to develop
> the kernel (I don't put a smile here because clearly this isn't an
> obvious thought).
>
> Andrea
> -
> 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, 15 Feb 2003, Larry McVoy wrote:
> Make up your mind as to what you want as a community and let me know.
> I know what you want is a GPLed BK. That's not on the table. You don't
> have one and you can't produce one any time soon, it would take years,
> ask the Subversion guys or the arch guys or anyone you like, this isn't a
> matter of some perl scripts and a weekend hack. So until someone produces
> a viable alternative, you can have or not have BK to use, depending on
> your behaviour. I'd love to reach a compromise which leaves all parties
> happy. You want free access to the data in real time, I want you to
> leave us a chance to grow our business. If you want to have access to
> the data in CVS and you want to be free to go clone BK and you want to
> be free to go use BK without charge, that's asking way too much.
Larry, I already said this and maybe you missed it ( or maybe not ).
What about having a GPLed ( or whatever other license ), read-only BK
available for the ones that simply need to fetch stuff from BK
repositories ? You don't have to maintain another repository for
compatibility, and also you enforce BK usage.
- Davide
On Sat, Feb 15, 2003 at 01:56:02PM -0800, Davide Libenzi wrote:
> Larry, I already said this and maybe you missed it ( or maybe not ).
> What about having a GPLed ( or whatever other license ), read-only BK
> available for the ones that simply need to fetch stuff from BK
> repositories ? You don't have to maintain another repository for
> compatibility, and also you enforce BK usage.
We're not going to expose the network protocol. For two reasons:
- it works really well (we're proud of this)
- it is really ugly (we're not proud of this :)
A read only client isn't read only, it has to be read/write to update the
out of date copy.
Believe me, if there was an easy way to give away a version that was not
a problem we would have long since done that.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Sat, 15 Feb 2003, Larry McVoy wrote:
> On Sat, Feb 15, 2003 at 01:56:02PM -0800, Davide Libenzi wrote:
> > Larry, I already said this and maybe you missed it ( or maybe not ).
> > What about having a GPLed ( or whatever other license ), read-only BK
> > available for the ones that simply need to fetch stuff from BK
> > repositories ? You don't have to maintain another repository for
> > compatibility, and also you enforce BK usage.
>
> We're not going to expose the network protocol. For two reasons:
> - it works really well (we're proud of this)
> - it is really ugly (we're not proud of this :)
>
> A read only client isn't read only, it has to be read/write to update the
> out of date copy.
I was meaning read-only for the repository point of view. Ok, you don't
need to give away the protocol. You don't even have to give away source
code. Why don't you choose a binary license that removes things that ppl
are against of here ?
- Davide
Larry,
>From reading this thread, and the similar ones that have preceeded it,
it seems to me that most people are not exactly bothered about using
the SCM functionality of BitKeeper, but just want to get the
up-to-the-second changes to Linus' tree.
I always thought that that is what the bk-commit mailing lists were
for? I could be wrong about that, not having used BitKeeper - if so,
what are they for, and would it not be possible to simply have a
mailing list which got sent a diff every time Linus' updated his tree?
Then people could just filter the mail from that list in to a script
that patched their local copy of the tree.
John.
John Bradford <[email protected]> wrote:
>
> Larry,
>
> >From reading this thread, and the similar ones that have preceeded it,
> it seems to me that most people are not exactly bothered about using
> the SCM functionality of BitKeeper, but just want to get the
> up-to-the-second changes to Linus' tree.
Yup.
> I always thought that that is what the bk-commit mailing lists were
> for? I could be wrong about that, not having used BitKeeper - if so,
> what are they for, and would it not be possible to simply have a
> mailing list which got sent a diff every time Linus' updated his tree?
The latest diff against the last-released kernel is always available
at http://www.kernel.org/pub/linux/kernel/v2.5/testing/cset/
"Gzipped full patch from ..."
> > I always thought that that is what the bk-commit mailing lists were
> > for? I could be wrong about that, not having used BitKeeper - if so,
> > what are they for, and would it not be possible to simply have a
> > mailing list which got sent a diff every time Linus' updated his tree?
>
> The latest diff against the last-released kernel is always available
> at http://www.kernel.org/pub/linux/kernel/v2.5/testing/cset/
>
> "Gzipped full patch from ..."
So it's perfectly possible to poll
http://www.kernel.org/pub/linux/kernel/v2.5/testing/cset/ every half
hour or so, run it through:
/HREF="(.*)">Gzippped full patch/
retrieve $1, download it, then gzip -dc /tmp/latest_changeset.gz patch
-p1
John.
On Sat, 15 Feb 2003 22:44:39 +0000 (GMT)
John Bradford <[email protected]> wrote:
> > > I always thought that that is what the bk-commit mailing lists were
> > > for? I could be wrong about that, not having used BitKeeper - if so,
> > > what are they for, and would it not be possible to simply have a
> > > mailing list which got sent a diff every time Linus' updated his tree?
> >
> > The latest diff against the last-released kernel is always available
> > at http://www.kernel.org/pub/linux/kernel/v2.5/testing/cset/
> >
> > "Gzipped full patch from ..."
>
> So it's perfectly possible to poll
> http://www.kernel.org/pub/linux/kernel/v2.5/testing/cset/ every half
> hour or so,
Well, the diff is made daily, at some relatively early time during the
morning in one of the time zones continental US is in. I think it's 4am
GMT -0800, but I could be wrong.
Matt
> > > > I always thought that that is what the bk-commit mailing lists were
> > > > for? I could be wrong about that, not having used BitKeeper - if so,
> > > > what are they for, and would it not be possible to simply have a
> > > > mailing list which got sent a diff every time Linus' updated his tree?
> > >
> > > The latest diff against the last-released kernel is always available
> > > at http://www.kernel.org/pub/linux/kernel/v2.5/testing/cset/
> > >
> > > "Gzipped full patch from ..."
> >
> > So it's perfectly possible to poll
> > http://www.kernel.org/pub/linux/kernel/v2.5/testing/cset/ every half
> > hour or so,
>
> Well, the diff is made daily, at some relatively early time during the
> morning in one of the time zones continental US is in. I think it's 4am
> GMT -0800, but I could be wrong.
Are you sure? At the moment, the latest changeset is 1.1027, made at
12:49:07 -08:00 today. That's just under four hours ago.
In any case, it would be better not to have to poll a website to get
updates, but have them actively delivered by smtp, which brings us
back to what I first suggested:
Why can't we have a mailing list that sends out a diff for each
update?
That way, all you need is:
:0
* ^X-Mailing-List: up-to-the-second-linux-patches
| /usr/local/bin/apply_patches
and
#!/bin/sh
cd /usr/src/linux-current
cat | patch -p1
mail $username
John,
> Why can't we have a mailing list that sends out a diff for each
> update?
>
> That way, all you need is:
>
> :0
> * ^X-Mailing-List: up-to-the-second-linux-patches
> | /usr/local/bin/apply_patches
>
> and
>
> #!/bin/sh
> cd /usr/src/linux-current
> cat | patch -p1
> mail $username
Sorry, I meant just:
#!/bin/sh
cd /usr/src/linux-current
cat | patch -p1
John.
> Why can't we have a mailing list that sends out a diff for each
> update?
You can, just get Linus to add a trigger to his tree to do so.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Sat, 15 Feb 2003, Larry McVoy wrote:
> On Sat, Feb 15, 2003 at 08:44:59PM +0000, Alan Cox wrote:
> > On Sat, 2003-02-15 at 18:12, Larry McVoy wrote:
> > > All of this sounds great and is exactly what is already the plan.
> > > There is one missing item. A consensus in the community that if we
> > > provide BK, the CVS mirror, bkbits hosting, in return the community
> > > agrees to leave off using BK to copy BK.
> >
> > The community is an amorphous thing so thats tricky to define
>
> You're right, I thought of that after I posted. What would probably
> work best is if someone who was not particularly BK friendly but
> is acknowledged as a Linux leader were to step forward and agree to
> represent the community interests.
Larry, what you ask is impossible.
This community isn't hierarchized and is unlikely to form a single opinion
on anything like corporate politics. No one can be authoritative of
everybody else's opinion.
It doesn't work in a pull model either where you ask for things. Rather,
you must push things and see how it goes, how people react.
> It's clear from the fuss this causes about every three weeks that people
> don't feel safe, on either side. You're scared that we're going to do
> some evil thing and we're scared that you are going to do evil thing.
That might be true, but I think the BK opponents from the community are more
concerned by preserving their "freedom" (or ability) to access the
up-to-the-minute changes that appeared in the official kernel reference
repository, and without being forced to use a proprietary tool with a
proprietary protocol and with restrictive license terms. I really think it
has nothing to do with BK itself beside the fact that it's BK that is used
to handle the data they cherish so much and no "free" path currently exists
to that data. Even if hourly snapshots do exist, that still makes those
people sort of second class citizens. They want the changes available to
them in real time but in the most purist free way too. The best answer is a
CVS gateway IMHO, and then the true believers, or those who simply can't
comply with your license for all sort of good and legitimate reasons, won't
have anything against you from that moment since they won't see BK as an
obstacle in the way.
If a real time CVS gateway exists, and bkbits.net is pushing CVS commits to
kernel.org and linux.org.uk just to name those few obvious examples among
others, then individuals within this community will have the choice between
many tools according to their respective characteristics and not based on the
quality of service with regards to the kernel repository.
Only then people won't be able to invoke the BitMover lock-in argument
against the Linux community (regardless if that was your intention or not),
and only then will you be able to consider those who try to reverse-engineer
your "technology" as bad people, since invoking fair use will then be much
harder to legitimate.
In other words, if people can have real time change sets to the reference
kernel and have the possibility of ignoring you and BK entirely at the same
time, only then the issue will be closed.
> Maybe it's not possible, but it would be nice if we could, operating in
> good faith, work out some sort of agreement that made sense. Yeah, I
> know it isn't binding, that the best you could do on the community side is
> have a bunch of people stand up and say "hey, leave BitMover alone, they
> are doing a good service" but I'd take that over the current mess any day.
You are doing the best you can in the terms you chose, and a lot of people
including myself are extremely grateful. Your terms are just totally
incompatible with the view of some people. And many of those people just
don't like what you do and they _never_ will, that's a simple fact of life.
Your only way out is to provide a mechanism that will allow them to totally
ignore you without impairing their access to the kernel development data.
BK might be way ahead at what it does, but real-time access to the kernel
repository must _not_ be among the advantages of BK against competitor
products/solutions.
Nicolas
On Sun, 2003-02-16 at 03:23, Larry McVoy wrote:
> > Why can't we have a mailing list that sends out a diff for each
> > update?
>
> You can, just get Linus to add a trigger to his tree to do so.
He did, the list exists 8)
Ok, as I see it there are two different groups wanting access to this
stuff without useing bitkeeper.
1. people who want to get a copy of that the kernel looks like right NOW
for who the currently hourly diffs and mailing list of patch submissions
isn't good enough.
These people want CVS/rsync access to the files, cut could probably be
satisfied with FTP/HTTP access and appropriate mirroring software.
2. people who can't/won't use bitkeeper but who want not only the
resulting files, but also all the underlying change history info.
This info is stored in SCCS format so just getting a current copy of the
tree including the SCCS directories should be good enough to satisfy them
and they can then run all the normal SCCS tools to access the info.
can the SCCS stuff be exported through CVS or do these people need some
other mechanism to get them?
after my offer to admin a mirror of bkbits that provides access through
ohter mechanisms I have been contacted by some people willing to provide
the server/bandwidth to host such a system and we are discussing the
details of how this will be setup so now the question is what services do
people need from such a mirror?
On the basis that it's easier to provide everything rather then to
convince people to change tools :-) here is what I'm thinking of (all of
these obviously read-only)
CVS
rsync
FTP
HTTP
is there anything else people want?
all of these would provide access to the raw files in the tree(s), none of
these will provide tarballs (if you want those contact the people who are
already hosting such services and live with the timelag)
David Lang
On Sat, 15 Feb 2003, Nicolas Pitre wrote:
> Date: Sat, 15 Feb 2003 23:08:58 -0500 (EST)
> From: Nicolas Pitre <[email protected]>
> To: Larry McVoy <[email protected]>
> Cc: Alan Cox <[email protected]>, lkml <[email protected]>
> Subject: Re: openbkweb-0.0
>
> On Sat, 15 Feb 2003, Larry McVoy wrote:
>
> > On Sat, Feb 15, 2003 at 08:44:59PM +0000, Alan Cox wrote:
> > > On Sat, 2003-02-15 at 18:12, Larry McVoy wrote:
> > > > All of this sounds great and is exactly what is already the plan.
> > > > There is one missing item. A consensus in the community that if we
> > > > provide BK, the CVS mirror, bkbits hosting, in return the community
> > > > agrees to leave off using BK to copy BK.
> > >
> > > The community is an amorphous thing so thats tricky to define
> >
> > You're right, I thought of that after I posted. What would probably
> > work best is if someone who was not particularly BK friendly but
> > is acknowledged as a Linux leader were to step forward and agree to
> > represent the community interests.
>
> Larry, what you ask is impossible.
>
> This community isn't hierarchized and is unlikely to form a single opinion
> on anything like corporate politics. No one can be authoritative of
> everybody else's opinion.
>
> It doesn't work in a pull model either where you ask for things. Rather,
> you must push things and see how it goes, how people react.
>
> > It's clear from the fuss this causes about every three weeks that people
> > don't feel safe, on either side. You're scared that we're going to do
> > some evil thing and we're scared that you are going to do evil thing.
>
> That might be true, but I think the BK opponents from the community are more
> concerned by preserving their "freedom" (or ability) to access the
> up-to-the-minute changes that appeared in the official kernel reference
> repository, and without being forced to use a proprietary tool with a
> proprietary protocol and with restrictive license terms. I really think it
> has nothing to do with BK itself beside the fact that it's BK that is used
> to handle the data they cherish so much and no "free" path currently exists
> to that data. Even if hourly snapshots do exist, that still makes those
> people sort of second class citizens. They want the changes available to
> them in real time but in the most purist free way too. The best answer is a
> CVS gateway IMHO, and then the true believers, or those who simply can't
> comply with your license for all sort of good and legitimate reasons, won't
> have anything against you from that moment since they won't see BK as an
> obstacle in the way.
>
> If a real time CVS gateway exists, and bkbits.net is pushing CVS commits to
> kernel.org and linux.org.uk just to name those few obvious examples among
> others, then individuals within this community will have the choice between
> many tools according to their respective characteristics and not based on the
> quality of service with regards to the kernel repository.
>
> Only then people won't be able to invoke the BitMover lock-in argument
> against the Linux community (regardless if that was your intention or not),
> and only then will you be able to consider those who try to reverse-engineer
> your "technology" as bad people, since invoking fair use will then be much
> harder to legitimate.
>
> In other words, if people can have real time change sets to the reference
> kernel and have the possibility of ignoring you and BK entirely at the same
> time, only then the issue will be closed.
>
> > Maybe it's not possible, but it would be nice if we could, operating in
> > good faith, work out some sort of agreement that made sense. Yeah, I
> > know it isn't binding, that the best you could do on the community side is
> > have a bunch of people stand up and say "hey, leave BitMover alone, they
> > are doing a good service" but I'd take that over the current mess any day.
>
> You are doing the best you can in the terms you chose, and a lot of people
> including myself are extremely grateful. Your terms are just totally
> incompatible with the view of some people. And many of those people just
> don't like what you do and they _never_ will, that's a simple fact of life.
> Your only way out is to provide a mechanism that will allow them to totally
> ignore you without impairing their access to the kernel development data.
> BK might be way ahead at what it does, but real-time access to the kernel
> repository must _not_ be among the advantages of BK against competitor
> products/solutions.
>
>
> Nicolas
>
> -
> 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, 15 Feb 2003, David Lang wrote:
> On the basis that it's easier to provide everything rather then to
> convince people to change tools :-) here is what I'm thinking of (all of
> these obviously read-only)
>
> CVS
> rsync
> FTP
> HTTP
>
> is there anything else people want?
If you can manage to have a CVS repository that is always updated to the
minute with full history info etc. then this should be suficient to satisfy
all needs. Public CVS repositories are common enough so people should know
how to use them already.
The best would be a few of those scattered around the world so things do
scale. It shouldn't be that much bandwidth for bkbits.net to update them
all automatically for example.
Nicolas
On Sat, Feb 15, 2003 at 10:11:20PM +0000, John Bradford wrote:
>
> From reading this thread, and the similar ones that have preceeded it,
> it seems to me that most people are not exactly bothered about using
> the SCM functionality of BitKeeper, but just want to get the
> up-to-the-second changes to Linus' tree.
Seems a fairly accurate analysis...
> I always thought that that is what the bk-commit mailing lists were
> for? I could be wrong about that, not having used BitKeeper - if so,
> what are they for, and would it not be possible to simply have a
> mailing list which got sent a diff every time Linus' updated his tree?
... but the solution is not sufficient. What about people wanting to track
one of the ppc[1] trees? What about Alan wanting to get at that 3cr990
which was in a bk repository only before he asked for another format? What
about...?
The only real way to solve this with mailinglists is for the mailinglists
to be run by BitMover, for every repository they host. I doubt they like
that idea.
I'm not using bk to get at patches out of principle, but I can't be
bothered enough to get into arguments about what Larry must or mustn't do.
And it's mostly true that bitkeeper usage may not have really made the
situation worse. But it has improved the situation for people who do use
it while leaving the rest out in the cold, creating inequality among Linux
users and developers. Larry shouldn't be surprised to get flak for that,
regardless of what his intentions are.
Regards,
Filip
[1] There is a linuxppc-commit list I was recently told, but it turns out
to be a comments-only list so it isn't useful for this. And there are
rsync trees, but they are weeks out of date wrt the bk trees most of
the time - and when Apple releases new hardware it's often necessary
in the beginning to run the very last benh kernel for it to work.
--
"Much blood has been spilled as a result of arguments about how many buttons
a mouse ought to have. Naive users prefer one (it is hard to push te wrong
button if there is only one), but sophisticated ones like the power of
multiple buttons to do fancy things."
-- Andrew S. Tanenbaum, `Structured Computer Organization'
Le sam 15/02/2003 ? 21:42, [email protected] a ?crit :
> The amazing thing to me is that I don't see Larry making any threats. It's
> more like pleading "Please let us continue to do this great thing, and don't
> torpedo my company out of some misguided idea that BK should be free just
> because you don't want to have to pay for it."
Larry is asking for assurances he obviously can't get, else he'll
regrettably have to do [lots of things generally frown upon in the
community]
Which is why I advised him to cool down (despite me being in position to
profit from a free bk clone creation like lots of other people). It's
painful to see him feed the flamewars after all the good work he's done.
And i'm sure that being the smart guy he is, he knows it. He just can't
help himself:(.
Regards,
--
Nicolas Mailhot
> > > Why can't we have a mailing list that sends out a diff for each
> > > update?
> >
> > You can, just get Linus to add a trigger to his tree to do so.
>
> He did, the list exists 8)
I thought so:
http://marc.theaimsgroup.com/?l=linux-kernel&m=104534718212591&w=2
I just wanted to confirm that bk-commit-head is actually:
1. Complete
2. Realtime
If so, anybody can track Linus' tree, in real time, without using
BitKeeper.
Therefore, mailing lists for every single Linux-related BK repository
would allow anybody to track all of the trees in real time, without
using BK.
Unless bandwidth is a problem, (possible for dial-up users), I don't
see why we can't do that. How many people subscribed to this list are
still on dial-up?
Larry needn't even pay for the outbound bandwidth for the mailing
list, except to forward it to somebody who is willing to send it out.
John.
On Sun, 2003-02-16 at 11:08, John Bradford wrote:
> I just wanted to confirm that bk-commit-head is actually:
>
> 1. Complete
It should be complete -- but bear in mind that you may receive the mails
in a different order to the order in which they were sent, so just
applying them from a mail filter isn't necessarily sensible.
Also note that the dates on them are the date of the changeset itself,
not the date of application to Linus' tree (or indeed the date of the
cron job which creates the mail).
> 2. Realtime
Almost -- it's run from an hourly cron job, which is more 'real time'
than Linus actually pushing from his own box to master.kernel.org and
quite enough of a demand on resources already.
It's not done with triggers on Linus' tree because I suspect that would
actually make Linus _wait_ while the mail is generated for every
changeset he's pushing to master.kernel.org. I do it with a cron job
which pulls from Linus' tree to another, and I don't do it with triggers
in my own tree because I suspect that would keep Linus' tree locked
while it generated the mails too. I do need to investigate possible
improvements to the way it's generated, though.
Suggestions welcome, preferably in 'diff -u' form.
cvs -d :pserver:[email protected]:/home/cvs co bkexport
(password anoncvs)
--
dwmw2
From: Larry McVoy <[email protected]>
Date: Fri, 14 Feb 2003 07:30:39 -0800
Larry,
> Third of all, you could be right, I could be wrong, and I'm still right.
> We give the software away for *free*. We *own* it. If it turns out that
> people want to behave like little children and not play nice, no problem,
> we'll promptly fork the tree and you are stuck with whatever version you
> had at the point you decided to not play nice.
you are talking about forking BK, not Linux. Right?
Your last sentence seems to me like from Microsoft.
--
Pavel Jan?k
I'm glad I'm not as fat and slow running as Emacs (20)...
-- Lars G. T. Jorgensen in gnu.emacs.help
> > I just wanted to confirm that bk-commit-head is actually:
> >
> > 1. Complete
>
> It should be complete -- but bear in mind that you may receive the mails
> in a different order to the order in which they were sent, so just
> applying them from a mail filter isn't necessarily sensible.
OK, fair enough, it does need to be more complicated than I originally
suggested, but each changeset is numbered, so presumably we could just
use that to ensure that we don't miss any.
> Also note that the dates on them are the date of the changeset itself,
> not the date of application to Linus' tree (or indeed the date of the
> cron job which creates the mail).
Well, that's OK as long as we are just trying to track Linus' tree, we
don't even need to know the patch's original date.
> > 2. Realtime
>
> Almost -- it's run from an hourly cron job, which is more 'real time'
> than Linus actually pushing from his own box to master.kernel.org and
> quite enough of a demand on resources already.
>
> It's not done with triggers on Linus' tree because I suspect that would
> actually make Linus _wait_ while the mail is generated for every
> changeset he's pushing to master.kernel.org. I do it with a cron job
> which pulls from Linus' tree to another, and I don't do it with triggers
> in my own tree because I suspect that would keep Linus' tree locked
> while it generated the mails too. I do need to investigate possible
> improvements to the way it's generated, though.
Can't Larry just do this from bkbits, though? That's what I don't
understand.
Maybe not for Linus' tree due to the volume of patches, but for most
other trees, a mail sent out for each commit should be no problem.
There should be no issues with locking - the mailing list shouldn't
*care* whether anybody is actually receiving the mail, it just
broadcasts the changes for everybody to see.
John.
> One answer, maybe the only viable answer, is to use patents to protect
> our technology. To date we've been very sparing in where we have done
> that, there are substantial chunks of BK without patent protection. Some
> leaders in the kernel group have privately told me to not ship BK without
> patent protection. That slows down how fast you get a better BK, it's not
> something we can just wave our hands and make be so, it's lots of time and
> money. A single patent costs more than enough bandwidth to keep all of
> you happy for a year. Whatever. If you guys can't come to some sort
> of consensus, then patents are the route we'll choose, even German law
> respects patents.
European law, for now, doesn't allow software patents. For the same
reason that we have a right of fair use, and a right of reverse
engineering. We value freedom more than money. Maybe this will change,
but it'ld be the worse thing that could happen to whole Free Software
movement - and even to the Open Source movement, and to most companies
that do non-free software too. You should speak to lawyer before
saying such false statements.
By threating to use patents to prevent us for ever using the same idea
as you do (even if they grew up in our own minds), you've just added a
last proof to the fact that you don't care at all about Free Software,
and even Open Source or the Linux kernel, but just care about the
money you can earn.
This is your right, but don't ask us to follow your rules then. Since
you are _not_ on our side.
--
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 Sun, 16 February 2003 15:42:21 +0100, Ga?l Le Mignot wrote:
>
> By threating to use patents to prevent us for ever using the same idea
> as you do (even if they grew up in our own minds), you've just added a
> last proof to the fact that you don't care at all about Free Software,
> and even Open Source or the Linux kernel, but just care about the
> money you can earn.
Money is a valid concern. Developers want to eat too, they might even
have families. So let's put things into perspective.
The market for Linux developers (Linux as in the kernel) consists
mainly of the big processor and/or server manufacturers. Some
developers work directly for them, some indirectly through a
distributor.
Processors and Servers are hardware, so those manufacturers basically
give Linux away for free, but have you pay for the hardware
afterwards. In the end, they make damn sure that you (yes, you) pay
for Linux development.
For SCM, there is no attached hardware. This is not just a different
piece of software, it is a different business model. The customers pay
for the software directly or not at all. Therefore a free software
model has very little funding.
The result of this is clearly visible. CVS is far from generating
income for the developers. This means less developers and most of
those work in their free time. Development is slow.
Bitkeeper has paying customers and generated some $4M already, which
is used to pay developers. The result is faster development. While
started later than CVS, Bitkeeper is already closer to the goal.
I don't like the bitkeeper license any more than you, but I have to
admit that Larry has figured out a way to fund SCM. And that helps the
Free Software movement, too. Now most people working on SCM projects
have a common idea, where to go. This helps to coordinate people and
speeds up development.
Larry knows this and is concerned about his income, but even with
software patents and such he will have a hard time to slow development
down more than he accelerated it by creating Bitkeeper. So calm down,
thing are not any worse than they would be without Larry.
J?rn
--
If you're willing to restrict the flexibility of your approach,
you can almost always do something better.
-- John Carmack
Larry says that he hosts bkbits.net on a T1 which is shared with
(probably) the IP traffic of bitkeeper.com and his VoIP.
A fully loaded T1 can carry about 1/2 a TB per month traffic. This costs
you at most (AT MOST!) about 350 Euros per month (e.g. http://www.odn.de) for
a 2,3 Mbit SDSL line, which carries even 1,5 times the traffic of a T1).
Rack housing with a moderate traffic volume (e.g. enough for most
service needs) cost you between 29 Euros for a dedicated server with 60
Gigs (http://www.hetzner.de) to 25,90 euros for a shared hosting with a gig of
disc space and unlimited traffic (http://www.hosteurope.de, Hostnet product).
All of the cited ISPs claim to have multi-GB uplinks to the various
german an international peering points. I wouldn't consider that a
"garden hose".
Larry claimed a $15k bill for his T1. This is about 1200$ per months.
You can get three flat 2.3 MBit SDSL lines for that. Or a dedicated
server with about a TB of traffic in a housing center.
Regards
Henning
On Sun, 2003-02-16 at 13:03, Andrew Walrond wrote:
> Alan Cox wrote:
> >
> > Unlimited bandwidth at low bitrate is cheap. If you want 100Mbit then boy
> > it gets pricy. Its the different between "all you get" and "you get xyz"
> >
>
> Me thinks you miss my point :)
>
> In the context of Larry saying "It costs $x,000 dollars for me to
> provide the bandwidth" and this guy saying "But you can get all you want
> for 50Euros" leads me to suspect that he believes he is sat at the end
> of an 8m main bore when infact he has at best a garden hose....
>
> Andrew
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20
In the US, at least, all the deals I've been able to find cap the
bandwidth at ~100Kbit/sec average rate.
On Sun, Feb 16, 2003 at 09:18:56PM +0100, Henning Schmiedehausen wrote:
> Larry says that he hosts bkbits.net on a T1 which is shared with
> (probably) the IP traffic of bitkeeper.com and his VoIP.
>
> A fully loaded T1 can carry about 1/2 a TB per month traffic. This costs
> you at most (AT MOST!) about 350 Euros per month (e.g. http://www.odn.de) for
> a 2,3 Mbit SDSL line, which carries even 1,5 times the traffic of a T1).
>
> Rack housing with a moderate traffic volume (e.g. enough for most
> service needs) cost you between 29 Euros for a dedicated server with 60
> Gigs (http://www.hetzner.de) to 25,90 euros for a shared hosting with a gig of
> disc space and unlimited traffic (http://www.hosteurope.de, Hostnet product).
>
> All of the cited ISPs claim to have multi-GB uplinks to the various
> german an international peering points. I wouldn't consider that a
> "garden hose".
>
> Larry claimed a $15k bill for his T1. This is about 1200$ per months.
> You can get three flat 2.3 MBit SDSL lines for that. Or a dedicated
> server with about a TB of traffic in a housing center.
>
> Regards
> Henning
>
>
>
> On Sun, 2003-02-16 at 13:03, Andrew Walrond wrote:
> > Alan Cox wrote:
> > >
> > > Unlimited bandwidth at low bitrate is cheap. If you want 100Mbit then boy
> > > it gets pricy. Its the different between "all you get" and "you get xyz"
> > >
> >
> > Me thinks you miss my point :)
> >
> > In the context of Larry saying "It costs $x,000 dollars for me to
> > provide the bandwidth" and this guy saying "But you can get all you want
> > for 50Euros" leads me to suspect that he believes he is sat at the end
> > of an 8m main bore when infact he has at best a garden hose....
> >
> > Andrew
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
> INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]
>
> Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
> D-91054 Buckenhof Fax.: 09131 / 50654-20
>
> -
> 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/
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Sat, 2003-02-15 at 17:58, Christoph Hellwig wrote:
> What is the particular problem for you that some kernel developers _do_
> use BitKeeper. What got worse to you over the old-style prepatches?
Well, the problem I have is not of a technical nature.
Actually (even if you wouldn't believe it), I do encourage Larry to
continue his product and I do hope that he earns vast amounts of money
with it. From the numbers of emails that I got, BK really seems to be a
great product which helps developers tremendously. I have no problem
with BK being a non-free product and it is solely Larrys' decision to
sell it or give it away for free or keep it for himself. It is his
product and his call.
The problem I have is, that at some point the BK company might be forced
to change the rules. Maybe Larry isn't in charge anymore. Maybe he needs
money. Maybe at some point kernel development _relies_ on BK. What if BK
decides that there are no more free licenses from this day on?
I have a problem with a core product of the free software movement
starting to rely more and more on a product which is controlled by a
single company. And I have a problem with the kernel being developed
under a vague but nevertheless possible threat of changing the BK
license.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20
Andrea Arcangeli <[email protected]> writes:
>I'm been told of several giga archives with dozen thousand revisions
>under subversion for istance (I know Al Viro blamed subversion code but
>if the design it's good it may be a good start). subversion may not
I'm still missing a single good argument for the current SVN being
"bad code" aside from Al Viros' lovecraftian comparisation which seem
to be universal accepted (I got some mails citing or even using this
comparisation to prove that SVN is "inferior"). The Apache Foundation
e.g. is planning to move most of its projects to SVN from CVS in the
near future. And all of these people on infrastructure@ can't be that
clueless...
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[email protected] +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
On 16 Feb 2003, Henning Schmiedehausen wrote:
> The problem I have is, that at some point the BK company might be forced
> to change the rules. Maybe Larry isn't in charge anymore. Maybe he needs
> money. Maybe at some point kernel development _relies_ on BK. What if BK
> decides that there are no more free licenses from this day on?
You export linux-kernel out of bitkeeper in SCCS format, and switch SCM
software.
--
-- John E. Jasen ([email protected])
-- User Error #2361: Please insert coffee and try again.
Larry McVoy <[email protected]> writes:
>In the US, at least, all the deals I've been able to find cap the
>bandwidth at ~100Kbit/sec average rate.
Then it's not a T1. It's a crippled thing able to carry a meagre 35
gigs per month with throttled bandwith and just 1.5 MBits peak rate.
No wonder your VoIP sounds like from a B-movie. :-)
Regards
Henning
>On Sun, Feb 16, 2003 at 09:18:56PM +0100, Henning Schmiedehausen wrote:
>> Larry says that he hosts bkbits.net on a T1 which is shared with
>> (probably) the IP traffic of bitkeeper.com and his VoIP.
>>
>> A fully loaded T1 can carry about 1/2 a TB per month traffic. This costs
>> you at most (AT MOST!) about 350 Euros per month (e.g. http://www.odn.de) for
>> a 2,3 Mbit SDSL line, which carries even 1,5 times the traffic of a T1).
>>
>> Rack housing with a moderate traffic volume (e.g. enough for most
>> service needs) cost you between 29 Euros for a dedicated server with 60
>> Gigs (http://www.hetzner.de) to 25,90 euros for a shared hosting with a gig of
>> disc space and unlimited traffic (http://www.hosteurope.de, Hostnet product).
>>
>> All of the cited ISPs claim to have multi-GB uplinks to the various
>> german an international peering points. I wouldn't consider that a
>> "garden hose".
>>
>> Larry claimed a $15k bill for his T1. This is about 1200$ per months.
>> You can get three flat 2.3 MBit SDSL lines for that. Or a dedicated
>> server with about a TB of traffic in a housing center.
>>
>> Regards
>> Henning
>>
>>
>>
>> On Sun, 2003-02-16 at 13:03, Andrew Walrond wrote:
>> > Alan Cox wrote:
>> > >
>> > > Unlimited bandwidth at low bitrate is cheap. If you want 100Mbit then boy
>> > > it gets pricy. Its the different between "all you get" and "you get xyz"
>> > >
>> >
>> > Me thinks you miss my point :)
>> >
>> > In the context of Larry saying "It costs $x,000 dollars for me to
>> > provide the bandwidth" and this guy saying "But you can get all you want
>> > for 50Euros" leads me to suspect that he believes he is sat at the end
>> > of an 8m main bore when infact he has at best a garden hose....
>> >
>> > Andrew
>> --
>> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
>> INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]
>>
>> Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
>> D-91054 Buckenhof Fax.: 09131 / 50654-20
>>
>> -
>> 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/
>--
>---
>Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
>-
>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/
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[email protected] +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
> >In the US, at least, all the deals I've been able to find cap the
> >bandwidth at ~100Kbit/sec average rate.
>
> Then it's not a T1. It's a crippled thing able to carry a meagre 35
> gigs per month with throttled bandwith and just 1.5 MBits peak rate.
> No wonder your VoIP sounds like from a B-movie. :-)
I think what Larry meant was that connectivity via DSL is only
available to him at an average of 100Kbit, and he therefore has to pay
for a leased line.
In the U.K., you can get 2 Mbit/256 Kbit ADSL with no bandwidth
limitations to you, for about 300 pounds/month. However, that that is
not the same as a leased line the connection is still contended. A
leased line is guaranteed bandwidth, (usually with a service level
agreement which will allow you to claim a refund if it fails).
The lowest price I was quoted for a 512 Kbit leased line was about
5000 pounds/year, and it varies a lot by location, too.
John.
Nicolas Pitre wrote:
> > CVS
> > rsync
> > FTP
> > HTTP
> >
> > is there anything else people want?
>
> If you can manage to have a CVS repository that is always updated to the
> minute with full history info etc. then this should be suficient to satisfy
> all needs. Public CVS repositories are common enough so people should know
> how to use them already.
I expect most people would prefer read-only CVS for keeping up to date.
However, rsync from the repository is generally _much_ faster than CVS
if you are tracking changes, so I (an impatient modem user) prefer rsync.
Also the SCCS repository is more fun for analysis and browsing
programs than a CVS equivalent because some of the metadata would be
lost converting to CVS.
So I vote for rsync read-only access to the actual SCCS-ish repository
files that BK manages.
Ideally you'd ensure the tree offered through rsync was a consistent
snapshot, offer a method of atomically updating the tree seen by rsync
is a consistent snapshot. (Although this isn't crucial; BK's
changeset files let you detect that at the client I believe).
-- Jamie
John Bradford wrote:
> In the U.K., you can get 2 Mbit/256 Kbit ADSL with no bandwidth
> limitations to you, for about 300 pounds/month. However, that that is
Even that is not entirely true. Just try using the bandwidth
continuously for a few days and see how unpopular you become ;)
Several of the larger adsl providers in the UK have now introduced "Fair
Usage" policies to curb these "rogue users" (direct quote btw)
No such thing as a free lunch. Never was, never will be.
Andrew Walrond
> > In the U.K., you can get 2 Mbit/256 Kbit ADSL with no bandwidth
> > limitations to you, for about 300 pounds/month. However, that that is
>
> Even that is not entirely true. Just try using the bandwidth
> continuously for a few days and see how unpopular you become ;)
Wrong.
http://aa.nu/office2000high.html
310 U.K. pounds plus V.A.T.
This is, quoting directly from the webpage:
an "all you can eat" service, allowing you as much bandwidth as you
can get 24 hours a day.
Please note - my only connection with Andrews & Arnold is as a happy
customer, and I do not subscribe to that particular service, because I
do not require such a high bandwidth allowance, since grabjohn.com is
served from a 10 Mbps connection in London's Docklands.
John.
I stand corrected; You quote an extra cost service without the fair
usage stuff. I should have read more carefully. You'll concur that the
lesser cost packages have usage limits though. (which was my intended point)
It's interesting though that multiplying your quoted ?300/month 2Mbps
connection up to an unlimited 10Mbps connection gives......?1500/month!
My original argument stands. NOBODY is doing an uncontended, unlimited
bandwidth service for 50 euros. :)
Andrew Walrond
> You'll concur that the lesser cost packages have usage limits
> though. (which was my intended point)
Yes.
> It's interesting though that multiplying your quoted ?300/month 2Mbps
> connection up to an unlimited 10Mbps connection gives......?1500/month!
>
> My original argument stands. NOBODY is doing an uncontended, unlimited
> bandwidth service for 50 euros. :)
Nobody I know of, in the U.K. is doing that.
Note, though, that DSL is theoretically capable of about 8 Mbit, so I
don't see any reason why it would not be possible to have 1 Mbit,
burstable to 8 Mbit.
Also, note that with leased lines, you will typically need a different
type of circuit above 2 Mbit, so it's not just the cost of bandwidth.
John.
On Mon, 17 Feb 2003, Jamie Lokier wrote:
> However, rsync from the repository is generally _much_ faster than CVS
> if you are tracking changes, so I (an impatient modem user) prefer rsync.
> So I vote for rsync read-only access to the actual SCCS-ish repository
> files that BK manages.
See ftp://nl.linux.org/pub/linux/bk2patch/
You can get BK trees (uncompressed SCCS) via rsync, as well as
patches from the latest tagged version to the head of the tree.
cheers,
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://guru.conectiva.com/
Current spamtrap: <a href=mailto:"[email protected]">[email protected]</a>
Hi!
> All of this sounds great and is exactly what is already the plan.
> There is one missing item. A consensus in the community that if we
> provide BK, the CVS mirror, bkbits hosting, in return the community
> agrees to leave off using BK to copy BK.
>
> If what is being asked of us is more free service and engineering and
> we are getting nothing in return, that's a non-starter.
This might help you with engineering, and sourceforge.net is willing
to provide you the bandwidth. If you create an account on sf.net, I
can easily add you to the linux25 project.
Oh, and I believe we do not need exactly Larry for this, just someone
who uses bk anyway and is willing to supervise the scripts. [I'm
mostly on modem, and often go away for > week.]
Pavel
[all2cvs script]
#!/bin/bash
A=$1
while [ $A -lt $2 ]; do
A=$[$A+1]
if [ ! -e ../data/1.$A ]; then
echo "Patch $A does not exist"
exit 1
fi
echo "Processing patch $A"
../scripts/diff2cvs ../data/1.$A
mv ../data/1.$A ../olddata/1.$A
echo "Done processing $A"
if [ -e ../data/STOP ]; then
echo "Stopped at user request after $A"
echo "Stopped at user request after $A" > ../data/STOP
exit 1
fi
I=1; while [ $I -lt 50000 ]; do I=$[$I+1]; done
done
[bk2all]
#!/bin/bash
cd /home/riel/bk-kernel/linux-2.5
A=$1
while [ $A -lt $2 ]; do
PREV=$A
A=$[$A+1]
echo "Processing patch $A"
bk export -tpatch -r1.$PREV,1.$A > ~/bkdata/1.$A
done
[diff2cvs]
#!/bin/bash
fake() {
eval $1
}
dir() {
while [ ! -d $1 ]; do
DIR=$1
OLDDIR=foo
while [ $OLDDIR != $DIR ]; do
mkdir $DIR && fake "cvs add $DIR"
OLDDIR=$DIR
DIR=${DIR%/*}
done
done
}
cat $1 | grep '^+++ ' | grep -v "/dev/null" | (
while true; do
read A B C || break
FILE=${B#*/}
if [ ! -e $FILE ]; then
touch $FILE || dir ${FILE%/*}
touch $FILE || echo "Could not create $FILE"
touch $FILE || exit 1
fake "cvs add -ko $FILE"
fi
done
)
cat $1 | patch -Esp1 || exit 3
cat $1 | grep '^--- ' | grep -v "/dev/null" | (
while true; do
read A B C || break
FILE=${B#*/}
if [ ! -e $FILE ]; then
fake "cvs remove $FILE"
fi
done
)
cat $1 | grep '^#' > /tmp/delme.diff2cvs
fake "cvs -z 3 commit -F /tmp/delme.diff2cvs ."
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
LRSE Hosting (me) will not participate in anything that doesn't have Larry
McVoy's full endorsement.
Sorry Pavel for the repeat message, I forgot to include everyone the first
time I sent this out.
-----Original Message-----
From: [email protected]
[mailto:[email protected]]On Behalf Of Pavel Machek
Sent: Sunday, February 16, 2003 4:57 PM
To: Larry McVoy; Nicolas Pitre; Larry McVoy; lkml
Subject: bk2cvs [was Re: openbkweb-0.0]
Hi!
> All of this sounds great and is exactly what is already the plan.
> There is one missing item. A consensus in the community that if we
> provide BK, the CVS mirror, bkbits hosting, in return the community
> agrees to leave off using BK to copy BK.
>
> If what is being asked of us is more free service and engineering and
> we are getting nothing in return, that's a non-starter.
This might help you with engineering, and sourceforge.net is willing
to provide you the bandwidth. If you create an account on sf.net, I
can easily add you to the linux25 project.
Oh, and I believe we do not need exactly Larry for this, just someone
who uses bk anyway and is willing to supervise the scripts. [I'm
mostly on modem, and often go away for > week.]
Pavel
[all2cvs script]
#!/bin/bash
A=$1
while [ $A -lt $2 ]; do
A=$[$A+1]
if [ ! -e ../data/1.$A ]; then
echo "Patch $A does not exist"
exit 1
fi
echo "Processing patch $A"
../scripts/diff2cvs ../data/1.$A
mv ../data/1.$A ../olddata/1.$A
echo "Done processing $A"
if [ -e ../data/STOP ]; then
echo "Stopped at user request after $A"
echo "Stopped at user request after $A" > ../data/STOP
exit 1
fi
I=1; while [ $I -lt 50000 ]; do I=$[$I+1]; done
done
[bk2all]
#!/bin/bash
cd /home/riel/bk-kernel/linux-2.5
A=$1
while [ $A -lt $2 ]; do
PREV=$A
A=$[$A+1]
echo "Processing patch $A"
bk export -tpatch -r1.$PREV,1.$A > ~/bkdata/1.$A
done
[diff2cvs]
#!/bin/bash
fake() {
eval $1
}
dir() {
while [ ! -d $1 ]; do
DIR=$1
OLDDIR=foo
while [ $OLDDIR != $DIR ]; do
mkdir $DIR && fake "cvs add $DIR"
OLDDIR=$DIR
DIR=${DIR%/*}
done
done
}
cat $1 | grep '^+++ ' | grep -v "/dev/null" | (
while true; do
read A B C || break
FILE=${B#*/}
if [ ! -e $FILE ]; then
touch $FILE || dir ${FILE%/*}
touch $FILE || echo "Could not create $FILE"
touch $FILE || exit 1
fake "cvs add -ko $FILE"
fi
done
)
cat $1 | patch -Esp1 || exit 3
cat $1 | grep '^--- ' | grep -v "/dev/null" | (
while true; do
read A B C || break
FILE=${B#*/}
if [ ! -e $FILE ]; then
fake "cvs remove $FILE"
fi
done
)
cat $1 | grep '^#' > /tmp/delme.diff2cvs
fake "cvs -z 3 commit -F /tmp/delme.diff2cvs ."
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
Hi!
> LRSE Hosting (me) will not participate in anything that doesn't have Larry
> McVoy's full endorsement.
What is LRSE? You are the person responsible for bkbits.net?
> Sorry Pavel for the repeat message, I forgot to include everyone the first
> time I sent this out.
Pavel
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
Hi Pavel!
LRSE is my marketing and hosting company, based in the Joliet, Il area
(south of Chicago). We are not responsible for bkbits.net. We just want to
help. For more information on LRSE, see http://www.lrsehosting.com/.
Larry was in the CC list twice, I shortened it.
Regards,
Scott
-----Original Message-----
Hi!
> LRSE Hosting (me) will not participate in anything that doesn't have Larry
> McVoy's full endorsement.
What is LRSE? You are the person responsible for bkbits.net?
Pavel
On Sun, Feb 16, 2003 at 09:26:15PM +0100, Henning Schmiedehausen wrote:
> The problem I have is, that at some point the BK company might be forced
> to change the rules. Maybe Larry isn't in charge anymore. Maybe he needs
> money. Maybe at some point kernel development _relies_ on BK. What if BK
> decides that there are no more free licenses from this day on?
Then we'll have to go back to old-style no-SCM releases.
> I have a problem with a core product of the free software movement
Who said Linux is part of the Free Software Movement? Remember that Linus
is no fanatical GNU monk, unless I got something completly wrong he even
writes propritary software in his daytime job..
Ok, it sounds like we have the following resources available for getting
the kernel source
1. FTP of hourly snapshots
2. e-mail of individual patches hourly (patch may be e-mailed before
bkbits.net is updated)
3. bitkeeper access to bkbits.net
4. read-only rsync (including access to the SCCS info) of the full
up-to-the-second tree
5. web access to look at individual patches (automated pulls not allowed)
6. kernel.org mirrors of releases
This isn't enough for people so will adding read-only CVS access to the
tree itself be enough? does the CVS access need to also include the SCCS
directories? what's the next thing that people will complain limits their
access to the kernel source?
it used to be that we only had #6 and the griping that people did was that
to many patches were dropped, now we have all the others and only #3 and
#5 are limited by the evil bitmover company at all ;-) all the others are
available to anyone withouta need to use any software they don't want to
use.
David Lang
On Mon, 17 Feb 2003, Rik van Riel wrote:
> Date: Mon, 17 Feb 2003 11:50:02 -0300 (BRT)
> From: Rik van Riel <[email protected]>
> To: Jamie Lokier <[email protected]>
> Cc: Nicolas Pitre <[email protected]>, David Lang <[email protected]>,
> Larry McVoy <[email protected]>, Alan Cox <[email protected]>,
> lkml <[email protected]>
> Subject: Re: openbkweb-0.0
>
> On Mon, 17 Feb 2003, Jamie Lokier wrote:
>
> > However, rsync from the repository is generally _much_ faster than CVS
> > if you are tracking changes, so I (an impatient modem user) prefer rsync.
>
> > So I vote for rsync read-only access to the actual SCCS-ish repository
> > files that BK manages.
>
> See ftp://nl.linux.org/pub/linux/bk2patch/
>
> You can get BK trees (uncompressed SCCS) via rsync, as well as
> patches from the latest tagged version to the head of the tree.
>
> cheers,
>
> Rik
> --
> Bravely reimplemented by the knights who say "NIH".
> http://www.surriel.com/ http://guru.conectiva.com/
> Current spamtrap: <a href=mailto:"[email protected]">[email protected]</a>
>
On Sun, Feb 16, 2003 at 09:03:24PM +0000, Henning P. Schmiedehausen wrote:
> Andrea Arcangeli <[email protected]> writes:
>
> >I'm been told of several giga archives with dozen thousand revisions
> >under subversion for istance (I know Al Viro blamed subversion code but
> >if the design it's good it may be a good start). subversion may not
>
> I'm still missing a single good argument for the current SVN being
> "bad code" aside from Al Viros' lovecraftian comparisation which seem
> to be universal accepted (I got some mails citing or even using this
> comparisation to prove that SVN is "inferior"). The Apache Foundation
> e.g. is planning to move most of its projects to SVN from CVS in the
> near future. And all of these people on infrastructure@ can't be that
> clueless...
The fact a product can work great doesn't mean the code have to be nice.
Certainly if a product works great likely it's well designed in terms of
highlevel algorithms though.
Anyways I really can't comment on the sourcecode of SVN, I've the tar.gz
of r4503 here but I didn't manage looking at it yet.
Andrea
On Sat, Feb 15, 2003 at 01:31:16PM -0800, David Lang wrote:
> Andrea, since the on-disk format for bitkeeper is supposed to be SCCS
> would it be good enough for you to be able to get a copy of this? what
> mechanism would you prefer to use to get updates (rsync, FTP, HTTP, etc)
how do you avoid races with rsync/ftp/http? How do you fetch the SCCS
format out of bkbits.net w/o using bitkeeper?
Andrea
On Wed, 19 Feb 2003, Andrea Arcangeli wrote:
> On Sat, Feb 15, 2003 at 01:31:16PM -0800, David Lang wrote:
> > Andrea, since the on-disk format for bitkeeper is supposed to be SCCS
> > would it be good enough for you to be able to get a copy of this? what
> > mechanism would you prefer to use to get updates (rsync, FTP, HTTP, etc)
>
> how do you avoid races with rsync/ftp/http? How do you fetch the SCCS
> format out of bkbits.net w/o using bitkeeper?
>
> Andrea
I don't know the RIGHT answer about the races (quick and dirty answer,
deep doing a rsync until there is nothing to get???)
as far as getting the SCCS format the idea is that someone who uses
bitkeeper pulls a copy from bkbits.net and then makes the SCCS formal
available via the other methods (after I sent you the question above Rik
posted that he is doing this with ftp (for patches) and rsync (full SCCS
format).
David Lang
On Wed, Feb 19, 2003 at 02:43:48AM -0800, David Lang wrote:
> On Wed, 19 Feb 2003, Andrea Arcangeli wrote:
>
> > On Sat, Feb 15, 2003 at 01:31:16PM -0800, David Lang wrote:
> > > Andrea, since the on-disk format for bitkeeper is supposed to be SCCS
> > > would it be good enough for you to be able to get a copy of this? what
> > > mechanism would you prefer to use to get updates (rsync, FTP, HTTP, etc)
> >
> > how do you avoid races with rsync/ftp/http? How do you fetch the SCCS
> > format out of bkbits.net w/o using bitkeeper?
> >
> > Andrea
>
> I don't know the RIGHT answer about the races (quick and dirty answer,
> deep doing a rsync until there is nothing to get???)
no it won't fix it (theoretically), I know in practice it would work
most of the time though :)
Andrea
[Cc: list shortened.]
From: David Lang <[email protected]>
Date: Tue, 18 Feb 2003 14:34:42 -0800 (PST)
> Ok, it sounds like we have the following resources available for getting
> the kernel source
[...]
> This isn't enough for people so will adding read-only CVS access to the
> tree itself be enough?
This will be enough for people who want to have usual access to the Linux
kernel source repository. It won't satisfy people who do not like the
approach of using non-free software for developing the Linux kernel.
--
Pavel Jan?k
/* Host controller interrupts must not be running while calling this
* function or the penguins will get angry. */
-- 2.2.16 drivers/usb/ohci.c
> Ok, it sounds like we have the following resources available for getting
> the kernel source
> ...
> This isn't enough for people so will adding read-only CVS access to the
> tree itself be enough?
I would like up to date kernel changes via RFC1149...
(waves fist in the air)
...and I want Larry McVoy to pay for the pigeons.
(Humor people, take a deep breath)
Paul Fulghum, [email protected]
Microgate Corporation, http://www.microgate.com
> I would like up to date kernel changes via RFC1149...
> (waves fist in the air)
> ...and I want Larry McVoy to pay for the pigeons.
I can of course pay for them, but we need some people named Pavel to actually
raise them so that they are pure pigeons, untainted by any evil corporate
influence.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Hi!
> > I would like up to date kernel changes via RFC1149...
> > (waves fist in the air)
> > ...and I want Larry McVoy to pay for the pigeons.
>
> I can of course pay for them, but we need some people named Pavel to actually
> raise them so that they are pure pigeons, untainted by any evil corporate
> influence.
-. O>
\~~~/
~-~
L
Sure, how many of them do you want?
Pavel
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
On Wed, 19 Feb 2003, Pavel [iso-8859-2] Jan?k wrote:
> From: David Lang <[email protected]>
> Date: Tue, 18 Feb 2003 14:34:42 -0800 (PST)
>
> > Ok, it sounds like we have the following resources available for getting
> > the kernel source
>
> [...]
>
> > This isn't enough for people so will adding read-only CVS access to the
> > tree itself be enough?
>
> This will be enough for people who want to have usual access to the Linux
> kernel source repository. It won't satisfy people who do not like the
> approach of using non-free software for developing the Linux kernel.
As soon as you have stellar access to the kernel source through free
software, then it shouldn't be your business if others are using non-free
tools to manage their own copy.
Nicolas
Hi!
> > On the basis that it's easier to provide everything rather then to
> > convince people to change tools :-) here is what I'm thinking of (all of
> > these obviously read-only)
> >
> > CVS
> > rsync
> > FTP
> > HTTP
> >
> > is there anything else people want?
>
> If you can manage to have a CVS repository that is always updated to the
> minute with full history info etc. then this should be suficient to satisfy
> all needs. Public CVS repositories are common enough so people should know
> how to use them already.
>
> The best would be a few of those scattered around the world so things do
> scale. It shouldn't be that much bandwidth for bkbits.net to update them
> all automatically for example.
Just put it up on sourceforge.net...
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]