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

Re: SEUL: Partitioning

> The file could be a fixed size; it doesn't have to be dynamic. umsdos/uvfat
> would be better choices if a resizable filesystem was necessary - I don't
> know how difficult it would be to change ext2 so that it could be resized,
> but I have a feeling it would not be easy because of inode tables,
> superblock copies, and block groups being calculated on the initial size of
> the disk.
Well...  Fixed size will work, but how do we determine how big to make it?  If 
the user is in 'trail mode', they want it to be only as big as necessary, else 
that's the first thing they delete when it's time to install Diablo.

As for a filesystem that *can* resize, there are several log-structured 
filesystem projects out there.  If we can influence one of them to stabilize 
and release, that may be the basis for a loopback root.  Certain filesystems 
are specifically tuned for strange underlying hardware, allowing us to put 
traps in to allow the filesystem to "sense" the underlying structure in the 
FAT filesystem.  The alternative is to do a defrag from Linux, make sure it's 
a contiguous file the facist way (do it behind the kernel's back) and make it 
-RHS so nothing fiddles around with it.

> That's why I suggested the loopback method - this eliminates the one part of
> the install process which is most likely to confuse new users. Don't forget
> that a slightly more computer literate person would also be very suspicious
> of something "automatically" adjusting his/her partition tables - it would
> sound too much like "Win95 is autodetecting your hardware, please wait"
> which is often followed by a system crash.
I agree there.  That's something I wouldn't want anything to do for me, but 
then I'm the type that plans partition tables in advance based on head 
movement (swap in the middle 'cause the head's always "closer") and try to 
align things on cylinder boundaries (OK, that's on Sequent boxes, but you get 
the point...).

The average user won't want to know that we're screwing around with his 
partition tables, just that we're setting up his system.  And also plz note 
that we won't be crashing his/her system for him/her.... ;-)  An extra level 
of verbosity over what M$ gives will be an advantage both for the clueless 
user, the semi-clueful user, and for tech support if it's ever needed.  M$ 
tech support (or whoever they've farmed it out to this week) just says "hang 
on the line (@$2.00/min) and try it again", not necessarily because they want 
the money (OK, I take that back...), but because they don't have a freaking 
clue what went wrong!

> Anyway, once the user has played with loopback-Linux for a while, then they
> will either love it or hate it. Uninstalling is then as easy as
> "erase c:\linux.dsk" - a major point if this is going to be user-friendly.
True..., though thinking anyone would ever want to *remove* SEUL is kinda 
defeatist... ;-)

> Sorry about pushing this idea so hard, but I really think that it would be a
> useful option.
I think it's a good idea too, we just have to make sure it's implemented 
correctly.  There are a huge number of variables we have to take into account, 
and if we don't do it correctly the user won't necessarily like what they get.


        Erik Walthinsen - Programmer, webmaster, 3D artist, etc.   __
  __                                                              / /\
 /  \           omega@sequent.com         Work: (503)578-5314    / /  \
|    | M E G A  omega@aracnet.com         Home: (503)281-4281   / / /\ \
_\  /_          psu12113@odin.cc.pdx.edu  Majoring in CS       / / /\ \ \
                                                              / /_/__\ \ \
Omega Station: http://www.aracnet.com/~omega/                /________\ \ \
     Info on Linux, Graphics, Descent, Laptops, etc.         \___________\/

Simple End User Linux Mailing list
To be removed from this mailing list send a message to majordomo@txcc.net
with the line
unsubscribe seul-project
in the body of the letter.