logoPuppy developer news:

from 2.20a to 3.00b

left-arrow Older news

arrow-rightLater news

Puppy 3.00 BETA with kernel 

I have created an alternative iso file with the "old" kernel that was used in a few versions of Puppy up to and including v2.16.1. It is to be found here:
...it's only 92.1MB, due I think to a smaller zdrv file.

The reasons for doing this are that some people reported problems when upgrading from v2.16 to 2.17. One problem was a real show-stopper: Puppy would not boot at all. Another problem was reports of dialup dropout.

I also have a problem to report when I moved up from v2.16. My Acer laptop that I now use as my primary daily workhorse, now has non-functional sound. The drive loads, just no sound comes out. A bug report to the ALSA developers has not resolved it. But, the sound worked fine in 2.16 and earlier. A problem with the ALSA driver version, or the kernel version, or both?

Anyway, I have created this iso file so that those people who had any of the above problems, or maybe something else that they suspect may have something to do with the kernel, can try it and find out for sure.

This build is for basic testing only. I don't recommend that you do anything much with it, like, don't install it. Though, I have tested it booting off a USB flash drive (in fact that's all I've tested, haven't even tried the live-CD). If it turns out that problems are fixed by reverting to this older kernel, then I intend to grab the source (the last of the 2.6.18 series) and compile it and make that an official alternative 3.00 -- in fact, I'll probably use it myself since the sound works for me.

Note, the live-cd has boot parameter 'layerfs=aufs' as I think that is what was used in v2.16. So if you do try an install somewhere, be sure to have that. When I compile the source I'll patch it with the latest unionfs so that we have the nice true-flushing.

if you have already got a pup_save file from testing the other 3.00beta, probably best to avoid it for this version.

On the subject of ALSA, does Puppy 3.0 have the ALSA libraries/utilities from Slackware 12?
If so, I suggest a complete ALSA installation because these libraries are unlikely to be the same ALSA version as the modules from, neither, for that matter.

Regarding your Acer's sound problem, try to load the ALSA module (snd-hda-intel?) with "model=acer" parameter.
So in /etc/modprobe.conf -

options snd-hda-intel model=acer

There are some other module parameters that can be tried; I read that "probe_mask=3" and "position_fix=3" is good for Acer's.
And there's also "enable_msi=1"

Regarding dialup dropouts, it would be good if the people who reported that problem could try Puppy 3.0 with the 2.6.21 kernel.
Maybe the upgrade of pptp to v1.7.1 will have fixed the problem?

wolf pup 
does the 2.6.18 alternative puppy have the same compile options like the 2.6.21 pup? 250hz timer?

john doe 
i concur with tempestuos's second comment.

pushing forward is usually better than looking back.

Barry Kauler 
The dialup drop problems occurred when moving from Puppy 2.16 to 2.17, so from kernel to It was for analog modem Internet access, which does not involve pptp.

Puppy 2.17 kernel has a 100Hz timer, same as the kernel. The experimental alternative iso that I have posted has the kernel from Puppy 2.16, I have not (yet) recompiled it.

It is only with Puppy 3.00 that I have moved up to a 250Hz timer (and tickless).

Well, Pup 3.00beta has ALSA kernel drivers version 1.0.14rc3, whereas the utilities/libraries are the 1.0.14final. When trying to get my sound to work in 2.17, I did make sure driver and libraries matched exactly. I'm not sure if I recall correctly, but I think there was a mismatch in 2.16, which had working sound.

I tried each of those sound options, no go. Besides, I didn't need any options in Puppy 2.16.

My main motivation for providing an alternative with the 2.6.18 kernel is for some long-term Puppy users who were unable to upgrade from 2.16, as the kernel gave errors in 2.17 and they were unable to boot. A couple of those people have expressed their disappointment to me. This alternative will enable them to get a clearer picture if it is the kernel to blame. And if it does indeed seem to be the kernel, then I will release a 3.00final alternative with a kernel that works for them.

I got pptp confused with ppp/pppd.
And now I see that there has been no change in ppp since v2.4.4 in June 2006.

Yes, 2.17 has ppp 2.4.4, but 2.16 has ppp 2.4.3.

v3 with the kernel works for me , for both sound and wine 9.39 which v2.17 did not
I got it up and runnibg and customized in very short order - so that makes me very happy
Nicely done Barry

I'm still using Puppy 2.16 on my Compaq Armada 1750 as ACPI does not work with 2.17 and 3.0 using kernel 2.6.21. I tried v3 with the old kernel and evrything works fine, ACPI, sound, Wifi.
Thanks Barry

I tried the 3.00 BETA and also 3.0 beta with kernel on a laptop that had been running 2.17.1. It is a Dell Inspiron 700m. Nothing new or fancy. Both kernels fail to boot. With the I get a panic on thw switch_root to unionfs.

I have tried a simple download via Seamonkey and now Xwget and both
produce failed mdsums:

sh-3.00# md5sum puppy-3.00beta-seamonkey-k2.6.18.1.iso
34ab06126d4b74c1486c93454302dd22 puppy-3.00beta-seamonkey-k2.6.18.1.iso
sh-3.00# md5sum puppy-3.00beta-seamonkey-k2.6.18.1.iso.md5.txt
c1ecf1b225f01c179dcb5a6a57a07720 puppy-3.00beta-seamonkey-k2.6.18.1.iso.md5.txt

Any ideas as to why, please?

I really want to try both versions of 3.00 on my Toughbook.

Thanks! doc

Hi Barry. I have 2 bits of feedback; one good, the other not so good.

First the good. This version has eliminated the permissions problems in 2.17 with userid nobody that prevented lampp from working. Hurrah!

Not so good is that installing the proprietory ATI driver for my graphics card (with MU's 3DCC) broke X. XWIN just wouldn't start, so had to run XORGWIZARD again losing the use of the driver which is necessary to run at the correct resolution.


All 3D drivers, both proprietary and opensource, are depend on kernel modules. And since Puppy 3.0 has a new kernel, no existing 3D kernel modules contributed on the forum will be compatible. You should wait until Puppy 3.0 reaches final stage and then various contributors (MU, kirk, or myself) will compile the necessary modules.

I am testing under vmware server (creating virtual machines).

The version puppy-3.00beta-seamonkey.iso got stuck when uncompressing the kernel.

The version puppy-3.00beta-seamonkey-k2.6.18.1.iso loaded correctly except that it tried to access /dev/hda and it stopped for 60 seconds as the image does not have any partitions when started for the first time. They must be created from within Puppy before shuting down the first time.

So, the old kernel seems still like a good option.

Tempestuous; thanks for the advice.

In the words of the song "you never get no-where if you're too hasty!"


Puppy version 3.00 BETA 

As usual, this is not a general release. It is for our Puppy-testers, to find any remaining bugs.

Download from here: ftp://ibiblio.org/pub/linux/distributions/puppylinux/test/puppy-3.00beta/
Release notes: http://www.puppylinux.com/download/release-3.00.htm

Although this is version 3.00beta, internally it is numbered '221', so the files are pup_221.sfs and zdrv_221.sfs.

The JWM color scheme and desktop image may be tweaked before the final. If anyone would like to come up with something, you are welcome to submit it.

Abiword and Gnumeric have not been upgraded. They are the same as in 2.17. I plan to upgrade these in Puppy 3.01. Something else long overdue is upgrade to pcmciautils, which now also falls back to 3.01.

There is still a bug with frugal install. The Universal Installer can install vmlinuz, initrd.gz, pup_221.sfs and zdrv_221.sfs to a subdirectory, however the zdrv file is not recognised, so extra modules that you might need, like for sound, don't get loaded. The zdrv file has to be placed at the root, '/', of the hard drive partition, which you will have to do manually.
I need some feedback on this -- do we need to have the zdrv file in each subdirectory in which there is a frugal install, or should it have to be at '/'? Or, maybe Puppy could be made to recognise either location. Anyway, I'll fix that for the final.
Note, extra sfs files do have to be at '/' in the hard drive partition, as that's where /mnt/home points to.

The devx_221.sfs has also been uploaded, but I think it needs a few small things fixed.

Only a small number of updated PET packages have been uploaded, and they are in the 'pet_packages-3' directory at ibiblio.org. I will be using this directory in future.

Please post bug reports to this forum thread:

Problems to access the zdrv file on the ibiblio server:

Firefox Result is a warning 550, not a directory.
Rest of the files are ok.

Finally I take all the files out of the iso image.

Okay, I fixed the zdrv file, it can now be downloaded.

dpt (dptxp<at>yahoo.co.in) 
Please strengthen the Hard Disk Installation of Puppy. It should be simple and reliable.
Everyone who has used Puppy loves it, but users fail to install it to
HDD properly, one OS was removed from my GRUB.
Please give this top priority.

I also had problems booting 2.16 from USB Flash, did not boot. Maybe
reliable booting from Flash (as good as from CD) can be done first.

I shall try to help once I am familiar with Linux, I have liked two
Linux Distros so far. Ubuntu, I use, Puppy I use but occasionally.

Please excuse me if I have posted at wrong place. I am a member at
murgalinux with dptxp user id.


Can't get pppd to work in 3.00beta:

Sep 17 04:18:03 (none) kern.debug kernel: unionfs: do delay copyup of "slhc.ko"
Sep 17 04:18:03 (none) kern.info kernel: PPP generic driver version 2.4.2
Sep 17 04:18:03 (none) kern.debug kernel: unionfs: do delay copyup of "ppp_generic.ko"
Sep 17 12:18:03 (none) daemon.notice pppd[5875]: pppd 2.4.4 started by root, uid 0
Sep 17 04:18:03 (none) kern.debug kernel: unionfs: do delay copyup of "utmp"
Sep 17 04:18:03 (none) kern.warn kernel: ppp_async: Unknown symbol crc_ccitt_table
Sep 17 04:18:03 (none) kern.debug kernel: unionfs: do delay copyup of "ppp_async.ko"
Sep 17 04:18:03 (none) kern.warn kernel: ppp_async: Unknown symbol crc_ccitt_table
Sep 17 04:18:03 (none) daemon.notice modprobe: FATAL: Error inserting ppp_async (/lib/modules/ Unknown symbol in module, or unknown parameter (see dmesg)
Sep 17 12:18:03 (none) daemon.err pppd[5875]: Couldn't set tty to PPP discipline: Invalid argument

Would have posted in the forum, but it's down right now.

Never mind. I think I may need to recompile my modem driver. It might be causing the problem with pppd.

With Puppy 3.0 B1 our BCMWL5.inf wireless card on an HP ZE2113US laptop is recognized as a BCN43xx and we have not yet been able to connect wirelessly to the internet.

Also we need a realplayer PetGet download.

In previous comment, that should have been "recognized as BCM43xx".

Upgrades: WakePup2, Pfind, PDF-Printer 

john doe has upgraded WakePup2, our Puppy boot floppy. Many improvements, including finding Puppy in a subdirectory and NTFS support -- which reminds me, I will have to upgrade the Universal Installer to add NTFS partitions to the choices when creating a boot floppy disk (I'll do that after the beta is released). Puppy has WakePup2 in the live-CD, no need to download it from anywhere.

zigbert has upgraded Pfind, a superb file find utility, to version 2.4.

That also reminds me -- authors, do be aware that Puppy has always had mime information in /etc/mailcap and /etc/mime.types. This is a very old Unix mime system, still in all Linux distros (or most anyway) -- I informed the author of NoteCase about this recently, as he had not worked out a universal way to determine the default web browser in a Linux system -- now fixed in the latest NoteCase -- sometimes the old and simple methods get forgotten.

jcoder24 has updated his CUPS PDF printer to version 0.8. Actually, in Puppy it is PET package cups_pdf-0.8, now up from cups_pdf-0.3 used in pup 2.17 -- this is slightly modified from the PET package that jcoder24 has posted on the forum as I have preconfigured the CUPS PET package with cups_pdf already setup as the default printer. On ibiblio.org there are also 'pdf_printer' PET packages but these are for the PDQ print system.

Oh yes, please note that PDQ is not in 3.00beta. It has become incompatible, as increasingly some applications are being compiled that require CUPS to print -- Epdfview for example.

Finally, I have written a wrapper script for Xdialog, to fix the LANG problem. The real 'Xdialog' is renamed to 'Xdialog.bin'.

extension .rar is not detected with rox, but works in Xarchiver.

does anybody know about the *.Z extension? it is used here: http://alge.anart.no/projects/xbible/

i believe that it is a compressed file i think that i got it to open somehow but i don't remember how

also i have been unable to compile BRS (bible retreval system) on which XBible depends

i think it can be opened with uncompress filename on the commandline but i'll have to check that later

john doe 
>...and NTFS support

just to make sure we are all on the same page, NTFS doesn't work "out of the box" with the new wakepup. it requires some tinkering on the users part.

working NTFS into the universal install is a neat idea.

when are we going to work on HFS+ booting and saving and mut and pmount support for puppy? have i not left enough information around?

Barry Kauler 
I have not made Xdialog into a wrapper script, as it wreaks some scripts.

Wrapper script for Xdialog? 
Authors are patching LANG=C into their scripts to fix a problem with Xdialog, but perhaps I should rename Xdailog to Xdialog.bin and create a script that exports LANG=C before launching Xdialog.bin? Tha would be a global solution.

Can we translate this script into other languages?

Barry Kauler 
I don't know. I'm just responding to the fix posted by various people in the forum. Regarding using Xdialog with other languages, perhaps there are comments about that in the forum.

Certainly, this is something to be taken up with the developer of Xdialog. We have a hacked version for GTK2, different from the developer's official vesion -- his version, last time I looked, was even less functional than ours -- the GTK2 version that is.

Barry Kauler 
I have not made Xdialog into a wrapper script as it wreaks some scripts.

pptp updated, puppybackground bugfix, synaptics driver 

As requested, pptp has been upgraded to v1.7.1.

MU (Mark) has fixed a bug in puppybackground, it needed LANG=C.

kirk, thanks for the Synaptics driver for Xorg.

Isomaster, kp upgrades, new procps, tmpfs flushing 

Andrew Smith, the author of the excellent Isomaster has brought out version 1.1.

'gray' has rewritten the 'KP' process management application to use Gnocl instead of Tk, so that it has a nice GTK2 user interface.

Which leads me to 'procps'. Puppy uses the 'ps' applet from Busybox, is cutdown and only understands one commandline option ('-w' I think), but gray's KP needs the full ps. So, I have put in the 'procps' package, but only two utilities from it, 'ps' and 'sysctl', as Busybox has most of the rest. A problem is that the Busybox ps is used in many Puppy scripts and has an output different from the full ps. To avoid break, I have implemented 'ps' as a script -- if ps is executed without any parameters then the Busybox applet is executed, otherwise the full version. The full version is named 'ps-FULL'.

'andrei' has been working on a method to get true flushing of tmpfs (RAM) to Flash drive, and if you have followed this Blog you will know this is an issue that we have been grappling with for sometime. He worked out a system that works the same for both unionfs and aufs.

Unionfs has been steadily progressing. I made the note in this Blog recently that Unionfs works in a situation where Aufs totally fails -- the frugal install with personal save on an entire partition. The 2.x series is supposed to have enhanced ability to write directly to a layer, and I experimented some more on that last night and into this morning, but found it's behaviour to be unreliable. Basically, if a directory or file is created in the pup_save file, then it should automatically appear at the top of the unionfs mountpoint, however in certain circumstances it remains invisible -- the issue has to do with creating multiple subdirectories.

When a file or directory is created directly on a layer, unionfs management detects it and makes it visible on the top -- except when it doesn't work. I was thinking to myself that what it really needs is some way to tell unionfs management to totally re-evaluate everything in the layers -- well, there is such a thing. Recent Unionfs docs state that this mechanism is not required with the latest versions, which had lead me to neglect trying it. There is a thing called 'incgen' which achieves this and is used like this:
# mount -t unionfs -o remount,incgen unionfs /

I am pleased to report that I got it working reliably. I stripped the 'snapmergepuppy' script down to its bare basics, with copy-down saving only, and I put true-flushing into the PET package manager, PETget, script /usr/sbin/petget. To avoid potential compromises to file integrity, I have constrained true flushing to only when installing a package.
The code that saves direct to the Flash drive layer and performs a full layer re-evaluation is very simple, and authors of other package installers can implement the same -- just look for the string "flush" in my petget script.

For those who are new to this, true flushing applies to the situation where Puppy is using a Flash drive for the pup_save file (or saving to an entire partition), where writing to Flash has to be constrained to prolong its life. Instead, Puppy works in RAM, saving to the Flash drive periodically. The problem arises if you don't have much RAM, or at least if free RAM space is less than the size of your pup_save file. By flushing the files from RAM to the pup_ave file, RAM space is freed up. Thus, you can now install lots of PET packages and not run out of RAM space.

A large part of the snapmergepuppy deals with the whiteout files, and this issue is totally independent of flushing. So, maybe that part should not have been stripped.

On the other hand, since we are testing flushing, maybe it is better to forget about everything except flushing. Maybe, indeed, we should forget for now about handling whiteout files, just to concentrate on flushing.
And then take care about handling whiteouts in the 3.00 final.

Yes, I was getting a bit confused about the code that handled whiteouts in snapmergepuppy and elsewhere, so I stripped it down to the absolute basics. My thinking was to get the basic functionality working reliably, and some fine points of whiteout handling can be added later, after the beta -- I was going to send you an email about this.
My cutdown snapmergepuppy does have whiteout handling, just the minimum.

barry there is an issue with .createpuppy giving an error if there is no text or space in between quotes in packages.txt

is that a feature? if not perhaps if there is nothing between the quotes then the size of the package could be automatically fetched an put in there or auto insert a space if there is not any text or space

barry there is an issue with .createpuppy giving an error if there is no text or space in between quotes in packages.txt

is that a feature? if not perhaps if there is nothing between the quotes then the size of the package could be automatically fetched an put in there or auto insert a space if there is not any text or space

cb88, I think I ixed that recently.

An extra note regarding petget. It also has some whiteout-repair code in it, to ensure that dirs and files written direct to pup_ro1 aren't blocked by whiteouts in pup_rw.

Thanks, Barry.
A full ps is a great addition to Puppy. It will allow much more flexible process analysis than the cut down version, making Puppy a more standard Linux.

Pbdict bugfix 

'zigbert' has fixed a bug and made various improvements in Pbdict, our online dictionary and thesaurus. Forum thread here:

It works fine, but one thing I noticed when run it is from a terminal in 2.20+ is this output:
(gtkdialog3:9642): Gtk-CRITICAL **: gtk_widget_grab_default: assertion `GTK_WIDGET_CAN_DEFAULT (widget)' failed
Perhaps MU knows what this is? ...is it a problem with PuppyBasic?


Your mention of PbDict, which I use all the time, prompted me to ask about this. I suppose there is a reason for it but would like to know, even if it's a "dumb" question -

After one keys a search term into PbDict, or PFinder, or PSI why cannot he simply continue and key "enter" (as in Google search, for example) instead of having to pick up the mouse to click on "dict" or "search" or "OK" etc. Perhaps it simplifies programming but seems lame in the human interface.

After being continually dazzled by all the brilliant things being done here, it strains my humility to ask such a pedestrian thing ;-)


I was continually dismayed by the quirk Henry detailed and have long since opted for the non-GUI approach. One tap of F4 opens a terminal, I type "dict" and the word I'm interested in and the enter key.

On a related note, I've been further avoiding mouse-addiction induced RSI and carpel tunnel syndrome by using existing hot-keys and adding my own in /root/.jwm/jwmrc-personal.

Barry - have you seen the latest versions of Pfind and jcoder's pdf-writer? There's quite a bit of new functionality, and Pfind is pretty stable now .

-and pfind is now all gtkdialog


Your request is already fixed in the latest PBdict and Pfind.

Unleashed-CD orders 

I've got three CD orders to process. I was almost going to process them, but decided to hold them until pup 3.00 is released -- I'll send emails to let them know why the delay.
For anyone else who wants to order a CD, if you do so I will post it after 3.00 is out, which is likely to be... well, soon. The beta is due on the 16th and it all depends on how many bugs it has.

Doug Perry 
If I'm one of those 'held back' I appreciate your ensuring I receive the very latest Puppy Unleashed, as promised! :-)

Pure-ftpd, Trash and Pbackup updated 

'getnikar' (David) has updated the script for the pure-ftpd FTP server package. Forum thread:

'disciple' has improved the trashcan so that it can handle paths and filenames with spaces. Forum thread:

'zigbert' has updated his great Puppy-backup program to version 3.0.0. Forum thread:

These will be in the next Puppy.

Network Wizard upgraded 

Tempestuous, Dougal and others have been working on improving the Network Wizard, script /usr/sbin/net-setup.sh. Their last update was on the 24th of August, posted here:

Now it's my turn... I want to put this into pup 3.00, so I have done some more work on it and got it to my liking. I reduced the size somewhat, while keeping all the functionality, changed the primary window so that the 'tree' widget is eliminated. There was a problem with the 'Back' button after an interface had been configured.

I've posted my version at the above thread for testing, but do note that to get it to work,one of two things must be done -- either update gtkdialog to version 0.7.20, or edit the net-setup.sh script and remove the '--geometry' commandline option. My alternative to the 'tree' displays okay, except gtkdialog miscalculates the window width, so it has to be set on the commandline -- but the '--geometry' cmmandline option in gtkdialog3 v0.7.18 (used in pup 2.17) causes a segmentation fault. The change-log for gtkdialog states that was fixed for 0.7.20.

To see what I have done in the script, look for the string 'v2.21'.

Yawn. I'm going to relax, go for a short walk, eat and watch TV for awhile. I've been sitting in front of this screen from dawn till dusk -- quite literally. 6am to 6pm. Even ate lunch in front of it.

JWM window manager 2.0.1 

I've upgraded, but my first superficial assessment is, so what? People have been urging me to upgrade from v1.8, but my desktop looks the same, and a quick peruse through the online docs doesn't show anything that will startlingly improve the desktop appearance or performance ...or have I missed something?

And I'm very puzzled. I have compiled in pup 2.2x and the jwm executable is 334KB, whereas v1.8 is 128KB (compiled in an earlier Puppy). Even the v2.0 I compiled awhile ago is 130KB. Yes, it's stripped. I checked and both have the same shared libraries -- my first thought was that perhaps one library got compiled in statically, but apparently not. Weird.

Hi Barry,

new version has gradients. You have to configure .jwmrc.

Best regards


More specifically, where you have one colour put 2 in separated by a colon. There's a new default one at /usr/local/etc/jwmrc.system which has stuff in it to look at/copy from.

But I expect you know all that already, so I'll shut up and stop being a smartass now.

JWM issues I remember are:

- Blinky and the free memory applet misbehaving or disappearing for no reason.
- The 'minimise all windows'/'show desktop' button was withdrawn.

I wish the virtual desktops icon could be disabled too - I never have more than one (must be a sign of an untidy mind).

Anyway I hope the gradients allow for some shinny schemes.

from /root/.jwmrc-tray

I agree that extra shininess is not worth more than a few k
I tried to have a look at this using devx-2.20 to compile jwm-2.01 but got
# make
cd src ; make all
make[1]: Entering directory `/tmp/jwm-2.0.1/src'
gcc -c -g -O2 -I/usr/include/libpng12 -I/usr/X11R7/include -I/usr/include/freetype2 -I/usr/X11R7/include -I/usr/include/fribidi background.c
In file included from background.c:10:
jwm.h:75:40: error: X11/extensions/shape.h: No such file or directory
jwm.h:78:43: error: X11/extensions/Xinerama.h: No such file or directory
make[1]: *** [background.o] Error 1
make[1]: Leaving directory `/tmp/jwm-2.0.1/src'
make: *** [all] Error 2

the output from configure is subtlety different to 2.16 as well

# diff configure-pup-2.16.log configure-pup-2.20.log
< checking ft2build.h presence... [b]no[/b]
> checking ft2build.h presence... [b]yes[/b]
< Compile flags: -g -O2 -I/usr/include/libpng12 -I/usr/include/freetype2 -I/usr/X11R7/include -I/usr/X11R7/include -I/usr/include/fribidi
< Link flags: -L/usr/X11R6/lib -lX11 [b]-L//usr/lib[/b] -lpng12 -lz [b]-lm[/b] -ljpeg -L/usr/X11R7/lib -lXft -lXrender -lfontconfig -lfreetype -lz -lX11 -L/usr/X11R7/lib -lXrender -lX11 -lfribidi -lXpm -lXext -lXinerama
> Compile flags: -g -O2 -I/usr/include/libpng12 -I/usr/X11R7/include -I/usr/include/freetype2 -I/usr/X11R7/include -I/usr/include/fribidi
> Link flags: -L/usr/X11R6/lib -lX11 -lpng12 -ljpeg -L/usr/X11R7/lib -lXft -lXrender -lfontconfig -lfreetype -lz -lX11 -L/usr/X11R7/lib -lXrender -lX11 -lfribidi -lXpm -lXext -lXinerama

Tom again 

here is the part of my .jwmrc for a vista look of jwm. Hope it helps. Apologize my bad english.

<!-- new for jwm 2.0, replaces borderstyle above -->







<!-- Additional TrayStyle attribute: insert -->




Yeah, the devx_220.sfs file is not quite right. I have fixed those missing header files. I think that I got a bigger executable because a library has got compiled in statically, even though 'ldd' shows it as shared -- due to it being a shared dependency of another shared library. Anyway, I should be able to fix that in the devx file.

So, apart from possible bug fixes, the big new thing is the gradients.

Yeah - the gradients are cool, but it is REALLY annoying being unable to resize windows from the top. Joe said he's thinking of reenabling it somehow though.

Zygo - you'll also want to change .jwmrc so it says
<Desktops count="1"/>, otherwise one day you might end up on another desktop by accident, by using a shortcut key.

Thanks disciple. I do that with the JWM configuration program. Which makes the pager all the more unnecessary. I now realise the issue is not with JWM.

This forum can be read but this is my second (in-time) attempt to post. It was also unavailable about 3 and 5 hours ago.

The other thing that now works in JWM is the pager in the taskbar. You must use the right drag on the mouse to move windows from one desktop to the others, within the pager.

The themes of course should be upgraded and have needed it. This is why jwm configuration doesn't work on hide taskbar or height adjustments, if you change to a different theme other than default. There is an unused tag in the themes that needs remarking out in the older themes as shown by "jwm -p" in terminal.

I have been using jwm 2.0.1 with puppy 2.17, so no problem on compiling.

Here is my newest theme for jwm 2.0.1 called hotdog.

TITLE: hotdog
Created: 01/09/2007
Version: 0.1.0
Updates: none: first release.
JWM ver: 0.23.0
Hacked BK Feb 2006 for JWM 1.4



<Font>DejaVu Sans-11:bold</Font>





<Font>DejaVu Sans-12:bold</Font>

<Font>DejaVu Sans-11</Font>

<Font>DejaVu Sans-13:bold</Font>
<!-- <Height>24</Height> -->





<Font>DejaVu Sans-13</Font>


<Font>DejaVu Sans-12</Font>



Good Luck, Kal, just an end user

Network detection backgrounded at bootup 

Network detection at bootup causes a significant delay, mostly while waiting for the dhcp server to respond in my case. We did investigate "backgrounding" it awhile back, but I had issues with the 'ifplugstatus' program returning different results when run as a background process. It was weird, I never found out why. Now though, I can't reproduce it. Anyway, longtime-Puppy-enthusiast and contributor 'pakt' (Paul) has found a bug in the rc.network script related to backgrounding. I have applied his fix and now my Puppy is booting up many seconds faster!

For anyone interested, pakt's forum thread on this is here:

Unleashed: packages for building without Xorg and SeaMonkey 

I have created a couple of packages to make it easy if Unleashed is used to build a Puppy without Xorg or any Mozilla-based application.

'xorg_libs_tiny-7.2' has the libraries needed by Xvesa and GUI applications. Uncompressed size is 2412KB.

'seamonkey_libs_tiny-1.1.2' has the libraries needed by Xine/Gxine and Pidgin/Gaim. Uncompressed size 904KB.

Desperate request!!!
Could you please, please, please release a parallel version of puppy without the patented codecs installed by default?
I don't know how to remove them myself, and am not game to use them in oz. because of our free trade agreement with u.s. and all the copyright implications that came with it.
Many businesses/charities who resell older pcs may really appreciate this, as your distro is one of the -extremely few- that is viable for otherwise-thrown-away systems (ie, it's both fast and interesting...)
Perhaps you could include a "one-click" script so users can optionally add the codecs in again over the net.
I am guessing the best place to find which codecs are potentially problematic would be through the "ubuntu" project, who seem quite careful about this, and probably know exactly what can and can't be included.
You probably need to disable the bytecode interpreter in truetype fonts at compile time, too, as I think it is patented.

All the best, great project, in fact it's incredible!

rl - I did work on a license-free Puppy earlier this year, but it was based on a very old version of Puppy. I'm thinking of using Raffy's SafePup, which is based on my BarelyPup2.13, to make iPup (name courtesy of Todd and Raffy ;)), customised to be free of licensed code. Send me a PM from the Puppy Forum if you want to contact me.

rl, I think you will be surprised (and probably disappointed) to discover how many codecs are patented.
WindowsMedia, RealVideo and H.264 are obvious examples, but also ALL of the MPEG codecs are patented.
The opensource MPEG codecs, while patent free themselves, still contravene copyright of the intellectual property contained within their code.
If gxine is compiled with all of these codecs disabled, the only useful codecs remaining will be Ogg Vorbis and Ogg Theora.
About 75% of ffmpeg contravenes copyright, so that has to go. So, too, libmad.
The only useful media player that can be "legally" included is XMMS with the license-free MP3 codec provided by Thomson (the licensing representative of the Fraunhofer Institute) -
And even then, this codec cannot be redistributed. Each end user must download the codec themselves.

Barry Kauler 
Using patented codecs in Puppy doesn't mean it is illegal. But, I think that's why you put the "legally" in quotes!

rl (r1000000) 
I appreciate the time that people have spent replying to my request, thank you, and I understand that it would take away considerable functionality to remove codecs etc. - but I was not suggesting removing them from your main version, just making a very-quick "extra" build available occaisionly, just for those to whom it is an issue. I would not find the missing codecs a major problem, as I could still browse the web, write letters, send email etc.

Pakt, I have sent you a message from the forum, (from r1000000) hope you got it ok?

Great project everyone, all the best!

Xvesa overhauled 
This has been a long time coming. I have used Xorg exclusively for so long, that Xvesa has been neglected and has accumulated various bugs. What actually reminded me to do something about it is our keen Puppy enthusiast 'gray' recently rewrote the Xvesa Video Wizard with a GTK2 GUI -- previously it used xmessage, a very spartan Xlib GUI.

Another thing that has been on my mind is that we may have a resurgence of interest in builds of Puppy with Xvesa only, no Xorg. The biggest argument against this, and the primary reason we went over to Xorg, is that on some PCs with conventional cathode-ray-tube monitors the screen refresh frequency was too low, giving an annoying flicker. However with LCD monitors this is not an issue.

I went through the Xvesa Video Wizard (/usr/sbin/video-wizard) and fixed a few things. I changed the GUI layout a bit to my liking. There was a problem with the HTML-vewer coming up with the welcome page, even though the information is now on the desktop -- fixed.

Widescreen support was a problem. If you are lucky enough to have an Intel video chip and a widescreen monitor, Puppy has a little program named '915resolution' that allows the X server to run in the widescreen resolution. However, the code for setting this up is in the Xorg Video Wizard (/usr/sbin/xorgwizard), and you have to run this first, then afterwards choose Xvesa and widescreen is supported. If there is a build of Puppy that does not have Xorg, then the widescreen support is not there -- or rather, wasn't. I have now put extra code into /usr/X11R7/bin/xwin so that before Xvesa starts for the first time, 915resolution is applied if required. Meaning, the Puppy desktop loads, the Xvesa Wizard appears, and the widescreen resolution is in the list of choices.

Another problem was alignment of icons on the right side of the screen. The 'xlock' icon and any icons vertically under it are supposed to be shifted to the right side. That wasn't working, now fixed.

Changing the subject, I was contacted recently about the licence of the 'createpuppy' script in Unleashed. It only had a copyright notice in my name. I have now added a LGPL notice.

By the same token, would it be possible to have only xorg installed and have the xorg wizard present only the one/two that is/are installed?

Hi Barry,

does this also fix the bug with foreign keymaps, which I've found to be present in 2.16, 2.17 and 2.20-alpha?


is this gonna fix the blue garbled screen i get when i exit X on my laptop? it has the neomagic 256av w/ 2mb

Resizing of 'pup_save.2fs' file fixed 

The Utility menu has an entry "Resize personal storage file", which was reported not to work. I found that the /usr/sbin/resizepfile.sh script was buggy, though that was not the cause of the resize failure. I fixed the script, and also added some buttons for smaller size increases (+16MB and +32MB).

At reboot, the resizing appears to work, but only the pup_save.2fs file size increases, not the ext2 filesystem inside it. I tracked down the cause. The 'resize2fs' utility expects a file '/etc/mtab' to tell it what devices are mounted, and aborts if this file is not present. It is adequate to create this file as a symlink to /proc/mounts, which is what I did (in the initial ramdisk) and then resizing worked.

i have modified init (2.17.1) for my needs, maybe its useful for others

1st modification, dont load into ram if paramter found

[ "$PMEDIA" = "ideflash" ] && SIZETESTK=$SIZEFILLK #do not want pup_xxx.sfs in ram.
if [ "$mhnc2r" ];then
echo "mhnc2r found, dont copying pup_xxx.sfs to ram " >/dev/console
echo -n "Mntg $NAMEPUPSFS off /dev/${sfspart}..." >/dev/console
losetup /dev/loop0 ${sfsmntpt}/$NAMEPUPSFS
echo "mhnc2r not found, use default behavoiur " >/dev/console
if [ $SIZEFILLK -gt $SIZETESTK ];then
#create a separate tmpfs... (thanks to Mitch for suggestion)
echo -n "Creating tmpfs for $NAMEPUPSFS on (/initrd)/mnt/tmpfs..." >/dev/console
mount tmpfs /mnt/tmpfs -t tmpfs -o size=${SIZEPUPSFSK}k;check_status $?
echo -n "Copying $NAMEPUPSFS to tmpfs..." >/dev/console
cp -f ${sfsmntpt}/$NAMEPUPSFS /mnt/tmpfs/
losetup /dev/loop0 /mnt/tmpfs/$NAMEPUPSFS
#do not unmount PDEV1 if mounted directly in a unionfs layer...
[ ${1} = "/mnt/dev_ro1" ] && umntfunc /mnt/dev_ro1
echo -n "Mntg $NAMEPUPSFS off /dev/${sfspart}..." >/dev/console
losetup /dev/loop0 ${sfsmntpt}/$NAMEPUPSFS

2nd, no need for large tmpfs

#total ram, less any shared video...
PCRAMSIZE=`free | head -n 2 | tail -n 1 | tr -s " " | cut -f 3 -d " "`
# SIZEFILLK=`expr $PCRAMSIZE \/ 2` #half of ram.
if [ "$mhram" ];then
echo "mhram parameter found, using $MHRAM for tmpfs" >/dev/console
SIZEFILLK=`expr $MHRAM` #miho
SIZEFILLK=`expr $PCRAMSIZE \/ 4` #quarter of ram.
echo "using 1/4 of physical ram $SIZEFILLK" >/dev/console
3rd example syslinux.cfg

default vmlinuz root=/dev/ram0 initrd=initrd.gz PMEDIA=usbflash mhram=32000 mhnc2r=0


regards, miho

Serial mouse bugfix, customised pup_save name 
I have fixed lots of bugs, they don't always get announced. Anyway, there is one in 2.20-alpha that I fixed yesterday. My serial mouse did not work in Xorg, and I found that the auto-probe that Xorg 7.2 does when the Xorg Wizard is run, sets the mouse to '/dev/input/mice' even when a serial mouse is detected. The older Xorg 7.0 saw the existence of '/dev/mouse' and used that. I patched the Xorg Wizard (/usr/sbin/xorgwizard) so that /etc/X11/xorg.conf is restored to '/dev/mouse'.

This morning I added some extra functionality to the shutdown script, including customisation of the name of the 'pup_save.2fs' file. If you are into having lots of pup_save files, when you boot the live-CD you get a list of them, but it is difficult to remember which one is the one you want. Pup 2.20alpha presents you with a complete list of all 'pup_save' files on the computer, one big list, so meaningful names are important. Now you can create a file with any arbitrary extra string inserted, for example 'pup_save-v217_kde.2fs'.

Could you list the date and time of the *2fs files too. I would help a lot.

Along with the naming option, could you add the Puppy version number to the heading of the boot-up pupsave list. That way we can be sure to match correctly any version-related pupsaves and avoid inadvertant upgrades.

Customised pup_save names will be great, simplifying the sequence of steps to end up with an appropriately named pup_save file.

Next Puppy will be 3.00 

Pup 2.20-alpha will be followed by a beta on about the 16th of September. This date is chosen as that's when I'll be in Perth and have ADSL2 Internet access.

Considering the enormous changes, a completely new 'init' script, just about every package upgraded, even a new kernel, I have decided that the final release will be v3.00.

When will the final be released? That of course depends on how buggy the beta is. I need to earn a bit of money to pay the bills (I basically work on Puppy full-time these days, and have almost no other income), and I've been offered eight days work at the Perth Royal Show. This is an annual carnival held in our State capital city, and is an opportunity for country folks to show off their stuff to city people. I was offered the job off gatekeeper for the horse section, to stand guard and only let horse-people who have passes through. Ha, ha, what a total change from the heavy thinking I do all day! I'm looking forward to it.

That will start on the 29th of September, and for that duration I won't have much input to the Puppy project. I'm hoping that v3.00 will be out well before then.

barry i do have a few requests for puppy 3.00

#1 could you please switch to opera it is leaving firefox in the dust so to speak even with only 64mb ram (the 9.02version) is anyhow

#2 i assume that you will have to recompile xorg and drivers while you are at it could you do the 3d drivers too? and have them as official .pets on ibiblio?

#3 xorg 7.3 i think that they are talking about it haveing fast switching of resolution and some other cool stuff. the opensource nvidia driver may be worth checking out even though it is new.

#4 call to gtk themers i would like to get a nice vista like them in puppy so there is a uniform black theme like the theme in opera called lix 1_5 very slick so what if MS did it first (or popularized it first) it is still cool. then this package of extra thems could be sent to barry for review and upload to ibiblio

justification....seamonkey is getting bigger and slower and soon won't run with pfix=ram on an 128mb PC or at the very least it will be much slower than opera. I find that opera is nearly as fast as dillo and there is an even faster(or so they claim) version 9.5 comeing up. normally puppy default to fast and light software why is seamonkey even in there i don't know i mean it is faster than IE 7 but big deal that requires 2 gigs of ram anyway (that was a complete dramatization the IE 7 part anyway)

why the 3d drivers well...beryl (hangs head)...stuff renders smoother(i think) better video...some of that is covered by xorg but almost all modern PC have a decent GPU(an intel GMA at the least) and puppy should be readily upgradeable to take full advantage. And finally it would be nice for once to have 3d drivers from the git go in a version of puppy linux

why the themes tricking people into thinking i got vista running in 64mb ram is hilarious...roflmbool

and barry have fun as a horse bouncer LOL

Barry Kauler 
Puppy 2.20 (and 3.00) is based on Slackware 12 packages. I am using Xorg 7.2 from Slackware. If any extra functionality is available for Slackware 12, it will work in Puppy also.

I didn't know you were working full time on Puppy, but your efforts sure get great results!

So as not to be a leecher, I donated what I could to support you and thank you for your excellent work. I wish it could be more.

I hope you don't get your foot stepped on by a horse, and I hope you have some fun!

John from Warren, MI

hope we are not shooting ourselves in the foot with slack compatability slackware is very big you know perhaps vector linux binaries (slack based) will work as it seems to be optimization oriented

I'm still a newbie at Linux. I've been reading about kernel compiling, and I've been thinking about getting a new machine. Would it be possible or advantageous to build Puppy to take advantage of a dual core processor? They're about impossible to avoid these days. I know backward compatibility is a big point, but keeping it that way also makes it lightning fast on newer machines, something I really like. Just wondering if there's any more speed to be had.


Re: opera. I really like it - use it for a lot of my browsing these days though not able to get over the firefox appeal :) - but don't think we should replace seamonkey with it, as I found the opera mail client (in 9.00 at least) very basic, full of bugs and not able to do many of the things that seamonkey can. So my request to Barry - let's stick to seamonkey!

#what I miss of seamonkey & firefox, and have in opera? is (compressed HTML) MHT.
#I presume it's a lot of extra work, but it could be wonderful if 3d drivers should be in zdrv puppy...sometimes in the past I manage once to compile nvidia drivers (wasn't easy some links had to be erased...the nv module must be previously droppedd) and they work ,but it was verry difficult too complicated for newbye.I know it make puppy to fatten but it would be only zdrv file which can be used only once, or maybe an separate zdrv3d file?
#slackware binary compatibility is welcomed!maybe somebody will write an simple application for slack reposytories or at least an help pages with links to them....By the way .mo modules from SLAX will be recognized: one click mounting by ROX and by BootManager? like .sfs files?
#is too complicated to find for puppy an toolbar icon to easy change the keyboard on the fly (without restarting Xorg), like in KDE? in curent way is almost unsolved in puppy to edit/make bilingual documents, use the dictionary in other language than english...If I could find an tinny .pps viewer compatible with puppy, I shouldn't use OpenOffice at all.
Have a good rest (for your mind ) in this period, I 'm sure you'll come back with great ideeas for puppy30

" I'm looking forward to it. "

Hmmm! How very EDucational for you.


Have a great time BK.


ferike - the mozilla archive format extension does MHT as well.

"If I could find an tinny .pps viewer compatible with puppy, I shouldn't use OpenOffice at all."
If you have Java installed, you can use the non-commercial version of TonicPoint.

I'd be all for 3d drivers in a PETget package. Not in Puppy itself though. As for the zdrv_xxx.sfs file, it wouldn't slow down Puppy, but it would increase download times. I think as far as Puppy is concerned, they aren't needed by enough people to be in zdrv. But PETgets would be cool (I'd make good use of them too).


Maybe it's too late and not worth the bother, but what NinerSevenTango posted above about multi processor support might not be a bad idea. I built a kernel with SMP and had no problems running with my single core Centrino. JohnDoe did the same and ran it on a pentium 75mhz with out problems. You can see some of this testing on a thread started by tempestuous:


Barry Kauler 
No, I'm not ready to go for a SMP kernel, as the 'help' when running the kernel config explicitly warns that it might not work properly on all single-processor PCs. They also warn that there is a loss of performance on single-processor PCs.


John did note some loss of performance, but thought it was do to another config change. Puppy's so fast anyway, don't know if it would make that much difference.

Thanks again.


To where do we send contributions to support your amazing work on Puppy?

Those of us who lack the skills to do more than break the apps that you and others build (or to beg for new ones) can at least help with a few dollars.

It has been so long since I last sent something I have forgotten the PayPal or other place to send it.


David Colburn in Florida (edoc)

Donation button: http://puppylinux.com/download/index.html

The Puppy From Scratch page looks out-of-date:
If you get a chance, could you update the page?
Also is the devx_*.sfs module from
up-to-date? Thanks.

Kernel upgrade 

I was faced with a problem. Puppy 2.20 has an upgraded gcc (C compiler) v4.1.2, but the kernel and modules used in pup 2.17 was compiled with gcc v3.4.4. The 2.20-alpha has this kernel, but the problem is that noone can compile extra modules for it, or rather, they would have to use Puppy 2.17. The reason is, a module must be compiled with the same compiler version as the kernel was compiled with.

I would prefer to stay with one kernel version for at least a few versions of Puppy, but in this case I really don't have much alternative. I decided to recompile the kernel, but realised that if I stay with the same kernel version that will cause problems as Puppy will attempt to load any pre-existing user-compiled modules, which will fail.

So, I chose to move on to a new kernel, and I selected v2.6.21.7, the last of the 2.6.21.x series (which was released on the 4th August 2007). I did not go onto a later kernel, as I wanted my extra modules to compile, and was more interested in stability. I took the opportunity to carefully look through the configuration and find the DVB options that Ted Dog wants -- I think I got it right this time. I also upped the timer from 100Hz to 250Hz, which is the same as the Slackware kernel, but then decided to be brave and also selected the 'tickless' option.

All the extra modem, security, sound, wireless modules compiled okay, and I grabbed later versions in some cases. I've done basic testing on a few computers, seems fine.

Good call, Barry.
I don't like to see a kernel upgrade in the middle of a "series" of releases, but when the series has a significant change, I actually prefer to see a kernel upgrade. It makes things more clear, both for developers and users.

Please don't use 2.6.22. The wifi stack has been completely revised from this version on, and not all wifi modules have been properly rewritten yet to support the new wifi stack. So wifi support under 2.6.22 is hit-and-miss.

Hello BarryK

I have a problem with perl and devx_217.sfs (in clean puppy 2.17.1 frugal install), and I'm wondering if the same C compiler and options was used to compile puppy's OpenSSL, and perl code in devx_xxx.sfs. The reason I'm asking is that I've been having a lot of (as yet unresolved) trouble trying to add in a perl module I need, Net::SSLeay (straight from CPAN website), so that I can get TLS support in a perl email program I'm using. I don't admittedly know if incompatible compiler issues are causing the problem, but I've tried everything I can think of (I've installed some other perl modules without problem, but not any related to OpenSSL).

I'm very new to puppy linux (though an old hand at linux generally), but I've been working with puppy (2.17.1) a huge amount just recently. Fantastic distribution!

Best wishes

William (puppy forum member mcewanw)

re: installing perl module Net::SSLeay problem

Sorry I meant to add that I've posted more details about the problem to the puppy developer's forum at thread:


The overall problem is discussed on murga forum at thread:


Best wishes, William (mcewanw)

Barry Kauler 
Well, with pup 3.00 it is all Slackware 12 packages, and there are repositories, such as http://www.slacky.eu/repository/slackware-12.0/
If it isn't avalable, and you can't create it in Puppy, you can fall back to installing Slackware or Vector or one of the others and trying to compile/install it.

Frugal install on steroids! 

I wanted to do a full install of Puppy, for the purpose of recompiling the kernel -- I have always preferred the full installation for doing that.
However, I was out of drive space, so I decided to try my external USB 40GB hard drive. This has two partitions -- sda1 is 3GB NTFS, sda2 is 33GB ext3. The Universal Installer only offers to do a frugal install on a USB hard drive, so I went along with that.

What I had then was a USB hard drive with extlinux installed to make it bootable, and yep, booted up nicely. At first shutdown, instead of choosing to create a pup_save.2fs file, I chose to save to the entire partition -- you get this choice if the partition has a Linux f.s. Rebooted, and it came up nicely, in PUPMODE=6.

The PUPMODE value is the sum of 4 + 2, where 4 means the pup_220.sfs exists and 2 means a "full install" of Puppy was found in the boot partition. It isn't really a full install, but Puppy sees /etc/puppyversion exists in the boot partition, so adds '2' onto the PUPMODE. If there had been a tmpfs top layer in the unionfs, then another '1' would have got added on, but as the hard drive can sustain many writes this is not required.

What was really pleasing was the free memory shown in the taskbar: 30.8GB.

I'm running it right now. Apps load fast, as the pup_220.sfs got loaded into RAM at bootup.

When I first conceived of this mode of operation, ages ago, I briefly tested it, but this is now the first time I'm giving it a real workout. And I ran into a problem when I wanted to load the devx_220.sfs file -- it wouldn't. I fixed the /mnt/home so that it is a symlink to '/'. I fixed Pmount so it shows the partition sda2 mounted on /mnt/home. I fixed the 'init' script so that it correctly loaded the devx_220.sfs file.

But, at bootup got a kernel panic. Aufs could not handle it, gave a message "/pup_ro3 overlapping". Aufs gets confused, as /pup_ro3 has devx_220.sfs mounted on it, but '/' is mounted on /pup_rw hich becomes the top layer in the union f.s -- so /pup_ro3 is appearing in two layers.
So, I booted with the 'layerfs=unionfs' boot parameter, causing Puppy to use unionfs instead of aufs, and it worked! One huge tick for unionfs! Unionfs seems to have resolved the demented layers -- the /initrd/pup_rw/pup_ro3 is just empty, /initrd/pup_ro3 has the goods. I'll bring in the kernel source and have a go at compiling, see if it all keeps working happily when given real heavy work to do...

might want to give the aufs guys a heads up just so it is a fair fight ;-)

It's the other way around here - always using frugal install if not the live CD. To many users doing it this way, the workings of fs layers is important.

Thanks for exploring the frugal-partition installation technique. I have felt for a while that it is the optimal way to run Puppy. But I was frustrated that the additional sfs files could not be used in that environment.

Now that you have added devx to the mix, could you also implement support for up to three such files, as in the frugal-pupsave situation? And have all that work with any type of hard drive? Could also you load the added sfs files into ramdisk when space allows?
Thanks, again, as this combination maximizes both speed and "personal data" capacity.

I have fixed it so it loads .sfs files just like normal -- that is, up to three.

that is great since i was just trying to compile octave add ran out of memory with a 512 puppsave

NetSurf web browser 

I'm experimenting with NetSurf, a small GTK2 web browser with CSS support (not Javascript though). Puppy 2.17 uses Gtkmoz as the internal HTML viewer, however all the cut-down Mozilla-based browsers use a lot of resources to run. Minimo is another example. Actually, Gtkmoz is only the GtkTestEmbed application that ships with the SeaMonkey package.

NetSurf 1.1 package is 1.0MB uncompressed, and the executable itself is only 470K. I tried it out as a web browser, and although it has SSL, it crashed when I logged in to PayPal.

As an internal HTML viewer it is fine. I also wanted to use it for the CUPS web interface, however when adding a printer it did not render a pull-down menu properly. Meaning it is probably almost there but not quite. I have joined the NetSurf email list, and will suggest development should aim at supporting the CUPS web interface.

Note, I didn't compile it, as I couldn't figure out how (well, I only tried for about one minute). Instead I grabbed a binary from a Debian repository. The NetSurf home page is here:

thanks for giving us low end pc users a little extra consideration

it must be very active since the test builds are built every 15 min.

wonder if the javascript support from hv3 could be ported?
cb88 ;-)

the forum seems to be dowm getting this message

Critical Error

Could not connect to the database

It looks like NetSurf renders pages a whole lot better than Dillo. I look forward to giving it a try, if NetSurf makes it into the final release!

Sine Nomine 
Hi Barry,

Thanks for your great work on puppy! I don't know about how many resources it takes but

I have been experimenting with 2.20 & the granparadiso alpha-7 build. On a 667mhz celeron

with 192 MB of ram, I currently have 61.3 available according to the free ram icon down near the clock.

No flash is NOT running, but I find that an easy way to permit rapid browsing without unwanted ads,


Just my 2 cents worth.

Thanks again

Sine Nomine


* tabs
* bookmarks
* changing tab name
* changing font for tabs
* encodings (all available from GTK2)

Configuration can be done via $HOME/.termit file (example is provided).

500k: http://termit.googlecode.com/files/termit-1.0.2.tar.gz
20k (tiny): http://termit.googlecode.com/files/term

As far as I know :
dillo is lightest but missses javascript and java.
opera is very light and fast but very complete.
firefox, seamonkey are too slow on old pcs.

You are 200% right to keep puppy as small as possible :-) It will be faster and easier to maintain.

You can try a pc with only 32mb ram and you will notice which apps are ok and which not. :-)
By the way, many laptops models have probs with xorg to start,like toshiba tecra 8000.

Why not create a user puppy with passw puppy, so it will limitate risks of erasing system data.

By the way why is there /usr/X11R6 and /usr/X11R7 installed ? do we need both ???
There are also twice same docs for cups : /usr/doc/cups and /usr/doc/cups-1.1.23

Are smbclient and smbmount run , even if we dont need samba ?

It would be nice too that windows key would work by default :-)

Seamonkey is slow because it uses many libraries ?
ldd /usr/lib/mozilla/seamonkey-bin


Netsurf can be compiled as follows:

Install the "Lemon Parser Generator" from Debian sid:


Install "re2c" from Debian sid:


Download the NetSurf 1.1 Source Code:


From the Netsurf source directory do:
make gtk
make gtk install

In my case, the resulting Netsurf binary handles the PayPal website without any problems.

It also appears to handle the Cups Interface on "http://localhost:631/", although the response to menu clicks is rather slow.

Thanks for that, I'll compile it for 2.20. The Debian binary puts out a lot of complaints on stderr.

No, X11R6 isn't actually installed. If you look closely, you'll see that /usr/X11R6 is just a symlink to /usr/X11R7. It's there in case older scripts or packages try to use /usr/X11R6.

Any directory with an arrow on it is just a symlink. I haven't checked (running an older version ATM), but that's probably the case with the CUPS documentation too.

make clean
make gtk

if you get an error about a missing css-function.

Here is a dotpup, I removed what seemed not necessary (internationalization, docs).
I upxed the binary, but I cannot do that with the glade-file, that is 220 kb.

If it renders slow, try to disable cairo in the options.


oops, broke the last message, sorry... here is the dotpup:

Mark, it runs and am posting via NetSurf now. Tabs and other keys (like home, end) don't work, and the fonts are rather small in Gmail (zooming kills the browser). It handles mail.com well (mail.com uses advanced javascripts). It could not show Yahomail login fields. My Puppy now is 2.16.

Barry Kauler 
I had a reply from the author, after enquiring about the CUPS web interface not working. The pull-down menu to select a printer does not work. He confirmed that is not yet implemented, but will be sometime, he can't say when. But, my guess is that he is pleased with our interest, so will give it some attention soon.

The developers have no plans to implement Javascript, but invite anyone else to join them for that and they will offer full support.

Barry Kauler 
Re fonts, set Dejavu Sans as the default, and bump up the minimum size setting -- I think that I had to make that really high, like 12.

Burniso2cd bugfix and improved 

The author of 'cdrecord', a utility in the 'cdrtools' package, changed the output format when 'cdrecord -scanbus' is executed. Thus, scripts in Puppy 2.17 and earlier that have this will not work in 2.20. Note, the Debian fork of cdrtools also has the same problem.

I fixed the Burniso2cd utility (see Multimedia menu), script /usr/sbin/burniso2cd, and while I was in the script I decided to give it a complete overhaul. Improvements to the user interface, also can now select the burn speed.

While I think of it, Nathan if you read this, I did a search of the scripts, looking for others that execute 'cdrecord -scanbus', and found that the 'copy_cd' script in Grafburn does. I think I remember something about you using the Debian fork, so you probably already have the script working okay with the different output format.

It cold be nice if the burned CD could be verified by itself (menuoption) or at least verified outside the burnerprogamme, as it is futional restriktet - maybe even buggy.
I saw md5deep which could probally be usefulll:

"I fixed the Burniso2cd utility" On DVD (can not remember if same for CD-RW) it says if using DVD-RW, that you should blank the DVD-RW before burning. This has never been required as the program does the blanking before writing . . . It frees a step if people are aware of this.

Barry, is this why multisession does not work in 2.20 alpha?

Ecomoney (info<at>ecomoney.co.uk) 
Currently the default is to look inside the "root" directory to find the ISO. Would it be possible for the burniso2cd script to remember the location of the last burned ISO and return to that location next time it is run. Most ISO files are stored outside the pup_save.2fs for space reasons in a separate folder (perhaps /mnt/home would be a better default location?).

Utilities updated 

Busybox has been updated from v1.01 to 1.6.1.
Coreutils updated from 5.2.1 to 6.9.
Util-linux from 2.12q to 2.12r.

how are you.

In Flash: (CD multisessions use union up)
Can puppy use rootpassword edit configs bypass unionfs directly?
Can puppy use /home or /desktop insted of pup_save.3fs?
Can puppy be simple linux+window_environment like MS /windows?
Can applications be catgory under /opt or /applicatios or /programs?
Aufs can be bypass,tmpfs can be flush,let linux file system work.
I am puppy idiot want learn more, please educate me.


There's a bug in grep in Busybox v1.01. It's always case sensitive even with the i (insensitive) parameter

echo 'Fred flies' | grep -o -i 'f.' returns only one match.

It's not mentined on the site. Any chance of replacing if with a better grep?

Barry Kauler 
Recent versions of Puppy do not use the Busybox grep, they have the full grep program.

Mike Lockmoore 

Follow the "Community Home" and "Community Forum" links to the right. The documentation sub-site found through the Community Home link will help you get up and running. The Community Forum has many people ready and willing to help new users. By reading the general background information at these places, you will see answers to most of your questions, and for the others, you may see that they are not exactly relevant.

This "Developer News" site is for Puppy's creator Barry to communicate with some other people who work on developing and testing brand-new versions of Puppy. It's not really an appropriate place to seek general help. Check out the links and you can find plenty of help. Welcome to Puppy and good luck.

Atol filemanager bug "fixed" 

It was reported that the menu "Advanced -> Open terminal" does not work, even though 'rxvt' is selected in the setup. I found that the setup ("Advanced -> Options") requires the full path for rxvt, that is '/usr/bin/rxvt'. Strangely, the entry for the text editor, 'geany', does not require a path.

Atol is something that I missed since I use Puppy. I really hope it will become the part of Puppy.

From my experience the full featured two panes file manager emelFM2 (1680 KB) seems to be better option than Atol (1062 KB) that offers only a few very basic operations.

http://puppyfiles.org/dotpupsde/dotpups (436441 bytes)

hi barry,

the full path for rxvt would have been my mod, as the original default terminal & editor were non-puppian. i can't recall why i put in the full-path?

do you have a dload location for your atol so i can remove the one on this thread & replace it with your's?


Barry Kauler 
In about a week from now, I'll upload all the new PETs to ibiblio.

'pfix=ram' bug fixed 

I spent about four hours this morning creating decorations for the next Christmas tree!

I don't have any CD-RWs, so I burnt a heap of CD-Rs, trying to track down the bug with the 'pfix=ram' boot parameter. It was elusive, but I was pleased when I found the cause. There were two bugs in the 'init' script. One little bug was the cause of most of the bug-reports from our Puppy-testers. It was a variable in a loop in the 'init' script that should have been initialised each time round the loop. Anyway, the repercusions:

If you booted the live-CD with 'pfix=ram', and the PC has a full-install of Puppy somewhere on it, you will get a kernel panic.

If you avoided the kernel panic, Puppy started up in RAM alright, except with PDEV1="". That causes great trouble, as many scripts read PDEV1 from /etc/rc.d/PUPSTATE and expect it to have the boot partition. For example,the 'zdrvfind' script needs it to locate the 'zdrv_220.sfs' file, consequently modules do not load. Another example is the 'rc.shutdown' script.

Maybe some effect on frugal install also, I'll have to check that one.

Note, when I was testing 2.20alpha prior to its release, I mostly booted from a Flash drive, as that's most convenient way of quickly testing changes. I also tested a h.d. frugal install having booted off a Flash drive, and it worked fine.

" I spent about four hours this morning creating decorations for the next Christmas tree! "


Was that Cinder Claus is coming to town.
Cheer up..Chris

Maybe this novel way of fixing technical problems would translate to Linux.

No sacrificing of live puppies though, please.

Nepal fix to technical problem

Santa lives in Korvatunturi in Finnish Lapland. Near the border of Finland and Russia. About 100km from my home in Ivalo.


Please, check also the bug when booting from fugal install with psubdir parameter.


andrew (andrew<at>andrew.org) 
I thought you were using QEMU or VMWare for this sort of things.

CUPS problems 

I'm trying to get printing working in 2.20alpha.

Firstly, when installing a printer, the CUPS web interface asks for a username and password. I don't recall Puppy's root password, so exit from X, type "passwd" and enter a password, for example "puppy". Start X, run the CUPS web interface and when it asks for username and password, enter "root" and "puppy".
...I don't know how to configure CUPS not to ask for a username/password.

Second problem, and it seems that this has to be fixed before setting up the printer. 2.20alpha does not have 'foomatic-rip' installed, so I grabbed it from Puppy 2.17, placed it at /usr/bin/foomatic-rip, and created a symlink from /usr/lib/cups/filters/foomatic-rip.

Then I setup the printer and clicked "Printer test page" button, but got an error message "/usr/lib/cups/filter/foomatic-rip failed". Nowhere can I see any details on why it failed. The foomatic-rip script does have an option to turn on debugging, but that doesn't work.

Barry, you need /etc/cups/cupsd.conf

In it, you can change the debugging level from "info" to "debug".

This file also controls permissions. I've sent you a PM with a correct cupsd.conf.

Pakt, 2.20alpha already has the cupsd.conf taken from Puppy 2.17, so it's the same as what you sent me. That doesn't fix the username/password problem.

However, thanks for the info about turning on debug. From that I was able to observe /var/log/cups/error.log and see what the error was... a missing Type1 font. It seems that the test-page is different from that in the earlier CUPS version used in pup 2.17.

Grrrr... I installed the font, but then the CUPS web interface came up with another message, "printer not connected; will retry in 30 seconds..." But it is connected, and the web interface shows it as available, idle, ready to accept jobs. The error log file throws no light on why this message appears. Now I'm stuck again.

Some else has the "printer not connected" error and has been trying to fix it for a month...

But now I have a new error message to worry about. When I click the button to print a test page, the web interface comes up with "Quota limit reached". There are no pending jobs, no apparent cache files anywhere in /var, after rebooting still gives the same error message.

Why is it that whenever I play around with CUPS, there is so much trouble?

I'm going to build pup with the old CUPS version from 2.17.

Barry, I'm assuming you execute

"/etc/rc.d/rc.cups restart"

after every change you make to restart the CUPS daemon.

Pakt, yes, although I was doing a complete 'stop' then a 'start'.

I have "solved" the problem, and can now print. I just went back to CUPS version 1.1.23 as used in Puppy 2.17 -- that originally came out of Slackware 11, I didn't actually compile it. It's a bit smaller too. The version in Puppy 2.20alpha is 1.2.10, taken from Slackware 12.

There's probably been enough user-testing of 2.20alpha for now. I'm working through the bugs reported so far, and will knock them off one at a time and report back here.


Found a Synaptics module for Xorg 7.2 that works. Posted it here:


I was going to compile it, but many of the Xorg include files are missing. Do you know where to find them?

You can find the binary packages at a slackware repository, see links at www.slackware.com, in a directory slackware/x.

I have slack 12 installed from a DVD that I purchased.

You may need more than just the include files -- they will be at /usr/include/X11. But also the package may have 'something-config' in /usr/bin, '.pc' files in /usr/lib/pkgconfig, '.m4' files in /usr/share/aclocal, '.la' and '.a' files in /usr/lib.

I have relocated everything to /usr/X11R7, so some of the files need to be edited -- the .pc and .la files.

HOWEVER, do not compile any modules using 2.20alpha, and devx_220.sfs, as it has a different 'gcc' version. I need to recompile the kernel with the new gcc first, which I'll do for 2.20beta. For now, you have to compile modules in 2.17.

Thanks Barry,

I was going to send you a message about the kernel compiled with gcc 3.4, but your way ahead of me. I tried to compile the ATI fglrx driver and it complained about it.

It's good that the issue of users (and passwords) has been brought up. Once, I was installing free lightspeedserver and it wants a "whole" profile for user nobody. I understand that it looks for a profile somewhere - how can we possibly fix this issue?

Forum feedback links for 2.20alpha 

Please provide feedback to these threads, which I will read regularly:

2.20 Alpha "Happy": http://www.murga-linux.com/puppy/viewtopic.php?t=21475
Puppy 2.20alpha - eth0 driver not loaded: http://www.murga-linux.com/puppy/viewtopic.php?t=21476
Be "Happy" - New Alpha TESTING released: http://www.murga-linux.com/puppy/viewtopic.php?t=21337

It's probably been suggested before but here goes.

19MB seems hard to justify to launch gtkmoz to browse a help file.
Also using seamonkey to run the CUPS interface is pretty heavy.

I know that both dillo and hv3 have their faults.
I'm not sure if you have cut down on a lightweight html viewer to reduce the sfs size or because of their bugs.

If you included hv3 in the zdrv file to be loaded on request:
It would have no effect on the size of the squashfile loaded into RAM.
Machines that are really short of RAM will not have loaded the pup_220.sfs into RAM anyway.
It would increase the size of the iso but I presume that that is not the major issue.

Possible you could keep Sage happy by putting the real cfdisk in there as well :-)

Just to make it clear I meant 19MB of RAM when its running.

Barry Kauler 
Yes, I have a surprise for 2.20beta, a new lightweight web browser with CSS support, which will be used as the internal HTML viewer and the CUPS web interface.

(c) Copyright Barry Kauler 2008, all rights reserved. http://puppylinux.com/