"Stateless Linux" project

seth vidal skvidal at phy.duke.edu
Wed Sep 15 06:40:37 UTC 2004


> Great idea.
> Imagine being able to bring your identity/keys/config info on a USB
> stick to a conference, or a branch office of your company, or hotel
> room.
> There are laptops in the conference rooms for you to do a presentation,
> or public machines for you to work on.
> Insert the bootable USB stick, it boots a minimal kernel in RAM then
> sets up a VPM to the Stateless Linux server back in your
> department/office. Installs to the laptop and you are off.
> Hopefully the shutdown sequence does a sync back to the server.
> 
> I blue-skyed the idea of bringing a complete distro on a large USB stick
> at the UKUUG meeting this year. This is a much better concept.
> 
> No more lugging laptops about.

So I don't mean to be a wet blanket but:
 Most people and many IT groups cannot successfully make a video
projector work for presentations. Do we seriously think that something
as complex as what is being suggested has a snowball's chance in hell of
succeeding.

I know this is all pie in the sky but cmon folks, let's bound ourselves
a little bit in reality. Moving as much data as we're talking about for
a distribution and even remotely having the hope of getting it
functioning on whatever goofy hardware some misc location has is as
close to delusional as you can get.

So why not take a few steps back from the ubiquitous computing, I-take-
my-desktop-with-me-wherever-I-go model and try to achieve a few limited
goals:

1. fool proof pxe configurations out of the box in the install of the
dhcp server or even maybe a pxelinux package!
2. a good syncing file system or backup tool that isn't ridiculously
difficult to configure for the average user.
3. a network filesystem that has:
  - robustness
  - locking
  - strong authentication
  - success in working over high-latency connections
  - doesn't piss off kernel developers by it's mere existence.
  and has all of those things, at the same time. Hell, I'd take 4/5.
4. A usb implementation that has a mode other than 'panic and die w/
unhelpful error message' when it encounters a problem.
5. a firewire implementation that doesn't make most kernel developers
cringe.

What do you think about starting with this list before the flights of
fancy and delusions of grandeur are undertaken?

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.

-sv








More information about the fedora-devel-list mailing list