From: Michele Andreoli (m.andreoli@tin.it)
Date: Fri Nov 03 2000 - 21:37:24 CET
On Fri, Nov 03, 2000 at 04:59:59PM +0100, Dumas Patrice nicely wrote:
> Michele Andreoli a écrit :
>
> > Hello,
> >
> > It's the time to improve the the 'client side' in muLinux.
> > It is better to split the basic functions in muLinux in two
> > parts: server and workstation.
>
> I also think it is a good idea.
>
> I have comment about another thing. Maybe you should take advantage of that
> change to remove any link between any add-on and /usr/local. I don't know if
> it is only me, but I like to have that directory to put things I have done
> myself. It is more important for hd based muLinux, but it is (for me) a
> feaure that could be interesting. Oh maybe, I am too conservative, I also
> shoud use every other directory ;-).
I understand your point, but in the RAM muLinux I have to attach this
directory in some place! Otherwise, it will be only a empty directory.
A this stage (in my developement version) /usr/local is a provvisory
link to the SRV addon: /usr/srv, so many old script still works.
But you point is fine: I have to release this dir under the control
of the user. In the RAM system, it remains only an attach point
>
> Well, as you are asking for conceptual question, I have 3 "conceptual"
> proposals.
>
> 1) I have remarked that there was 2 kinds of informations in the .cnf files.
> One is about the values stored, the other is the values stored. So maybe it
> would be cleaner to have the information about the storage put in another
> location, for example in the corresponding .fun, so that stuff that can have
> the values modified is apart from stuff that don't have to be modified. It
> leads to another benefit, that is the information that doesn't change isn't
> duplicated anymore, so this will save space in the /startup files, and maybe
> it would become possible to store 2 different profiles on the floppy.
Do you means to separate dynamic and static info in the *.cnf pool?
But the static part is only a little percentage: the RESOURCE variable,
that store the basic info about resource, like "ntfs support", etc.
The most import variables are ACTION= (a bad name: should be STATUS),
and VAR_LIST.
So, what is static?
>
> 2) I think that /a, /c, /cdrom should be moved to /mnt (for example) so that
> automatic writing in /etc/fstab, for the kind of "automatic" mounting that is
> done should be expanded without overcrowding the / directory. For example, I
> have a mount point for loop (/mnt/loop), a mount point for 2 cdroms drives
> (one being a burner), for 2 floppy drives, my dos drive, a linux partition,
> an external hard drive that goes in the parallel port.
This is the RedHat way-of-life; so cdrom is mounted in /mnt/cdrom.
I do not like that, sorry. I like economy.
> I don't know if
> muLinux is going to support all these devices, but it allready support some,
> so for the scalability, I advocate /a,/c and /cdrom to be placed in another
> directory that /. And also maybe /startup, (but this point isn't as clear
> IMO, as /startup is really specific to muLinux).
Oh yes, it is *totally* muLinux specificy :-)
What's the problem in seeing this directories in the top hierarchy?
>
> 3) I haven't dug much in the scripts to know more about this, as I have never
> really looked at add-ons and the way they are handled, but I don't like the
> fact that .fun related to add-ons are located on the root floppy. I think it
> would be better if they were with the add-on, so that it would save space on
> the root floppy, but also be conceptually more clear (IMO).
I, many times, pondered on that. This script are currently in the startup
disk because they are loaded by the /bin/setup script: the Setup script
do not differentiate from addon and other resource.
Why do not put them on the addon itself? Because they mantains a lot
of info required at the stage of unpacking. The most important are the
"mount point" and the "info screen".
Without know the "mount point", I can't unpack, because I can't trust
on the availabilty of a big work-space.
The only work-around is to abandon the .tar.bz2 format and to introduce
a form of package. The addons should be created in two segment: INFO+DATA.
The first segment, few kB, a little tgz archive?, should mantains any
info about addon, like: mount_point, info, pre- and post- install
scripts, etc.
With this solution, i can load the INFO part with a command like:
dd if=/dev/fd0H1722 bs=1k count=20k | gzip -dc
| (cd /setup/fun ; tar -xf-)
After that, I have to read interpret the INFO part and load the DATA
part:
dd if=/dev/fd0H1722 skip=20k ... etc ...
>
> What do you all think about all that ?
>
[snip]
Thank you, for the useful discussion on this subject. Many improvements
can be planned, but that are not urgent. A way to answer to all your
question is: a package manager! It is not hard to achieve, but
requires also an enourmous uploading task with my modem.
I oscillate from two stage: improve/fill. A this moment I'm in the "fill"
stage :-)
Michele
-- "I'd like to conclude with a positive statement, but I can't remember any. Would two negative ones do?" -- Woody Allen --------------------------------------------------------------------- To unsubscribe, e-mail: mulinux-unsubscribe@sunsite.auc.dk For additional commands, e-mail: mulinux-help@sunsite.auc.dk
This archive was generated by hypermail 2.1.6 : Sat Feb 08 2003 - 15:27:16 CET