Re: SEUL: Comments about the loopback idea and the waste of resources

[Thomas Molesworth <thomas@bass.almac.co.uk>]

On 1 Jul 1997 jfm2@club-internet.fr wrote:

> At first sight it seems simple.  You use initrd (see Kernel Doc),
> loadlin loads the initial Ram disk and in it Linux finds losetup for
> loading the initrd disk.  The problem is than you have to mount the DOS
> partition so you will be unable later to put the loopback image at /.

I see loopback as working more like a partition than a filesystem on top of
another filesystem. It may be possible to chroot /loopback. I don't believe
that initrd is necessary when using loopback.

> And there are people speaking of patching the kernel.  Well who will
> do it?  Any kernel hackers here?  And nobody is asking if the loopback
> interface is really needed.

I'd do it - it shouldn't be too hard.

> There is a simple solution if you want avoiding the user
> partitionning: it is called UMSDOS.  Yes I know it is unefficient.
> This is a VERY GOOD point: the user knows UMSDOS is only for testing,
> if he likes Linux he will try the full install, if you give him
> something reasonably efficient on a DOS partition then Linux will stay
> for ever there looking like just another DOS program.  With a bit of
> luck you will have some users buying Windows "because it is needed for
> running SEUL".  :-)

umsdos is VERY slow (or at least I have always found it to be so), and it
also suffers from the 32K cluster size or whatever it is that MSDOS inflicts
on 3.2gig drives. Loopback should, in theory, be able to run at the speed of
normal ext2 filesystems because it can ignore the FAT system behind it after
the start+end offsets are found.

I agree with the point about it reducing the number of users who take the
step of a partition install, but at least they'd be running SEUL. More to
the point, they'd be running Linux.

> There is also a general remark: there are a lot of people proposing to
> redo things already existing specially in the install part.  The
> loopback idea instead of UMSDOS is an example.  Another is the idea of
> building a SEUL install starting from nil.  Sorry but what is wrong
> with the RedHat 4.2 install?  It is a piece of cake, needs only one
> floppy and it is able to connect to an FTP site and install from there
> without need of a CD.  Well two things are wrong, partitionning and
> the network part.  Fix the network and give him either a better fdisk
> (one who does the job with little user intervention) or at least a
> utility who bases on free disk space to advise the user about how to
> partition.  Hack the install a bit to add UMSDOS support and you have
> an instant user friendly install.  How much time for developping that:
> a couple of man/weeks at most (discounting the better fdisk).  And yes
> we can do it: RedHat is GPLed.

I haven't got RHv4.2 (just 4.1), but I found the install was not
particularly friendly, crashes at the slightest opportunity (changing VTs
crashed it for me, although once installed Linux works fine for me), and
when things go wrong it doesn't know how to cope.

> Sorry but the real weakness of present installs is not being difficult
> to install (RedHat and LST are pretty easy), it is later when using
> them than users have problems.

Many problems do appear later, I agree. However, the installation is often
not as straightforward as it could be.

> So I really don't see why use precious resources in grandiose install
> projects when there are more important problems to solve in the area
> of the day to day use of Linux.

We need a list, a specification, and a group of co-ordinators.

--
Thomas Molesworth            (thomas@bass.almac.co.uk)

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