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
