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
