I broke cardbus compile in -pre4 on accident. Sorry about that...
(I don't have a public repository yet, so there's no place to pull form)
diffstat results:
drivers/pcmcia/cardbus.c | 3 +--
1 files changed, 1 insertion, 2 deletions
ChangeSet
1.231 02/02/08 18:22:27 [email protected] +1 -0
Doh!
struct device has no ->sysdata
and ->device should be ->dev
drivers/pcmcia/cardbus.c
1.7 02/02/08 18:22:27 [email protected] +1 -2
Doh!
struct device has no ->sysdata
and ->device should be ->dev
diff -Nru a/drivers/pcmcia/cardbus.c b/drivers/pcmcia/cardbus.c
--- a/drivers/pcmcia/cardbus.c Fri Feb 8 18:23:08 2002
+++ b/drivers/pcmcia/cardbus.c Fri Feb 8 18:23:08 2002
@@ -279,8 +279,7 @@
pci_readw(dev, PCI_DEVICE_ID, &dev->device);
dev->hdr_type = hdr & 0x7f;
- dev->dev.parent = bus->device;
- dev->dev.sysdata = bus->sysdata;
+ dev->dev.parent = bus->dev;
strcpy(dev->dev.name, dev->name);
strcpy(dev->dev.bus_id, dev->slot_name);
device_register(&dev->dev);
On Feb 08, 2002 18:25 -0800, Patrick Mochel wrote:
> (I don't have a public repository yet, so there's no place to pull form)
I don't see why everyone who is using BK is expecting Linus to do a pull.
In the non-BK case, wasn't it always a "push" model, and Linus would not
"pull" from URLs and such? Why are people not simply doing:
!bk send -r+ (other options) -
from within their editor (or equivalent) to inline the CSET in the email?
This has the added advantage that other people reading the email can also
import the CSET immediately if they so desire.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
Andreas Dilger wrote:
>
> On Feb 08, 2002 18:25 -0800, Patrick Mochel wrote:
> > (I don't have a public repository yet, so there's no place to pull form)
>
> I don't see why everyone who is using BK is expecting Linus to do a pull.
> In the non-BK case, wasn't it always a "push" model, and Linus would not
> "pull" from URLs and such? Why are people not simply doing:
>
> !bk send -r+ (other options) -
>
> from within their editor (or equivalent) to inline the CSET in the email?
> This has the added advantage that other people reading the email can also
> import the CSET immediately if they so desire.
This is a good point...
'bk pull' is probably most useful to high volume submitters, where the
contents of most patches is either obvious and/or uninteresting. 'bk
send -d -r<rev> -' should be fine for importing.
But this is still a trial run of BK, so who knows what will wind up to
be the best policy for casual submitters.
And there's nothing wrong at all with sending GNU patches...
Jeff
--
Jeff Garzik | "I went through my candy like hot oatmeal
Building 1024 | through an internally-buttered weasel."
MandrakeSoft | - goats.com
On Fri, Feb 08, 2002 at 08:39:31PM -0700, Andreas Dilger wrote:
> On Feb 08, 2002 18:25 -0800, Patrick Mochel wrote:
> > (I don't have a public repository yet, so there's no place to pull form)
Read the second half below to see how to get one.
> I don't see why everyone who is using BK is expecting Linus to do a pull.
For one, he seems to like that model, if the data is in a well known
place, he can pull it when he is ready. Makes it easy for him to not
worry about whether he has all the stuff Jeff wants to give him, pull
either says there is nothing to do or it doesn't.
The other issue is that if you do the "bk send -r+" thing, that assumes
that the receiver has the parent of the most recent change. The patch
will not apply otherwise. This is one difference between BK & diff/patch.
diff/patch will work in more cases, BK is insistent that the receiver has
everything that the sender had except the data sent. So if you let Linus
pull from a known place then you know he can apply your patch using BK,
if you don't, then he might be able to apply your patch.
On to the "known place" issue. One problem people have is having a
place to stash this stuff. Since BK is a replicating system, you can
have the same data in lots of different places, like your laptop, your
home machine, work machine, whatever, but you need a place that other
people can pull from that is always there. Anyone can install BK, read
the bkd man page and set up such a place. For those people who either
don't want to do that, or don't have a place where they can run a BKD,
or they don't trust the BKD software to be secure, or whatever, we've set
up bkbits.net, it's somewhat like sourceforge but right now, at least,
mostly intended for the benefit of the kernel team. We originally set it
up for the PPC team but anyone can stash a copy of their repository there.
To get the model, think of this as a staging area. You don't work there,
you don't use that system to do your patches or really do very much at
all. You work where you work right now. Make your stuff work, test it
out, and when you are ready, push a copy of it up to bkbits.net and send
out mail. People can go look at the changelogs, see the diffs, pull the
changes using BK, etc. And Jeff asked for URL format that he can post
so you can do a
wget <URL>
and you have the patch described in his posting. That should keep the
non-BK users happy, in essense the BK users are adding the data and
BK may be viewed as a patchbot. For those who don't like the license
or for whatever reason just like plain patches better, they can slurp
down the patches any time they want.
If you want to get a project space up there, send mail to
[email protected] and we'll send you instructions, it's pretty easy
to set up, you log in and pick a name and add your identity.pub and
you're all set. There is a little admin shell you can use to populate
your repository. Then you may push your patches there and point Linus
at them and hope he pulls them. I can see that in short order Linus
is going to be asking for the "show me everything I don't have on one
web page" tool, but that's cool, we've been meaning to build that one
for a while.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Larry McVoy wrote:
>
> On Fri, Feb 08, 2002 at 08:39:31PM -0700, Andreas Dilger wrote:
> > On Feb 08, 2002 18:25 -0800, Patrick Mochel wrote:
> > > (I don't have a public repository yet, so there's no place to pull form)
>
> Read the second half below to see how to get one.
>
> > I don't see why everyone who is using BK is expecting Linus to do a pull.
>
> For one, he seems to like that model,
Well I don't. I'd like to see as many kernel changes as possible
sent to this mailing list, as unified diffs, with an explanation.
-
On Feb 08, 2002 23:02 -0500, Jeff Garzik wrote:
> Andreas Dilger wrote:
> > I don't see why everyone who is using BK is expecting Linus to do a pull.
> > In the non-BK case, wasn't it always a "push" model, and Linus would not
> > "pull" from URLs and such? Why are people not simply doing:
> >
> > !bk send -r+ (other options) -
> >
> > from within their editor (or equivalent) to inline the CSET in the email?
> > This has the added advantage that other people reading the email can also
> > import the CSET immediately if they so desire.
>
> 'bk pull' is probably most useful to high volume submitters, where the
> contents of most patches is either obvious and/or uninteresting.
The problem is that (AFAIK) bk pull does not let Linus pick-and-choose
which patches he wants to accept as easily as importing them at the time
he reads each email. It basically assumes that he wants everything that
is in the repository he is pulling from.
> 'bk send -d -r<rev> -' should be fine for importing.
Yes, that would be my thought as well. Sadly, running the command
bk send -d -r+ -wgzip_uu -
does not work as I would _hope_ it would, namely putting a regular context
diff at the beginning of the email, and gzip_uu for only the CSET. That
would give us the best of both worlds, namely a diff to look at (which
most people can read easily), and the compressed CSET for people who
have BK.
I suppose it is possible to do exactly what I want by running both:
bk changes -r<rev> # generates Changelog
bk export -tpatch -h -du -r<rev> # generates context diff
bk send -wgzip_uu -r<rev> - # generates gzipped/uuencoded CSET
This has the added benefit that 'bk export' does not contain changes to
the BK files themselves, only the real changes.
I have no idea if this would confuse BK if you tried to recieve from
a file which had both of these in it...
> But this is still a trial run of BK, so who knows what will wind up to
> be the best policy for casual submitters.
>
> And there's nothing wrong at all with sending GNU patches...
Oh, I agree that for people without BK they can keep sending patches.
I would prefer that people who _do_ have BK to send the CSET along with
the patch to the mailing list so that you don't have to go hunting for a
specific CSET, or if you can't because you are not currently connected.
This might also be possible if BK could export/import a whole changeset
in patch form, plus some magic stuff at the beginning/end (gzip_uu) which
had all of the BK metadata in it, but I don't know if that is possible or
desirable.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
On Sat, Feb 09, 2002 at 12:29:20AM -0700, Andreas Dilger wrote:
> Yes, that would be my thought as well. Sadly, running the command
>
> bk send -d -r+ -wgzip_uu -
>
> does not work as I would _hope_ it would, namely putting a regular context
> diff at the beginning of the email, and gzip_uu for only the CSET.
Whoops, that's a bug. Type "bk sendbug" and send us a bug report, we'll
fix it. Sorry about that.
> > But this is still a trial run of BK, so who knows what will wind up to
> > be the best policy for casual submitters.
> >
> > And there's nothing wrong at all with sending GNU patches...
>
> Oh, I agree that for people without BK they can keep sending patches.
It occurs to me that there is no reason you can't generate a regular
patch from BK and mail it to the list w/ the changeset comments. That
keeps all the non-BK users perfectly happy, nothing has changed for
them and they can use BK or not as they see fit. In addition, you can
send off a BK patch to Linus and/or stuff a patch into a publicly
available BK tree and point him at it.
If you all can reach any sort of concensus on what is a pleasant patch
format for non-BK users, just tell me, and I'll make sure BK can generate
that sort of patch easily.
> This might also be possible if BK could export/import a whole changeset
> in patch form, plus some magic stuff at the beginning/end (gzip_uu) which
> had all of the BK metadata in it, but I don't know if that is possible or
> desirable.
Well, send -d is essentially that - it's two patches, a GNU patch and a
BK patch. It was a mistake for us to wrap the whole thing, we should
leave the regular diffs alone and just wrap the BK stuff. We can do
that.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Friday 08 February 2002 10:39 pm, Andreas Dilger wrote:
> On Feb 08, 2002 18:25 -0800, Patrick Mochel wrote:
> > (I don't have a public repository yet, so there's no place to pull form)
>
> I don't see why everyone who is using BK is expecting Linus to do a pull.
> In the non-BK case, wasn't it always a "push" model, and Linus would not
> "pull" from URLs and such?
I'm all for it. I think it's a good thing.
In the absence of significant latency issues, pull scales better than push.
It always has. Push is better in low bandwidth situations with lots of idle
capacity, but it breaks down when the system approaches saturation.
Pull data is naturally supplied when you're ready for it (assuming no
significant latency to access it). Push either scrolls by unread or piles up
in your inbox and gets buried until it goes stale. Web pages work on a pull
model, "push" was an internet fad a few years ago that failed for a reason.
When push models hit saturation it breaks down and you wind up with the old
"I love lucy" episode with the chocolate factory. Back in the days where
ethernet used hubs instead of switches, going over 50% utilization could lock
the whole network pretty easily, and these days with switched gigabit
eithernet you still have network interfaces going into interrupt livelock but
able to handle a higher load in polling mode. The Linux scheduler itself
pulls tasks from a pool of runnable tasks. If each task had a timer that
expired generating an interrupt that pushed it to a processor, things
wouldn't work so well. (I could go on...)
Linus has actually been using his mailbox to simulate pull by keeping the
push model at saturation and having repeated retransmits of stuff he expects
to repeatedly delete until he's ready to reach out and grab it as it passes
by when the time is right. The flood he's plucking stuff from is his inbox
instead of the internet, but the fact remains 90% of it flows by unread
(wasting attention to delete it, a small amount but it adds up), and isn't
guaranteed to be there when he IS ready for it.
Humans naturally work by pull. It just works better to grab stuff out of the
fridge when you're hungry instead of having it crammed down your throat at
random. Push winds up going into a buffer which we pull from (which is how
mail works), and if that buffer overflows during load spikes, or is just
constantly filling faster than it drains in the long term, then you wind up
retransmitting stuff that got dropped (increasing the bandwidth usage) and it
all just falls apart...
Years ago, Linus wasn't regularly at saturation, so push was fine. (Optimal
even: interrupts are better than polling up until you approach livelock.)
And with Linus's previous toolset, grabbing code from URLs was a significant
interruption in his workflow, hence a bad thing. But with bitkeeper, it
isn't. And if Linus is going to focus on taking the bulk of new patches from
a dozen or so trusted lieutenants anyway, it makes sense for them to give him
the option of a pull model.
I'd encourage this trend. If in the future linus pulls from lieutenants and
lieutenants pull from maintainers, the dropped patches problem basically goes
away. Just make sure that when the level above you IS ready to take it from
your level, it's there and ready for them...
Rob
Standard disclaimer: it's 4:30am, who knows how much sense this will make in
the morning? :)
On Saturday 09 February 2002 12:32 am, Andrew Morton wrote:
> Larry McVoy wrote:
> > For one, he seems to like that model,
>
> Well I don't. I'd like to see as many kernel changes as possible
> sent to this mailing list, as unified diffs, with an explanation.
I personally hope one of the patchbot projects (patches-only lists,
filtered/moderated) gets mature enough to use soon.
Optimizing the bandwidth of Linus and optimizing for the rest of the
developer community are two seperate problems which may require two seperate
toolchains. Posting a patch to the list already isn't enough to get it to
Linus. Hasn't been for a while...
Rob
>>>>> "Rob" == Rob Landley <[email protected]> writes:
Rob> Optimizing the bandwidth of Linus and optimizing for the rest of the
Rob> developer community are two seperate problems which may require two seperate
Rob> toolchains. Posting a patch to the list already isn't enough to get it to
Rob> Linus. Hasn't been for a while...
Yeah, right, and now people hope that commiting to some obscure
repository will be enough get it to Linus ?
Lemme tell ya, the result is that it won't get not only to Linus, but
to the majority of the community.
Sorry, hoping that some _tool_ will solve the (supposed) problems in
the kernel development is just plain stupid.
Regards,
-velco
PS. Interesting trend to note is the usually the amount of whining is
inversely proportional to one's contribution to the kernel.
On 9 Feb 2002, Momchil Velikov wrote:
> PS. Interesting trend to note is the usually the amount of whining is
> inversely proportional to one's contribution to the kernel.
<pedantic> to (constant + one's contribution to the kernel). After all,
Rob has only finite bandwidth. </pedantic>
On Feb 09, 2002 04:27 -0500, Rob Landley wrote:
> On Friday 08 February 2002 10:39 pm, Andreas Dilger wrote:
> > I don't see why everyone who is using BK is expecting Linus to do a pull.
> > In the non-BK case, wasn't it always a "push" model, and Linus would not
> > "pull" from URLs and such?
>
> I'd encourage this trend. If in the future linus pulls from lieutenants and
> lieutenants pull from maintainers, the dropped patches problem basically goes
> away. Just make sure that when the level above you IS ready to take it from
> your level, it's there and ready for them...
OK, so Linus has been using BK for a couple of weeks now, and some of the
lieutenants have started setting up BK repositories at bkbits.net. Is
there _any_ way that one can understand the heirarchy of repositories
at bkbits.net? There's "linus", "linux", "linux25", and a bunch of other
obvious branch repositories. Which one should kernel developers
clone/pull from? It would be nice if there was a heirarchy or something
which showed the parent-child relationship.
I suppose (due to the BK design) that it is not fatal if you do your initial
clone from a URL that might go "dead" because you can always change your
parent URL and you haven't lost anything.
Clearly, all of the repositories need to start as clones of Linus'
repository, or there is no chance of them passing CSETs back and forth
among the developers. Does the fact that 'linux-arm' is apparently not
a descendent from the 'official' linux-2.4 or linux-2.5 repository doom
that developer from not being able to send CSETs to any other kernel
developer or Linus? Sure, they could send patches, but then they would
forever have to diff/patch and resolve conflicts on their end rather
than just pulling/pushing CSETs with all of the other kernel developers.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
and if you keep doing this you will also need to cleanup and implement the
'hardlink for identical files' idea that was batted around a year or so
ago, otherwise with all the copies of the linus tree with a few K of
patches from different developers you'll start to notice the storage space
used, even at today's drive prices :-)
David Lang
On Fri, 8 Feb 2002, Larry McVoy wrote:
> Date: Fri, 8 Feb 2002 21:12:57 -0800
> From: Larry McVoy <[email protected]>
> To: Patrick Mochel <[email protected]>, [email protected]
> Subject: Re: [bk patch] Make cardbus compile in -pre4
>
> On Fri, Feb 08, 2002 at 08:39:31PM -0700, Andreas Dilger wrote:
> > On Feb 08, 2002 18:25 -0800, Patrick Mochel wrote:
> > > (I don't have a public repository yet, so there's no place to pull form)
>
> Read the second half below to see how to get one.
>
> > I don't see why everyone who is using BK is expecting Linus to do a pull.
>
> For one, he seems to like that model, if the data is in a well known
> place, he can pull it when he is ready. Makes it easy for him to not
> worry about whether he has all the stuff Jeff wants to give him, pull
> either says there is nothing to do or it doesn't.
>
> The other issue is that if you do the "bk send -r+" thing, that assumes
> that the receiver has the parent of the most recent change. The patch
> will not apply otherwise. This is one difference between BK & diff/patch.
> diff/patch will work in more cases, BK is insistent that the receiver has
> everything that the sender had except the data sent. So if you let Linus
> pull from a known place then you know he can apply your patch using BK,
> if you don't, then he might be able to apply your patch.
>
> On to the "known place" issue. One problem people have is having a
> place to stash this stuff. Since BK is a replicating system, you can
> have the same data in lots of different places, like your laptop, your
> home machine, work machine, whatever, but you need a place that other
> people can pull from that is always there. Anyone can install BK, read
> the bkd man page and set up such a place. For those people who either
> don't want to do that, or don't have a place where they can run a BKD,
> or they don't trust the BKD software to be secure, or whatever, we've set
> up bkbits.net, it's somewhat like sourceforge but right now, at least,
> mostly intended for the benefit of the kernel team. We originally set it
> up for the PPC team but anyone can stash a copy of their repository there.
>
> To get the model, think of this as a staging area. You don't work there,
> you don't use that system to do your patches or really do very much at
> all. You work where you work right now. Make your stuff work, test it
> out, and when you are ready, push a copy of it up to bkbits.net and send
> out mail. People can go look at the changelogs, see the diffs, pull the
> changes using BK, etc. And Jeff asked for URL format that he can post
> so you can do a
>
> wget <URL>
>
> and you have the patch described in his posting. That should keep the
> non-BK users happy, in essense the BK users are adding the data and
> BK may be viewed as a patchbot. For those who don't like the license
> or for whatever reason just like plain patches better, they can slurp
> down the patches any time they want.
>
> If you want to get a project space up there, send mail to
> [email protected] and we'll send you instructions, it's pretty easy
> to set up, you log in and pick a name and add your identity.pub and
> you're all set. There is a little admin shell you can use to populate
> your repository. Then you may push your patches there and point Linus
> at them and hope he pulls them. I can see that in short order Linus
> is going to be asking for the "show me everything I don't have on one
> web page" tool, but that's cool, we've been meaning to build that one
> for a while.
> --
> ---
> 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/
>
Patrick Mochel <[email protected]> writes:
> I broke cardbus compile in -pre4 on accident. Sorry about that...
It compiles in -pre5 but doesn't work unless you also apply the patch
below. Without this patch, bus_id will be empty which makes
device_register fail.
--- linux/drivers/pcmcia/cardbus.c.old Sat Feb 9 12:39:49 2002
+++ linux/drivers/pcmcia/cardbus.c Sat Feb 9 12:14:36 2002
@@ -279,13 +279,13 @@
pci_readw(dev, PCI_DEVICE_ID, &dev->device);
dev->hdr_type = hdr & 0x7f;
+ pci_setup_device(dev);
+
dev->dev.parent = bus->dev;
strcpy(dev->dev.name, dev->name);
strcpy(dev->dev.bus_id, dev->slot_name);
device_register(&dev->dev);
- pci_setup_device(dev);
-
/* FIXME: Do we need to enable the expansion ROM? */
for (r = 0; r < 7; r++) {
struct resource *res = dev->resource + r;
--
Peter Osterlund - [email protected]
http://w1.894.telia.com/~u89404340
On February 9, 2002 10:57 am, Momchil Velikov wrote:
> PS. Interesting trend to note is the usually the amount of whining is
> inversely proportional to one's contribution to the kernel.
Complaining and whining are not the same thing. Some major contributors
have complained, that's why Linus takes this seriously.
--
Daniel
On Sat, Feb 09, 2002 at 02:14:52AM -0800, David Lang wrote:
> and if you keep doing this you will also need to cleanup and implement the
> 'hardlink for identical files' idea that was batted around a year or so
> ago, otherwise with all the copies of the linus tree with a few K of
> patches from different developers you'll start to notice the storage space
> used, even at today's drive prices :-)
bk clone -l
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Sat, Feb 09, 2002 at 07:54:25AM -0800, Larry McVoy wrote:
> On Sat, Feb 09, 2002 at 02:14:52AM -0800, David Lang wrote:
> > and if you keep doing this you will also need to cleanup and implement the
> > 'hardlink for identical files' idea that was batted around a year or so
> > ago, otherwise with all the copies of the linus tree with a few K of
> > patches from different developers you'll start to notice the storage space
> > used, even at today's drive prices :-)
>
> bk clone -l
Erm:
$ bk version
BitKeeper/Free version is bk-2.1.4 20020205155016 for x86-glibc22-linux
Built by: [email protected] in /build/bk-2.1.x-lm/src
Built on: Tue Feb 5 08:01:19 PST 2002
$ bk clone -l
usage: bk clone [-ql] [-E<env>=<val>] [-r<rev>] [-z[<d>]] <from> [<to>]
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
> > bk clone -l
>
> $ bk version
> BitKeeper/Free version is bk-2.1.4 20020205155016 for x86-glibc22-linux
> Built by: [email protected] in /build/bk-2.1.x-lm/src
> Built on: Tue Feb 5 08:01:19 PST 2002
> $ bk clone -l
> usage: bk clone [-ql] [-E<env>=<val>] [-r<rev>] [-z[<d>]] <from> [<to>]
Tom, I can't believe you are running that ancient version of BK, why it is
already 4 days old! Try and stay current :-)
There is a 2.1.4b release that has clone -l in it, along with some rollup
fixes/enhancements for Linus.
There is an undocumented version of clone -l in your release which works like
bk lclone from to
and does the hardlinks.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Saturday 09 February 2002 05:01 am, Alexander Viro wrote:
> On 9 Feb 2002, Momchil Velikov wrote:
> > PS. Interesting trend to note is the usually the amount of whining is
> > inversely proportional to one's contribution to the kernel.
>
> <pedantic> to (constant + one's contribution to the kernel). After all,
> Rob has only finite bandwidth. </pedantic>
And here I thought I was still in Al's killfile... :)
Rob
On Sat, Feb 09, 2002 at 03:08:25AM -0700, Andreas Dilger wrote:
> OK, so Linus has been using BK for a couple of weeks now, and some of the
> lieutenants have started setting up BK repositories at bkbits.net. Is
> there _any_ way that one can understand the heirarchy of repositories
> at bkbits.net? There's "linus", "linux", "linux25", and a bunch of other
> obvious branch repositories. Which one should kernel developers
> clone/pull from? It would be nice if there was a heirarchy or something
> which showed the parent-child relationship.
The 'linus' one seems to be the parent, because if I try to pull from
it bk tells me that the tree is for the private use of Linus only.
And all the other 2.5 repositories seem to be slighly out of date
(the linux/linux-2.5 one is at -pre3 instead of -pre5 etc).
So, what is supposed to be the definitive, public bk repository,
to pull from in order to have the latest changes ? (the one which will
go on bk.kernel.org eventually)
Stelian.
--
Stelian Pop <[email protected]>
Alcove - http://www.alcove.com
On Sat, 9 Feb 2002, Stelian Pop wrote:
>
> So, what is supposed to be the definitive, public bk repository,
> to pull from in order to have the latest changes ? (the one which will
> go on bk.kernel.org eventually)
Right now the "definitive" bk repository is on master.kernel.org, which
can only be accessed by people who have accounts there.
I also push it to my private version on bkbits.net, and it is supposed to
be automatically then pushed onwards to the public one that is at
http://linux.bkbits.net:8080/linux-2.5, but the infrastructure for that
isn't yet working.
NOTE! If you're working on something that doesn't absolutely need the
stuff in -pre5, you can (and should) just take the pre3 tree, and work
there. When I pull stuff from people I don't require that they be
up-to-date with me - one of the advantages of bk is that it's really easy
to merge stuff.
We'll get the official tree out in a more timely manner, one of the issues
is actually just the scalability of pushing to lots of developers for the
first time.
So if you're interested in BK: get one of the "older" trees now (eg the
2.5.4-pre3 one that is public). Because that will make it a lot easier and
a lot faster to just "bk pull" once the more modern trees come on-line if
you have at least a base for it.
Oh - final comment: try to pull over a fast line, and don't bog down
bkbits.net more than necessary. For example, if you are behind a modem or
a slow DSL line and you want to clone the repository and you have an
account with faster speeds, I'd suggest you _first_ clone it to that other
account, and then later clone it from there over the slow line.
(After that you can re-parent your slow one and make all further "bk
pull"s directly - getting a few days or weeks of work with a "pull" is not
too costly, but when doing the whole clone it is better to get in and get
out faster to avoid clogging up the server with lots of bkd's that are
just waiting..)
Linus
On Sat, Feb 09, 2002 at 12:59:16PM -0800, Linus Torvalds wrote:
> Right now the "definitive" bk repository is on master.kernel.org, which
> can only be accessed by people who have accounts there.
>
> I also push it to my private version on bkbits.net, and it is supposed to
> be automatically then pushed onwards to the public one that is at
> http://linux.bkbits.net:8080/linux-2.5, but the infrastructure for that
> isn't yet working.
Ok, understood. While waiting for a 'proper' infrastructure', maybe
a simple cron entry will do the job ? (since the bk pull from your
private tree on bkbits to the public tree on bkbits is not supposed
to ever fail or have merge errors...)
Anyway, just did a 'bk pull' once again and noticed than linux.bkbits.net
has again the latest version. Thanks! (or thanks Larry, whatever is
more appropriate :-)).
Stelian.
--
Stelian Pop <[email protected]>
Alcove - http://www.alcove.com
> > I also push it to my private version on bkbits.net, and it is supposed to
> > be automatically then pushed onwards to the public one that is at
> > http://linux.bkbits.net:8080/linux-2.5, but the infrastructure for that
> > isn't yet working.
>
> Ok, understood. While waiting for a 'proper' infrastructure', maybe
> a simple cron entry will do the job ? (since the bk pull from your
> private tree on bkbits to the public tree on bkbits is not supposed
> to ever fail or have merge errors...)
This is my problem. You could help if you could tell me what exactly
are the magic wands to wave such that you can ssh in without typing
a password. I know about ssh-agent but that doesn't help for this,
I know that in certain cases ssh lets me in without anything. I thought
there was some routine where you ssh-ed one way and then the other way
and it left enough state that it trusted you, does any ssh genuis out
there know what I'm talking about? If I have this, I can set up the
cron job, I'm sure this is obvious and I'm just overlooking something
but I can't find it.
> Anyway, just did a 'bk pull' once again and noticed than linux.bkbits.net
> has again the latest version. Thanks! (or thanks Larry, whatever is
> more appropriate :-)).
Yeah, I did it by hand. Hopefully automated by the end of the day.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Sat, Feb 09, 2002 at 12:26:49PM -0800, Larry McVoy wrote:
> This is my problem. You could help if you could tell me what exactly
> are the magic wands to wave such that you can ssh in without typing
> a password.
Set up $HOME/.shosts ? (man 1 ssh)
> > has again the latest version. Thanks! (or thanks Larry, whatever is
> > more appropriate :-)).
>
> Yeah, I did it by hand. Hopefully automated by the end of the day.
Would it be possible to do something to keep the 2.4 tree up to date too ?
(something like checking if the latest incremental patch from kernel.org
was applied to the tree, and if not, apply it as a changeset and tag) ?
Stelian.
--
Stelian Pop <[email protected]>
Alcove - http://www.alcove.com
On Sat, 9 Feb 2002, Larry McVoy wrote:
> This is my problem. You could help if you could tell me what exactly
> are the magic wands to wave such that you can ssh in without typing
> a password. I know about ssh-agent but that doesn't help for this,
> I know that in certain cases ssh lets me in without anything. I thought
> there was some routine where you ssh-ed one way and then the other way
> and it left enough state that it trusted you, does any ssh genuis out
> there know what I'm talking about? If I have this, I can set up the
> cron job, I'm sure this is obvious and I'm just overlooking something
> but I can't find it.
Just get the .ssh/id_dsa.pub from the client you want to allow in without
a password and copy it inside .ssh/authorized_keys2 in the server.
ssh-agent is useful if you protect your keys with a password so that you
don't have to retype the password to unblock you own key over and over.
Nothing to do with accessing other sites.
If you need any help just tell me.
Pau
do you have a script that can go back after the fact and see what can be
hardlinked?
I'm thinking specififcly of the type of thing that will be happening to
your server where you have a bunch of people putting in a clone of one
tree who will probably not be doing a clone -l to set it up, but who could
have and you want to clean up after the fact (and perhapse again on a
periodic basis, becouse after all of these trees apply a changeset from
linus they will all have changed (breaking the origional hardlinks) but
will still be duplicates of each other.
David Lang
On Sat, 9 Feb 2002, Larry McVoy wrote:
> Date: Sat, 9 Feb 2002 09:05:27 -0800
> From: Larry McVoy <[email protected]>
> To: Tom Rini <[email protected]>
> Cc: David Lang <[email protected]>, Larry McVoy <[email protected]>,
> Patrick Mochel <[email protected]>, [email protected]
> Subject: Re: [bk patch] Make cardbus compile in -pre4
>
> > > bk clone -l
> >
> > $ bk version
> > BitKeeper/Free version is bk-2.1.4 20020205155016 for x86-glibc22-linux
> > Built by: [email protected] in /build/bk-2.1.x-lm/src
> > Built on: Tue Feb 5 08:01:19 PST 2002
> > $ bk clone -l
> > usage: bk clone [-ql] [-E<env>=<val>] [-r<rev>] [-z[<d>]] <from> [<to>]
>
> Tom, I can't believe you are running that ancient version of BK, why it is
> already 4 days old! Try and stay current :-)
>
> There is a 2.1.4b release that has clone -l in it, along with some rollup
> fixes/enhancements for Linus.
>
> There is an undocumented version of clone -l in your release which works like
>
> bk lclone from to
>
> and does the hardlinks.
> --
> ---
> Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
>
I just set this up between a couple machines at work and one thing we
ended up doing to get it to work was to generate a key without a
passphrase on it to use for syncing, otherwise the ssh on the machine
inititing the connection wanted a password to start the connection. you
also need to do the stuff mentioned for the receiving end so that it
doesn't ask for a password.
David Lang
On Sat, 9 Feb 2002, Pau Aliagas wrote:
> Date: Sat, 9 Feb 2002 21:57:50 +0100 (CET)
> From: Pau Aliagas <[email protected]>
> To: Larry McVoy <[email protected]>
> Cc: [email protected]
> Subject: Re: pull vs push (was Re: [bk patch] Make cardbus compile in
> -pre4)
>
> On Sat, 9 Feb 2002, Larry McVoy wrote:
>
> > This is my problem. You could help if you could tell me what exactly
> > are the magic wands to wave such that you can ssh in without typing
> > a password. I know about ssh-agent but that doesn't help for this,
> > I know that in certain cases ssh lets me in without anything. I thought
> > there was some routine where you ssh-ed one way and then the other way
> > and it left enough state that it trusted you, does any ssh genuis out
> > there know what I'm talking about? If I have this, I can set up the
> > cron job, I'm sure this is obvious and I'm just overlooking something
> > but I can't find it.
>
> Just get the .ssh/id_dsa.pub from the client you want to allow in without
> a password and copy it inside .ssh/authorized_keys2 in the server.
>
> ssh-agent is useful if you protect your keys with a password so that you
> don't have to retype the password to unblock you own key over and over.
> Nothing to do with accessing other sites.
>
> If you need any help just tell me.
> Pau
>
> -
> 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, Feb 09, 2002 at 01:01:34PM -0800, David Lang wrote:
> do you have a script that can go back after the fact and see what can be
> hardlinked?
>
> I'm thinking specififcly of the type of thing that will be happening to
> your server where you have a bunch of people putting in a clone of one
> tree who will probably not be doing a clone -l to set it up, but who could
> have and you want to clean up after the fact (and perhapse again on a
> periodic basis, becouse after all of these trees apply a changeset from
> linus they will all have changed (breaking the origional hardlinks) but
> will still be duplicates of each other.
We don't, but we can, and we should. "bk relink tree1 tree2" seems like
the right interface.
Right now we aren't too worried about the disk space, the data is sitting
on a pair of 40GB drives and we're running the trees in gzip mode, so they
are 75MB each. But yes, it's a good idea, we should do it, and probably
should figure out some way to make it automatic. I'll add it to the
(ever growing) list, thanks.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Saturday 09 February 2002 03:26 pm, Larry McVoy wrote:
> > > I also push it to my private version on bkbits.net, and it is supposed
> > > to be automatically then pushed onwards to the public one that is at
> > > http://linux.bkbits.net:8080/linux-2.5, but the infrastructure for that
> > > isn't yet working.
> >
> > Ok, understood. While waiting for a 'proper' infrastructure', maybe
> > a simple cron entry will do the job ? (since the bk pull from your
> > private tree on bkbits to the public tree on bkbits is not supposed
> > to ever fail or have merge errors...)
>
> This is my problem. You could help if you could tell me what exactly
> are the magic wands to wave such that you can ssh in without typing
> a password.
You need three or four files in the .ssh directory of the account in
question. (This is assuming that ssh protocol 2 comes first in your
ssh_config and sshd_config files.)
1) The file ~/.ssh/known_hosts2 lists the host keys. If you just ssh to a
box it'll prompt you if it should add an unknown key to the file. (Just do
this manually once in each direction and this file will be happy. You can
assemble it manually from /etc/ssh/ssh_host_key.pub if you want, but I doubt
you need to.)
2) Generate a public/private pair of dsa encryption keys, with:
ssh-keygen -d -f ~/.ssh/id_dsa
Just press enter twice for the passphrase (you don't want one for
passwordless sshing).
3) In the .ssh dir, copy "id_dsa.pub" to "authorized_keys2"
4) Copy the three files you just created (id_dsa, id_dsa.pub, and
authorized_keys2) to the ~/.ssh directory on the other box.
This allows bidirectional passwordless sshing. If you want to only ssh in
one direction, keep the public keys (id_dsa.pub and authorized_keys2) but zap
the private key on the appropriate box.
Now just try to ssh as the user in question. (su username, then ssh 1.2.3.4)
If you're piping data from one box to another, you might want to use the -T
option to tell it no controlling TTY. (Largely a matter of personal
taste...) And sometimes -C "echo hello" works better than just having the
commands explicitly on the end of the command line...
I have this working over here. If I missed a step, email me.
Rob
On Feb 09, 2002 13:41 -0800, Larry McVoy wrote:
> We don't, but we can, and we should. "bk relink tree1 tree2" seems like
> the right interface.
Yes, this would be great. It should probably only do this for files in
SCCS and BitKeeper directories, because vim (for example) will do the
wrong thing with hard-linked files if you edit them. Maybe there could
be another option which would relink all of the checked-out files as well,
for people who use emacs?
> Right now we aren't too worried about the disk space, the data is sitting
> on a pair of 40GB drives and we're running the trees in gzip mode, so they
> are 75MB each. But yes, it's a good idea, we should do it, and probably
> should figure out some way to make it automatic. I'll add it to the
> (ever growing) list, thanks.
One thing that I've noticed (got my first linux-2.5 clone last night) is
that the kernel build process is somewhat broken by the fact that not
everything that you need to build is checked out of the repository by
make.
It appears to handle .c files ok, but it failed for all of the .h files.
I take it this means that gcc doesn't know anything about SCCS, and it
would also appear that make is not properly checking dependencies for
these files, or it would have checked them out, right?
Also, things like "make menuconfig" and such also fail (because they are
doing stuff within scripts that have no concept of SCCS or BK). Will
the new kernel build system take any of this into account?
I would prefer if we only checked out as much as we need (instead of
doing something like 'bk -r edit' which will use up a lot of space in
each clone for architectures and drivers which I don't need).
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
Stelian Pop wrote:
> Would it be possible to do something to keep the 2.4 tree up to date too ?
> (something like checking if the latest incremental patch from kernel.org
> was applied to the tree, and if not, apply it as a changeset and tag) ?
Convince Marcelo to look at BK for merging :)
Jeff, slowly getting spoiled by BK and Linus
--
Jeff Garzik | "I went through my candy like hot oatmeal
Building 1024 | through an internally-buttered weasel."
MandrakeSoft | - goats.com
On Sat, Feb 09, 2002 at 04:36:03PM -0700, Andreas Dilger wrote:
> One thing that I've noticed (got my first linux-2.5 clone last night) is
> that the kernel build process is somewhat broken by the fact that not
> everything that you need to build is checked out of the repository by
> make.
>
> It appears to handle .c files ok, but it failed for all of the .h files.
> I take it this means that gcc doesn't know anything about SCCS, and it
> would also appear that make is not properly checking dependencies for
> these files, or it would have checked them out, right?
It's a 'feature' of the dependancy setup of the kernel. bk -r get -q
will checkout all of the files everywhere, and the build _should_ work
(there's been times autogenerated files were in the kernel and thus
broke building from a bk repo).
> Also, things like "make menuconfig" and such also fail (because they are
> doing stuff within scripts that have no concept of SCCS or BK). Will
> the new kernel build system take any of this into account?
I don't think they do now, but it wouldn't be too hard I'd think. If of
course the files needed to build/run the tools get checked out :)
> I would prefer if we only checked out as much as we need (instead of
> doing something like 'bk -r edit' which will use up a lot of space in
> each clone for architectures and drivers which I don't need).
Don't -r edit, -r get. You can go and selectively clean out some dirs,
but in short, no.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
On Sat, Feb 09, 2002 at 09:51:10PM +0100, Stelian Pop wrote:
> Would it be possible to do something to keep the 2.4 tree up to date too ?
> (something like checking if the latest incremental patch from kernel.org
> was applied to the tree, and if not, apply it as a changeset and tag) ?
Someone has to do the work, it's certainly possible. That tree is up to date
with what Linus has done.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Sat, Feb 09, 2002 at 04:36:03PM -0700, Andreas Dilger wrote:
> On Feb 09, 2002 13:41 -0800, Larry McVoy wrote:
> > We don't, but we can, and we should. "bk relink tree1 tree2" seems like
> > the right interface.
>
> Yes, this would be great. It should probably only do this for files in
> SCCS and BitKeeper directories, because vim (for example) will do the
Correct.
> One thing that I've noticed (got my first linux-2.5 clone last night) is
> that the kernel build process is somewhat broken by the fact that not
> everything that you need to build is checked out of the repository by
> make.
>
> It appears to handle .c files ok, but it failed for all of the .h files.
This is because the dependencies are incorrect in the makefiles. If you
have correct dependencies in the makefiles, make will do the right thing.
One alternative would be to have a scripts/bk-get which takes as an arg
the architecture[s] you want and gets the files that make sense for
that architecture. That would help somewhat.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Feb 09, 2002 12:26 -0800, Larry McVoy wrote:
> This is my problem. You could help if you could tell me what exactly
> are the magic wands to wave such that you can ssh in without typing
> a password. I know about ssh-agent but that doesn't help for this,
> I know that in certain cases ssh lets me in without anything. I thought
> there was some routine where you ssh-ed one way and then the other way
> and it left enough state that it trusted you, does any ssh genuis out
> there know what I'm talking about? If I have this, I can set up the
> cron job, I'm sure this is obvious and I'm just overlooking something
> but I can't find it.
OK, so to log in or run a command on a remote machine R, from your local
machine L, you need to have a copy of your public key L:~/.ssh/identity.pub
in the file R:~/.ssh/authorized_keys. You can have multiple keys in
R:~/.ssh/authorized_keys. When ssh'ing from L to R, you also need to
have L:~/.ssh/identity available and possibly type in a pass-phrase if
needed (for automated systems you probably do not want a pass-phrase,
so you set it up with its own key).
Just FYI, the rest of the story goes like:
If your L:~/.ssh/identity has a pass-phrase (or if you want to do multi-
hop ssh'ing, I think) you will probably want to use an ssh-agent to hold
all of your private keys. GDM (Gnome X login) will start ssh-agent for
you I believe, and then you have to do "ssh-add [identity file ...]" to
add one or more private keys to the ssh-agent, which will prompt you for a
pass-phrase if needed. If you have multiple private keys (identity files)
then newer versions of ssh-add will try the same pass-phrase for all of
them before prompting you again.
Then, when you ssh over to another machine, and that machine is listed
in /etc/ssh/ssh_config or .ssh/config as "ForwardAgent yes" it will
pass on your private key(s) to a new agent started on the remote machine,
which will allow you to do passwordless ssh to another machine, etc.
Likewise, as long as you have "ForwardX11 yes" for each machine in the
chain, you will be able to start an X session at the far end and it
will tunnel through all of the ssh hops to display on L's screen.
You probably want to have a pass-phrase on all of your private keys,
because if anyone ever could read your ~/.ssh/identity file, they can
effectively do anything you can do, and connect anywhere that has your
corresponding identity.pub file in the authorized_keys file without
a password.
Note also, for most new versions of SSH, it will try SSH protocol 2
before it tries SSH 1. This means that everywhere I said "identity"
it will use "id_dsa", "identity.pub" becomes "id_dsa.pub", and
"authorized_keys" becomes "authorized_keys2". You can change the default
order if you want with "Protocol 1,2" in your ~/.ssh/config file, or
you can add both your L:~/.ssh/identity and L:~/.ssh/id_dsa to the
ssh-agent, and add the id_dsa.pub to authorized_keys2.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
Larry McVoy <[email protected]> wrote:
> This is my problem. You could help if you could tell me what exactly
> are the magic wands to wave such that you can ssh in without typing
> a password. I know about ssh-agent but that doesn't help for this,
Setup your key with an empty passphrase should do the trick.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Feb 09, 2002 16:45 -0700, Tom Rini wrote:
> On Sat, Feb 09, 2002 at 04:36:03PM -0700, Andreas Dilger wrote:
> > One thing that I've noticed (got my first linux-2.5 clone last night) is
> > that the kernel build process is somewhat broken by the fact that not
> > everything that you need to build is checked out of the repository by
> > make.
> >
> > It appears to handle .c files ok, but it failed for all of the .h files.
> > I take it this means that gcc doesn't know anything about SCCS, and it
> > would also appear that make is not properly checking dependencies for
> > these files, or it would have checked them out, right?
>
> It's a 'feature' of the dependancy setup of the kernel. bk -r get -q
> will checkout all of the files everywhere, and the build _should_ work
> (there's been times autogenerated files were in the kernel and thus
> broke building from a bk repo).
Well, I looked at it some more, and "make dep" was totally broken
until I "bk get" the headers. All of the .depend files were empty,
probably because "make dep" couldn't find/read any files. It may
be enough to fix this by having "make dep" do something to "bk get"
each file if it is not there. It still appears to be a bit of
a problem, because before you do "bk get", "find" does not return any
files for mkdep to look at, a bit of chicken-and-egg problem there.
We could also try to "make" each header file, because make is smart
enough to handle SCCS/BK, CVS, etc so we won't be putting BK-specific
knowledge into the make system (try "make -d include/linux/fs.h"). I
don't know for sure, since I've never worked with the build system much.
> > I would prefer if we only checked out as much as we need (instead of
> > doing something like 'bk -r edit' which will use up a lot of space in
> > each clone for architectures and drivers which I don't need).
>
> Don't -r edit, -r get.
Well, write bits don't take up any space. While I can alias vi='bk vim'
to check out a particular file for editing, VIM is not smart enough (or
I don't know how to configure it) to check out files for editing if I
open them from within the editor or use tags to jump to the file.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
Herbert Xu wrote:
>
> Larry McVoy <[email protected]> wrote:
>
> > This is my problem. You could help if you could tell me what exactly
> > are the magic wands to wave such that you can ssh in without typing
> > a password. I know about ssh-agent but that doesn't help for this,
>
> Setup your key with an empty passphrase should do the trick.
Ug. no. That is way way insecure.
Most modern distros have an ssh-agent running as a parent of all
X-spawned processed (including processes spawned by xterms). So, one
only needs to run
ssh-add ~/.ssh/id_dsa ~/.ssh/identity
once, and input your password once. After that, no passwords are
needed.
For those with multiple peer shells and no X-parented ssh-agent, you
will need to run ssh-agent ONCE, like so:
ssh-agent > ~/tmp/ssh-agent.out
and then for each shell, you need to run:
eval `cat ~/tmp/ssh-agent.out`
and then run the ssh-add command from above.
--
Jeff Garzik | "I went through my candy like hot oatmeal
Building 1024 | through an internally-buttered weasel."
MandrakeSoft | - goats.com
On Sat, Feb 09, 2002 at 07:54:29PM -0500, Jeff Garzik wrote:
> Herbert Xu wrote:
> >
> > Setup your key with an empty passphrase should do the trick.
>
> Ug. no. That is way way insecure.
>
> Most modern distros have an ssh-agent running as a parent of all
> X-spawned processed (including processes spawned by xterms). So, one
> only needs to run
> ssh-add ~/.ssh/id_dsa ~/.ssh/identity
> once, and input your password once. After that, no passwords are
> needed.
This is fine for interactive use. But for a daily cron job, it's
just as insecure as no passphrases at all.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Jeff Garzik <[email protected]> writes:
> For those with multiple peer shells and no X-parented ssh-agent, you
> will need to run ssh-agent ONCE, like so:
>
> ssh-agent > ~/tmp/ssh-agent.out
>
> and then for each shell, you need to run:
>
> eval `cat ~/tmp/ssh-agent.out`
>
> and then run the ssh-add command from above.
I keep the following in my .bashrc and use the `agent' command to
initialize the ssh-agent.
# Allow `agent' to start the ssh-agent usefully on all running
# bash instances. SIGQUIT was chosen because it is ignored by
# bash by default, even in non-interactive shells, so that a
# shell not trapping it by some chance won't be terminated.
if test -f ~/.ssh/agent; then
. ~/.ssh/agent
fi
function agent {
killall -q ssh-agent
ssh-agent > ~/.ssh/agent
killall -QUIT bash >/dev/null 2>&1
ssh-add ~/.ssh/identity
ssh-add ~/.ssh/id_dsa
}
trap -- '. ~/.ssh/agent' SIGQUIT
--
"Be circumspect in your liaisons with women.
It is better to be seen at the opera with a man
than at mass with a woman."
--De Maintenon
how does this work when running something from cron? (I think that's the
type of thing Larry is trying to do)
David Lang
On Sat, 9 Feb 2002, Jeff Garzik wrote:
> Date: Sat, 09 Feb 2002 19:54:29 -0500
> From: Jeff Garzik <[email protected]>
> To: Herbert Xu <[email protected]>
> Cc: Larry McVoy <[email protected]>, [email protected]
> Subject: ssh primer (was Re: pull vs push (was Re: [bk patch] Make
> cardbus compile in -pre4))
>
> Herbert Xu wrote:
> >
> > Larry McVoy <[email protected]> wrote:
> >
> > > This is my problem. You could help if you could tell me what exactly
> > > are the magic wands to wave such that you can ssh in without typing
> > > a password. I know about ssh-agent but that doesn't help for this,
> >
> > Setup your key with an empty passphrase should do the trick.
>
> Ug. no. That is way way insecure.
>
> Most modern distros have an ssh-agent running as a parent of all
> X-spawned processed (including processes spawned by xterms). So, one
> only needs to run
> ssh-add ~/.ssh/id_dsa ~/.ssh/identity
> once, and input your password once. After that, no passwords are
> needed.
>
>
> For those with multiple peer shells and no X-parented ssh-agent, you
> will need to run ssh-agent ONCE, like so:
>
> ssh-agent > ~/tmp/ssh-agent.out
>
> and then for each shell, you need to run:
>
> eval `cat ~/tmp/ssh-agent.out`
>
> and then run the ssh-add command from above.
>
> --
> Jeff Garzik | "I went through my candy like hot oatmeal
> Building 1024 | through an internally-buttered weasel."
> MandrakeSoft | - goats.com
> -
> 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/
>
David Lang wrote:
> how does this work when running something from cron? (I think that's the
> type of thing Larry is trying to do)
A simple mutation of this:
> > For those with multiple peer shells and no X-parented ssh-agent, you
> > will need to run ssh-agent ONCE, like so:
> >
> > ssh-agent > ~/tmp/ssh-agent.out
> >
> > and then for each shell, you need to run:
> >
> > eval `cat ~/tmp/ssh-agent.out`
Run ssh-agent and ssh-add once per reboot, such as from
/usr/local/bin/login-bkpull.
>From the cron script, run the eval line shown.
No passwords are prompted for.
Jeff
--
Jeff Garzik | "I went through my candy like hot oatmeal
Building 1024 | through an internally-buttered weasel."
MandrakeSoft | - goats.com
Herbert Xu wrote:
>
> On Sat, Feb 09, 2002 at 07:54:29PM -0500, Jeff Garzik wrote:
> > Herbert Xu wrote:
> > >
> > > Setup your key with an empty passphrase should do the trick.
> >
> > Ug. no. That is way way insecure.
> >
> > Most modern distros have an ssh-agent running as a parent of all
> > X-spawned processed (including processes spawned by xterms). So, one
> > only needs to run
> > ssh-add ~/.ssh/id_dsa ~/.ssh/identity
> > once, and input your password once. After that, no passwords are
> > needed.
>
> This is fine for interactive use. But for a daily cron job, it's
> just as insecure as no passphrases at all.
It is far easier to guess your private key with a blank passphrase.
Jeff
--
Jeff Garzik | "I went through my candy like hot oatmeal
Building 1024 | through an internally-buttered weasel."
MandrakeSoft | - goats.com
Andreas Dilger wrote:
> The problem is that (AFAIK) bk pull does not let Linus pick-and-choose
> which patches he wants to accept as easily as importing them at the time
> he reads each email. It basically assumes that he wants everything that
> is in the repository he is pulling from.
Yes and no. 'bk pull' does indeed make the presumption that Linus will
like or dislike the entire patchset being pulled. That's why one wants
to separate different types of changes into different BK trees. For
example you might have a BK clone with just ext2 fixes, then a BK clone
off of your ext2-fixes tree which contains your ext2 resize work. Or,
if you wanted those separate and not parent-child, you could clone both
ext2-fixes and ext2-resize trees off of Linus's standard tree.
But I disagree a bit. Basically, if you organize the trees from which
Linus would do a 'bk pull' then he can easily (a) 'bk unpull' if he
dislikes everything, and (b) easily inspect each changeset.
I personally plan on sending Linus GNU patches simply for his review, as
I did with the recent swap_device cleanup patch, as well as giving him a
location for doing the 'bk pull'. In that specific case, there was a
tree http://gkernel.bkbits.net/vm-2.5 which contained nothing but that
one change.
Used in this sense, 'bk pull' is really the primary merging tool, and
e-mail is simply a reminder to Linus that he should do a pull.
Jeff
--
Jeff Garzik | "I went through my candy like hot oatmeal
Building 1024 | through an internally-buttered weasel."
MandrakeSoft | - goats.com
> a password. I know about ssh-agent but that doesn't help for this,
> I know that in certain cases ssh lets me in without anything. I thought
> there was some routine where you ssh-ed one way and then the other way
> and it left enough state that it trusted you, does any ssh genuis out
> there know what I'm talking about? If I have this, I can set up the
> cron job, I'm sure this is obvious and I'm just overlooking something
> but I can't find it.
For the paranoid
You ssh from the source to an untrusted chrooted nopriv uid on the target
using a ssh pass phrase and ipchains static ip rules to allow only some
IP's access
A cron or other triggered job on the receiving machine checks the GPG
signatures of the uploaded data and moves/processes it if it matches or
if the key matches blocks off that machine and ID and mails the admin.
Alan
In article <[email protected]>,
Andreas Dilger <[email protected]> wrote:
>
>The problem is that (AFAIK) bk pull does not let Linus pick-and-choose
>which patches he wants to accept as easily as importing them at the time
>he reads each email. It basically assumes that he wants everything that
>is in the repository he is pulling from.
Yes and no.
I hope that the developers that I work enough with for it to matter tend
to be fairly good at keeping things separate (ie separate BK trees for
different development efforts etc), in which case it's not a big issue.
And yes, from at least one developer I have already done a partial pull,
ie taken only partial changes. In that case the changes I disagreed with
were at the end, so it was easy enough to just do a "bk pull" into
another tree, do a "bk undo", and only merge after that.
But I agree - if I end up having to do that more than occasionally, I'm
going to ask that developer to stop using bk at least as far as I'm
concerned (ie he can use bk for himself, but I wouldn't accept bk
patches from developers who cannot keep their stuff cleanly separated).
Linus
In article <[email protected]>,
Daniel Phillips <[email protected]> wrote:
>
>Complaining and whining are not the same thing. Some major contributors
>have complained, that's why Linus takes this seriously.
Well, in all honesty, it's not so much that I take it seriously - it's
not as if the complaints are in any way new (or even more serious than
before - I think we had a much more serious spat a few years ago). The
fact is, people will _always_ complain about the way things are done.
[ This very _same_ "how to maintain" flameware is not only a regular
topic on linux-kernel, it's a regular topic on the BSD lists, on the
gcc lists, and probably on every single bigger software project,
whether open source or not. Why do you think there are so many
different source control packages? ;]
But I _have_ promised Larry for the last two years or so to give BK a
chance (the last time I promised him I'd start using it as of 2.5.0),
and the discussion to a large degree just made me feel I had a good
reason to take a week off and try it out.
I doubt bk per se will really change any of the real issues. It will
almost certainly make it somewhat easier to merge patches from some
people, but I also suspect that those are largely the same people that I
already was pretty good at merging patches from before.
The fundamental issue that I think I (or any human, for that matter)
work best with just a few (on the order of ten) closer contacts, and
that I want people to "network" more is pretty independent of BK or not.
However, in the long run what BK may do is to make it easier to migrate
to a "group model", where the traditional "linus tree" doesn't even
exist any more. I'm not ready to do that yet, but clearly it has to
happen at _some_ point. Nobody lives forever.
And I do like BK so far.
Linus
In article <[email protected]>,
Larry McVoy <[email protected]> wrote:
>
>This is because the dependencies are incorrect in the makefiles. If you
>have correct dependencies in the makefiles, make will do the right thing.
Modulo bugs.
For some reason, on my work machine, "make" will not correctly check out
files that are "include"d from the makefile.
On my home machine, it will.
The really interesting thing is, they're both make 3.79.1.
Besides, I'd at least personally rather do "bk -r get -q" than have to
watch those SCCS files and BitKeeper files. That way the filename
completion works inside the shell too..
Linus
Good day, Larry,
On Sat, 9 Feb 2002, Larry McVoy wrote:
> On Sat, Feb 09, 2002 at 01:01:34PM -0800, David Lang wrote:
> > do you have a script that can go back after the fact and see what can be
> > hardlinked?
> >
> > I'm thinking specififcly of the type of thing that will be happening to
> > your server where you have a bunch of people putting in a clone of one
> > tree who will probably not be doing a clone -l to set it up, but who could
> > have and you want to clean up after the fact (and perhapse again on a
> > periodic basis, becouse after all of these trees apply a changeset from
> > linus they will all have changed (breaking the origional hardlinks) but
> > will still be duplicates of each other.
>
> We don't, but we can, and we should. "bk relink tree1 tree2" seems like
> the right interface.
>
> Right now we aren't too worried about the disk space, the data is sitting
> on a pair of 40GB drives and we're running the trees in gzip mode, so they
> are 75MB each. But yes, it's a good idea, we should do it, and probably
> should figure out some way to make it automatic. I'll add it to the
> (ever growing) list, thanks.
Larry, I'll save you the time.
"freedups -a -d /some/dir [/other/dirs]" will look for identical
files (the -d requires dates to be equal as well as the content) and
hardlink them. It's not terribly efficient, but works marvelously well.
Run it from cron once a week or so, perhaps?
http://www.stearns.org/freedups/
Cheers,
- Bill
---------------------------------------------------------------------------
"Patience is a minor form of despair, disguised as virtue."
-- Ambrose Bierce, on qualifiers
--------------------------------------------------------------------------
William Stearns ([email protected]). Mason, Buildkernel, named2hosts,
and ipfwadm2ipchains are at: http://www.pobox.com/~wstearns
LinuxMonth; articles for Linux Enthusiasts! http://www.linuxmonth.com
--------------------------------------------------------------------------
Linus Torvalds <[email protected]> writes:
> from at least one developer I have already done a partial pull,
> ie taken only partial changes. In that case the changes I disagreed with
> were at the end, so it was easy enough to just do a "bk pull" into
> another tree, do a "bk undo", and only merge after that.
>
> But I agree - if I end up having to do that more than occasionally, I'm
> going to ask that developer to stop using bk at least as far as I'm
> concerned (ie he can use bk for himself, but I wouldn't accept bk
> patches from developers who cannot keep their stuff cleanly separated).
What about BK CSET (or regular patch) submissions from non-core
developers? Would you accept CSETs via email if they are preceeded
by a unified diff and explanation? This would make it much easier
for any non-core developer to avoid having to re-sync their changes
with you if/when you accept that change into your tree.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
On Sat, Feb 09, 2002 at 08:24:46PM -0500, Jeff Garzik wrote:
>
> It is far easier to guess your private key with a blank passphrase.
Please show me how to do this without gaining access to the machine
in question.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Sat, 9 Feb 2002, David Lang wrote:
> I just set this up between a couple machines at work and one thing we
> ended up doing to get it to work was to generate a key without a
> passphrase on it to use for syncing, otherwise the ssh on the machine
> inititing the connection wanted a password to start the connection. you
> also need to do the stuff mentioned for the receiving end so that it
> doesn't ask for a password.
That's ok if you can't type the password as in batch jobs.
Pau
[Larry McVoy]
> This is my problem. You could help if you could tell me what exactly
> are the magic wands to wave such that you can ssh in without typing
> a password. I know about ssh-agent but that doesn't help for this,
> I know that in certain cases ssh lets me in without anything. I thought
> there was some routine where you ssh-ed one way and then the other way
> and it left enough state that it trusted you, does any ssh genuis out
> there know what I'm talking about? If I have this, I can set up the
> cron job, I'm sure this is obvious and I'm just overlooking something
> but I can't find it.
When I'm paranoid I do something like this:
Source host:
$ ssh-keygen -t dsa -b 2048 -f keyfile -P ""
on the target add a line to ~someuser/.ssh/authorized_keys2:
from="allowed.hostname",command="/some/command" ssh-dss AA[and the rest of keyfile.pub]
/some/command looks like this:
#!/bin/sh
if cd /target ; then
:
else
echo FAILED1
exit
fi
if cat > filename ; then
:
else
echo FAILED4
exit
fi
if [ \! -s filename ] ; then
echo FAILED2
exit
fi
prev=".9"
for i in .8 .7 .6 .5 .4 .3 .2 .1 ""; do
mv filename$i filename$prev >/dev/null 2>&1
prev=$i
done
if mv filename.transport filename ; then
check=`sum -r filename | awk '{print $1}'`
echo OK$check
exit
fi
echo FAILED3
The command to send the file is typically:
#!/bin/sh
check=`sum -r /file/to/send | awk '{print $1}'`
reply=`(cat /file/to/send ; sleep 5 ) | \
ssh -l someuser -i keyfile target "echo hello there"`
if [ "x$reply" = "xOK$check" ] ; then
echo Copy OK $check
else
echo COPY NOT OK. Please do something.
fi
--
- Terje
[email protected]
On Sat, Feb 09, 2002 at 03:52:58PM -0800, Larry McVoy wrote:
> On Sat, Feb 09, 2002 at 04:36:03PM -0700, Andreas Dilger wrote:
> > On Feb 09, 2002 13:41 -0800, Larry McVoy wrote:
> > > We don't, but we can, and we should. "bk relink tree1 tree2" seems like
> > > the right interface.
> >
> > Yes, this would be great. It should probably only do this for files in
> > SCCS and BitKeeper directories, because vim (for example) will do the
>
> Correct.
>
> > One thing that I've noticed (got my first linux-2.5 clone last night) is
> > that the kernel build process is somewhat broken by the fact that not
> > everything that you need to build is checked out of the repository by
> > make.
> >
> > It appears to handle .c files ok, but it failed for all of the .h files.
>
> This is because the dependencies are incorrect in the makefiles. If you
> have correct dependencies in the makefiles, make will do the right thing.
Or more specifically, the 'dependancy' stage of the kernel knows
_nothing_ about SCCS. It _might_ not be that hard to hack up the
scripts/mkdep.c program to check if an #include'd file exists (and if it
doesn't, if (any search patch)/SCCS exists, and if so, get it.
> One alternative would be to have a scripts/bk-get which takes as an arg
> the architecture[s] you want and gets the files that make sense for
> that architecture. That would help somewhat.
If it's just a flat list of files, it'd be rather hellish to maintain
I'd think. It _might_ not be too horrible to try and glean files from
CONFIG options (but isn't part of the point of the kernel's current dep
system to not depend on CONFIG_xxx options?) and assume all of include/
is needed.
Or kbuild-2.5 might just work since it does deps in a more 'correct'
manner.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
On Sun, 10 Feb 2002, Andreas Dilger wrote:
>
> What about BK CSET (or regular patch) submissions from non-core
> developers? Would you accept CSETs via email if they are preceeded
> by a unified diff and explanation?
What's the difference here with "bk send"?
I have worked with a few BK patches in email, and I have to say that I
pretty much detest them. The less I have to work with them, the better,
although that may just because I don't yet have the same kind of
infrastructure for them as I have for regulat patches.
Making the infrastructure is not that hard, so if people start sending me
bk patches by email, I can improve it, and I'll probably not dislike bk
send as much as I do now.
(But _please_ do a "bk send" to a file, and edit the file before you send
it, instead of sending directly with that "Bitkeeper patch" subject line.
It looks like "bk send" was really designed for automatic merges, not for
humans)
Linus
Once upon a time, Linus Torvalds <[email protected]> said:
>The fundamental issue that I think I (or any human, for that matter)
>work best with just a few (on the order of ten) closer contacts, and
>that I want people to "network" more is pretty independent of BK or not.
What we need is an "Oracle of Linus" like the "Oracle of Bacon" (aka the
"Kevin Bacon" game). Alan Cox (along with a few others) has a Linus
number of 1 for example. Now the tree just need to be defined better,
so developers can know their Linus number and know the best path for
them to submit patches.
Just a suggestion from a humble user (with a Bacon number of 1 :-) ).
--
Chris Adams <[email protected]>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
William Stearns wrote:
> Good day, Larry,
>
> On Sat, 9 Feb 2002, Larry McVoy wrote:
>
>
>>On Sat, Feb 09, 2002 at 01:01:34PM -0800, David Lang wrote:
>>
>>>do you have a script that can go back after the fact and see what can be
>>>hardlinked?
>>>
>>>I'm thinking specififcly of the type of thing that will be happening to
>>>your server where you have a bunch of people putting in a clone of one
>>>tree who will probably not be doing a clone -l to set it up, but who could
>>>have and you want to clean up after the fact (and perhapse again on a
>>>periodic basis, becouse after all of these trees apply a changeset from
>>>linus they will all have changed (breaking the origional hardlinks) but
>>>will still be duplicates of each other.
>>>
>>We don't, but we can, and we should. "bk relink tree1 tree2" seems like
>>the right interface.
>>
>>Right now we aren't too worried about the disk space, the data is sitting
>>on a pair of 40GB drives and we're running the trees in gzip mode, so they
>>are 75MB each. But yes, it's a good idea, we should do it, and probably
>>should figure out some way to make it automatic. I'll add it to the
>>(ever growing) list, thanks.
>>
>
> Larry, I'll save you the time.
> "freedups -a -d /some/dir [/other/dirs]" will look for identical
> files (the -d requires dates to be equal as well as the content) and
> hardlink them. It's not terribly efficient, but works marvelously well.
> Run it from cron once a week or so, perhaps?
> http://www.stearns.org/freedups/
> Cheers,
> - Bill
Not terribly efficient? That's a bit of an understatement :-)
The findup component of fslint is MUCH quicker, and it's
also written in bash. A quick test against two 2.4.17 trees gives:
1m36s for ./findup /usr/src/linux[12] | ./fstool/mergeDup
18m17s for ./freedups -a /usr/src/linux[12]
Note mergeDup was a quick hack and took 1m30s of findup's time!
I'm going to rewrite it in python ASAP to help with this.
You can download the current version of fslint from
http://developers.antefacto.net/~padraig/fslint.tar.gz
Padraig.
Hi!
> > I don't see why everyone who is using BK is expecting Linus to do a pull.
> > In the non-BK case, wasn't it always a "push" model, and Linus would not
> > "pull" from URLs and such?
>
> I'm all for it. I think it's a good thing.
>
> In the absence of significant latency issues, pull scales better than push.
> It always has. Push is better in low bandwidth situations with lots of idle
> capacity, but it breaks down when the system approaches saturation.
>
> Pull data is naturally supplied when you're ready for it (assuming no
> significant latency to access it). Push either scrolls by unread or piles up
> in your inbox and gets buried until it goes stale. Web pages work on a pull
> model, "push" was an internet fad a few years ago that failed for a reason.
> When push models hit saturation it breaks down and you wind up with the old
> "I love lucy" episode with the chocolate factory. Back in the days where
What's "i love lucy" episode?
Pavel
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
On Feb 10, 2002 12:57 -0800, Linus Torvalds wrote:
> On Sun, 10 Feb 2002, Andreas Dilger wrote:
> > What about BK CSET (or regular patch) submissions from non-core
> > developers? Would you accept CSETs via email if they are preceeded
> > by a unified diff and explanation?
>
> I have worked with a few BK patches in email, and I have to say that I
> pretty much detest them. The less I have to work with them, the better,
> although that may just because I don't yet have the same kind of
> infrastructure for them as I have for regulat patches.
>
> (But _please_ do a "bk send" to a file, and edit the file before you send
> it, instead of sending directly with that "Bitkeeper patch" subject line.
> It looks like "bk send" was really designed for automatic merges, not for
> humans)
Yes, the first time I used "bk send" to send something directly to Ted it
happened that I was offline so I looked into my mail spool at the emails
and also hated it. What I was proposing instead of just "bk send" is to
prepend the changelog entry, a real unified diff, and gzip_uu CSET at the
end. Larry has agreed that "bk send -d -wgzip_uu" wrapping the diff part
of the patch is a bug to be fixed.
So, instead of the current layout of "'This is a BitKeeper patch' comment +
commented-out diff + BK stuff", I would send "CSET ChangeLog + unified diff +
gzip_uu wrapped BK stuff". This would be the output of (probably in a script):
bk changes -r<rev>
bk export -tpatch -h -du -r<rev>
bk send -wgzip_uu -r<rev> -
For example, your recent 2.5.4 release would look like the below, and I
_think_ you could just accept this with "bk receive -a [repository path]",
but I'm not sure how good the BK heuristics are for finding a CSET at the
end of a long patch. I'm only skeptical because the current "bk send"
output comments out the diff part of the output.
[email protected], 2002-02-10 19:24:03-08:00, [email protected]
update version
TAG: v2.5.4
diff -Nru a/Makefile b/Makefile
--- a/Makefile Mon Feb 11 10:44:32 2002
+++ b/Makefile Mon Feb 11 10:44:32 2002
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 5
SUBLEVEL = 4
-EXTRAVERSION =-pre6
+EXTRAVERSION =
KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)
This BitKeeper patch contains the following changesets:
1.262
## Wrapped with gzip_uu ##
begin 664 bkpatch3560
M'XL(`!\#:#P``[V4T6[;(!2&K\-3(/5RLG,.!H(M>5K71ENU=8V<==HMLFEL
MU;$K0[)6\L./6%U255.R1-LP<,'!1X?OY^>,WEK3)2-=5/7"=.2,?FRM2T;U
M4_,8/B^&5>-\(&M;'QBO;#>V73ZNJV;U&+!0$!^;:9>7=&TZFXPPC+8K[NG!
M)*-L^N'V\WE&2)K2BU(W"S,WCJ8I<6VWUG5AWVE7UFT3NDXW=FF<#O-VV6^W
M]@R`^4_@)`(A>Y3`)WV.!:+F:`I@7$F^RU:V2W,@%R(@CQGO47$AR"7%D$E&
M@8U]1Z`8)XPG$`6@$@"Z)S5]@S0`\I[^W<-<D)RN'@KMS("U:AORB?IBN2*S
M'402'-D(`0WD[8%BK_6]N:MJ\[+6.%(]@)K(OI"ZB'/4JA"QT&(?G->9//:(
M<8AZ%))+<JQDS_\.%*Y_+QF*/Y$,_H5D+W69T[6W1LB)I0L_:C^./2LJ$)ZX
M;R>HO+':+_:'G7:4WGM%>ZVWG[B*X@VR"1MLAE*=;#/\3S8;+N<-#;H?0_=`
M9UN:)XAQR2F2J\TT_?XU._\VS>97-U]HNGLY\]+D]W:U3/%.<B5B)#\!WOU:
%+9D%````
`
end
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
On Mon, 11 Feb 2002 11:51:04 +0000, Pavel Machek <[email protected]>
wrote:
>Hi!
>
>> > I don't see why everyone who is using BK is expecting Linus to do a pull.
>> > In the non-BK case, wasn't it always a "push" model, and Linus would not
>> > "pull" from URLs and such?
>>
>> I'm all for it. I think it's a good thing.
>>
>> In the absence of significant latency issues, pull scales better than push.
>> It always has. Push is better in low bandwidth situations with lots of idle
>> capacity, but it breaks down when the system approaches saturation.
>>
>> Pull data is naturally supplied when you're ready for it (assuming no
>> significant latency to access it). Push either scrolls by unread or piles up
>> in your inbox and gets buried until it goes stale. Web pages work on a pull
>> model, "push" was an internet fad a few years ago that failed for a reason.
>> When push models hit saturation it breaks down and you wind up with the old
>> "I love lucy" episode with the chocolate factory. Back in the days where
>
>What's "i love lucy" episode?
> Pavel
"I Love Lucy" was a 1950s sitcom on television, one of the first and
very good indeed.
In the episode referred to, Lucy and her friend Ethel get hired as
candy-packers in a candy factory. The candies come by on a conveyer
belt and the girls put them in boxes. Everything went smoothly... the
manager reviewed the situation, and congratulated them. Then they
increased the conveyer belt flow. After a few more cycles, the candy
was coming too fast. So they started taking the candies, stuffing them
into pockets, blouses, mouths... and the scene ends with the manager
arriving back madder then heck.
john
--------- Received message begins Here ---------
>
> Hi!
>
> > > I don't see why everyone who is using BK is expecting Linus to do a pull.
> > > In the non-BK case, wasn't it always a "push" model, and Linus would not
> > > "pull" from URLs and such?
> >
> > I'm all for it. I think it's a good thing.
> >
> > In the absence of significant latency issues, pull scales better than push.
> > It always has. Push is better in low bandwidth situations with lots of idle
> > capacity, but it breaks down when the system approaches saturation.
> >
> > Pull data is naturally supplied when you're ready for it (assuming no
> > significant latency to access it). Push either scrolls by unread or piles up
> > in your inbox and gets buried until it goes stale. Web pages work on a pull
> > model, "push" was an internet fad a few years ago that failed for a reason.
> > When push models hit saturation it breaks down and you wind up with the old
> > "I love lucy" episode with the chocolate factory. Back in the days where
>
> What's "i love lucy" episode?
It is an old TV show showing a queue overflow - The chocolate machine was
producing candy faster than the personnell could handle and dispose of it.
I think it was being boxed - the skit starts out with the machine on slow,
and a brief training session by a supervisor. The supervisor verifies that
the candy was handled properly at the slow speed. Then she leaves. The
machine makes a sudden jump in production, close to the limit of the
personnel (Lucy and Vivian) who just manage to keep up.
Then the machine gradually increases the production rate. At first, they
toss exess in to another box, then start trying to eat it, then dropping
on the floor .... until the supervisor returns to turn off the maching.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [email protected]
Any opinions expressed are solely my own.
Padraig Brady wrote:
> William Stearns wrote:
>
>> Good day, Larry,
>>
>> On Sat, 9 Feb 2002, Larry McVoy wrote:
>>
>>
>>> On Sat, Feb 09, 2002 at 01:01:34PM -0800, David Lang wrote:
>>>
>>>> do you have a script that can go back after the fact and see what
>>>> can be
>>>> hardlinked?
>>>>
>>>> I'm thinking specififcly of the type of thing that will be happening to
>>>> your server where you have a bunch of people putting in a clone of one
>>>> tree who will probably not be doing a clone -l to set it up, but who
>>>> could
>>>> have and you want to clean up after the fact (and perhapse again on a
>>>> periodic basis, becouse after all of these trees apply a changeset from
>>>> linus they will all have changed (breaking the origional hardlinks) but
>>>> will still be duplicates of each other.
>>>>
>>> We don't, but we can, and we should. "bk relink tree1 tree2" seems
>>> like the right interface.
>>>
>>> Right now we aren't too worried about the disk space, the data is
>>> sitting on a pair of 40GB drives and we're running the trees in gzip
>>> mode, so they
>>> are 75MB each. But yes, it's a good idea, we should do it, and probably
>>> should figure out some way to make it automatic. I'll add it to the
>>> (ever growing) list, thanks.
>>>
>>
>> Larry, I'll save you the time.
>> "freedups -a -d /some/dir [/other/dirs]" will look for identical
>> files (the -d requires dates to be equal as well as the content) and
>> hardlink them. It's not terribly efficient, but works marvelously
>> well. Run it from cron once a week or so, perhaps?
>> http://www.stearns.org/freedups/
>> Cheers,
>> - Bill
>
>
>
> Not terribly efficient? That's a bit of an understatement :-)
> The findup component of fslint is MUCH quicker, and it's
> also written in bash. A quick test against two 2.4.17 trees gives:
>
> 1m36s for ./findup /usr/src/linux[12] | ./fstool/mergeDup
> 18m17s for ./freedups -a /usr/src/linux[12]
>
> Note mergeDup was a quick hack and took 1m30s of findup's time!
> I'm going to rewrite it in python ASAP to help with this.
>
> You can download the current version of fslint from
> http://developers.antefacto.net/~padraig/fslint.tar.gz
OK I've updated fslint which can be downloaded @
http://www.iol.ie/~padraiga/fslint/fslint-1.11.tar.gz
To merge 2 linux trees you do: ./findup -m /usr/src/linux[12]
This will take about 37 seconds (note freedups takes 15
minutes to do the same). Note be careful that your editor
handles hardlinked files as you expect.
Padraig.
On Sat, Feb 09, 2002 at 08:24:46PM -0500, Jeff Garzik wrote:
> It is far easier to guess your private key with a blank passphrase.
I challenge you to present a method for doing so.
On Wednesday 13 February 2002 12:13 pm, Aaron Lehmann wrote:
> On Sat, Feb 09, 2002 at 08:24:46PM -0500, Jeff Garzik wrote:
> > It is far easier to guess your private key with a blank passphrase.
>
> I challenge you to present a method for doing so.
Your public/private key pair are pretty straightforward public key
cryptography. If you can brute force one given the other, it wouldn't be
safe to use it over the wire in the first place.
The point of having a passphrase is that some really paranoid people want to
have both a key AND a password to get into their box. A password in and of
itself isn't all that secure, since any human memorizable password contains
so little information it would be trivial to break computationally via brute
force (if you can arrange a brute force attack, which login tries to prevent
with the ~3 second delay between attempts, but they still tend to get written
down, or people watch keystrokes over your shoulder...). And a key you carry
around with you on a floppy or propogate to multiple boxes can be stolen
(copied) from any of those places without you necessarily knowing about it.
In terms of brute forcing the key, the passphrase adds a fairly trivial
number of bits to the key. It's not "far" easer, an 8 character mixed case
nonsense password with numbers and punctuation mixed in is still less than 6
bits per character, or at best an extra 48 bits. You can select a 1024 bit
key if you want to be really really paranoid.
Not that it's worth it. Keys get exponentially more difficult to brute force
as the key length increases. I read part of a book a long time ago (might
have been called "applied cryptography") that figured out that if you could
build a perfectly efficient computer that could do 1 bit's worth of
calculation with the the amount of energy in the minimal electron state
transition in a hydrogen atom, and you built a dyson sphere around the sun to
capture its entire energy output for the however many billion years its
expected to last, you wouldn't even brute-force exhaust a relatively small
keyspace (128 bits? 256 bits? Something like that).
Somebody else here is likely to recognize the above anecdote and give a more
accurate reference. Book title and page number would be good...
Rob
On Wed, Feb 13, 2002 at 07:22:57PM -0500, Rob Landley wrote:
> In terms of brute forcing the key, the passphrase adds a fairly trivial
> number of bits to the key. It's not "far" easer, an 8 character mixed case
> nonsense password with numbers and punctuation mixed in is still less than 6
> bits per character, or at best an extra 48 bits. You can select a 1024 bit
> key if you want to be really really paranoid.
I agree that it isn't worth it.
I assume that Jeff didn't understand the principles behind public key
cryptography that SSH uses which keep communications secure unless the
private key is compromised (and the private key should never leave
client machine). When you have a passphrase, you encrypt this private
key with a hash of it. Not having a passphrase removes this layer of
security, but if you include the passphrase in a script for automatic
use you're undoing any advantage that a passphrase gives you in the
first place.
In short, to compromise a private key without access to that key
(which presumably only you would have if the key was on your system,
and you must assume that if someone could access your private key they
could access any passphrase you were storing in a script to facilitate
automatic use of it), you'd have to either have unheard of amounts of
computational power and a few millenia on your hands, or come across a
mathematical breakthrough. I certainly hope that Mr. Garzik has not
broken public key cryptography!
Note that you can't compare public key bits to passphrase bits (which
are more like symmetric key bits). You probably know this.
> Not that it's worth it. Keys get exponentially more difficult to brute force
> as the key length increases. I read part of a book a long time ago (might
> have been called "applied cryptography") that figured out that if you could
> build a perfectly efficient computer that could do 1 bit's worth of
> calculation with the the amount of energy in the minimal electron state
> transition in a hydrogen atom, and you built a dyson sphere around the sun to
> capture its entire energy output for the however many billion years its
> expected to last, you wouldn't even brute-force exhaust a relatively small
> keyspace (128 bits? 256 bits? Something like that).
That was Applied Cryptography. I believe he said that the energy
output of a supernova was insufficient to cycle a counter through
about 2^190, based on accepted thermodynamic principles and data. Of
course, this makes brute force of something like a 256 bit symmetric
key completely infeasible and bounded by physical law. Not that 128
bits is very shabby, but it only takes a few billion years of all the
current computing power on earth to brute force something like that.
Rob Landley <[email protected]> writes:
> Not that it's worth it. Keys get exponentially more difficult to
> brute force as the key length increases. I read part of a book a
> long time ago (might have been called "applied cryptography") that
> figured out that if you could build a perfectly efficient computer
> that could do 1 bit's worth of calculation with the the amount of
> energy in the minimal electron state transition in a hydrogen atom,
> and you built a dyson sphere around the sun to capture its entire
> energy output for the however many billion years its expected to
> last, you wouldn't even brute-force exhaust a relatively small
> keyspace (128 bits? 256 bits? Something like that).
>
> Somebody else here is likely to recognize the above anecdote and give a more
> accurate reference. Book title and page number would be good...
Bruce Schneier's "Applied Cryptography" (second edition, may be in the
first edition as well), pages 157-158 ("Thermodynamic Limitations").
--
Hilsen Harald.