Puppy Linux Discussion Forum

[technosaurus]

This may be of interest - the old static qt3 build of Opera in 6.5Mb: Opera-9.27

and a whole list of apps that work with gtk-1.2
http://kmandla.wordpress.com/2008/09/02/more-fun-gtk12-stuff/

[goingnuts]

JWM now using his fonts - changed font in .jwmrc to: -adobe-courier-bold-r-normal--14-140-75-75-m-90-iso8859-1

Updated the X_base pet with technosaurous rxvt and included freememapplet as it is an essential info-part of Puppy. Included a small applet "Control Panel" that generates a dynamic menu in dialog. For now only a modified Display-Manager present. The cost of this is an increase in size of 54K (but now there are 4 fonts present...)

The final ISO-build with GUI is 7,7Mb including LYNX-web browser (but no new builds made public yet). Same build with host drivers is 10Mb - and running on host fast as...

Done a quick test to start xwin very early in rc.init: X starts ok but JWM refuses claiming he can not find his config file at that point. We might just end up in the XP-situation (needing the hourglass-courser) if all other init happens in background?

Would like to dig into the GTK-world but every time I try to compile there I get:
The gtk-config script installed by GTK could not be found
*** If GTK was installed in PREFIX, make sure PREFIX/bin is in
*** your path, or set the GTK_CONFIG environment variable to the
*** full path to gtk-config.
configure: error: GTK+ not found (required)

[technosaurus]

I compiled a static version of gtk-1.2 with all of the debian patches if you want it, otherwise you can add this to your .profile script (or its equivalent)

export GTK_CONFIG=/path/to/gtk-config

[goingnuts]

technosaurus: Thank you - you are helping a lot! If possible I would like to try your static version.

[technosaurus]

I was only able to cut ~500kb off of the opera package by setting the skin to be basically blank, removing unnecessary files and optimizing images and upxing the binary (recent versions can have 5-7MB of cruft removed)... It is a 6Mb tarball so will have to post it elsewhere

Here is gtk-1.2 with debian patches, I intentionally compiled them "--without-pic" to only be used in executables (so they won't work in shared libs)

(They should probably have a pinstall script that sets any environment variables like export GTK_CONFIG=/path/to/gtk-config etc..., but everything is in the standard locations)

if you run in to issues with gtk2 overriding them at configure, renaming the glib/gtk libs, *.pc files and -*config files may help - keep in mind that if a library can use either 1.2 or 2.0 and the script auto detects it, then gtk2 will get pulled in (unless you can --disable or --without it)

[technosaurus]

Opera 9.27 (static Qt3) seems to work well and only dependencies are:
libX11, libXext, libSM, libICE, libpthread, libdl, libm, libz, libc, libXau, libXdmcp
It can be stripped down to a ~6Mb (probably undistributable) tarball

upx'ing the 14MB opera binary helps,

to remove the 317kb /usr/share/opera/skins/standard_skin.zip
without it looking all garbled add this to [User Prefs] in /etc/opera6rc

[goingnuts]

Again: Thank you. Will test and learn.

[technosaurus]

minimal mtpaint with static gtk1 (no support for xft, freetype, tiff, jpg2000 lcms, threading or nls ... only Xpm, png, gif and jpeg)

deps are lib{c,dl,gif,ICE,jpeg,m,png12,SM,X11,Xau,Xdmcp,Xext,z}

here is some info from top
resource usage gtk2 dynamic : 17656
resource usage gtk1 static: 6748


and dillo-0.8.6
deps are lib{c,dl,jpeg,m,png12,pthread,X11,Xau,Xdmcp,Xext,z}
resource usage gtk1 static: 4880

emelfm file manager
deps are lib{c,dl,m,pthread,X11,Xau,Xdmcp,Xext}
resource usage gtk1 static: 4288

gentoo file manager ()
deps are lib{c,dl,m,X11,Xau,Xdmcp,Xext}
resource usage gtk1 static: 4268

[goingnuts]

technosaurus: Using your pets reveals you are 30869s in the future...
These are goodies - personally I like the Dillo approach...

Would be nice with a desktop-manager to replace ROX-Filer - I have been testing xtdesktop but it do not bring more that the jwm traybutton approach concerning functionality - except the icons are without the background. If jwm could just show the icons and leave out the background...
A Rox-Filer pet with most needed for pUPnGo is 4,2Mb (expanded 11Mb) and startup of X, jwm is clearly sloooow in qemu.
WIth X_base still able to boot in below 20Mb ram environment and run Dillo from above.

[technosaurus]

yes I am, but thanks to one of Lobster's super top secret squirrel browser plugins, I am able to communicate back in time though this forum. (actually I set it about a day forward to be able to compile some sources from SVN in a different time zone without waiting or hacking the build scripts)

If you plan to use more than 2 gtk programs it is probably best to use the shared versions from the ibiblio repo.... and amigo has a large collection of gtk apps in his amigolinux repo as well.

Rox is available as gtk too and only uses 6604 (running with shared libs) (needs some configuring still)
deps are lib{c,dl,gdk-1,gdk_pixbuf,glib-1,gmodule-1,gtk-1,ICE,jpeg,m,png12,SM,tiff,X11,Xau,Xdmcp,Xext,xml2,z}

[wjaguar]

When compiling stuff for GTK+1, add "-DGTK_NO_CHECK_CASTS" to CFLAGS. This will disable debug code, making binary size a bit smaller.

[goingnuts]

Attached package installer and package-remover for pUPnGO. As resources in pUPnGO are limited installing packages needs to be done differently from org. P412. The installer/remover is based on a database-file keeping track of every package and its files. Packages for pUPnGO should containg everything needed to make the contained application run on a bare pUPnGO. This removes the need for a package manager and moves the overhead from the OS to the packages. This will eventually leed to more shared files belong installed packages than is the case in org. P412. And therefore this different approach preventing removal of one package breaking another packages dependencies...

As pUPnGO was meant to be for "embedded" or single application systems the above approach make sense - if you want a more feature rich OS you would probably not start from the level of pUPnGO...

The installer/remover is dialog/Xdialog based and by default will not interfere with the org. P412 pet-installer - but a compatibility mode can be activated by removing out-commented tag in top of the installer-script.

The installer/remover only take .pets as package-formate, it needs only BusyBox applications to run. It does not handle menu-update, dependency checking, if space is available or other special features found in the original P412 installer. Most of those special tasks should be handled by using pinstall.sh and punstall.sh inside packages - which is supported...

I have tested the programs intensively in my running P412 - but might not be aware of all the features in the advanced org. P412 installer. I would appreciate any feedback on bugs, things missing etc.

[technosaurus]

hv3 isn't quite as good as Opera, but it is half the size and better than dillo/netsurf and does reasonably well with rendering css and some javascript (it at least displays the puppy web desktop)
http://tkhtml.tcl.tk/hv3-linux-nightly-08_0203.gz

[goingnuts]

I have been looking at the different browsers - installed size added when introduced in pUPnGo:
Lynx will add approx. 1Mb - but no graphics...
Dillo-static build will add approx. 2Mb - some graphics
Links2 will add 4Mb - some graphics
hv3 will add 4Mb - most graphics but also render pages very nice.

The used pUPnGO-build is approx 17Mb unpacked - so when will they run reasonably in X (and no swap)?
Lynx: 24Mb (20Mb extremely slow)
Dillo: 24Mb (20Mb starts swift but freeze)
Links2: 24Mb (20Mb freeze)
hv3: 36Mb
All tested in qemu which might give readings approx. 4Mb too high...and test done with load of all qemu hw-drivers.

hv3 has superior quality, Dillo has the smallest size of the graphic browsers, links2 works both in GUI and text mode and lynx2 text mode only.

Additional comment 040510: Tried to reproduce the above and could suddenly not get pass the "loading modules..." during boot unless I had 64Mb RAM...
Reason was I had been playing with recompile of depmod as BusyBox depmod seemed very slow at boot (1,5min versus 30 sec for org. P412 depmod in qemu). But that was if RAM was higher or equal to 64Mb. So BB depmod works below 64Mb RAM but is slow where org. depmod works above 64Mb RAM and is fast...

[technosaurus]

a little info about modutils from busybox:
(the default option even with allyesconfig is modprobe small - I usually compile the fuller version by manually selecting it in menuconfig - it adds about 17kb if I recall)

from http://git.busybox.net/busybox/tree/modutils/Config.in

config MODPROBE_SMALL
bool "Simplified modutils"
default n
help
Simplified modutils.

With this option modprobe does not require modules.dep file
and does not use /etc/modules.conf file.
It scans module files in /lib/modules/`uname -r` and
determines dependencies and module alias names on the fly.
This may make module loading slower, most notably
when one needs to load module by alias (this requires
scanning through module _bodies_).

At the first attempt to load a module by alias modprobe
will try to generate modules.dep.bb file in order to speed up
future loads by alias. Failure to do so (read-only /lib/modules,
etc) is not reported, and future modprobes will be slow too.

NB: modules.dep.bb file format is not compatible
with modules.dep file as created/used by standard module tools.

Additional module parameters can be stored in
/etc/modules/$module_name files.

Apart from modprobe, other utilities are also provided:
- insmod is an alias to modprobe
- rmmod is an alias to modprobe -r
- depmod generates modules.dep.bb

As of 2008-07, this code is experimental. It is 14kb smaller
than "non-small" modutils.