Knoppix to Debian - A Roadmap what needs to be done
Hi,
first let me introduce to you.
My Name is Fabian Franz, I am 20 years old and studying computer science in
the second semester on the university of Karlsruhe.
I did start to work with Knoppix last year and did make a initial port to PPC
on the last LinuxTag.
I am still a major contributor to Knoppix and have some sponsored packages in
debian. (netpipes, testdisk (until I had build-problems), slurm, qtparted)
and my own packages for knoppix will follow.
1. I propose to have a new section "livecd" for packages that need to be in
debian, so that you can install everything from one hand. As I am no
debian-developer you'll have to make the necessary negotiations / policy
changes that allow that. There will be packages, that are just necessary on a
live-cd.
2. I think the most important step is to have a official CVS / arch for
knoppix, which will hopefully soon be reality. (LinuxTag team is working on
that)
It'll make knoppix development more transparent and allow to work on the
packages in the first place.
Soon after LinuxTag I had almost all packages lintian clean, but I lost sync
again, which would not have happened if I had a CVS at that time.
3. There are currently 2 build processes for knoppix:
- Klaus build scripts, which are speed optimized and have the need to boot
into the system, then master from there.
- chroot, make some changes, clean up, master.
The first scripts have the advantage that they do everything necessary to have
a clean boot-cd. Yes, there are scripts that can do that and yes they are
available from web (a bit outdated (for the still to be released 3.4), but
I'm almost sure Klaus would publish his new ones in CVS)
The second solution is what most "Remastering"-scripts / howtos propose, it
has the advantage that there is no need to boot into the system.
4. Kernel and Hardware Detection:
I am not sure that the Knoppix-scripts + hwsetup (based on kudzu without its
flaws (e.g. being too aggressive)) will work with a plain debian kernel.
As far as I have understand the debian-kernel is very modular. Well perhaps
its a bit too modular. I dunno how knoppix would react to having to load the
ide-support first.
Our "boot-floppies" linuxrc / miniroot.gz and the whole knoppix-autoconfig
concept is grown up.
Well this has disdavantages, but one of the mail goals is still reached:
Knoppix with an almost vanilla kernel runs on most of the hardware and does
not crash.
And if it does crash we have "cheatcodes" to avoid this. Some are kernel
parameters, but there are mor to disable acpi, ide-scsi-emulation, scsi, usb,
sound, and so on.
Gnoppix for example in my opinion does a rather bad job (yes I filed already a
bug report) as it disabled the noscsi cheatcode (by building it into the
kernel), thus letting my machine crash. It also disabled the "expert
concept".
In my opinion it is important to have some concept to disable
hardware-detection features and I found cheatcodes a convenient way. (Well
there is a concept with grub-menus, but that are details)
I don't know if discover can support all of that yet, so I would propose to
work with the standard knoppix packages for the live-CD and do a smooth
migration.
One step could be to modularise knoppix-autoconfig, but I have not yet found
the need to do so ...
You must understand: Most of the things knoppix uses are there for certain
reasons. Of course it needs to be checked if they apply still, but for
example hwsetup is nice, as it shows a progress meter. I dunno about discover
here.
Hardware detection for Knoppix also means: Setup of X11-config, Setup
of /etc/fstab, automatic DHCP-Requests (that are in background), include of
persistent home / saved configuration ...
5. X11 / Xsession
Knoppix currently uses /etc/inittab and /etc/init.d/xsession to start the
Xserver, which basicly does a startx.
The real sessions dependant on desktop is started
in /etc/X11/Xsession.d/45xsession, which imho is a nice solution, as one can
display an image and such give visual feedback very soon.
6. General Security management
Knoppix' philosophy is it to have invalid passwords and use the sudo-mechanism
to gain root-rights.
Also there are no services running.
I think we should keep this policy as far as possible.
6. KDE Tuning
We are using several tricks to get the most out of KDE.
We disable the screen lock for example, have our knoppix-menu and some addons
on that.
7. Modified Init
That is the most complicated step, knoppix needs to use a modified init to be
able to eject the CD, what many users like and prevents forgetting to eject
and letting it in the drive with nerved computer-owners and so on ;-).
Ok, so much for the philosophy and technology.
I think I can as soon as the CVS is up, update my trunk and I'm also willing
to upload it for you before thats the case. (At least the meta-packages I
created are usable)
Where I could need help, was in writing man pages or some smaller things, that
don't need much technical know how, but work :-).
Ok, what you can do:
- Test the original debian kernel with Knoppix: What does work - what does not
work?
- Debootstrap a testing, install all packages from
developer.linuxtag.net/knoppix/ boot into it and use Klaus' build scripts.
Upload to see where it needs work / tweaking ...
See also:
http://mailman.linuxtag.org/pipermail/debian-knoppix/2003-July/003389.html
Yes, before last linuxtag I did knoppify a woody ...
I don't think its all that much work. The worst step probably is to get it
into debian, but with some support and motivation a CVS it can get
reality ...
Well I'll set it up on my todo :-).
Tell me what you think.
cu
Fabian
Reply to: