Hi,
some things I noticed when using grml 0.8 recently that might be changed some day to make grml even better:
1. When loading grml on older machines there is a noticable delay (and cdrom activity) when there are loaded lots of screen and zsh instances into the virtual consoles. I'd like to have a cheatcode (or a runlevel) that only loads programs for console 1 at startup. Other consoles are loaded after a key has been pressed there. For those consoles that use rungetty, its --prompt option could be used to archieve this.
2. Having GRUB available on GRML is great. However, I'd like to have a few "Grub keyboard layouts" included for people who, unlike me, cannot find all that special chars like = or / on an American keyboard layout. You can find a German and a French layout on my bootdisk (or its config files) available at http://home.arcor.de/mschierlm/bootdisk/. On the other hand, you can save about 1MB on CD by using a 360KB floppy image instead of a 1.44MB one. (I tested it and chainloading a 360KB GRUB disk image from memdisk works.)
3. When, for some reason, I need grml booted on two machines and cannot use the grml-terminalserver (for example because I may not interfere with DHCP servers in the network and do not have a crossover network cable with me either) I like to use the toram option. But, obviously, it needs lots of RAM and time to get started. In these cases grml-small would be better. But I want to carry around as few disks as possible. So I thought if it is possible to splitting the squashfs image into two images that are merged by unionfs, where the smaller one contains a basic system that includes all stuff from grml-small (which may be larger than 50MB, but as small as possible) and have a cheatcode to load only the small part into ram (and not use the large part at all). I do not know if this is feasible in the grml build process (obviously it will require some extra work of splitting the image), but it would be cool. I don't know any live cd that tries to do things like this, so perhaps it is not possible...?
4. The bootsplash flickers quite a lot. You might reduce flickering by replacing the »/usr/bin/clear« by »echo -ne '\033[H\033[25l'« which will not clear the screen but move the cursor to top and set the cursor invisible. Another nice thing would be having boot messages scrolling in a small "window" inside the bootsplash, like it can be done by »ESC [ first ; last r« (see »man console_codes | less +/region«), but since I do not know how many users are using bootsplash anyway (I usually do not), this is just eye-candy and very low priority for me :-)
Feel free to flame me now ;-)
Michael
regarding 1:
there is "grml small" bootparam, which starts fewer consoles on startup
----- Original Message ----- From: "Michael Schierl" schierlm-public@gmx.de To: grml@mur.at Sent: Sunday, November 05, 2006 7:03 PM Subject: [Grml] Suggestions
Hi,
some things I noticed when using grml 0.8 recently that might be changed some day to make grml even better:
1. When loading grml on older machines there is a noticable delay (and cdrom activity) when there are loaded lots of screen and zsh instances into the virtual consoles. I'd like to have a cheatcode (or a runlevel) that only loads programs for console 1 at startup. Other consoles are loaded after a key has been pressed there. For those consoles that use rungetty, its --prompt option could be used to archieve this.
2. Having GRUB available on GRML is great. However, I'd like to have a few "Grub keyboard layouts" included for people who, unlike me, cannot find all that special chars like = or / on an American keyboard layout. You can find a German and a French layout on my bootdisk (or its config files) available at http://home.arcor.de/mschierlm/bootdisk/. On the other hand, you can save about 1MB on CD by using a 360KB floppy image instead of a 1.44MB one. (I tested it and chainloading a 360KB GRUB disk image from memdisk works.)
3. When, for some reason, I need grml booted on two machines and cannot use the grml-terminalserver (for example because I may not interfere with DHCP servers in the network and do not have a crossover network cable with me either) I like to use the toram option. But, obviously, it needs lots of RAM and time to get started. In these cases grml-small would be better. But I want to carry around as few disks as possible. So I thought if it is possible to splitting the squashfs image into two images that are merged by unionfs, where the smaller one contains a basic system that includes all stuff from grml-small (which may be larger than 50MB, but as small as possible) and have a cheatcode to load only the small part into ram (and not use the large part at all). I do not know if this is feasible in the grml build process (obviously it will require some extra work of splitting the image), but it would be cool. I don't know any live cd that tries to do things like this, so perhaps it is not possible...?
4. The bootsplash flickers quite a lot. You might reduce flickering by replacing the »/usr/bin/clear« by »echo -ne '\033[H\033[25l'« which will not clear the screen but move the cursor to top and set the cursor invisible. Another nice thing would be having boot messages scrolling in a small "window" inside the bootsplash, like it can be done by »ESC [ first ; last r« (see »man console_codes | less +/region«), but since I do not know how many users are using bootsplash anyway (I usually do not), this is just eye-candy and very low priority for me :-)
Feel free to flame me now ;-)
Michael
_______________________________________________ Grml mailing list - Grml@mur.at http://lists.mur.at/mailman/listinfo/grml join #grml on irc.freenode.org grml-devel-blog: http://grml.supersized.org/
* Michael Schierl schierlm-public@gmx.de [20061105 19:15]:
some things I noticed when using grml 0.8 recently that might be changed some day to make grml even better:
- When loading grml on older machines there is a noticable delay (and cdrom activity) when there are loaded lots of screen and zsh instances into the virtual consoles. I'd like to have a cheatcode (or a runlevel) that only loads programs for console 1 at startup. Other consoles are loaded after a key has been pressed there. For those consoles that use rungetty, its --prompt option could be used to archieve this.
As already mentioned on the mailing list, take a look at booting with "grml small".
I really like your idea with the --prompt option and integrated it: http://hg.grml.org/grml-etc/rev/db04e8e2294e
- Having GRUB available on GRML is great. However, I'd like to have a few "Grub keyboard layouts" included for people who, unlike me, cannot find all that special chars like = or / on an American keyboard layout. You can find a German and a French layout on my bootdisk (or its config files) available at http://home.arcor.de/mschierlm/bootdisk/. On the other hand, you can save about 1MB on CD by using a 360KB floppy image instead of a 1.44MB one. (I tested it and chainloading a 360KB GRUB disk image from memdisk works.)
I like your allinone.img! Are you interested in inclusion into main grml? If so please feel free to contact me (just write me a personal mail or join #grml on freenode).
- When, for some reason, I need grml booted on two machines and cannot use the grml-terminalserver (for example because I may not interfere with DHCP servers in the network and do not have a crossover network cable with me either) I like to use the toram option. But, obviously, it needs lots of RAM and time to get started. In these cases grml-small would be better. But I want to carry around as few disks as possible. So I thought if it is possible to splitting the squashfs image into two images that are merged by unionfs, where the smaller one contains a basic system that includes all stuff from grml-small (which may be larger than 50MB, but as small as possible) and have a cheatcode to load only the small part into ram (and not use the large part at all). I do not know if this is feasible in the grml build process (obviously it will require some extra work of splitting the image), but it would be cool. I don't know any live cd that tries to do things like this, so perhaps it is not possible...?
Interesting idea. I'll add it to the todolist and will discuss it with other developers.
- The bootsplash flickers quite a lot. You might reduce flickering by replacing the »/usr/bin/clear« by »echo -ne '\033[H\033[25l'« which will not clear the screen but move the cursor to top and set the cursor invisible. Another nice thing would be having boot messages scrolling in a small "window" inside the bootsplash, like it can be done by »ESC [ first ; last r« (see »man console_codes | less +/region«), but since I do not know how many users are using bootsplash anyway (I usually do not), this is just eye-candy and very low priority for me :-)
Excellent feedback! Already incorporated: http://hg.grml.org/grml-autoconfig/rev/fa92ef1d5c3e
Feel free to flame me now ;-)
Nothing to flame, brilliant feedback. :) Thanks!
regards, -mika-
On Mon, 06 Nov 2006 23:23:23 +0100, Michael Prokop wrote:
... So I thought if it is possible to splitting the squashfs image into two images that are merged by unionfs, where the smaller one contains a basic system that includes all stuff from grml-small (which may be larger than 50MB, but as small as possible) and have a cheatcode to load only the small part into ram (and not use the large part at all). I do not know if this is feasible in the grml build process (obviously it will require some extra work of splitting the image), but it would be cool. I don't know any live cd that tries to do things like this, so perhaps it is not possible...?
Interesting idea. I'll add it to the todolist and will discuss it with other developers.
Thanks for the consideration. I wanted that long time ago. It is totally feasible, and has been done in other live cd system, like slax (http://www.slax.org/features.php):
,----- | Other Live CDs contain all software in a single compressed file. If you run | such a Live OS from CD-ROM, the CD drive has to seek back and forth really | frequently, because different files are located on different locations of | the CD medium. This makes the system notably slow. | | With SLAX, all conformable parts of the filesystem are compressed to a | standalone file, which doesn't contain anything else. For example, all files | which belongs to Xwindow are packed in xwindow.mo, KOffice related stuff is | in koffice.mo, etc. If you work with KOffice, you usually need only files | from KOffice and nothing else, and hence all files from that part of the | filesystem are separated from the rest of it, your CD drive has to seek only | in a 10 MB area. This significantly improves the speed. `-----
This is just an example. I think the most advanced Live CD regarding using unionFS is Puppy Linux, it allows 5 layers to work together, and it has detailed docs on how it is done:
http://www.puppyos.com/development/howpuppyworks.html
BTW, I have planned long time ago to write the author of Puppy Linux a personal email to invite him join on board to develop grml, but haven't go time to do that yet. :-)
Tong wrote:
unionFS is Puppy Linux, it allows 5 layers to work together, and it has detailed docs on how it is done:
http://www.puppyos.com/development/howpuppyworks.html
BTW, I have planned long time ago to write the author of Puppy Linux a personal email to invite him join on board to develop grml, but haven't go time to do that yet. :-)
Puppy Linux is nice. We considered it. What decided grml instead is the portable Debian system. Puppy is anything but standard. Puppy has its own repository system, etc. That means extra work when you want to install things not in the Puppy repos. With a big USB hard drive, Puppy's compression and clever games are don't-cares. USB2 hard drive seek/r/w speed is so much faster than CD's that access/speed issues are don't-cares.
Summary -- borrowing Puppy ideas is fine, if compatible with grml2hd portable USB systems. (No reason for problems, just saying.) We believe the days of live CDs are numbered as high-capacity mobile storage devices get cheaper. We get 80 Gig USB2 bus-powered palm drives for less than $100.
But you're right, Puppy is clever, though grml might teach Puppy some lessons too.
On Tue, 07 Nov 2006 16:03:14 -0700, Mark wrote:
unionFS is Puppy Linux, it allows 5 layers to work together, and it has detailed docs on how it is done:
http://www.puppyos.com/development/howpuppyworks.html
BTW, I have planned long time ago to write the author of Puppy Linux a personal email to invite him join on board to develop grml, but haven't go time to do that yet. :-)
Puppy Linux is nice. We considered it. What decided grml instead is the portable Debian system. Puppy is anything but standard. Puppy has its own repository system, etc. That means extra work when you want to install things not in the Puppy repos. ...
That's why I never tried it and wanted to invite the author of Puppy Linux to join Debian/Grml instead. :-)
Summary -- borrowing Puppy ideas is fine, if compatible with grml2hd portable USB systems. (No reason for problems, just saying.)
Bingo.
participants (5)
-
Mark -
Michael Prokop -
Michael Schierl -
roland -
T