From: Michele Andreoli (m.andreoli@tin.it)
Date: Tue Nov 06 2001 - 11:29:45 CET
On Tue, Nov 06, 2001 at 08:13:55AM +0100, Karl-Heinz Zimmer nicely wrote:
>
> does this "being obsolete" indicate you are going to reorganize muLinux?
> If so please try to do it in a way that the _1_ floppy solution will
> still be working!
>
Periodically, I return back on this well-known problem. On the other
hand, the first floppy is the mulinux's "neck of bottle": it destroy any
attempt to upgrade the kernel.
But an old kernel prevent the possibility to mount new Linux EXT2 disks, so
I think the "rescue" nature of the first floppy is being overvaluated,
a this moment, isn't true?
Maybe, a set of workaround can be designed; more imagination is required.
I think muLinux requires a lot of restyling. Some guidelines and
hypothesis:
Home site
---------
The muLinux home site is so bad, but so bad that I'm ashamed to
publicize the link, and still I'm hidding it to my strict relatives.
Packages yes, packages no (urgency=low)
-------------------------
To make muLinux a package-based distro is still more complex to
realize and mantain for a single person. It is difficult to design
the set of packages and to distribute them using floppy-disk as
preferred media. In that, it resemble to old Slackware.
So, I think, muLinux will rest addon-based.
But add-on have to be redesigned
A new addon concept (urgency=high)
----------------------------------
A new kind of archive (for example: XYZ.add) made of two parts:
"control-part" (10k) and "data-part" (the rest).
The loader extracts the 10k on the head, the "control part", and extract
vital informations from it, like mount points, content's description,
etc. The data-part is still tar+bzip2.
In this way, the loader can load also thirth part add-ons.
For those who like technicism:
# extract control-part
# dd if=XYZ.add bs=1k count=10 | gzip -d > /setup/addons/XYZ/control
# .. control-part analisys ..
# extract data-part
# dd if=XYZ.add bs=1k skip=10 | bzip2 -ds | tar -xf -
Add-ons and Setup
-----------------
Addons must be moved out of the Setup control. Setup only must
manage daemons and utilities.
To populate /setup/fun has to be demanded to the addon-loader
(examining the control-part); the same for the "order" in which they
have to be started and stopped.
Oh, mon dieu, all modern Linuxes works in this way!
Actual design is simply crazy and anti-economic.
Sync with the server
--------------------
With the new addon concept, a new script can be developed: upgrade
or download an addon using a PPP connection. A sort of Debian apt-get.
A new rescue-floppy concept
----------------------------
A new dialog-based script, able to create the rescue-floppy, following
precise request from the user, linking it only with requested
modules and tools.
I think the all-in-one rescue-floppy is now a bumping concept, because
kernel 2.4 is big, big.
Maybe, with some trick, should be possible to create a basic rescue-floppy
without start muLinux, using the "mu" script.
The better, should be to have a 1440 rescue, dos-formatted, booting
with syslinux. In this way, to add something in it is very, very
simple topics.
The new "BASE" floppy disk
--------------------------
The disk should contains only libc5 tools, the simplest shell, E3 editors,
and other assembly routines. If disk-space is enough, it should
contains the PPP code, in order to download the remaining floppy from
Internet.
Dual libraries
---------------
I produced a lot of systems with libc5 and libc6: this dualism works
very well. The "core-part" (booting, UNIX shell and commands, etc) is libc5;
the "application-part" is libc6, at the state-of-art.
On the other hand, this is true also for actual muLinux: the PERL addon
activate also libc6, an old release of it.
X-Windows 4.1
-------------
To upgrade X is also on the wish-list. The 4.* serie is incredibly easy
to setup: autoprobing, no modelines, etc. Oh, too great to have X4.1!
Why? Why?
------------
Because the kernel 2.4 is a such wonderful world, and we can have
a complete access to Sound, PCMCIA, USB, irDA (infrared), etc. also
under the rustic land of muLinux.
How to proceed?
---------------
I do not know. I'm expecting comments and proposal from You.
One solution is to freeze the actual muLinux release on Sunsite.Auc.dk
and to start another release on the SourceForge, maybe with
another mailinglist, devoted to developing.
All that, anyway, requires a formidable work, and I have no free-time
as at the beginning of this project.
Michele
-- I keep trying to locate a meeting of Quantum Physicists. But everytime they set a meeting time, the location changes. And vice versa -- Anonymous --------------------------------------------------------------------- To unsubscribe, e-mail: mulinux-unsubscribe@sunsite.dk For additional commands, e-mail: mulinux-help@sunsite.dk
This archive was generated by hypermail 2.1.6 : Sat Feb 08 2003 - 15:27:20 CET