Page 2 of 4
Posted: Tue 20 Dec 2011, 12:17
by technosaurus
here is a screeny of my ~2s booting kernel - It has almost everything but the essentials to get to X with jwm and rxvt so for most people it will be just a toy ... ironically that is why I made it - so my kids can't accidentally bork something up (can't mount drives or access any networks - just play games)
If anyone is interested I can post my .config and a tarball of the initramfs
The bzImage (from 2.6.32.50 source) is only 1437k including the builtin Xvesa, jwm and rxvt ... so it should even fit on a floppy. (really I could get it down to ~1mb with a busybox recompile with only needed applets -- and could cut resource usage to as low as ~4mb)
Posted: Tue 20 Dec 2011, 20:07
by Bert
That's very impressive technosaurus!
Shouldn't the "everything" on the first line of your post be "nothing"? Or do I need extra English lessons
... ironically that is why I made it - so my kids can't accidentally bork something up (can't mount drives or access any networks - just play games)
Would love to have something similar for my girlfriend's box, with just eth0 and a browser.... would liberate her from her technofear (and liberate me, the repair man)
Posted: Tue 20 Dec 2011, 22:06
by Karl Godt
If anyone is interested I can post my .config and a tarball of the initramfs
The bzImage (from 2.6.32.50 source) is only 1437k including the builtin Xvesa, jwm and rxvt
YES , go ahead !
AFAIK it is possible to adjust the paths in the kernel config like path to uevent(helper) or /sbin/init .
I had been not aware of the possibility to compile Xvesa and others into the kernel, too .
I know there is the embedded feature in make menuconfig .
Posted: Wed 21 Dec 2011, 09:38
by technosaurus
Ok here it is, Puppy in <1mb in a single bzImage
Resource usage in X with jwm running and an rxvt terminal open:
MEMUSAGEKB=5020 (with background) 2892kb without background image
Resource usage at the console:
MEMUSAGEKB=2288
I wanted to see how far I could go so I ended up disabling even proc and sys, (which breaks top and ps) so I needed a way to get memory usage. I also replaced busybox with dash and mount from embutils (sh is used by rxvt which also needs /dev/pts so needed to mount a devpts) and just for grins i wrote my own init in C . I could get the resource usage down under 2Mb if jwm were compiled with only X11 with maybe xpm support and used st instead of rxvt
here is the code I wrote for memused
Code: Select all
#include <sys/sysinfo.h>
int main(int argc, char **argv){
struct sysinfo info;
sysinfo(&info);
printf("MEMUSEDKB=%d\n",(info.totalram - info.freeram)*info.mem_unit/1024);
}
here is my init code
Code: Select all
#include <unistd.h>
#include <sys/wait.h>
#include <stdlib.h>
//these could be functions but gcc complains less this way
#define EGGSACKWEIGHT(a) ({int s,p;if((p=fork())==0){execvp(a[0],a);}else{while(wait(&s)!= p);}})
#define SHIFTN(i,a) ({ int j=0;while(a[j] != NULL){a[j]=a[j+i];j++;}})
#define EGGSACK(a) ({if((fork())==0) execvp(a[0],a);})
int main(int argc, char** argv) {
//export PATH="/bin" HOME="/root" TERM="xterm /bin/sh" SHELL="/bin/sh" PS1="# " USER=root LOGNAME=$USER HISTSIZE=1000 HISTFILE="$HOME/.history" INPUTRC=/etc/inputrc
//setenv("PATH","/bin",1);
putenv("PATH=/bin");
putenv("HOME=/root");
putenv("TERM=xterm");
putenv("SHELL=/bin/sh");
putenv("PS1=#");
putenv("USER=root");
putenv("LOGNAME=root");
putenv("HISTSIZE=1000");
putenv("HISTFILE=/root/.history");
putenv("INPUTRC=/etc/inputrc");
char* X[99];
//mount devpts /dev/pts -t devpts
X[0]="mount";
X[1]="devpts";
X[2]="/dev/pts";
X[3]="-t";
X[4]="devpts";
X[5]=NULL;
EGGSACK(X);
//Xvesa -screen 640x480x16 -nolisten tcp -tst -I &
X[0]="Xvesa";
X[1]="-screen";
X[2]="640x480x16";
X[3]="-nolisten";
X[4]="tcp";
X[5]="-tst";
X[6]=NULL;
EGGSACK(X);
//script? ... try getenv("XINITRC") and getenv("HOME") + /.xinitrc
putenv("SHELL=/bin/sh");
putenv("DISPLAY=:0");
X[0]="jwm";
X[1]="-display";
X[2]=":0";
X[3]=NULL;
EGGSACKWEIGHT(X);
X[0]="killall";
if (argc>1) {
X[1]="Xvesa"; //see above... maybe change to X
}else{
X[1]="Xorg";
}
X[2]=NULL;
EGGSACK(X);
X[0]="sh";
X[1]=NULL;
EGGSACKWEIGHT(X);
}
I also commented this line in the kernel source (init/do_mounts.c) - the wait isn't needed here
Posted: Wed 21 Dec 2011, 15:41
by PANZERKOPF
technosaurus wrote:Ok here it is, Puppy in <1mb in a single bzImage
Have tested it. Whole boot process takes 0.5 Sec (or thereabout).
Seems kernel is filled with gunpowder....
Posted: Wed 21 Dec 2011, 16:02
by nooby
But what does it take then to make all the needed changes?
I feel so dense. If it is this easy then why don't the devs of
Lupu or slacko use part of it to speed up the boot of those OS?
Posted: Wed 21 Dec 2011, 17:58
by Aitch
techno
Would I be right in saying microsaurus is only for playing games/videos?
Is it potentially useful as a puppy rescue tool on a floppy? i.e. can mount drives/partitions or edit/copy/paste things be added? Can any network/browser be added?
Do we just write/copy the image to floppy?
I like the sound of 1/2 second boot....
Aitch
Posted: Wed 21 Dec 2011, 18:05
by nooby
Yes would be cool if you can make something like a rescue thing
for USB and CD/DVD but I don't mind if it works as frugal install on HD
Posted: Wed 21 Dec 2011, 18:17
by PANZERKOPF
nooby wrote:Yes would be cool if you can make something like a rescue thing
for USB and CD/DVD but I don't mind if it works as frugal install on HD
This is a kernel with embedded root filesystem so it always boots "as frugal".
You can boot it from any device supported by BIOS and bootloader.
Posted: Wed 21 Dec 2011, 23:33
by gcmartin
@Techno
that's impressive for getting something booted in a box.
Now, could this be extended to a need (practical one) where I need a router service which runs the following fron X-desktop
- DNSMASQ
- Web server
- full SAMBA server
in a 32MB RAM platform? I don't care about the ISO size as that is unimportant to me, I am only concerned about it running in RAM. And, it must be able to use USB storage, LAN Motherboard peripherals along with wireless
This is the smallest useful application platform I could think of for using a small system. (The web server is optional.)
Hmmm...
edited: (even though I envision practical use, to do this is probably not possible)
Posted: Wed 21 Dec 2011, 23:45
by nooby
PANZERKOPF wrote:nooby wrote:Yes would be cool if you can make something like a rescue thing
for USB and CD/DVD but I don't mind if it works as frugal install on HD
This is a kernel with embedded root filesystem so it always boots "as frugal".
You can boot it from any device supported by BIOS and bootloader.
I trust that my poor English made a misleading connotation
or what the word is.
I actually prefer that it is frugal. But your answer was very helpful.
Does that mean that instead of usung aufs? and Squash? it
only uses vmlinuz and initrd and as you say the root is imbedded.
I know almost nothing. My vague grasp is that vmlinuz is the kernel
and that initrd is a kind of script that read what grub menu.lst has to
offer as puppy code like pfix=ram and other such codes.
Then the init read scripts take care of a lot of things as an overlay
to the kernel.
So what you say is that instead of a big overlay that take a long time to
boot Technosarius has imbedded the "root" into that vmlinuz?
I guess that is what Tiny Core do too or similar? Them having to us
odd name for their two files. That can also boot frugally and are fast booting.
Anyway thanks for caring about me. Kudos to Technosarius for putting time into such experiments. Cool indeed
Posted: Thu 22 Dec 2011, 00:44
by Lobster
Ok here it is, Puppy in <1mb in a single bzImage
Does this mean if I put the bzImage on a USB I was booting from I would go to desktop?
Could this be combined with a browser?
Is this ideal for known hardware, so for example for the Raspberry PI? (not yet available to any Puppy even by auction)
http://puppylinux.org/wikka/PARM
Posted: Thu 22 Dec 2011, 01:59
by seaside
Lobster wrote:Ok here it is, Puppy in <1mb in a single bzImage
Does this mean if I put the bzImage on a USB I was booting from I would go to desktop?
Lobster, Yes... I just tried that and made the mistake of blinking during boot and missed the entire event.
Technosaurus, a really amazing piece of work... WOW.
Regards,
s
Posted: Thu 22 Dec 2011, 06:27
by technosaurus
The funny thing is that even though this version has no usb support built in, it doesn't matter because once the usb bootloader hands it over the kernel doesn't yet know where it is, it just un-lzma's itself and runs.
As far as building upon it, you can use an initrd.lzma image similar to what puppy uses (an lzma'd cpio archive) for playing games or whatever without risk of damaging anything ... I am currently running it in qemu with:
qemu-system-i386 -kernel bzImage -cpu kvm32 -alt-grab
(I use the alt-grab so I can Ctrl+Alt+Backspace in it while running Xvesa/Xorg with "-nozap" )
Here is the asterisk:
it currently has no file system support other than initramfs
only very basic hardware support needed for Xvesa (no sound)
also no tcp support (thus no internet)
no module support, means none of this can be added without recompiling the kernel (it only takes a couple minutes)
it is basically allnoconfig + vesa framebuffer, vm86, devpts, initramfs, lzma, unix sockets + AT keyboard and ps2 mouse (with synaptic extensions)
I also did some expert level configuration to remove all the debugging and gnu-isms and used more sane values for things like the number of devpts (reduced from 512 to 16 to save ~8mb RAM usage) ... its all in the DOTconfig
Now that the asterisk is explained, it should be more straightforward to start adding things back to the kernel to support other options. For the web server with X, enable tcp in the kernel and put the webserver+content either directly into the initramfs or a separate initrd.lzma(s) ... you can't do it in qemu, but many bootloaders support multiple initrd's, so you could have additional initrd's for separate sites etc... could be good for a web browser too
I will likely test internet stuff with dillo1 when I do my gtk1 build using minimum profit text editor, dillo, emelfm, Xdialog, mtpaint and aumix... will only add ~1Mb + maybe .5mb for the needed kernel options and support files... the hardest part will be figuring out how to set up my puppy qemu host so that I can connect.
btw, does anyone know the "record" for fast booting?
Edit: almost forgot to mention arm ... yes, arm could be done in a similar way using qemu and Rob Landley's cross compilers - just change the arch from 586 to arm[*] in the kernel - nothing else is platform specific AFAIK except maybe vesa, but you will also want usb, usbhid and usb mouse for the Pi.
Posted: Thu 22 Dec 2011, 07:00
by Lobster
I will likely test internet stuff with dillo1
Ah thanks guys.
Beginning to get a handle on this.
This is part of the original remit of Saluki? Puppy remastered.
I very much hope we see this (or something similar on the Raspberry Pi)
We need that minimalism. We need that fast booting. We need our smartest dogs.
A fast booting dillo, that I could use and impress mermaids with . . .
Bravo
Posted: Thu 22 Dec 2011, 16:02
by PANZERKOPF
nooby wrote:
Does that mean that instead of usung aufs? and Squash? it
only uses vmlinuz and initrd and as you say the root is imbedded.
Aufs is mostly used when we want to create a writable layer (tmpfs or other) upon read only filesystem (squashfs or other). Initramfs used in Microsaurus is already writable so aufs is unneeded here.
nooby wrote:
I know almost nothing. My vague grasp is that vmlinuz is the kernel
and that initrd is a kind of script that read what grub menu.lst has to
offer as puppy code like pfix=ram and other such codes.
Then the init read scripts take care of a lot of things as an overlay
to the kernel.
Initrd is archive contains tools and scripts. Kernel unpacks it to the ramfs and
runs init script. After initialisation we can continue working in that rootfs (Microsaurus and Tinycore way) or delete it and jump to the other root filesystem (Puppy way).
nooby wrote:
I guess that is what Tiny Core do too or similar?
Yes, with one difference: Tinycore uses separate file (initrd.gz) whereas Microsaurus has embedded it into kernel image. Recent kernels (since 2.6.??
have forgotten.....) let us integrate an archive (was mentioned above) to the body.
So we have one file with complete OS inside.
Posted: Fri 23 Dec 2011, 02:19
by technosaurus
I put together a gtk1 version with goingnut's multicall binary of ROX-Filer, Xdialog, dillo, mtpaint and minimum profit (text editor) ... it also has aumix but sound/internet still isn't supported.
The environment variables for rox are set in the init binary (APP_DIR and CHOICESPATH)
Resource usage is hovering around 6-7mb , but that is without the Rox Pinboard (desktop icons) ... I still need to figure out the old format and where it goes.
Posted: Fri 23 Dec 2011, 06:17
by goingnuts
pinbord entries in /root/Choices/ROX-Filer PuppyPin.
Loaded via /sbin/pup_event_frontend_d which needs patch for grid, yafsplash, busybox difff a.o. to work with BB only.
Run "/sbin/clean_desk_icons" and "/sbin/pup_event_frontend_d" via /root/.xinitrc before running:
#ROX-pin
if [ $(which rox) ]; then
#relocates right-side icons to actual right-side of screen...
/usr/sbin/fixPuppyPin /root/Choices/ROX-Filer/PuppyPin
rox -p /root/Choices/ROX-Filer/PuppyPin
fi
(also from /root/.xinitrc)
Note: PinboardAdd supported but not PinboardRemove
Posted: Fri 23 Dec 2011, 10:35
by technosaurus
goingnuts wrote:pinbord entries in /root/Choices/ROX-Filer PuppyPin.
Loaded via /sbin/pup_event_frontend_d which needs patch for grid, yafsplash, busybox difff a.o. to work with BB only.
Run "/sbin/clean_desk_icons" and "/sbin/pup_event_frontend_d" via /root/.xinitrc before running:
#ROX-pin
if [ $(which rox) ]; then
#relocates right-side icons to actual right-side of screen...
/usr/sbin/fixPuppyPin /root/Choices/ROX-Filer/PuppyPin
rox -p /root/Choices/ROX-Filer/PuppyPin
fi
(also from /root/.xinitrc)
Note: PinboardAdd supported but not PinboardRemove
I kinda figured it out. I am exporting APP_DIR as /usr/share/ROX-Filer (with the pixmaps directory symlinked to ../pixmaps) and CHOICESPATH as just /usr/share - putting the MIME-* directories in a more standardized place with other mime stuff (and reachable in a multi-user setup by exporting new paths)... I don't want to use any legacy Puppy-isms where it can be improved upon.
All in all it is getting a decent feel to it - I will probably set the default resolution in the gtk1 version to {1024x768,800x600}x16 though (will use some extra resources, but not as cramped)
I do miss gtkdialog a bit, but gtkserver could be a replacement since it does have a gtk1 backend... only not as many examples.
something this (untested) would support multiple possible locations depending on user/mode/etc...:
Code: Select all
for x in ${CHOICESPATH//:/ }/ROX-Filer/PuppyPin; do
[ -x "$x" ] && fixPuppyPin "$x" && break
done
for using in standard Puppy's / Puplets the startupcommand (init within X) could use meminfo to determine whether to keep the gtk versions or bump up to gtk2/3 on the main filesystem as well as which daemons to run by default
One thing that no package manager really does, is track the typical resource usage. If I continue to develop this, it will be an integral part of package management. This way we could list all of the packages that provide for instance "defaultbrowser" by resource usage, with any that exceed the systems resource limit by itself grayed out and/or italicized if it could cause problems in typical usage. This could even be based on MIME-types such that the default handler for each MIME-Type defaults to opening the package manager to those "provides". ... but that would be too simple, right?
Posted: Fri 23 Dec 2011, 18:30
by Aitch
Great stuff, techno
I really like the sound of the final paragraph....can't believe it hasn't been included before
Might a Puppy4.4 evolve out of this, or is it abandoned?
There seemed to have been plenty of .pet tests....but no OS??
...or did I miss it because it was so fast?
Maybe add-on SFS's is the way to go, on a barebone/microsaurus base?
Interesting xorg development - dynamic loading video
http://www.phoronix.com/scan.php?page=n ... px=MTAzMjM
Aitch