xwoaf - rebuild

[goingnuts]

Thanks Barry! They are nice findings - especially if the mdesk source "at last" is released. It's like Christmas - lot of presents

[technosaurus]

although many of these have been lost to the interwebs, it is still possible to build most of them. We have preserved tinyX on github; jwm is still maintained and we now have alternatives to rxvt (st). In my experiments with nanosaurus, I built a kernel image with a builtin initramfs that included jwm, rxvt and a basic "init" in under 1MB. Since then I have produced patches to allow jwm to use stb_image instead of libjpeg and libpng and nanosvg instead of cairo ... and suckless terminal is now as good as if not better than rxvt. Netsurf now has basic javascript support and can be buiilt using using xcb (and linux framebuffer) backend which would allow using something like what slitaz uses for configuration dialogs instead of gtkdialog (it uses busybox httpd and html forms - no javascript technically required). I briefly experimented with nuklear (see github) as a replacement for gtk+ GUIs and though it seems to be on par with gtk+, I would need to find/write a glib replacement to fully replace gtk+. I should have some development time after the new year, so let me know what you would like to see in the new year (and hopefully a new laptop for development)... more jwm improvements? replace gtk/gtkdialog? minimal init system? GUI multicall binary(ies)? porting X11 apps to xcb?

I have done a ton of experiments over the years, but I don't do a lot of "marketing", so I really don't know what people want/like. The only projects that got much interest seemed to be the stuff the end users actually see like my jwm-tools and simple icon tray or small SVG icons; however I would have expected more interest in my DNS caching experiment that significantly improved browsing speed (up to 30000%) or my sysvinit replacement scripts that improved boot speed by 2000%.

[BarryK]

although many of these have been lost to the interwebs, it is still possible to build most of them. We have preserved tinyX on github; jwm is still maintained and we now have alternatives to rxvt (st). In my experiments with nanosaurus, I built a kernel image with a builtin initramfs that included jwm, rxvt and a basic "init" in under 1MB. Since then I have produced patches to allow jwm to use stb_image instead of libjpeg and libpng and nanosvg instead of cairo ... and suckless terminal is now as good as if not better than rxvt. Netsurf now has basic javascript support and can be buiilt using using xcb (and linux framebuffer) backend which would allow using something like what slitaz uses for configuration dialogs instead of gtkdialog (it uses busybox httpd and html forms - no javascript technically required). I briefly experimented with nuklear (see github) as a replacement for gtk+ GUIs and though it seems to be on par with gtk+, I would need to find/write a glib replacement to fully replace gtk+. I should have some development time after the new year, so let me know what you would like to see in the new year (and hopefully a new laptop for development)... more jwm improvements? replace gtk/gtkdialog? minimal init system? GUI multicall binary(ies)? porting X11 apps to xcb?

I have done a ton of experiments over the years, but I don't do a lot of "marketing", so I really don't know what people want/like. The only projects that got much interest seemed to be the stuff the end users actually see like my jwm-tools and simple icon tray or small SVG icons; however I would have expected more interest in my DNS caching experiment that significantly improved browsing speed (up to 30000%) or my sysvinit replacement scripts that improved boot speed by 2000%.

Yes, I see so many interesting projects, that have been forgot or lost, bits and pieces that could be put together to build a new kind of radically small, lean-and-mean Puppy.

That is very good news about netsurf!

A new pup built with xlib apps, tinyx, and gtk 1.2, would be great. There were such nice gtk1.2 apps that we abandoned. Also there were some very interesting projects, such as xft support in gtk1.2, for antialiased fonts -- there was a git site for that.

A suppose a good start would be to collect everything we can find and put it into a repository somewhere, somewhere that is not going to go away.
Unfortunately, I had a huge collection of old stuff on a usb hard drive that got stolen -- my place got burgled several years ago.

Then setup a build environment, which is not the easy part. Personally, I favour being very conventional and use glibc -- it avoids so many hassles.

Maybe a project like OpenEmbedded or Yocto would be a good tool to use.
I mention those two, as I had very good experiences with them:
http://barryk.org/news/?viewDetailed=00361
http://barryk.org/news/?viewDetailed=00367

Regarding T2, I give up. The problem is, only Rene, the maintainer, is the only one maintaining it, and only just barely. It has been like this for years. Rene compiles for a mips target, arm is totally neglected.
EDIT: no, haven't really given up on T2. Keep saying I will, but then go back and play with it some more.

I'm just "thinking out loud" here.

[ally]

I have archived goingnuts efforts here:

http://archive.org/details/puppylinux?and[]=goingnuts

I can upload anything you want saving to the archive

[goingnuts]

goingnuts,
On your xwoaf webpage, you wrote that 1diskx cannot be found anymore.

You can get it from this most unlikely URL:

http://soundproofingforum.co.uk/soundpr ... oofing.htm

I have just now run "unrar x mungdev20100301.rar"

It has image files for using in qemu.

It has 'hda.img' and 'hdb.img' in it, intended to be used in vmware.
I wonder how we could open those files, without having vmware?

Here is how to "easy" access the content of hda.img:

Code: Select all

#create a directory to unpack the mungdev20100301.rar
mkdir mungdev
#and move mungdev20100301.rar to this directory
#then run
unrar e mungdev20100301.rar
#convert hda.img to raw image for qemu
qemu-img convert -O raw hda.img hda.raw		#the -O is -O as in Oliphant
#now you can boot qemu with this command:
qemu -m 128 -boot c -hda hda.raw
#or mount the disk and access the content via your file browser
mkdir mnt
mount -o loop,offset=32256 hda.raw mnt

#hdb.img seems to be an empty harddisk

BUT: I find no source for mdesk. In /home/mungkie you find 1diskxwin-soundproofing.tar.bz2 and after extraction you can find the bin mdesk in /home/mungkie/1diskwin-soundproofing/mdesk-1.2.0 but no source. I might have overlooked it though...

technosaurus: You really have contributed with many unique solutions and your nanosaurus was great inspiration! The gtk-1.2 road is well documented but if one aims for 1.44Mb floppy its still too large. I thought of gtkdialog-1 reduced to xpm-graphics and with some features removed - then scripting all apps - but it seem still to be too big...
XawPlus gives smaller bins than Xaw (and they look better) but they drag in Xt and friends - and Xaw is not always stable or user-friendly.
The McTools widget set is smaller than GTK-1.2 and use only X11, Xau and Xpm - but until now I have not been able to do a single app with it myself. That could be a new project for very tiny (but advanced) GUI apps.

ally: Thanks a lot!

Add: If you choose to run the hda.raw within qemu cd to home/mungkie and run ./createsystem.sh
It will build most things but when it comes to mdesk it stops and says "You need to upgrade". It should be possible to get it running though by manually creating the rest of the root - but I still havent seen any of the apps in mdesk running. It seems to hold Xvesa, mterm, xawterm, game, calc, paint, gifr, pty, mdesk, menu, dial, cscript, rxvt, xhost, wm, usk, vncviewer, fspanel, rdesktop, ssh, xpmroot and xfm - impressive...

[foxpup]

The iso would not boot with Qemu, but did a manual frugal install to HDD (ext2 partition) and it booted fine with grub4dos.

I would like to try it out this way to see what it is all about.
What's in your menu.lst? I can't get it right.

[Keef]

foxpup

Here it is:

Code: Select all

title xwoaf
  find --set-root --ignore-floppies --ignore-cd /xwoaf/bzImage
  kernel /xwoaf/bzImage root=/dev/ram0 
  initrd /xwoaf/Image.gz

[foxpup]

Thanks Keef!

Works very well. xwaof boots very fast on my P3 (amd palomino). It's faster than anything

I put it on ext3, next to several frugal puppies. So it does not have to be ext2.

However 2 issues for now:
my keyboard is azerty (be-latin1)
I have no internet, normally it is a network connection, ethernet, eth0

How can I set up these?
Where can I find this kind of info, or even what is or is not possible?

[BarryK]

BUT: I find no source for mdesk. In /home/mungkie you find 1diskxwin-soundproofing.tar.bz2 and after extraction you can find the bin mdesk in /home/mungkie/1diskwin-soundproofing/mdesk-1.2.0 but no source. I might have overlooked it though...

Hmmm, the website says it is in that .rar file, quoting:

full source of the mdesk desktop tools added

That's a shame if he hasn't actually put it in.

[BarryK]

although many of these have been lost to the interwebs, it is still possible to build most of them. We have preserved tinyX on github; jwm is still maintained and we now have alternatives to rxvt (st). In my experiments with nanosaurus, I built a kernel image with a builtin initramfs that included jwm, rxvt and a basic "init" in under 1MB..

Have you actually called it "nanosaurus" anywhere? I just tried a google on "nanosaurus puppy" and came up with this:

http://nanosaurus.tumblr.com/post/50293601365/puppy-3

What forum threads are best to see your work in the gtk 1.2 nanosaurus category?

[technosaurus]

actually my "microsaurus" image was less than 1mb with the jwm+xvesa+rxvt initramfs built into the kernel and the gtk1 multicall binary with dillo, rox, asound and gtkdialog1 was well under half a megabyte compressed, so it would probably work... iguleder has patched version of a lot of gtk1 programs on his GitHub repo (dimkr i believe), but they would need to be combined into one repo to make a multicall binary.

unfortunately microsaurus is no longer available since the forum reduced the file size limit, i would post clickable links but i am traveling and using my phone to post.

http://www.murga-linux.com/puppy/viewtopic.php?p=590822

[goingnuts]

Hmmm, the website says it is in that .rar file, quoting:

full source of the mdesk desktop tools added

That's a shame if he hasn't actually put it in.

In /root/create we get a direct link to where it should be and the naming:

Code: Select all

cd 1diskxwin-soundproofing
./make remake n
./installX

cd ..
tar xjf mdesk.tar.bz2
cd mdesk
./make_all.sh uclibc
cp apps/mdesk /usr/X11R6/bin/

If one use strings on the mdesk bin we get some information directly from the source to search for (ex:"Text Widget: The multiply action's argument" - thats Xaw). Xaw is nowhere else - so I guess this is from a static linked Xawlib in mdesk.

mungkie seems to like obfuscation so source might be in the download but hidden...
Could it be deleted? Then recovery tools should be used...
Could it be renamed/replaced (and maybe afterwards deleted)?
Can we find it?
Do we bother...?

[BarryK]

goingnuts,
Do you know about this:

https://sourceforge.net/projects/sf-xpa ... xft-progs/

It is very interesting. xlib apps can use freetype fonts, with anti-aliasing and utf-8.

It states that apps can be modified quite easily to use libxaw3dxft.

That would be a very good enhancement for xwoaf!

[BarryK]

actually my "microsaurus" image was less than 1mb with the jwm+xvesa+rxvt initramfs built into the kernel and the gtk1 multicall binary with dillo, rox, asound and gtkdialog1 was well under half a megabyte compressed, so it would probably work... iguleder has patched version of a lot of gtk1 programs on his GitHub repo (dimkr i believe), but they would need to be combined into one repo to make a multicall binary.

unfortunately microsaurus is no longer available since the forum reduced the file size limit, i would post clickable links but i am traveling and using my phone to post.

http://www.murga-linux.com/puppy/viewtopic.php?p=590822

Yes, if you could upload microsaurus sometime, I would like to play with it.

Right now i am downloading all of Iguleder's (dimkr) source packages, that he used for his 'rlsd' distro:

http://dimkr.insomnia247.nl/sources/

[BarryK]

goingnuts,
Just popped in to the forum to let you know what a pleasant experience I had, compiling xwoaf-rebuild!

Very simple, "just works'.

It would probably be quite easy to port to the Pi3. I would have to populate xwoafchain with armv7 binaries.

[goingnuts]

Thank you for testing - very nice feedback!
I did have a quick test of xaw3dxft - tested linking with chimera - works OK.
I will try to make a build package with my xawplus variant of xwoaf.

[goingnuts]

Thanks Keef!

Works very well. xwaof boots very fast on my P3 (amd palomino). It's faster than anything

I put it on ext3, next to several frugal puppies. So it does not have to be ext2.

However 2 issues for now:
my keyboard is azerty (be-latin1)
I have no internet, normally it is a network connection, ethernet, eth0

How can I set up these?
Where can I find this kind of info, or even what is or is not possible?

For keyboard you will have to modify the build - and for ethernet you need to build the kernel and correct module for your net device - and then rebuild the image. A lot of work without guarantee for success - but also a lot of fun while doing it

[goingnuts]

It bothered me to release xwoaf-toolchain without the ability to rebuild the old kernel-2.2.25. It needs gcc-2.95.3 or older - every test to patch kernel source to accept gcc-3.x.x have failed. And cross compiling gcc-2.95.3 to work in the toolchain also failed. But:
One can build a simple gcc-2.95.3 within the toolchain using gcc-3.4.3, install it in /opt and then use it to compile the kernel. Only minor patch to the kernel needed to cope with binutils-2.19.1.

It is important to link cc to the gcc-2.95.3 compiler before doing the kernel build - it is linked to ccache in the toolchain.
Ran into problems with missing as86 and ld86 - not every version of it builds with uclibc to a working bin - but bin86-0.4 does.

So in the end I am now able to compile the original xwoaf kernel-2.2.25 and modules to same size and features as the original.

I have updated the howto here where also xwoaf-build-package_kernel.tar.gz can be downloaded (buildscripts, patches and sources).
So the adventurous can now time travel back and build kernel 2.2.25 (bl3, xwoaf and skatos are some of the more known distributions that used it or nearby relatives).

[NeroVance]

Yes, I see so many interesting projects, that have been forgot or lost, bits and pieces that could be put together to build a new kind of radically small, lean-and-mean Puppy.

A new pup built with xlib apps, tinyx, and gtk 1.2, would be great. There were such nice gtk1.2 apps that we abandoned. Also there were some very interesting projects, such as xft support in gtk1.2, for antialiased fonts -- there was a git site for that.

Tbh I would love to see what software can still be compiled with gtk1.2 and if there are older versions of some software of which we cannot compile that would still suit our needs.

I feel like Puppy has really changed a lot since even the 4.x days. From the loss of Tcl, to the splintering into dozens of different puppies. I like the variety, but at the same time, it seems like it adds a lot of possible incompatibility, back in the day you didn't have to worry about what the base distro was and what arch the package needed to be in

If you wanted a program you would just hit up the forum and people would show their wares, almost like a little informal marketplace, which I will admit I always liked

[goingnuts]

NeroVance: Agree! One option to address the possible incompatibility of pets for various versions of Puppy could be to supply static linked binaries. This give "portability" beyond Puppy as well. I know this is not possible with some applications, but when possible, it could be the target. Size on disc will increase but that is really not a limiting factor for most users...

Some findings working further with xwoaf...

My first approach to get more room was to use "mklibs" which repack the dynamic libraries to only contain what the applications on the floppy needs - and that does work.

Then tried to use upx on the binaries but that gave a slight increase in total size (of Image.gz).

sstrip reduces a tiny bit but not with the magnitude I was looking for.

exepak works - but upx seems more efficient.

The dynamic libraries wont compress with upx - though recent versions of upx works with libc libraries - it refuses to compress uclibc dynamic libraries.

upx can compress the kernel but afterwards kernel wont boot.

Never compress busybox as execution speed decreases a lot.

My present solution is to create multi call binaries and static link them. This give the possibility to reduce size of dynamic libraries left and the static linked binaries compress well with upx.

The creation of multi call binaries is a much more complicated process but frees space. And they work outside xwoaf too as no external libraries are needed.

The new free space is used to include cdrom and loop modules in kernel (you cant compress modules but build in modules are compressed with the kernel), upgraded version of busybox and added support for creating/formating partitions and added extlinux to make hard disk boot able. So now install to hard disk can be performed - at least from floppy - install from iso-boot depend if the cd/dvd-drive is recognized correctly by this 15 year old kernel. And tools for setting the keyboard is now included.

At the moment the floppy contains the following applications: jwm menu rxvt xcmd xinit xsetroot xcalc xcalendar xe xfilemanager xminesweep busybox pr extlinux Xvesa.


xwoaf_rebuild3 floppy-image
xwoaf_rebuild3 iso-image