[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: "Stateless Linux" project

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]