On Wednesday 15 September 2004 03:05 am, seth vidal wrote:
On Wed, 2004-09-15 at 08:01 +0100, John Hearns wrote:
> On Wed, 2004-09-15 at 07:40, seth vidal wrote:
> > > Great idea.
> >
> > I'm sorry if I sound like a curmudgeon but this is just what happens
> > when you hear developers promising the world year after year and the
> > world simply never showing up.
>
> Point(s) taken. I won't argue - you are right.
>
> However, I'd just like to flag up the popularity of Knoppix.
> Who really would have predicted two years ago that it would be common
> for people to hand out live CDs at public meetings, or engineers take
> along a Knoppix CD to rescue and diagnose sick systems (I do).
> At the UKUUG meeting there was a presentation from Sunderland University
> on preparing custom Knoppix CDs for their staff and students this year.
> Other places will be doing similar.
> I fully recognise this is a different scenario.
You are indeed correct. And what would the world be if there wasn't some
pie-in-the-sky dreaming. Knoppix is not that different a scenario but I
would like to bring up a useful point. Knoppix has to do very similar
things as stateless linux will need to do insofar as hardware detection
and configuration.
how many of us have popped in a knoppix to a new machine only to see it
fail spectacularly to figure out what we just inserted it in? I think
everyone has. HW detection has a long way to go, not to mention drivers.
-sv
And Knoppix uses Kudzu.
In response to Rudi:
Another problem to worry about is saturation of the link upstream.
I'm
sure the average user wouldn't want the browser choked by rsync. Yes,
you can tell rsync to use at most N KB/s, but that's not always easy to
get right, if the user is in the position to estimate it at all - not to
mention that link speed might change at any time for e.g. mobile users.
And you run into the risk of the opposite scenario: you are forcing
rsync to use only a fraction of the bandwidth, when there's nothing else
using the rest.
Well, we could setup a bandwidth sharing policy by default, like the SFQ, I'd
imagine that should do a decent job of managing the bandwidth between what
the client is doing and the background rsync (or equivalent).
-R