logoPuppy developer news:

from 2.15ce to 2.16

left-arrow Older news

arrow-rightLater news

Puppy version 2.16 released 

Another wonderful new Puppy! The 'standard' release is puppy-2.16-seamonkey-fulldrivers.iso live-CD and is 89.9MB. There is a massive list of new features, which is incredible considering that we have only incremented the version number from 2.14 to 2.16 (with the 2.15 Community Edition in between). New features include the SFS Boot Manager, "humongous initrd", print-to-PDF, flush-RAM-to-Flash, plus a host of new and updated applications developed especially for Puppy.

The release notes have been updated:

Download from here:

Looks good, smells god and, so far, is working for me - well done again Barry!
All we need now is for someone who understands all the goodies and how they work to write a new guide to how it works and how to use it.

Woof woof

Mirrors and bitorrents here please

Works fast and smoothly.

My menu.lst Grub4dos frugal install file:

title Puppy-p2.16
rootnoverify (hd0,4)
kernel /bp216/vmlinuz root=/dev/ram0 PMEDIA=idehd psubdir=bp216
initrd /bp216/initrd.gz

I hope that Xorg problem with missing display resolutions list will be solved in next release.

Wow very nice!!

Started to install flash 9, but then noticed it was already there. Thanks! Probably should be noted in the release notes.

Woof wow* woof (...indeed!!!)

(Oh my God!!! :RASPBERRY
By using "wow*", I just infringed on one of M$ 235 patents
AND I'm using LINUX too!!! A hardcore criminal indeed ;-) )

BOW WOW :-) - finally managed to do TFTP booting with the humongous initrd! (see the RC post below) Only 130 MB RAM is used by Puppy 2.16.


[I mean, the humongous initrd is discussed in the "Puppy 2.16rc (release candidate) uploaded", the 3rd item below.]

"...the kernel alone infringes 42 M$ patents..." (Linus is still ROTFLing about this one...). OMG, Barry that doggy of yours is p***ing all over M$'s backyard...;-)

Posted also on this thread as this is where Distrowatch links to:

Apart from the ibiblio download site, if you live in Europe you might find the NLUUG mirror quicker:

I've put the Unleashed CD together, stuffed as much as I can in it (699MB). This is a v2.16 'standard' bootable CD with the 'devx_216.sfs' and 'openofice-2.2.0.sfs' modules, kernel source, plus the complete Unleashed package 'puppy-unleashed-2.16.tar.gz' -- which has all of the packages that you find in 'pet_packages-2' at ibiblio plus tools for creating a custom Puppy as described here:
Get the CD from here:

Two SFS modules recommended for use with v2.16 are 'devx-216.sfs' and 'openoffice-2.2.0.sfs' and these are downloadable from:
or http://ftp.nluug.nl/ftp/pub/os/Linux/di ... modules-2/
Download these to /mnt/home (location where your "pup_save" personal storage file is, after the first shutdown). The SFS Boot Manager is to be found in the "System" menu -- make sure you uncheck the checkbox (you'll know what I mean when you run the Boot Manager).

Rico (canarymail<at>terra.es) 
I am following puppy since the beginning and I must say
that it is growing out of the puppy fase heading into a
mature platform. It is ironic that the masses again are
following Windows next OS Vista despite the fact that this
time it is a bloated OS. While there are these exceptional
Linux compilations like Puppy Linux : small, fast, easy and
very complete. There is almost no difference anymore between
a Windows desktop and a Puppy desktop. The difference is huge
when it comes to consuming hardware resources. The Migration
from Win 98 - 2000 - XP always forced you to buy faster
hardware which performance each time was cancelled out by the
next OS, leaving you with no gain. Same story now with Vista.
Every new version of Puppy drains about the same amount of
resources and doesn't cancel out your faster hardware. I always
ask my friends : what can't you do with 98 - 2000 - XP that you
can do with Vista ? After 3 generations of Windows I am not going
to migrate again if I still do the same things since Win98.
Thanks Barry for bringing this platform into the world and giving
the people a choice !
Greetings Rico

Universal Installer bugfixes 

There are some quick hacks to fix the Universal Installer. See here if you would like to test it:

Barry, I notice that your version of the installer is only allowing to choose a partition that doesn't already have a full install but Dougal's version allow's to choose any available partition (which is handy for upgrading). Just wondered if there was a reason for this.

My version is Dougal's version.

Ok, sorry it's just there's some different versions in that thread. The full install I did using the last one and the wipe option worked OK except I had to run the grub setup seperate and because vmlinuz is in the puppy216 sub directory I symlinked it to /boot/vmlinuz for grub to find it.

Encryption bugfix 

Puppy 2.16 suports encryption of the "pup_save" file, with a choice of "light" or "heavy" encryption. Light uses 'xor', heavy uses 'aes' encryption. Kirk and others have recently tested aes encryption, and I added xor, just assuming that it would also work.

The reason for this assumption is that I tested xor with losetup many many moons ago -- perhaps a couple of years -- and it worked fine. The invocation was like this:
losetup-FULL -e xor /dev/loop2 name-of-pup-save-file

However, the kernel has changed, and the above line causes the kernel to load a module named 'xor.ko' (or at least to try to when booting), but that module has nothing to do with xor encryption as required by losetup.
The solution, I found, is to invoke like this:
losetup-FULL -E 1 /dev/loop2 name-of-pup-save-file

The number '1' tells losetup to use its inbuilt xor encryption. Note, the only module needed to be loaded is 'cryptoloop.ko'.
I have modified 'rc.shutdown' and 'init' scripts accordingly.

Very pleased to see that is possible to have a secure filesystem!
now i can really use puppy as a security linux preventing others to read my files or log in on my pc.

Puppy 2.16rc (release candidate) uploaded 

This is not (quite) ready for general public release, but is for our band of Puppy-testers.

The release notes have been updated:

Download from here:

The above link also has a "humongous initrd.gz", which has pup_216.sfs and zdrv_216.sfs inside it. This can be used as you wish, including for network booting, but note the boot parameters will have to include
'root=/dev/ram0 ramdisk_size=93952'

Please note, if you have ordered a CD from me in the last week, I'm holding processing of orders until 2.16final.

Out of curiosity, and this may not be a question anyone wants to waste time on, what is the difference between a release candidate and a beta?

According to Wikipedia article of software release life cycle, http://en.wikipedia.org/wiki/Development_stage:

A "beta version" is the first version released outside the organization or community that develops the software, for the purpose of evaluation or real-world black-box testing.

The term "release candidate" refers to a version with potential to be a final product, ready to release unless fatal bugs emerge.

I hope this clarify the difference between the two terms.

Have a nice day. 8-)

Looking good and running smooth! Very nice release Barry :-)

Yes, it it looks basically okay, I'll just change it's status from 'rc' to 'final'.

Note, I've uploaded all the PET packages. Will upload 'puppy-unleashed-core-2.16' soon.

Can anyone let me know if the "xor" encryption is working? If so, how it is done...

looks great, working great on both usb and the cf card i use as a ide drive

another great release Barry

Great work, nice looking desktop. I've just tried gxine. wmv does not show up correctly, whereas mpeg does (installing extra codecs pet does not change the situation)

But maybe the reason is my laptop (Fujitsu siemens C1020)

Besides skype.pet installs qt-library (dependency) correctly, but needs an extra symlink in /usr/lib/ to start.

Don't get me wrong - I really like puppylinux and use it regularly at home. I just wanted to mention the above said so that one can possibly fix it before pup_216 final release

have a nice day

kjoe [from austria, the land without an "l" or kangaroos inside :-) ]

Dougal, 'xor', yes, I forgot to check that one. I tested it well over a year ago and I think the xor functionality is/was built-in to losetup, didn't need a module. I know there is a xor.ko but I don't know what that is for. Anyone else know more on this?

kjoe, there is no missing symlink. The post-install dialog window in PETget tells you to reboot Puppy if you have installed a library or web browser. Qt is a library. Reboot and Puppy will be able to find the symlink.

Please note! The purpose of 2.16rc is to fix any final bugs. As it turns out, we do have some, so the final is delayed a couple of days, hopefully fixed by 17th. Right now I'm looking into the 'xor' encryption problem reported by Dougal, and frugal install kernel panic reported by G2 and Lobster.

vanchutr (vanchutr<at>gmail.com) 
I used the frugall instaltion: The xor wizard worked well if I put the zdrv_216.sfs in same place with the others (vmlinuz, initrd.gz...).
If I d't have the zdrv_216.sfs Pup gave me many another selection to choice, however the system work smooth. Thanks Barry

John Doe 
In addition to encryption:

The xor function is used to calculate parity for mirrored raids (Raid1):

I meant to suggest this a while back. Can Xorg Wizard be programmed to use a lower default synchronization of 60 Hz? This is in line with the goal of Puppy to be used on older pcs, so if a user presses the 'ok' button by mistake he'll still get a display istead of fuzz! Happened to me a few times, especially when I'm using an old Philips 105 CRT monitor.

Thanks for the great work on Puppy!

Just trying out v2.16. So far so good. I wish that the Puppy Software Installer found in v2.15 CE is present here. It makes installing and removing software much easier.

Suggestion about how to improve frugal install:

Suggestion about how to solve missing resolutions problem in xorgwizard:

I'm sorry about the wrong link in my previous post. The right link is:

Suggestion about how to solve missing resolutions problem in xorgwizard:

Just installed Puppy Software Installer (PSI). Its a bit of a work but it can be done. Through PSI, I was able to install I would like to use.

Still testing... 8-)

Another question: has the full "ls" been updated? In the alpha it doesn't show colours, so I ended up going back to the Busybox version...

Okay, that's a strange one. /etc/profile has this:
#v2.16 have gone to full ls, now need this...

#auto: only creates ansi color codes if o/p to a tty, not in a script...
alias ls='ls --color=auto'

Which is also in /root/.bashrc.

If you execute 'rxvt -e sh' then you do not get color.
If you execute rxvt -e bash' then you do.
But, the 'sh' is supposed to read /etc/profile, so why don't we get color? Strange thing is, when I fixed this, I thought it was fixed, but now it isn't.
.... G2, you're the expert in this stuff, do you see where the problem is?

a shell does not read /etc/profile, or any equivalent profile config file, unless it is a login shell (the --login option)

in any case, i don't think aliases are exported to subprocesses, so putting aliases in /etc/profile does not work

invoking a bash shell DOES read $HOME/.bashrc ... aliases in .bashrc should work

but when bash is executed as sh (or when busybox's ash is executed) it behaves as sh, not as bash ... and sh does not execute .bashrc ... sh does execute a config file if it is set by the variable ENV

so, if you want to setup aliases for bash, the correct place to put the aliases is in .bashrc ... if you want to setup aliases for ash and/or sh, you should set the variable ENV in /etc/profile, like this:

export ENV=/root/.bashrc

actually, there are a number of config files that can be used to setup quite complicated behaviour, but i think most distros keep the shell initializations fairly simple, and put most options and aliases in one file, and just source that file from the other config files, if necessary ... for example, there might be a file /root/.bash_profile which would execute if a bash login shell runs, but the .bash_profile file just sources .bashrc

Extra modules, patched kernel source, petget fix, Dougal-remaster upgrade 

The kernel used in 2.16 beta/final is slightly different from that used in 2.14 and 2.15CE. A few extra modules were added, and a 'ksize' patch applied to the source to support extended capability of Aufs.

Ted Dog and JohnDoe requested the extra modules. They are to be found at:

The patched kernel source is at:
...courtesy of Ted Dog who owns this site.
I also uploaded the 'ksize' patch file and the '.config' file.

PETget is for installing PET packages, those ending with '.pet' in the filename. PETget has a file-selection dialog for choosing an already-download package to install, and I got the impression from some posts that one or more people have tried to install a DotPup package.
I didn't follow through all the logic, but this may have caused some chaos. Anyway, I have added extra screening so that only a '.pet' or '.tar.gz' file can be chosen -- the latter may be old PupGet packages. I also added an extra message in the dialog window to only choose a '.pet' file.

Dougal's enhanced remaster script was last updated on Dec. 5, however I had an older one in Puppy. I've upgraded and the Unleashed package is 'dougalremaster-2.16'.

Just a thought.. Why not allow one to choose a .pup and let Petget call on dotpuprox.sh for "seamless integration" ?

Ted Dog 
Do I need to use the devx_sfs? Two modules had a great number of symbol errors, had to add firmware directory is it still next to the modues directory under /lib? Also under multisession DVD the /dev directory resets (lost DVB subdirectory) even when it is recorded correctly on the DVD. other wises RC looks good.

Humongous initrd, pdev1 boot-param bug fixes 

An experimental Puppy was released a month or so ago that has what I call a "humongous initrd" -- look back in this blog for the announcement. Since then, the 'init' script has had many changes and the humongous initrd was broken. I've now fixed it.

With Puppy Unleashed you can now create an 'initrd.gz' file with the 'pup_216.sfs' and optionally the 'zdrv_216.sfs' file/s inside it. This means that Puppy consists of only two files, vmlinuz and initrd.gz, which is convenient for network booting of a thin station but the PC needs to have plenty of RAM -- probably 256M is okay but I have my doubts about running Mozilla apps, so 512M would be better.

I tested by replacing the initrd.gz, pup_216.sfs and zdrv_216.sfs files on my USB Flash drive with the single humongous initrd.gz, then edited the syslinux.cfg file:
default vmlinuz root=/dev/ram0 initrd=initrd.gz pmedia=usbflash ramdisk_size=93984

As I built the initrd.gz as a traditional ramdisk (with internal ext2 filesystem), the 'root=/dev/ram0' boot parameter is required. Also, as the ramdisk is bigger than the kernel default maximum of 16384KB, the 'ramdisk_size' parameter is requird.
Note, if doing this manually, to determine the required ramdisk size, gunzip the initrd.gz file then right-click to view file properties, and file-size is shown in bytes -- divide by 1024 toget kilobytes.

I will probably have 2.16rc ready in a few days, will also upload a humongous-initrd live-cd iso also.
Interested persons such as Raffy and Steven can then test network booting -- you can probably leave off the 'pmedia' parameter entirely for PXE etc. booting. It should be able to create a local pup_save file on any available media.

'PDEV1' is a variable used in the 'init' script. It designates the partition that have booted from, for example 'sda1' or 'hda1'. It is unlikely to be needed, but this paramete can also be passed as a boot parameter, upper or lower-case. It will prevent Puppy from searching any further. It can even be a drive rather than partition, example 'hda' and 'sda' and Puppy will search the partitions of that drive only.
Anyway, it wasn't working right and I fixed it.

Thanks, Barry. For those curious about the use of "humongous initrd", it is to support network booting following "DRBL", see http://drbl.sourceforge.net/ , led by Steven Shiau.

Quote: BarryK
"'PDEV1' is a variable used in the 'init' script. It designates the partition that have booted from, for example 'sda1' or 'hda1'. It is unlikely to be needed, but this paramete can also be passed as a boot parameter, upper or lower-case. It will prevent Puppy from searching any further. It can even be a drive rather than partition, example 'hda' and 'sda' and Puppy will search the partitions of that drive only.
Anyway, it wasn't working right and I fixed it."

If I understand this correctly, that should mean that users booting multiple copies of Puppy 2.16RC1 should NOT need to use the Grub hide/unhide parameter to avoid picking up an unintended copy of Puppy?

WhoDo, yes, pdev1 can be used instead of hiding.

Ever since I saw DRBL-Live (and what it can do...), I'm stuck with the idea that Puppy will make the ideal base.
Literally "a dog to the rescue" ;-)

chooselocale fixed, snapmergepuppy updated 

The /usr/sbin/chooselocale script, invoked from the "Desktop -> Chooselocale country localisation" menu, had a couple of bugs, now fixed. Thanks to forum-member 'gray' for reporting this -- a couple of other people also reported problems with this script earlier.

Forum member andrei has examined my 'snapmergepuppy' script for handling flushing of RAM to the pup_save file, and made some improvements. This is for aufs. andrei has a very sharp mind to figure out the fine details of these tricky whiteout files! I've updated to andrei's new snapmergepuppy, actually the file is now 'snapmergepuppy-aufs', as Puppy is supporting both aufs and unionfs. There is also 'snapmergepuppy-unionfs', and 'snapmergepuppy' is a symlink created at bootup that points to the correct script.

Mark South 
Barry, in addition to the new choose-locale process, have you added any new locales to the old set?


Let's stay with the 'semi-obsolete' ramdisk! 

Please read the previous two posts to get the background to this post.

The previous two posts introduced issues with the initrd (ramdisk) versus initramfs (cpio archive). Right now I'm running 2.16 with an initrd, whereas previous 2.16's used a initramfs.

The Puppy Unleashed system used to create Puppy, has a 'createpuppy' script that now can choose either way. Puppy will run quite happily with either. I think if creating a 'humongous initrd' for network booting, then the initramfs may be a good choice, but otherwise, I have gone back to the initrd.

The initrd means that my long-term 'security monitor' idea can still be developed. It also means that potentially we can achieve better shutdown.

As the initrd exists prior-to and continues to exist independent of the union f.s., it is something that can be switched back into at shutdown, to enable complete dismantling of the union f.s. This is a potential that would need to be developed.

So, the ramdisk is back! But, what does that mean to the end-user? The only thing is those boot parameters 'root=/dev/ram0' and optionally 'ramdisk_size=<size>'. If you have been testing 2.16 and have removed 'root=/dev/ram0' from the GRUB, LILO, syslinux.cfg or isolinux.cfg, please put it back.
Actually, it never had to be removed, as if the kernel loads a cpio initrd.gz file and finds a script '/init', then the 'root=/dev/ram0' boot parameter is ignored.

I know Dougal will be happy that the ramdisk is back! Dougal, please modify the Universal Installer so that 'root=/dev/ram0' is restored to its former places.

Oh, one other thing that the end-user will notice is that the /initrd directory will have the complete initial ramdisk as before, and you can even chroot into it.

Although the esoterica is well beyond my own ambit, Barry, as a user, I am extremely grateful that you took the time to outline the present status of and your thoughts for Puppy development. Anticipating one group of users, might I ask you, please, to extend your explanations to those of us who use full HD installs?
Additionally, many will be concerned with the escalating size of Puppy. Two fs, two mounting utilities, too (sic!) many? Quo Vadis? Elsewhere, I have advocated a compact (50Mb max.) Puppy and a comprehensive 'Muppy' style that rivals the major distros, complete with kitchen sink.

Hi Barry, please excuse the off-topic...
MUT's dead CDplayer symlink fixable (with a lot of Kal's help)
...in usr/local/bin copy gxineshell script to gplaycd and then edit gplaycd, replacing both [b]gxine "$@"[/b] with [b]gxine cdda:/1[/b].
After that gxine is the default CD player and autoplays audioCDs from MUT

the problem with unmounting the pup_save file when Puppy shuts down would not affect you at all, if you do a full install to a dedicated partition ... because you don't have a pup_save file to unmount ... one of the advantages of a full install

Barry Kauler 
No Sage, the size of Puppy is not increased. Supporting both unionfs and aufs only adds about 50K (uncompressed) to the size.
These are unerlying technical details, they don't really impact the end user. Puppy works as before, same size, no more complex.

Having a bet both ways 

Please read the previous post first!
I have been using various experimental, alphas and betas of 2.16 for sometime and I'm very happy with both the cpio initramfs and aufs. So, what's the problem?

The older initrd (ramdisk) system formed part of a long-term plan. I designed it to remain in memory while the main Puppy filesystem is running. My thinking was to use this as a kind of security monitor, as it is created prior-to and is totally outside the main union f.s.
The initramfs however, cannot exist after the switch is made to the main f.s. -- it is a temporary thing at bootup only. Hence my long-term plan, however vague, is thwarted.

Another issue is shutdown, and this is something we are debating right now on the main forum. The union f.s., whether it is unionfs or aufs, has a problem with shutting down cleanly. The problem is very specific -- if the 'pup_save' file is mounted directly on the /initrd/pup_rw layer of the union (the top read-write layer) then it is always busy and can't be remounted ro nor unmounted, not even lazy-unmount.
This means that at next bootup a f.s. check shows some errors. In the case of unionfs, these errors seem to be harmless, as GuestToo explained in the forum, and are easily fixed at the f.s. check at bootup. Aufs on the other hand causes many more errors, but these also seem to be repaired at bootup okay.

I've been running 2.16's with aufs for sometime, and there has been no problem. The pup_save files may be shutdown not quite 'clean', but are repaired okay at bootup.
Please note that this situation has always been with us in earlier pups. I'm just a bit concerned that aufs leaves the pup_save in a less 'clean' state than does unionfs.

On the other hand, when the pup_save file is in a Flash drive, the unclean shutdown problem does not occur. This is because the pup_save file is not mounted on /initrd/pup_rw, instead on /initrd/pup_ro1, the next-down layer in the union and mounted read-only (read-only in the union, but it can still be written to directly).

So, I decided to have a "bet each way". Puppy 2.16 now supports both unionfs and aufs! The 'init' boot script decides which to use. If booting from a Flash drive, uses aufs, otherwise uses unionfs. If you want to force usage of aufs, just put the string 'aufs' into the boot parameters in your syslinux.cfg or whatever.

This gives us cleaner shutdown of the pup_save file for non-flash drives, plus the advantage of true flushing of ram to pup_save for Flash drives that aufs offers.

We may go fully to aufs in a future version, if we can more properly solve the shutdown issues. This is where the ramdisk comes in... which I will explain in the next post.

Forum thread where we have been discussing shutdown:

initrd versus initramfs, unionfs versus aufs 

This post is about very technical "under the bonnet" stuff, that doesn't have any (or very little) impact on the end user. But even if you are an end-user this may interest you. I'll first provide a bit of a summary:

All puppies up to and including 2.15CE have used an initrd and unionfs. When Puppy boots, the file initrd.gz loads into a ramdisk, /dev/ram0 -- this is a complete self-contained Linux environment, very small. After that, the pup_xxx.sfs gets loaded and Puppy switches over to that. The pup_xxx.sfs is setup in an overlay system known as unionfs, that is described elsewhere.

Puppy 2.16beta has moved to a initramfs and aufs. At bootup, the initrd.gz file is loaded, but it is what is called a cpio archive and it loads into what is called a initramfs, not into a ramdisk. Nearly all of the major distros have gone this way. To quote from official kernel docs:
The older "ram disk" mechanism created a synthetic block device out of
an area of ram and used it as backing store for a filesystem. This block
device was of fixed size, so the filesystem mounted on it was of fixed
size. Using a ram disk also required unnecessarily copying memory from the
fake block device into the page cache (and copying changes back out), as well
as creating and destroying dentries. Plus it needed a filesystem driver
(such as ext2) to format and interpret this data.

Compared to ramfs, this wastes memory (and memory bus bandwidth), creates
unnecessary work for the CPU, and pollutes the CPU caches. (There are tricks
to avoid this copying by playing with the page tables, but they're unpleasantly
complicated and turn out to be about as expensive as the copying anyway.)
More to the point, all the work ramfs is doing has to happen _anyway_,
since all file access goes through the page and dentry caches. The ram
disk is simply unnecessary, ramfs is internally much simpler.

Another reason ramdisks are semi-obsolete is that the introduction of
loopback devices offered a more flexible and convenient way to create
synthetic block devices, now from files instead of from chunks of memory.

The initramfs also means that we no longer need the 'root=/dev/ram0' boot parameter, nor the 'ramdisk_size=<value>' parameter, which particularly interested me as convenient for creation of very large initrd.gz's for network booting -- again, that's another story.

Major distros that use unionfs have also moved to aufs. We have done so as aufs has improved handling of whiteout files, plus allows true flushing of RAM to the 'pup_save' file for Flashdrives.

But, I have reservations and have reconsidered these moves. I'll explain further in the next post.

Full readlink, new rev utility 

The Aufs package has the 'unionctl' utility, that is a Bash script. It uses the 'readlink' utility but crashes as the Busybox readlink applet does not support the required commandline options.
Therefore I have moved to the full 'readline', in the 'coreutils' package.
Note, the Busybox applet was at /usr/bin/readlink, but in Vector the location is /bin/readlink, so I have changed to the latter.

The 'unionctl' script requires the 'rev' utility, from the 'util-linux' package. I have placed this at /usr/bin/rev.
Note, this is a weird little program -- it reverses the order of characters on each line, so if a line is "one line in a file" it becomes "elif a ni enil eno".

not sure how big rev is but you can duplicate its behaviour using a script with sed that is 59 bytes

sed '/\n/!G;s/\(.\)\(.*\n\)/&\2\1/;//D;s/.//' $1

How big is sed? ;-)

alienjeff (alienjeff<at>charter.net) 

Hint #1: sh-3.00# which sed
Hint #2: sh-3.00# ls -la /bin/se*


sed is in puppy already and used by many things so its free, nada, 0 bytes

Puppy 2.16beta available 

As usual, the alphas and betas are not intended for general public use, but for our dedicated band of Puppy-testers.

Read the Release Notes here:
Pay particular attention to the upgrade notes, as the exp3 and alpha releases will have copied the zdrv_216.sfs and pup_216.sfs files off the CD to the same place as the "pup_save" file (/mnthome).

Download from here:

Well, it looks good, Barry. It's been a real treat watching you work on this - an education and edification!

A bit of juggling the icons and all my stuff is comfortably working in 2.16beta. I did find it necessary, as you suggested, to use puppy pfix=clean with my current .2fs. (Otherwise X would not start.)

Thanks and congratulations!


The releasenotes tells that Pfind 1.0 follows Puppy 2.16. I would request Pfind 1.2, to get the latest bugfixes.


[i]Well, it looks good, Barry. It's been a real treat watching you work on this - an education and edification![/i]

:) I agree. Great to see so many other developers involved too. That is very inspiring.

Have created a forum thread for bugs

Be intererested if the new Sheep + Frisbee game is popular. Someone posted a 10k or 30k version of tetris (a very popular game) that might suit too . . .

Zigbert, I missed that one! Ok, Pfind is updated to 1.2 for the final release.

Very nice! One thing, RipperX is not listed in the Menu under Multimedia, I thought it was removed, but it's still there in /usr/local/bin. Needs a menu entry. I like RipperX because of it's CDDB support, glad to see it's still in there!


Thanks for adding Dougal's boot option "debug". If there were a way to capture all of the scrolling debug boot text, many things could be learned about the boot process.

Hats-off to Barry and Dougal


Ive been following puppy for about 2 years now, I always enjoy reading your daily progress... Nice release by the way. I just wish I would try to learn how to program puppy apps, So I can contribute something good for the puppy community... Take care!!!!

Puppy with the usual sparse but more stylish look! It has lots of innovations as usual. :)

Did I miss a tip about how to use Puppy with a big initrd, or will that be implemented in the next version?

ted dog 
sh-3.00# modprobe or51132
sh-3.00# modprobe dvb-core
sh-3.00# modprobe cx88-alsa
FATAL: Module cx88_alsa not found.
sh-3.00# modprobe cx88-blackbird
FATAL: Module cx88_blackbird not found.
sh-3.00# modprobe cx88-dvb
FATAL: Module cx88_dvb not found.
sh-3.00# modprobe cx88-vp3054-i2c
FATAL: Module cx88_vp3054_i2c not found.
sh-3.00# modprobe cx88xx

sh-3.00# modprobe cx8800

sh-3.00# modprobe cx8802

almost there.

Hi, Barry
can you please check on your machine if normal audio CDs are directly playable? The audioCD "CD Player" sym-link in MUT works? I am trying with 2.13, 2.14 and 2.15CE on a few different machines to figure out if it is hardware related...no luck so far, only GXine works...

Barry Kauler 
There is a problem, some CD players used in Puppy require an audio cable from the drive to the motherboard, which some PCs do not have, even though the sockets are there.
Gxine does not need that, recodes the audio directly from the CD.

Steven Shiau 
It's nice to see a new version with a lot of new things.
How about the question Raffy asked ? i.e.
How to use Puppy with a big initrd, or will that be implemented in the next version?

Barry Kauler 
Steven, Puppy Unleashed, the environment used to build puppies from individual packages, can build what I called a 'humongous initrd' puppy. I can create and upload one of those, have been preoccupied. ...I'll try and make time to create it and test before the 2.16final, make sure it still boots okay.

Tks Barry, it's clear now...I have stopped connecting the audio out plug myself, to reduce cabling and improve airflow and cooling. Will keep in mind for the future.

The xor ("Light") encryption doesn't seem to be working.

I tried doing it manually and after you give losetup the password it gives an error:
ioctl: LOOP_SET_STATUS: invalid argument

I tried different size save files and it didn't help.
I also tried probing the "xor" module first and it didn't help.

Final additions before 2.16beta 

Nathan's Grafburn is updated to v0.10.1.
GINS patched by MU, updated, now v0.9.1.
The latest Universal Installer update from Dougal, dated circa 9th May.
Zigbert's Pbackup updated to v2.0.1.
After conversation with GuestToo, trying some variations in remounting the pup_save and ntfs partitions read-only, in the rc.shutdown script.

Terrence Day (tday<at>ispwest.com) 
Not sure where to post this, but beta 16 is the first puppy that works with the built-in wi-fi on my Dell Inspiron 2200. Goodbye PCMCIA wi-fi card.

Barry Kauler 
The only difference from 2.14 that would account for that is the firmware contributed by tempestuous, so you have him to thank.

JwmConfig updated, new pdfprinter 

Nathan has redesigned the user interface of JwmConfig (JWM configuration in the Desktop menu). I have upgraded the Unleashed package from jwmconfig-27nov06 to jwmconfig-5may07. Forum thread:

Jcoder24 has done something wonderful! He has enhanced the PDQ printing system with print-to-PDF-file. This has many uses, one of which is any application can now output a PDF file, another is that if you can't print from Puppy then you can create a PDF file and print elsewhere.
I have named the Unleashed packages pdfprinter_pdq_gs-0.2 and pdfprinter_pdq_ad-0.2. Forum thread:

I had to modify jcoder24's 'pinstall.sh' scripts to suit the Unleashed package. The problem is paths. In Unleashed, the current directory will be <path>/rootfs-complete when the pinstall.sh executes, whereas when the package is installed as a separate package by PETget the current directory will be '/'. The pdfprinter_pdf_gs pinstall.sh was easy to modify, but the other a bit more involved -- I don't know if I got it right. I'll upload the packages to ibiblio in a day or so, for jcoder24 or anyone to look at -- well, expect the 2.16beta to come out soon also.

Barry, I updated the Universal-Installer on the Murga forum.

While I'm here, a couple of little things:
- the code for minixcal isn't on puptrix -- you might want to add it, in case it gets removed from the Murga forum.

- You mentioned somewhere pupmode 3. I assume that is a full-install on flash media. When I was working on the Universal Installer I noticed that pupmode 3 doesn't seem to be allowed: flash media are only allowed frugal installs. Any reason for this?

Dougal, okay, uploaded minixcal, also puppyserialdetect 1.1d and the latest gins patched by MU.

PUPMODE 3.... I experimented with that ages ago. Off the top of my head, I don't see why it should be blocked. If I have done so, it may be more of an oversight than anything else. It would be an interesting option.

2.16beta coming soon 

Just looking at my shortlist, and seems like I can bring out 2.16beta in a couple of days.

Universal Installer, Mini-volume, Grafburn updated 

I originally wrote the Puppy Universal Installer back in June 2006 and it was released with Puppy 2.0.0 -- see http://www.puppylinux.com/news/news2006a.htm
The idea then was there were various separate scripts for installing to different media and I thought that I could get it more consistent, streamlined and powerful by having one integrated "swiss army knife" installer.
Recently, Dougal has enhanced the code, see this forum thread: http://www.murga-linux.com/puppy/viewtopic.php?t=17500
I have updated Puppy with the enhanced script posted by Dougal on 1st May.

Kirk posted that the Network Wizard was not working properly as it needs some files in /etc/WAG/. Actually, the Wireless Access Gadget (WAG) was an earlier project, superceded by rarsa's Network Wizard (well, that's another script I started, now admirably enhanced by rarsa), but is seems that /etc/WAG/ (files therein) are still needed. So, I have placed those files into the net_setup-2.15-1 Unleashed package (rarsa's Network Wizard package) and renamed it to net_setup-2.15-1.1.

I have upgraded rarsa'a Mini-volume applet (the thing you see in the taskbar for controlling volume) to version 0.7. The Unleashed package is mini_volume-0.7.

Nathan has updated his Grafburn CD/DVD burner application to 0.10, so I have also updated the Unleashed package, named grafburn-0.10.

Nathan Fisher 
There was a bug in dvd burning with the 0.10 Grafburn package, so I had to do another minor release to fix it. The package is in the same forum thread as before. Sorry about that:RASPBERRY

Improved mouse and keyboard detection 

/usr/sbin/puppyserialdetect is a C program that used to detect presence of a serial mouse and serial modem. The code was originally written by RedHat and Mandrake had a hand in it as well. I got it out of a library called 'Detect' that I think I found on a Mandrake source repository, and I extracted just the bits needed for serial detection.

Dougal recently had a look at the source and activated the extra detection of USB and PS/2 mice. Jesse then did some code cleanup and further improvements and also added detection of USB and PS/2 keyboards. The forum thread for this:

I'm not sure, there seem to still be some issues from some posts to that thread. However, I have upgraded to the new puppyserialdetect version 1.1d posted by Jesse, and made some basic mods to /etc/rc.d/rc.local0 to accomodate it.
The main thing that I appreciate is detection of a PS/2 mouse, and this has further improved accuracy of mouse detection. Serial mouse detection is still not perfect, but I made a note in an earlier blog post that manual selection of a serial mouse can be used to override automatic detection, and this required a small mod to rc.local0 also.

Note, I'm not using the new keyboard detection feature of puppyserialdetect, as the current detection seems to be working fine. If we get any keyboard detection problems then we can certainly look at this again.

Note also, I am sticking with '/dev/psaux' for the PS/2 mouse, as other scripts expect that. Also, I don't have any reason to change it, even if /dev/input/mice does work.

SheepPool game 

It's about time we had a new game in the 'standard' Puppy live-CD!

Lvds discovered this. It's a Flash game, so runs in a browser. Darn stupid sheep, I can't even get one of them into gate number 1 ...maybe I'm just getting too old, my daughter could probably do it easily.

Anyway, here is where lvds announced it:

I've made it into an Unleashed package and it will be in 2.16beta.

I managed to do the first three. But the fourth sheep, I just start laughing and cannot stop. I tried it several times, same effect.

Ted Dog 
Good thing I have goat and cows, Until now I did not know that sheep explode. I was able to get them all toward first pocket but after half got into pocket the others in the group blew-up, the electric fence is a bit to strong.:RASPBERRY

Only a bit? Exploding sounds like it was way towards being strong. Unless you mean "too strong".

- Your Friendly Neighborhood Grammar Nazi

PRename batch file renamer 

Puppy had PBrename 0.4 written by plinej (Jason). He has rewritten it and it is now PRename v0.3. I have upgraded Puppy and there is now a new Unleashed package (not yet uploaded) with slight modifications to the .pet posted by Jason. See his forum announcement here:

Note, this is a great tool. A long time ago, the only equivalent we had was a script written in Perl, with a GTK1 GUI -- man oh man, the overheads you need for that! Basically, the GTK bindings for Perl (or Python for that matter) are a no no for a no-bloat distro like Puppy. PRename uses Gtkdialog3 for the GUI interface. Then there's rarsa's favourite, Gnocl for Tcl. Also, you should see what Brad and Mark have done with GINS! -- fantastic GUIs for any scripts. Informative GINS forum thread:

I've been having a lot of success with the new gtkdialog too. Of all the approaches it still seems the easiest to me, and definately there is a ton of flexibility in laying out an interface.
JWM Config manager which fits on smaller screens.
Latest Grafburn largely redesigned in gtkdialog3. Also uses half the temp space now.

Anyway I'm really impressed with what can be done. My applications can have menubars, toolbars, and tabbed windows now. Icons for buttons, windows, and menu entries can be gtk stock icons. Text markup possible. New style file and directory selctor. I'm still discovering new things that can be done with it.

I'd have to say I'm even more impressed by what Rarsa is able to accomplish with Gnocl though. His volume mixer is fantastic, and the remotedesktop client is nice and elagent.

Xorg Wizard update 

/usr/sbin/xorgwizard is a script that I wrote originally, since has received considerable updates by Dougal. His latest has incorporated special support for a Synaptics touchpad. For further information see this forum thread: http://www.murga-linux.com/puppy/viewtopic.php?t=17369

With reference to that forum thread, note that I am using the version posted on 24th April, not that of 28th. I have also modified it very slightly, as explained in the thread, due to this problem:

When testing X, clicking the OK button to verify that the test succeeded, hangs my laptop. The other way of verifying is to press CTRL-ALT-BACKSPACE, which works fine for me. However, on some PCs CTRL-ALT-BACKSPACE is caught by the BIOS and shuts down the computer!
The problem of the computer hanging when you click the OK button appears to be due to particular video hardware and this is the more common problem.
Therefore, I modified the message displayed when testing X to emphasise that you should press CRTL-ALT-BACKSPACE to verify, and clicking the OK button is second method if first fails. This way, only a very few people will get a nasty surprise.

Changing the subject, I have taken 'probedisk' and 'probepart' back to the original versions as used in Puppy 2.14 and earlier. This is because of unresolved issues with the scripts.

puppylinux.com, puppylinux.com now hosted on ibiblio 

We are still getting organised on this, and I've been distracted by the mini-holiday plus urgent bugs in 2.16alpha, but here is basically what has happened.

I've been getting too many Internet-related bills, so wanted to simplify things re the hosting. The ibiblio people have very kindly agreed to provide virtual hosting for us, with a modest amount of space for web pages. Now, Ted Dog is in much worse situation than me, financial and health-wise. He has registered puppylinux.com but the hosting account expired. So, we have got together and pointed puppylinux.com and puppylinux.com to the new ibiblio site. Ibiblio require us to point both domains at the same front page.

My plan is not to renew my Netirms account, which hosts all the 'puppylinux' domains and I will park those domains somewhere with redirection to the puppylinux.com/net site -- I think it's also possible to emnbed an instruction to search engines to use the redirected-to domain in future?
I will probably move my blog to puppylinux.com.

Ted Dog will be involved with the ibiblio site. I think that we will be able to host some small puplets on the ibiblio puppylinux ftp download site and Ted Dog will be maintainer and coordinator of that, plus maybe some other stuff.
Note, Ted Dog also has puptrix.org, for which hosting is paid-up for another year.

The ibiblio people have been very kind, and I do have to be careful not to take too much advantage of that. As much as possible should be hosted elsewhere. Everything hosted by ibiblio has to be non-commercial, and I can't sell CDs, so have removed that from the download page.

However, CDs can be sold from the puppylinux.org site, hosted by Servage. Due to sales referrals, this site is paid up until 2012! The main problem with that site is bandwidth -- we ran into limits sometime back, but it's been good for awhile.

Barry, I really wished you had asked the community for more help on this. What I meant is maybe a fundraiser or some contest to create more revenue. Anyway, I am glad that you are able to manage what is on your plate !

I was told to give a look at these fellas: http://www.site5.com/

A fellow irc member & puppy user directed me to that website and he is now using them over nearlyfreespeech.net

Mark South (marksouth2000<at>yahoo.co.uk) 
Barry, I would be more than willing to help with the Internet bills and would also be happy to help out with the hosting issues. The present state of the net permits a fair level of lateral thinking to be applied to how large files are hosted for download. I've already done quite a bit of research on the subject for a couple of other projects that i've been working on.

Please do contact me by email, you already have my email address and I've put it in this post to make it even simpler.


Ted Dog 
Educate us dude. I have a idea to setup a directory for sfs, pet, & pups, that our torrent client would be configured to use. That way easy sharing and we have a way to tell what can be pruned from the servers. I have looked into this but lack the server side know-how.

Barry Kauler 
Thanks for the sentiments guys!

What has happened is good, as ibiblio is free. Also, they have new hardware and their site is faster. As longer as the University of North Carolina wants to keep supporting ibiblio as a free host, all is fine...

Ibiblio require us to have a .net or .org as their hosting is non-commercial, and an additional .com is allowed. That's why we need the puppylinux.com for ibiblio -- and it makes sense to have that domain name for the "official" non-commercial site.

Another big plus with ibiblio is the mirrors, and no bandwidth limit. The only thing they warn about is not to use them as a place to host stuff that could be hosted elsewhere.

So, ibiblio is a good solution, but of course we need more hosting for the heaps of other stuff we have, such as SFSs, DotPups, a myriad of puplets (some very big), wikis, forums, etc.

Since I'm setup okay with ibiblio, I'm thinking that what we should aim for is a community-supported site that is a host for downloads, like puppylinux.org (which is really our community information/wiki site) -- puppylinux.org has worked well, as referrals have made it paid-up until 2012.
There could be donations going directly to this new community site to maintain it, rather than involving me. Mark, what you have already wetup could be the basis of this site? ...well, I suppose it already is, but we could make it a bit more formal, with a donation mechanism to sustain it.

I'm thinking too, I could hand over the 'puppylinux' domains to this community site, if they are wanted. Maybe I could give the 'keys' to Ted Dog or Mark and they could be pointed at the community download site -- only if you want to keep alive the 'puppylinux' name.

yes, especially isos and sfs need a reliable solution.
I was planning to spend the donations I got meanwhile for another domain, just for new files, to reduce traffic.
But if we could use ibiblio.org - perfect.

I then would keep the donations to pay the next year-rates for puppyfiles.org only as a dotpup-repository (packages in general), and drop puppyisos.org.

puppyfiles.org will get a webinterface to allow easy uploads like in the murga-forum, but based on Ftp.
So it still will make sense to use it, as a "quick and dirty" upload place, while ibiblio.org could be used as an archive mirror.

The dotpups might be mirrored then on a montly base from puppyfiles.org to ibiblio.org.

I think ibiblio.org will not allow "quick" uploads by "suspicious" users, at least this was an issue when I got the offer to host files on the Suse/Debian servers by Max Plack Institute.


Tony (tony<at>veronicxathecow.co.uk) 
Hi, as always I want to thank Barry and all others for hard work. Cheers!

Might I suggest that Torrents are the answer for all files. Correct me if I am wrong but...

A Torrent run from a server will always use less bandwidth than the equivalent number of downloads (Assuming more than 1 other person is connected?

It is scalable, when a new Puppy is released the more that connect to download the more available it becomes. Puppy members are so helpful I am sure they would keep seeding for a while (I know I would be very happy to help that way)

If all Torrents were kept at one site then it would be less frustrating to find files which tend to be in a number of different places in my experience, a fair number of whom tend to be down.)

Perhaps the primary download link could be for Torrent with a more tucked away direct link in case of lack of Torrent client (I think most people nowadays have such a client) or other problems

All the best
Tony (veronicathecow)

Hi Barry,

May be it would be good to think at a business plan for puppy. Such things can be done easily nowadays and contribute also to consolidate a strong linux distribution. Many users are willing to help you for your puppy distirbution, even though they do not always know how to. Having a business plan would canalise everybody's efforts.

To tell you how easy it is, when we have decided over here to publicly distribute our remastered puppy (which was aimed at support for the gamers community of Dofus) we created one in an hour. Well it was more than a test to check viability of such a plan instead of really willing to gain money. The test proved to be efficient and in the context of your puppy distro it could help better.

As a worldwide used distribution, i believe users would be more than happy to contribute at supporting their preferred distribution, and moreover it would not cost anything to anyone.

ps: i don't know if this is the right place to discuss this, but while at work the firewall prevent me from access to www.murga-linux.com forum (though i have access to all other forums, there might be something setted up differenlty on www.murga-linux.com)

Best regards,

Barry Kauler 
Mark, I think that you have misread my post. I think that I wrote it ambiguously. What I intended to convey is that ibiblio.org cannot be an archive for other than the main official Puppy plus perhaps a couple of small puplets. My proposal was a separate host like your puppyisos.org, that will be directly supported by a donation mechanism.

Eric/caneri (ericmulcaster<at>gmail.com) 
Barry..I loved the pictures of your trip. My little project for free space/bandwidth for the pup is still on track. I have just talked with the provider (Monday May 7) and they are still interested in supplying puppy with space etc. It is just a slow process with such a large corporation. I have a asked for 10-20 gb space and 5-15tb /month of bandwidth. Although I can't make promises, I think there may be a positive outcome from this...I can only hope.

Mark Ulrich 
ok, I see.
So I will continue to look for a practicable solution.

The MaxPlanck servers would be great, but we would need a rsync computer with DSL.
I found no appartment yet, so can not do that on my own.

Erics proposal looks interesting, too.
Puppyisos currently has 40-25060 GB traffic/day, but it gets deactivated when 100GB were reached.

So an account with 1 terabyte would be fantastic.
Also the thing posted by Kenny looks interesting, though I'm sceptical about "traps". Servage also seemed fantastic at first sight, and it certainly is for this price.
But these cheap prices always have some limitations of course.


Mark Ulrich 
oops... should be "40-260 GB traffic/day"

This is a test - CGI error was here in previous two visits. ;-)

Why not make the ibiblio site as a top domain for Puppy Linux, like puppylinuxweb.org or the current puppylinux.org, maintained by Barry himself? This is consistent with what was already done with pupweb. And ibiblio will be happy with a .org name. If Barry decides on using the latter, the current website can be given another name.

Multisession DVD now working 

I've been at this since before dawn until after sunset ...I was determined to nail this one, and finally got there, after much travails.

Dear oh dear... As mentioned in the previous post, I upgraded 'cdrtools' from 2.01.01a10 to 2.01.01a26, but had to roll back the 'mkisofs' utility.
Then I used my little 'burniso2cd' program but it crashed -- which I found is due to the new 'cdrecord' utility. Oh dear, 'cdrecord -scanbus' outputs a different format than before -- it was this that broke my script. How many other scripts are going to get broken, I wonder?

Anyway, I have rolled 'cdrtools' completely back to v2.01.01a10. We should checkout the Debian fork of this project, I think.

I found a peculiar problem with 'growisofs', the utility in the dvd+rw-tools package for burning to a DVD. Up until now I have used the '-speed=4' parameter, however on one of my PCs this causes an error and growisofs aborts with a "cannot change speed" message. I think that I used this drive with an earlier version of Puppy, so perhaps this is something to do with the kernel?
Anyway, I simply removed that parameter and growisofs worked.

Having successfully saved a session (finally), there was an error at bootup as Aufs failed to create the union of layers. I found the reason for this. If sufficient RAM, pup_216.sfs is copied into RAM, specifically into /pup_rw which is the top layer of the union. However, pup_216.sfs is itself mounted on /pup_ro2 via loop back device and that is the second layer of the union. Unionfs accepts this, however not Aufs. I had to create a separate tmpfs in which to copy pup_216.sfs, then Aufs worked.

I haven't tried a CD yet, but fairly confident it will work too.

Barry Kauler 
I have compiled the Debian fork, 'cdrkit' version
Their utility 'wodim' is the same as 'cdrecord' and has the same output format as the latest 'cdrecord' in cdrtools. I don't want to mess around any more, will stay with the older cdrtools package.

Thanks, Barry!:-) You must feel like you ran a marathon.

cdrtools problems 

Puppy has the 'cdrtools' package version 2.01.01a10. I was experiencing problems with 'cdrecord' utility, so I upgraded to cdrtools 2.01.01a26. I don't yet know if cdrecord is any better, but 'mkisofs' has gone down the drain.

When saving the first session to DVD-R, 'growisofs' calls 'mkisofs', but the latter exited with the totally useless error message "mkisofs has failed". Curses. I tried running mkisofs directly from the commandline, same error. Went back to the old mkisofs, works fine.

I don't know if it will cause any trouble, but I upgraded the cdrtools Unleashed package to the 'a26' release but kept the 'a10' mkisofs executable.

Hmmm, I also found my laptop will not boot a multisession DVD -- I was hoping the problem occurred only for a CD as reported earlier, but no such luck.

Barry, you might check Acer's website if they have updated firmware for your drive. You can also check 'The Firmware Page' http://forum.rpc1.org/portal.php - they have a huge collection of firmware upgrades for optical drives. I've upgraded my drives a number of times.


Ted Dog 
Sounds like a BIOS problem we have with laptops since the beginning of multisessions v1.01.
It doesn't seem fixable, I've looked into it for a long time, and only thing I've seen work was a boot-loader not based on current el-torrio, that ignores the failure cd/dvd scan due to a common laptop BIOS bug. I have
lossed the work I was doing due to a HD failure, but It might be on a back-up.
That boot loader was very ugly to look at, and written in assm. Named after a criptic under used assm command. I have not written in assm. since 6502 or Z-80 days.

Multisession-CD on a laptop 

I am now working on the multisession CD/DVD as it is broken in 2.16alpha.

However, I ran into a very old bug. I'm testing with CD-Rs on my laptop, and when I save a session 'cdrecord' program opens then immediately closes the tray -- at least it does sometimes. The problem with that is that the laptop does not have automatice closing of the tray, so it opens and then you wonder what has happened -- you can manually close the tray and saving will continue, but that is also problematic.
So, I have tackled this problem first. The rc.shutdown script now detects if the tray is not closed when it should be, then asks you to do so. On the first test it worked okay ...but then I discovered that my laptop will not boot a CD with more than one session on it. The same CD boots fine on a "normal" PC. I haven't tested a DVD yet.

Okay, I have the session saving okay, but then we get a kernel panic at bootup, as reported by Puppy-testers. I have implemented 'pfix=debug' as suggested by Dougal, however the thought occurred to me for a simple improvement to 'pfix=rdsh' -- instead of dropping out of the 'init' script to a shell near the end of the script (before switch_root), I have also made it drop to a shell on any error. That is, on entry to the 'check_status' function with an error status, after displaying the error messages there is a drop to shell -- but only for 'pfix=rdsh' boot param.

Next thing I will do is find out what is causing the kernel panic. Aufs is failing to create the union on pup_new, with the enigmatic error message that "/pup_ro2 is overlapped". I'll work on this a bit later today.

Barry, please excuse the off-topic...:-)
but until this: http://puppylinux.com/forum/?1173087234 ,
I didn't realize that you were in contact with Steven!!!
I have used both their Clonezilla-LiveCD and DRBL-LiveCD to backup/clone my chubbier systems. I was so thrilled with their tools that I actually wrote a how-to in www.linuxquestions.org...
What struck me almost instantly when using DRBL-LiveCD (it is based on an "Etch" image...) is the (...remote it seemed then...) possibility of using Puppy as a base!!! Or - even better - the DRBL set of tools to evolve as a dotPUP!!! That would lead to a sort of super-powerful "Rescue"-Puppy or "Clone"-Puppy (...if one includes GParted as well...) being able to backup/restore/clone and rescue complete systems ranging from Linux to Windows...

Definitely worth a try!

Barry, I don't have a laptop, but my brother does. He reports the exact same thing as happened to you. He burned a multisession CD-R which booted on his laptop, then seemed to save the session to the CD when he shut down. The laptop will not reboot the CD but his desktop will, and all the programs he installed before he saved the session are there.

Reply to John's off-topic backup issue...
John, I've just spent some time using Puppy to do this and found that it already has almost everything that I want. The Pudd script will back up files, a partition, or an entire drive with compression over Ethernet to a remote machine. I had thought that I was innovative in some of my ideas but they were implemented ages ago by others in Puppy's standard toolset. Try out Pudd yourself (Menu/Utility/Pudd).

I wrote Pudd ages ago, and it has been very neglected for well over a year. I do recall someone reporting a problem with it, but never followed it up. Any feedback on its performance is welcome.

GParted fixed in 2.16alpha 

Three people reported that GParted failed to format a partition ...hmmm, no one picked up why, but it was very easy to find out. GParted has a "Details" button, which displays a log, and that showed that the 'nice' program is missing.

/bin/nice is from the Coreutils package. Puppy never had it before as Busybox has 'renice' which does basically the same thing. It is normal for a Linux distro to have 'nice' though, so it is now in. GParted is now happy.

Barry, any possibility of upgrading GParted to version 0.3.3 with all needed utils? Older versions do not work with XFS. If this is hard to do (too much space required...) what would be needed to have 0.3.3 as an add-on package?

I know that this is not relevant, but
I would really like to ask whether or
not you are planning to release any
64bit version or even any 32bit but
SMP version. Working with puppy at the
moment leaves half of my CPU power out
of the play.


I forgot to ask, we will ever see Beryl and/or Compiz in some future version of Puppy?

Barry Kauler 
GParted in 2.16alpha is 0.3.3.
64bit? no. SMP-enabled kernel? sometime perhaps.

Tks Barry!!! That should do the trick!! I'l have a try with it on some XFS-formatted disks and provide some feedback...

...maybe I'm wrong, but I think one of the key ideas behind Puppy is to be a compact bloatware-free OS. Beryl/Compiz may be spectacular to show off, but they are merely eye candy, not true tools (...and hence fall definitely under the "bloatware" category...). Going for maximum cross-compatibility and earlier hardware compatibility, pure 64bit does not help at all!! Even as a fork it would be extremely complex to handle...About the case for SMP, I'm not sure either...Puppy is not power-hungry, nor CPU-hungry. Even with one core it can deliver...and all this talk about next generations of CPUs incorporating media-locks...I would prefer to stick with legacy!!!

...Barry beside GParted, memtest on 2.13 did not seem to work as well...Wouldn't it be a good idea to have a proper memtest86+ version included as a separate boot option on the Puppy ISO. It is very small...

JohnRoberts and Barry, dropping 64bit idea for the time being, makes
sense, until Puppy reaches a very mature version. You would want to
compile everything both 32bit and 64bit. However, dropping it
entirely you will have to drop too many future fans.

As for the SMP what you say JohnRoberts, doesn't make sense. CPUs
currently are all multicore. Usually one would like to use all
the computational power available. Have you ever thought that there
may be some developers who are not satisfied with SuSE or Gentoo
e.t.c. and they want a simple alternative as a developing and/or
testing platform? What you say over there sounds as if you want
a laptop just to boot your PC. If your computational needs are
enough for one processor to handle then fine. Then probably you
will never want to buy a laptop again. If you want more though
then currently you have to drop Puppy as it will only see
one CPU.

Barry, is it so hard to compile an SMP kernel and maintain 2
puppy distros at least in 32 bit? Or there is much more to be
done for the SMP than a simple kernel recompilation?

Holiday snapshots 

I have just arrived back. Posted some snapshots here:

Welcome back. Great scenic pics. :-)

Quite informative page, and the viewer tends to feel as one of the two bearded gentlemen savoring the scenery... :-)

Back home, moka5 is whipping thunder with its "LivePC in USB". moka5 must have come from those ancient rocks. ;-)

don (dgrabar<at>kaballero.com) 
A spectacularly beautiful place. You are fortunate that it is so inaccessible, and thus able to keep it from being "modernized" to accommodate hordes of tourists.

Excellent pics barry! I need a trip to a place like that.... I'll have to settle for a trip to six flags soon... I love rollercoasters.... Take care!

Thanks for sharing that with us, Barry. I agree about the colours that don't get caught by the camera, same goes for the Flinders Ranges too.

But that's another story :)

Wonderful pictures, wonderful country.
How to stop the greedy despoilers? You already have the largest, deepest pit in the world, and far too much uranium in your rocks for comfort. You simply cannot avoid politics if you want to save the lands for future generations. Otherwise, you'll become like 'God's Own Country' !!!

A most interesting and involving page you give us! Thank you very much. Seeing Tom Price from Google's satellite views raised my curiosity, which now is satisfied enough :RASPBERRY (except for a video of a rock-wallaby jumping up the cliffs...).

Bug reports for 2.16alpha 

I have started my "holiday" but have Internet access for a little while tonight.
A thread has been created in the main forum where you can provide feedback about 2.16alpha:
Also here:

Note, I have to drive about 1,500 kilometers (about 930 miles) and will be sleeping in my car tomorrow night, maybe even two nights. Eating at diners ...anyway, I'll be offline, so "see" ya soon!

Read about Tom Price (my destination) here:

Puppy 2.16alpha available for testing 

This is not a general release, it is for our band of Puppy-testers only. Download from here:
It should also filter through to the ibiblio mirrors.

It's 2.55pm on Wednesday 25th April right now, and this evening I have to go to a function, then tomorrow morning depart on an adventure to the mining town of Tom Price. I will have sporadic Internet access, so will keep in touch with feedback on the 2.16alpha, plus I'll have my laptop with me so will keep developing.

This 2.16alpha is basically what 2.16-final will be, so is the recommended environment for Puppy developers and testers. There will be some changes, maybe some package upgrades, definiely some bugfixes, then there will be 2.16beta before the final release.

Some notes on 2.16alpha:

There may be an issue with the SFS Boot Manager if you upgrade from an existing pup_save file. I did so, then chose to load the openoffice-2.2.0.sfs module, but the icons didn't appear on the desktop. It may have just been something peculiar about my pup_save file, don't know yet. Worked fine with a new pup_save file, adding and removing the SFS module.

The Boot Manager is in the System menu, but it will popup when you bootup with a new pup_save file.

If upgrading from 2.16exp3, do NOT use the pup_save that you may have tested it with, and be absolutely certain to delete pup_216.sfs and zdrv_216.sfs that will be found in the same partition as the pup_save file.

Which leads to another point: Puppy will copy .sfs files off the CD into the same hd partition as the pup_save file, for faster loading. 2.16exp3 was the first to do this, hence you have to get rid of them.

You may not like the grey desktop background -- too stark? weird? ...well, you are welcome to design something. I want very simple, light color, without 'noise'.

Booting from Flash drive now has true flushing. I have only tested from USB Flash, but I presume IDE CF card will work the same. The concept can be applied to multisession-CD/DVD but I have not yet implemented that.

On the subject of auto-saving to Flash drive, a message pops up every 30 minutes -- if that becomes too annoying, I'm open to suggestions, like maybe something more discrete.

To find out what is new, you will have to read down this blog. But, I think the most exciting things from user's viewpoint are the SFS Boot Manager and the true flushing for Flash drives.
There's lots of stuff we will be testing on the 2.16alpha platform, for example from Dougal, Rarsa and Zigbert, for intended inclusion in 2.16beta.
This alpha seems pretty solid to me ...let me know what you think. Note, my Developer Forum is currently experiencing some problems, so probably best to discuss on John's main Puppy Forum.

Oh yes, the 'test' directory at ibiblio also has openoffice-2.2.0.sfs, which has enhancements that the new Pup makes use of. These are outlined earlier in this blog, but basically it is the support for desktop icons and scripts in /etc/init.d/ and /etc/profile.d/.
So, this is the ideal SFS module to test with the new Pup.


Good news (downloading now) I am confident (based on past experience) that I can transfer day to day testing and usage to this Alpha.

I will be releasing a new Puppy presentation using Open Office, either today or tomorrow. Will include Alpha screen shot . . .

I look forward to the stark grey background. I do rather like the neutrality of grey - it can like black and white be used in a variety of ways, and the glass icons in 2.15 were a popular use of grey . . . The Puppy 2.14 sparkle was also step in the right direction. Simple, small elegant.

Summary of 2.16 "Puppy Luv"

Have a great adventure
any pics welcome on wiki . . .


This is the fastest Puppy I ever use. It works very well and I don't have any problem so far.

Thanks for fixing frugal install.

Personally, I like colors and will keep the old Puppy look and feel.

Another good news! Gxine can play flv files, both video and sound.

No problems with d/l and booting. New issue with the MBR after full install - 'Yes' no longer functions! Neither did the separate MBR installer from the menu. This is a new feature, but will investigate whether it is a generalised problem.
It was told to us many moons ago by the ultimate PC guru, Paul Mullen, that the most rational and elegant background, as well as screensaver, is BLACK! Black means no pixels are lit - it prolongs screen life and reduces power. It also looks terrific due to the stark contrast with icons, etc. In the greener environment we should all be using black backgrounds!

So far so good Barry -
I did not have the problem with the bootloader you mentioned
Tested so far :- cfcard
Copied initrd.gz, vmlinuz,pup_216.sfs,zdrv_216.xfx to usb and cfcard
renamed initrd to init216;vmlinuz to linuz216, copied pup_save.sfs to pup_save.216.sfs
added entry to syslinux.cfg
booted and took 216 option off menu

The system did its version upgrade - copied the icewm menu back - exit to prompt the xwin icewm

opend bootmanager - it showed my 2 sfs files
myprefs.sfs and wine934.sfs

tested TotalCommander (main wine app) worked perfectly
tested seamonkey (wine version) worked perfectly
so the bootmanager appears to have retained the configuration


Strange MBR install phenomenon seems to be related to old exptl3 fragments remaining on HD. Guess BK's warnings about old .sfs files was the portent to troubles. Easiest way was to reformat the drive - problem disappeared.
Today is world penguin day!

Ted Dog and John Doe, note, I didn't put the new kernel modules into the zdrv file. I will upload them separately soon -- it will just be a matter of install them then run 'depmod' for the system to recognise them.

okay have now tested on a USB
and I get that incredibly annoying screen message about flushing - pls do not do anything..... which i simply ignore as i am not going stop what i am doing every 30 minutes.
That needs removing - or suppressin in my view.
What exactly is the advantage of flushing and is there a way to be able to choose not to use it, or at the least suppress the message or change the timings

my system sees the cf card as a hard drive so I do not experience the same issues thank heavans


The reason it flushes is a compromise. It can't just access FLASH media like a normal harddrive because that would wear out the drive very fast. So instead it keeps everything you do in ram and saves it during shutdown. But that's bad for two reasons. For one, if the power dies, all your data is gone (even if you "saved" it, since it only saved to ram). For another, it eats your ram. So, to compromise Puppy will flush to disk every thirty minutes. That way stuff gets saved every so often and the ram gets freed up.

A simple control panel could be handy though, where you could enable or disable the popup, and change the save-interval. Now that there's a Save icon it would be a little more safe to not flush at all, and just do it by hand every once in a while.

Personally though, I'd rather it defaults to the thirty minute flush.

Clarification: When I said "even if you save it, since you're saving to ram" I meant if you just hit the save button in Abiword or whatever. The save icon on the desktop that I referred to is different, that flushes it.

I haven't actually used this alpha yet (I'm in class atm) so I don't know first hand how annoying the message might be. I also don't know if it would show up if you were, say, watching a full-screen movie or playing a full-screen game. Would it stay underneith, or come on top, or mess up the whole full-screen thing (think alt-tabbing out of a game in Win98)?

I'll have to install this to my jumpdrive sometime and play.

Also, you can probably manually tweak the timeout by editing /usr/sbin/savepuppyd, or even disable it completely. Though the structure is probably different from what I remember.

I like the new Desktop icons. Very sharp, well, except the "home" icon. Might just be me, but this puppy seems faster, AUFS maybe? There is probably some good reason for the switch from MUT to PMount on the desktop, if not, MUT is a lot more easy to look at. Might just be that I'm use to looking at MUT though.


Tried to connect to a WPA wifi AP with the network wizard, no luck. Had to copy /etc/WAG from 2.14 to get it to work. That directory is missing in 2.16a.

hey pizza yeah i do understand that, which is why for some time I have kept link on my icewm taskbar that does exactly that - in fact I think it was a pup that you did that gave me that idea in the first plcae
that way i click on it when i want and not at some arbritrary , and inconvenient interval.
I am not against automating the process, or even the icon on the desktop, just the fact that i have no choice in the matter.
Even MS lets you choose to do this automatically or manually


Flush to usb

Okay i think I see why it was so annoying - i was getting the pop-up every 5 minutes

now in my syslinux config file the option for the usb drive is shown as
append initrd=init216.gz PMEDIA=usbflash quiet

so I modified a few of the lines in savepuppyd -

#check PMEDIA is usbflash or ideflash...
SLEEPTIME=900 #save every 90 minutes.
#if not a flash media, can save more frequently...
#[ "`echo -n "$PMEDIA" | grep "flash"`" = "" ] && SLEEPTIME=50 #save every 5 minutes.

and now I can live with it


John Doe 
I'm as excited as ever for this one, I'm just having two main problems:


Also, drvc.so is missing from either gxine extra codecs or gxine. I get this error when I try to listen to my beloved c-span.org as rtsp stream.

Hi, Barry -

Sofar 2.16 has been running smoothly here, thanks!

Just wanted to highlight here that Pmount needs a 'unmount' option so it will fully replace MUT's functions.

MooDog, what do you mean? Pmount does have unmount.

Gdcrane, I don't understand. For pmedia=usbflash or ideflash, that code in savepuppyd will cause saving every 30 minutes. The variable PMEDIA has the string 'flash' in it, so the condition is not satisfied and the SLEEPTIME is not changed to 50.

you are right Barry - it didnt do what I had thought and i am still getting the popup every 5 minutes on the lenovo. - I tried 216 out on a different machine - and I get the desktop icon and the initial warning about do not remove your usb drive, and the popup did not appear every 5 minutes
Same usb drive, same syslinux config,

So now I am really puzzled - bottom line though is that on the lenovo intelligent terminal I get an annoying orange popup every 5 mins when I run off of a usb drive.

not sure what to try next - apart froom that its working like a champ - you do good work Barry

Oops - sorry!

I didn't realise that if you click the mounted partition icon it will unmount! I was looking for an 'unmount' icon next to the drive, I guess..

Thanks for clearing that up!

How about a 'manual save only' option? Not justfor flash drives but hard drives as well. Often I use my system to surf the web and would prefer that nothing be saved for the whole session so a 'manual save only' option would be perfect ... if I want to save something I can ...but I don't need to why do it.. I would welcome this option for my use in general ... not just for flash driver but for hard drives as well. One of the things I really liked about the old Flonix live CD distro. Please add this capability.

That would be nice, now that it can truly flush and not eat the ram. One "hacky" way you might be able to do it now is if you trick Puppy into thinking you have a flash drive by setting pmedia=ideflash, or pmedia=usbflash if you have a sata drive. I'm not certain that will still boot and function correctly, but I think it will.

that sort of work around when i try it gets some real funky results

I echo KJs senttiments which is which i liked the savepuppy pup you did


Excellent work barry! I love this release and is working great as far as I can tell.... Thanks...

216a is GREAT! I tried and tried to get 215ce installed on my old Thnkpad Laptop and it would not work. First time with 216a and it all works even auto loaded the pcimcia lan card with the wizard.

I also love the New Icons and simple look, grey is awsome.

Am off to DL the OpenOffice and see how it runs ;)

On that USB flash save, how about doing it the old Puppy way, copy instead of flush - most of the time? Only annoy the user with the flush warning if ram is getting low and a flush really is needed? Just a thought...

On the issue of deleting old SFS files, can that be made more idiot-proof? For example, with the boot script checking dates or md5sums or something like that, to determine that the sfs in question is an old one that ought not be used?

A project to improve mouse detection 

Dougal has had a breakthrough with mouse detection, see this forum thread: http://murga-linux.com/puppy/viewtopic.php?t=17575

As I am almost about to upload 2.16alpha, I won't put Dougal's program into it. It would involve rewriting some of the code in /etc/rc.d/rc.local0 and there are some issues, such as use of /dev/input/mice instead of /dev/psaux for ps/2 mouse.
But, it will be very easy for 2.16alpha-testers to test Dougal's new program, and we can also work on required mods to rc.local0 and test that too.
The same thing goes for Dougal's improved xorgwizard and puppyinstaller scripts.

I sometimes need to use a serial mouse together with a USB mouse, but so far, Puppy (2.13 through 2.15) can't manage to detect both at startup. If ONLY a serial mouse is present, it recognizes and runs it. But then it won't recognize the USB mouse when it's plugged in. The change mouse utility doesn't fix this.

If both are attached at startup, the serial mouse isn't installed at all.

NTFS support improved 

There have been steady advances in the NTFS support for Linux, also it was reported that incompatibility with NTFS in Vista has been fixed. This has prompted me to upgrade various packages ...which ended up being almost 5 hours continuous work. This is what was done:

FUSE package upgraded to v2.6.3 and compiled statically with uClibc as need static 'fusermount' in the initramfs.

FUSE package compiled normally. A new kernel module, also goes into the initramfs, plus a Unleashed package and relevant components into the 'devx' module.

Ntfs-3g usermode driver upgraded to v1.417. Compiled with uClibc as need static 'ntfs-3g' for the initramfs.

ntfs-3g package compiled and installed normally, created new Unleashed package and components into the 'devx' module.

Ntfsprogs upgraded to v1.13.1. New Unleashed package.

Parted upgraded to v1.8.6. New Unleashed package and components into 'devx' module.

Gparted upgraded to v0.3.3. Compiled statically with gtkmm libs. I found that the gtkmm '.a' static libs were missing from the 'devx' module, so had to recompile them and fix the 'devx' module. New Unleashed package.

Note, tha above steps had to be done in that order due to dependencies.

ted dog 
I can hardly wait.... and check out the other thing we talked about, its working ayyyy!:SURPRISED

Ted Dog, yes, so it is! There was a bit of a delay, partly because they didn't work over the weekend. It's catching me at a bad time though, as I'll be out of action for a few days, but I might get online Thursday night and I'll do some more work on our "project" -- I'll send you a p.m. I'm supposed to get 2.16alpha ready today, and I'm supposed to be going out to a function this evening, then tomorrow morning taking off on my trip ...hmmm. One reason for my urgency is I have broadband access now but it will probably only be dialup for the next 9 - 10 days.

Mouse mis-detection bug workaround 

This has been reported many times on the forum. The program 'puppyserialdetect' detects mouse and modem on the serial ports, but is unreliable. It sems to depend on the mouse -- I have one mouse that gets detected sometimes, sometimes not.

Anyway, the workaround is that if you manually choose the mouse in the Xorg Wizard or in the Mouse/Keyboard Wizard, if you choose a serial mouse, it will stick and puppyserialdetect result will be ignored.

There does need to be some degree of autodetection, as a usb flash drive can bootup on different PCs with different mouses. USB mouse detection seems reliable, so that remains autodetected. Note, I never figured out how to autodetect a ps/2 mouse, so that is chosen if a serial or USB mouse is not detected -- with the change now that if you choose serial manually then it will stick on that.

This is not going to affect many people, as the vast majority will be using ps/2 or USB mouses, for which autodetection continues as before.

Not necessarily, Barry. I am seeing instances of error messages about serialmousedetect even though I haven't used a serial mouse on a Linux distro for many years. Exptl 3 is particularly prone to throw out this message, but 2.15CE and other late 2-series sometimes do this as well.

I actually contacted Jesse and asked him to have a look at puppyserialdetect, hoping he might be able to write a simpler program to just get what we need (there seems to be much irrelevant code in it from the origibal library)...

Will Jesse be our saviour?

Barry Kauler 
If puppyserialdetect says there is a serial mouse present when in fact there isn't one, that is a more serious situation, that I haven't catered for. I haven't had that happen, don't recall anyone else reporting that.

Barry, I might have some good news. Please look here:

You might want to wait with it for the BETA, ut I don't know how many people will bother to test it for me, so maybe it will be best to put it in the ALPHA (assuming it passes your tests...)


Puppyserialdetect prgram has been very much improved, bugs fixed, posible serial io delays reduced, and a few minor features added too. Up to edition 1.1d, but there may still be things to fix/add, more info here:



2.16alpha coming real soon 

Some advance notice. I'm running out of time here. Right now it's 4pm Tuesday 24th April and I will be taking off on my trip to Tom Price on the morning of Thursday 26th. So, I plan to upload 2.16alpha on the evening of the 25th (I'm on GMT+8 here in Western Australia, roughly 12 hours ahead of the USA).

This will be alpha, so expected to be the basic thing to expect in the final, but some details may change, some packages may get upgraded. When we get to beta, packages will be frozen and it will be final testing. I've made up a shortlist of what needs to be in the alpha, for example I need to update fuser and ntfs-3g packages. Some things, like xorgwizard and puppyinstaller enhancements that Dougal is working on may have to be held over to the beta -- or it will be simple enough to download them and test in the 2.16alpha environment.

If anyone can think of something vital that needs to be in the alpha, add a comment here.

Note, from Thursday I will be unreachable for a few days. Hope to get online after I reach Tom Price.

I will switch to urgency mode and send your the reclasified .desktop files.

I've had them 95% ready but one thing or another have prevented me going the last mile.

Actually the remaining 5% is things that I'm not sure where they belong so I do some investigation to see where the original author would have liked it. That's where I got stuck.

I guess any place is better than no place.

Barry, in case you're still using Geany 0.10 it is very important that you ugrade it to 0.10.2, which fixed some serious bugs.

I think Mtpaint has had a few new versions released, but it's not very urgent.

It's not vital but I would suggest Numlockx for us who use standard keyboard and like that Numlock state is on after X is started.

Numlock state should stay off as default because off notebooks keyboard layouts.

Binary is only 6072 bytes and is available at:


Hi, Barry-

Does rc.firewall need to be updated to version 2.0 final? I've been seeing '2.0rc9' in the script for a while...



Stardust icons from Zigbert 

Zigbert has completed the Stardust GTK2 theme with a set of icons for Puppy. See his announcement:

In 2.16exp releases I have used the Stardust theme slightly modified, now I have adopted Zigbert's icons for the next pup. I'm going for a very stark minimalistic look this time.

Very nice ! You might also be interested in this: http://www.murga-linux.com/puppy/viewtopic.php?t=17537

ted dog 
not to be confused with ziggy stardust font?

Aufs success! 

I'm so pleased, booting the pup from a USB Flash drive is now so perfect... the previous mentioned problem with .wh.__dir_opaque files is fixed.

I have been corresponding with Junjiro Okajima, the author of Aufs and have received excellent advice. The Aufs project is developing very fast, and I was using an "old" version of Aufs (December 2006), partly because I thought that the Unionfs-compatibility mode had been discontinued in recent versions. Well, I was wrong on that, the latest CVS version has CONFIG_AUFS_COMPAT configure option for compatibility with Unionfs.

Okay, but more important, Junjiro told me that recent versions have exactly what I want, an option to not create those '.wh.__dir_opaque' files. With CONFIG_AUFS_COMPAT, this feature is disabled, but it is turned on by the parameter 'diropq=w' in the code that creates the Aufs union in the 'init' script.

And it works, it works ...the opaque files gone forever!

I also mentioned another problem with flushing files from the tmpfs layer down to the 'save' layer -- hidden directories. I have fixed that too.

I found that it had to be done in a certain order. If I create a directory, say 'testdir' and then create a a file in it, say 'testfile'. When I flush this, first create the 'testdir' in the 'save' layer, then copy the file, then delete the file on the tmpfs layer, then delete the 'testdir' on the tmpfs layer. I had to kind of get myself into the mindset of how the "reval" feature of Aufs would re-evaluate the layers when it detects a deletion.

That's great Barry - a real breakthrough :-)

way to go - my mouth is really watering now for the next release

We must surely be getting close to the "perfect" linux distro .. :RASPBERRY

My mouth is also watering for the next release..

Great work Barry..

This looks really good. Any chance of a new diagram of how the mounting will work?

sfs add-ons are squirming in excitement. :-)

Installing Puppy to a subdirectory 

Leon reported this problem. He manually did a "frugal" hard drive install and placed the Puppy files in /boot directory. He put the correct information into the GRUB menu.lst file, like this:
kernel (hd0,0)/boot/vmlinuz pmedia=idehd
initrd (hd0,0)/boot/initrd.gz
And it started to boot okay but the 'init' script could not find initrd.gz and booting stopped.

I have modified the 'init' script so that it now looks in '/boot' (if it exists) as well as '/', but I have also made it generic -- you can place a kernel boot parameter 'psubdir=boot' or any directory name you want. If 'psubdir' boot parameter does not exist then 'boot' is assumed.

I haven't actually tested this yet, so I don't now if anywhere later in the bootup or running or shutdown scripts this alternative path causes a problem.

This is very useful solution.
Thank you.

Sit Heel Speak 
Odd. I've been putting

initrd (hd0,0)/p201disk/initrd.gz

and suchlike into menu.lst since 1.08r1. Why do I get away with it? Is it perhaps because I put


in the kernel line?

I stick my initrd.gz file two layers deep: /boot/pza-301/initrd.gz
I never do anything fancy. My Grub config looks like this:

# Pizzapup 3.1 config begins
title PizzaPup 3.1
rootnoverify (hd0,4)
kernel /boot/pza-301/vmlinuz root=/dev/ram0 vga=normal loglevel=3 PMEDIA=satahd
initrd /boot/pza-301/initrd.gz
# Pizzapup 3.1 config ends

Maybe Barry actually meant the pup_xxx.sfs file?

John Doe 
I think Pizzasgood has got it with 'rootnoverify' (I use rootnoverify also and have no trouble with sub directories for those files on any partition).


This grub setting works for me.

title puppyLinux
root (hd0,0)
kernel /puppylinuxDev/vmlinuz root=/dev/ram0 ro
initrd /puppylinuxDev/initrd.gz

Also the statement seems bit confusing, why does init have to find initrd.gz, rather it is the bootloader (grub/lilo/???) which should be loading initrd and not init. Am I missing something here. If you are running init script it means you already have loaded initrd or have bypassed it and loaded a root partition.

Just a wild guess haven't dug into linux kernel for some time now, is it anything to do with the root=/dev/ram0 missing in Leons grub.conf.

I use grub4dos 0.4.2 on Windows 98SE. I have one hard disk drive and one vfat32 partition on it.

Grub4dos 0.4.2 files located in C:\ directory:

My boot.ini file located in C:\ directory:
[Boot Loader]
[Operating Systems]
multi(0)disk(0)rdisk(0)partition(1)\WIN98="Microsoft Windows 98 SE" /fastdetect
C:\="Microsoft Windows 98"

My Puppy 2.16e3 C:\boot\menu.lst frugal install file:
default 0
timeout 0
title Puppy-p2.16e3
rootnoverify (hd0,0)
kernel (hd0,0)/boot/vmlinuz PMEDIA=idehd
initrd (hd0,0)/boot/initrd.gz

Puppy 2.16e3 files located in C:\ directory:

Other Puppy 2.16e3 files are located in C:\boot directory.
Copies of initrd.gz file have to be in C:\boot and C:\ directory to boot Puppy 2.16e3 successfully.

The problem that occurred when booting Puppy 2.16e2 or Puppy 2.16e3

Although one copy of initrd.gz file is in C:\boot directory and if I delete or rename another copy from c:\initrd.gz to c:\initrd.gz_ then boot process stops at:

Now executing 'init' script in initial-ramdisk...
(Note initial-ramdisk is retained and in /initrd after bootup)
Loading kernel modules...
Looking for Puppy in hda1...
Using personal data file pup_save.2fs which is on partition hda1
ERROR, cannot find Puppy on 'idehd' boot media.
Exited to initial-ramdisk (/dev/ram0) commandline...

At first boot it was the same except:

This is how Barry explained the problem:

"yes, the init script checks for initrd.gz at c:\
Now, that's an interesting problem... Puppy will need to read where the actual initrd.gz is supposed to be, that is, c:\boot. I presume that GRUB passes 'initrd=/boot/initrd.gz' on the kernel commandline, so the 'init' script can read that."


My Puppy 2.14 C:\boot\menu.lst frugal install file:
default 0
timeout 0
title Puppy-p2.14
rootnoverify (hd0,0)
kernel (hd0,0)/boot/vmlinuz root=/dev/ram PMEDIA=idehd
initrd (hd0,0)/boot/initrd.gz

initrd.gz file was located only in C:\boot directory.

Hi Leon/Barry,

Any specific reason why puppy's init script tries to find from where the initrd image is loaded.Ideally shouldn't it not bother from where it got initrd image. Is it to see which is the first partition to look for pup_ver.sfs file or so.

The reason why I ask is if it is for this specific reason then because either way has you seem to be looking at all the partitions for puppy related files, it may not matter, which one you look first.

Pizza is right -- I've always kept my kernel and initr.gz in /boot/214, /boot/213 etc. so I can boot frugals of various versions.

Barry, I think it is much simpler to make a few slight modification to the way the files are searched than to start adding new parameters.
I looked into thins in the past (posted a modified init script on the Murga forum) and it's just a matter of changing a few places where you have "ls" to use "find -maxdepth 1" or the like and just making sure that when you mount the sfs (from within the tempfs) you get its actuall "name" by using "basename" -- in most places having PUPSFS be /some-dir/pup_21x.sfs will not matter (same for pup_save).

Barry Kauler 
Yes, it would be best to avoid another boot parameter. I'll look at it again.

More improvements, booting from Flash 

As requested, there is now a "Save" icon on the desktop, like for the multisession-CD. The background daemon 'savepuppyd' calls 'snapmergepuppy' to save/flush the session to the 'pup_save' file, periodically or when tmpfs getting full. But clicking the desktop icon sends a request to savepuppyd to do an immediate save.
It works nicely, you click the desktop icon and a info window pops up telling you that a save request is queued, then another window informing of the save taking place.

Something else that has also been requested sometime ago. It could be that you have more free space in RAM than you do in the 'pup_save' file and it is possible that you have installed too much stuff than can be saved. The freemem-applet shows how much is free in the pup_save file and that should be red-flashing if you reach that point. Also, when snapmergepuppy saves the session, it now checks the free space in the 'pup_save' file and will stop when it is nearly full, and put up a message telling you that you should delete some files.

Of course, you will also have the option of increasing the size of the pup_save file, but that requires a reboot.

Aufs progress notes 

As announced in the previous post, I have moved from Unionfs to Aufs, primarily due to the promise of improved direct access to the layers.
I have ended up totally rewriting the 'savepuppyd' and 'snapmergepuppy' scripts. The former is a daemon that calls snapmergepuppy periodically or when RAM is getting full, and the latter saves the tmpfs RAM layer down to the 'pup_save' layer.

savepuppyd now puts up an information window when the save is taking place, snapmergepuppy now uses 'lsof' to only save files that are not open -- except at shutdown when everything is saved.
Getting true flushing though, has only been partially succssful. I'm using the Aufs mount parameter 'udba=reval' which is a compromise for direct layer access, giving good speed, low resources. I found though, that files in a directory path with a hidden directory cannot be flushed. Also, and this is the real killer -- the accursed '.wh.__dir_opaque'problem is still there and also prevents flushing.

To explain this: if you install a package and some directories are created, the '.wh.__dir_opaque' file is created in each new directory, which tells Aufs to ignore anything that might later be created in lower layers. That is why flushing cannot work. I know that this is following a POSIX standard, and Unionfs ad Aufs both create ths file, but it serves no good purpose, only bad, in Puppy. I intend to contact the author of Aufs and ask how to hack the source to prevent this file from being created.

Otherwise, flushing does work. If you for example download a file (and do not create a new directory in the current session for it) then it will get flushed by snapmergepuppy.
In the case of booting from a flash drive 'opaque' files do not get saved, so at next bootup they are all gone. So, flushing does work then. The problem is only for new directories created in the current session.
There is probably a solution, to use 'udba=inode' which causes Aufs to track every change in the layers, and I could probably directly delete the 'opaque' files without rebooting. However, that has overheads. In fact, it would probably allow packages to get installed directly to the 'pup_save' layer.

Anyway, there is progress.

Barry, thanks as always for all the work.

Am a little concerned about thsi: "snapmergepuppy now uses 'lsof' to only save files that are not open".

If I understand this correctly, if I'm working on a file continuously in OpenOffice, this would mean it would not get flushed down to the flash drive until shutdown - even if many hours have passed. if in between I lose power or something, wouldn't that mean losing all the work since the system was booted? (in fact I suffer from power cuts and other things so frequently with my systems that I have a makeshift mirroring script which mirrors my important files to the hard drive every minute :) ).

Is there a reason it's an advantage not to flush open files?

normally in most of the situations I encounter in my work ( i engineer corporate applications ) backup of open files for office suites is best managed from within the suites themselves since this is very much a personal decision and not one that should be enforced globally.
I know that suites like OOo and MS and Corel all have this as a setting within them to cover usage such as you describe
It is a very bad idea from a system point of view to perform system level actions on open files and often results in unintended events and problematic troubleshooting
Just my 2c


I can't recall if I checked with OpenOffice. I haven't got it installed right now. But, I just tried Abiword, opened '/usr/share/examples/text/testdoc.doc'
# lsof | grep 'testdoc'
returns nothing, meaning that the file is not open. It seems that Abiword only opens the file when it has to do an actual read or write, it doesn't leave it open.
I just tried SeaMonkey browser and Composer, same thing.

Just to verify that lsof does actually work, I used SeaMonkey to download a file. While downloading, it is open continuously for writing, and in that case lsof does show it as open.

It would be good to know if there are any apps that are an exception to this, that leave a document file open continuously. In that case I would have to put in some special work-around patch for them.

Note, at shutdown everything gets saved, even open files. I was concerned, what if a file got left open somehow, not sure how, but anyway, wanted to make sure it did get saved. So at final shutdown lsof is not used.


You're probably right, I had simply assumed that OpenOffice would leave the file open. however, I don't seem to have lsof on my Puppy 2.14, as (when I tried to check with OpenOffice open) it can't find the command. Is it part of devx_214.sfs (which is not on this system at the moment) or added in a later Puppy? If I can find it, will test.

gdcrane, can see your point. I use OpenOffice auto-backup, but of course if you auto-backup to somewhere in your pup_save, then that backup won't be written to flash either except every half an hour. Hence my mirroring things.

lsof is new for 2.16 -- I've just added it, so it's not in the 2.16exp releases either. Other distros have it.
Of course, there is a difference between a document being 'open' in your application and the actual file being open. It seems that applications open a document and copy the whole thing into a cache then close the file -- which would make sense for performance reasons, also be a guard against corruption of the file.

"savepuppyd now puts up an information window when the save is taking place"

Will that be a window that doesn't steal focus and closes on it's own? I find it really annoying to be typing or playing a game, and then a window pops up and interrupts me.

Or maybe include a "don't show this again" button. A one time only interruption isn't so bad, as long as it doesn't happen every thirty minutes.

Barry Kauler 
Pizzasgood, it's a yaf-splash window and it will disappear pretty quickly, or you can click on it to make it go away immediately.
Saving to the Flash drive is a pretty important event, and you really do need to know that it is happening -- well, I think so anyway.
Besides, if you are a prior XP user you will be pretty accustomed to litle info windows popping up! ;-)

Concerning the "open" documents: couldn't this be a difference between how Linux and Windows work?
In Windows it seems like the moment one application is using a file you can't do anything with it, while if I open a file in Geany -- it seems like it just takes a "snapshot" of it and buffers everything it does until you choose to save.

Maybe the snapmerge script should save "open" documents (i.e. copy them to lower layer) but not flush them?

Barry Kauler 
[blockquote]Maybe the snapmerge script should save "open" documents (i.e. copy them to lower layer) but not flush them?[/blockquote]
That is very easy to implement. The snapmergepuppy script has a variable COPYIT which is set to 'yes' or 'no'. If a file is open, just set COPYIT=yes rather than jumping to the next file.
I'm trying to think if there would be any situation where reading an open file would be undesirable... if a download manager was writing continuously to a file, I suppose doing 'cp' on it is okay? Or, consider this ...a wordprocessor is saving a document, and right in the middle of the save, snapmergepuppy copies it down to the 'save' layer -- couldn't that conceivably result in a corrupted file saved, overwriting an older but okay file?

Aufs replaces Unionfs 

I'm testing Aufs, and it's looking good. Those who have been following the discussion on Unionfs will know that there are problems with "whiteout" files, however, there is a more compelling reason for considering moving to Aufs -- the ability to write directly to the layers.

Let me explain this "compelling reason". When Puppy boots from USB Flash or IDE Flash or multisession-CD/DVD, the Unionfs layers look like this:
/initrd/pup_rw -- working files, in a tmpfs in RAM.
/initrd/pup_ro1 -- the "pup_save" file, mounted by a loop device.
/initrd/pup_ro2 -- the pup_216.sfs file, mounted by a loop device.

The reason for the top layer being in RAM is to constrain writes to the pup_save file, in the case of USB Flash to every 30 minutes, which prolongs life of the Flash memory. Puppy runs a background program (daemon) that every 30 minutes calls 'snapmergepuppy' which is a script that copies the files on the pup_rw layer down to the pup_ro1 layer.
That is, the files get saved to the "pup_save" file, but note that word copied -- not actually flushed. Say for example you install a big PET package that eats up most of the free RAM space in the pup_rw layer -- tough, all the files will get copied down, but they are still in the top layer and will stay there until a reboot.
This is a serious fundamental problem.

However, Aufs allows direct writing and deleting of the layers, with some qualifications. For maximum performance of this direct-layer-access, I patched the kernel with a "ksize" patch supplied with the Aufs package (and while I was at it, enabled some extra modules that Ted Dog and John Doe wanted). In the 'init' script, the aufs layers are mounted with the parameter "udba=reval" or "udba-inotify" to allow direct-layer access.

Now, in snapmergepuppy, after copying a file down from pup_rw to pup_ro1, I can directly delete the file in the pup_rw layer. Aufs will recognise that a file has been deleted in a layer and will fall down to using the one on a lower layer. The parameter "udba=reval" is what I am using as the other one, "udba=inotify" has much higher CPU and system overheads. The latter is the best, the former has some limitations -- "udba=reval" works fine unless there is also a file of the same name in the lower pup_ro2 layer, then the file that was copied from pup_rw to pup_ro1 gets ignored -- in other words, delete the file in the pup_rw layer and the copy in pup_ro1 gets ignores and the one in pup_ro2 is seen on the top. The reason for this is the Aufs cache.
Anyway, I can work around this problem in snapmergepuppy, by only deleting files in the pup_rw layer when there isn't one on the pup_ro2 layer. This would be the normal situation.

Okay, the bottom line. It means that (mostly) true flushing will occur, so the files get saved to the "pup_save" file and the space in RAM gets freed up. Normally this occurs every 30 minutes or whatever, but now there is a new possibility -- to flush whenever the RAM starts to get full. I think that this is a truly wonderful improvement.

Okay, the current status. I've been testing the copying-down and deleting of the various layers, to find what works. I still have to modify 'snapmergepuppy' to perform the true flushing, plus to do so when RAM space in pup_rw gets full. I'll do that tomorrow morning. One of our Puppy enthusiasts, andrei, has done much wok on snapmergepuppy to improve whiteout-file handling, but Aufs is supposed to have much better whiteout-file handling so perhaps andrei's extra code is not needed. That remains to be seen. I will roll back to an earlier snapmergepuppy and work on that. After 2.16alpha is released, I'll invite andrei to look at it and see if any of his special code is needed.

Nathan F 
Very, very good news. Thank you Barry for doing this:-)

Barry when you (or if you) release this as an experimental version can I ask if it would be possible to base it on the exp2 you did rather than the exp3 - for purely selfish reasons I will be the first to admit. - or maybe you could release it in two flavors one with the compression you put into exp3 - and wone without.
I seem to have problems with the versions where you include compression.

As I said purely selfish reasons and not a demand just a wibni


I agree with gdcrane. Exp2 works very well and Exp3 is unusable to me.

Yes, Squashfs-Lzma and e2compr (ext2 compression) are being sidelined for now. They won't be in 2.16 alpha, which is what I plan to release next.

Perhaps another criterion for using "flush" is saving one's work, especially in a situation of unstable power grid.

Used only in flash devices (USB, IDE flash): Pardon my asking, but is it correct to assume that files opened in a mounted IDE partition are saved directly to the partition? So forced flushing will not apply there, as it is done automatically?

These are great news!
unionfs is a very important part of Puppy, and it is nice that
we would be able to use the latest version.

I am looking forward to testing the 2.16alpha.


With AUFS, you can remove and add .sfs files on the fly. At least it seems to work. Nathan had posted some packages in the main forum. The BootManager you made for 2.16experiment2 could be changed to work with out rebooting.

Yep, flushing is only needed when the pup_save.2fs file is on FLASH media. A menu entry or desktop icon to immediately save would be handy. For now there is my Save-Puppy dotpup, but having something integrated with Puppy would be better.

Forgot, might be a problem with low ram computers and adding and removing branches. See: http://www.murga-linux.com/puppy/viewto

Nathan F 
Adding aufs branches while running seems to be fine, but removing them is risky. There seems to be a correlation with low ram computers not being able to do it successfully, but I don't have enough data to go on. Either way, I think aufs is the way to go, for a lot of the reasons Barry mentioned as well as just overall better stability.

Great news, indeed.

Just one question: I seem to recall reading somewhere that a tempfs dosn't shrink if you empty it. If so, "flushing" won't really free ram, just prevent the tempfs from growing further -- so we need to make sure the "flushing" occures when there's still plenty of ram left for applications.

BTW, I think with all these changes it should be 2.20, not 2.16...

John Doe 
> and while I was at it, enabled some extra modules that Ted Dog and John Doe wanted


I'm looking forward to building up some pets for everyone which those will enable.

Starting and stopping services 

As mentioned awhile back, Puppy now has /etc/profile.d directory, in which packages can place scripts. These are usually for setting environment variables. An example is in the openoffice_cutdown3-2.2.0 PET package (not yet uploaded to ibiblio).

Many non-Puppy packages, for example Slackware packages, have such scripts, so this makes Puppy more compatible. Puppy v2.14 is able to install Slackware packages by using the 'tgz2pet' utility to convert the Slackware tarball to a PET package, then click on it and PETget will install it, even running the install script that is in most Slackware packages.

To further improve Puppy's compatibility with other Linux packages, I have now added /etc/init.d directory, with /etc/rc.d/init.d a symlink to it. This directory can have scripts for starting and stopping services, for example the ALSA sound server. "Normal" Linuxes have runlevels, with directories that have contents that specify which of the services in /etc/init.d are to be started, which are to be stopped. However, Puppy does not support runlevels, which was decided at Puppy version 0.1, originally because Busybox doesn't.

Unlike some other distros, Puppy does not have lots of services to manage. In fact, those that are running are essential. The vast majority of users would not mess with those services, so I don't see any need for any kind of service management.

I needed to create /etc/init.d as the JRE (Java Runtime Environment) package supplied with OpenOffice 2.2.0 places a service script in it, and I didn't want to have a hacked service management setup as I have done peviously for PCMCIA (I inserted code into /etc/rc.d/rc.local0 and rc.shudown).
So, what I have implemented is ultra-simple. There is now code in /etc/rc.d/rc.local0 that runs all servcies found in /etc/init.d/, with commandline parameter 'start'. At shutdown, /etc/rc.d/rc.shutdown now has code that runs all services found in /etc/init.d/, with commandline parameter 'stop'.

It does not preclude some kind of service management being added later, perhaps a GUI thing (in fact, it can be done very easily by adding or removing the executable attribute flag on a service script, as my code checks to see if it is set before executing the script).

The good thing now is the extra compatibility for installing Slackware packages in Puppy.

Barry Kauler 
I have also copied /etc/rc.d/functions script from Slackware, as some service scripts in Slackware packages require it. It contains functions to aid with starting and stopping daemons.

Nathan F 
Not sure if you ever saw it or not, but I created a fairly simple service manager for Grafpup early in the alpha cycle for 2.00. Any services you want to start are stored in an /etc/rc.d/rc.services text file, and are then run with "start" as a parameter during bootup. For safety everything in the init.d directory is run with "stop" as a parameter during shutdown, as any services still running when the system shuts down can cause the filesystems to be unmounted "dirty". It's pretty short and just uses a simple radiolist box to select what you want to have running.

I personally think it is very useful, even for Puppy, and could be used for ghttpd, pureftpd, or gpm if it is installed. Here's a link to the package.


The only issues would be that the icon I use is an svg, so it won't display in Puppy, and modifying your code to run the list stored in rc.services rather than everything in the init.d directory.

Nathan, yes I did have a quick look at your iso. The default is that there is no rc.services file, and if a package, like the JRE-6 package for OpenOffice is installed, I would want the service script to start and stop by default. That means there would have to be something extra that adds it automatically to the rc.service file when the package is installed, and removes at uninstall.

My approach, not necessarily the best of course but it seems reasonable, is whatever is in /etc/initrd/ gets started by default, but if you did want to disable it then just remove its executable attribute -- which is what a GUI like yours could do. If a package is uninstalled, the service script will get deleted and that's that.

I mean /etc/init.d/, not /etc/initrd/!


Now it be easy to possibly install the boot-up splash prog - 'Splashy" - that allows for a boot splash screen (animated, etc..) with progressbar for when Puppy boots up..

Great move, Barry..

Nathan F 
How ever you want to implement it, is fine. I just wanted to mention it since the two approaches are covering the same territory.

I looked at Splashy a couple months back. However, even if this allows it to work with less hacking, I don't think it would kick in until Puppy's half-booted anyway. To cover the whole boot, the bootsplash program would have to be launched by /sbin/init in initrd.gz.

Experimenting with that is my next project, as soon as my schedule clears up somewhat.


Yep - I also found that Splashy would have to be booted up very early in Puppy's boot sequence - at the time I looked at it I couldn't work out how to do it - but now that you mention /sbin/init in initrd.gz - that may be the way to go - however hacking it to also include the Splashy scripts in correct stepped sequence will be the biggest hurdle..

I may also do some experimenting with this myself..

Well, my plan is to just set up my own program I plan to make (named Pebble, as those make little splashes). It just seems more fun to me to make something specifically for Puppy than to hack at something else and try getting it to work.

But it may be easier to make Splashy work than I evaluated before. Maybe I should take a look before I start writing my own.

What's in a name? 

I notice recent discussion in the "Off topic" area of the Puppy Forum that there is some on-going dispute between some Puppy-users. The origin appears to be the creation of a domain name 'puppylinux-foundation.com' that others considered conflicted with prior claim to use of the proposed "Puppy Linux Foundation", the latter intended to become a legal entity.

Yes, the term "Puppy Linux Foundation" does have a prior claim in terms of its longer history. Several months ago I did make a statement to this effect, and I thought that the 'puppylinux-foundation.com' name was being deliberately confrontational -- and I suggested they might make peace by using a different domain name.

Apart from the brief comment, I stepped back and was not involved. After all, I'm doing this as a hobby, for fun. I'm simply not interested in the politics, nor empire-building. It's just fun, that is the spirit, or should be the spirit, of this project.

Anyway, time has rolled on, and from recent posts it seems that the conflict still simmers, unresolved.

Personally, I have a problem with the level of "noise" that I have to deal with everyday -- the number of emails, personal messages from the forums, plus the forums themselves. I can quite easily spend a couple of hours reading forum posts, which really eats into the day's productive hours. Also, as I will be travelling a lot in the future, I will have less regular Internet access. So, I will be stepping back a lot from day-to-day involvement/interaction and just focus on my hobby. Probably even this Blog will go back to a static News page like it used to be.

And the politics? Well, I'm just not interested. I'm working on upgrading some of my pages, also creating a new master-link page to all the Puppy websites, and I'm inclined to include 'puppylinux-foundation.com' in that list, with the understanding that it does not diminish the other parties prior claim to creating and using the 'Puppy Linux Foundation' name. If anyone wans to comment with a compelling reason why I should not do this, please do, but any comment posted here that is inflamatory will get deleted.

"I stepped back and was not involved.
After all, I'm doing this as a hobby, for fun.
I'm simply not interested in the politics, nor empire-building.
It's just fun, that is the spirit, or should be the spirit,
of this project."

Nothing to add to that statement.
Thanks for putting the fun back into OS.

I chose Puppy Linux because it works, everybody wants to make it a successful as other distribution, and, yes, it is fun to use. I hope and pray that we, members/users/programmers of the Puppy Linux community, should always follow the tenets set by Barry. Puppy Linux is still evolving, everyone should be focusing on improving it rather than on politics. 8-)

Eric (caneri) 
Politics is a waste of everyones time...other than for politicans of course..Barry...I will continue with my project for web space/bandwidth for puppy....and if successful,as far as I'm concerned is for anyone that needs space for constructive uses for the pup or open source projects of any flavour. As I will not be admin for this it's up to you and Lobster or people of your choice. Somehow Puppy has become my hobby also...It's a good thing this puppy...kind of fun you see..thanks for the pup


"After all, I'm doing this as a hobby, for fun.
I'm simply not interested in the politics, nor empire-building.
It's just fun, that is the spirit, or should be the spirit,
of this project."

Stick to it, Barry, life is too short to get involved into politics and power play

Well, I for one would be very sad if Barry felt like he had to 'step back' if that were to mean less involvement with Puppy. I use Puppy for everything and read this blog practically every day. If Barry were to withdraw from the kind of intense great work he has been doing, I would (no offense or criticism to the other great Puppians out there) feel almost bereaved :).

Barry, you're great and Puppy is, at least for my purposes, by far the best distro in existence. I hope these minor disputes don't get too irritating.

He means he'll spend less time playing with the forum and more time actually working on Puppy. I don't blame him. The thing gradually eats your time until you spend more time keeping up with it than being productive.

"I can quite easily spend a couple of hours reading forum posts, which really eats into the day's productive hours."

That's why I think it's a bad idea for you to point people from your forum to the Murga forum.

I go to the forum to help solve bugs, but I don't have time to sift through al the junk on the Murga forum, so I just end up hardly ever going there -- and the users who need help lose out.
Your forum is very quiet and so it's possible to visit it every day and do things there (there's no way I would have managed to pin down the elspci bug on the Murga forum -- there's would have been too many irrelevant coments that would have driven the thread off course).

Barry I retitled the off-topic post I made recently. I do hope that the new title puts a different light on what I was trying to express. You announced on your blog that you will be stepping back & this is why a foundation is needed, some of think so...


Dougal: "I think it's a bad idea for you to point people from your forum to the Murga forum."

Yes, I realized just now which forum should work better for my technical enquiries. I hope other devs realize that this forum exists:


Barry, I guess it is alright to include in your list any Puppy Linux-oriented site with clearly identified person/s owning and responsible for it, especially the site admin.

Barry, thank you for your time and extraordinary efforts in providing this community with Puppy Linux. I appreciate you and this one of a kind Linux distribution. It is very exciting to experience how this wonderful distribution evolves, each time a new version is released. Even though I am fairly new to Linux and have very little knowledge in computer science, I greatly enjoy reading the Puppy Developer News.

Thank you again, Puppy Linux is truly amazing.

sorry, i know this isn't a popular view, but you cannot separate politics from free software no matter how preferable it might be.

free software
- politics
nonfree software. it may take a while for some to realize it, but it's just the way it is. frankly, i'd rather just use puppy and be happy. being realistic does not always allow. politics made it possible for barry to use linux almost any way he wanted- another thing that is not possible is separating linux from free (as in libre) software, you need bsd for that. politics are inevitable. i hope this was not too inflammatory.

"It's just fun, that is the spirit, or should be the spirit, of this project."

Are we having fun yet? Less FUD and more fun please. Maybe a free joke with every 'serious' posting?

I will go and stand quietely in the corner . . .

Good to hear. I thought it was wise to leave us to settle our own problems amongst ourselves. I'm not sure if this has been settled yet but lets continue to move on.... If its not one thing its another, so if a group or person is showing themselves to be more helpful then hurtful, then I give them as many second chances as needed [i]if[/i] progress is being made.

Now as far as reverting this blog to a static news page, please don't completely. Just disabling the comments should be enough? RSS feeds and anchor links were much needed with the old news pages.

Nathan F 
Yes, I would second what J_Rey said about the blog. I think it really helps to be able to search through posts, open specific anchors, get things in a feed, etc. The static page just gets to be too long to go back and find information. If it's because the blog is acting up then there are alternatives available, with or without a database. But my guess would be any problems you experience are more than likely related to the host rather than the software, so solving them might be tricky.

Barry, you are 10000% right...
...and a hint about the future...I was wondering about the hardware dilemma...Trying to support newer and newer hardware in Puppy (and Linux, in general) vs. full compatibility with legacy hardware...In light of the makers' plans to embed DRM into the hardware, effectively locking the software to their wishes (and holding all of us by the 2#$!!...), I am inclined to say "NO THANKS" and consider sticking with legacy as long as it will be able to switch-on...

Maybe Wordpress can help - it is a blog, and now it has an accompanying forum. Its spam filtering works well. It has been working well in the different occasions that I tried it since 2005.

Glenn (grholme<at>yahoo.com) 
I've been dealing with operating systems since 1970 as a systems programmer. In that nearly 40 years, I have never had so much fun as I have with puppy. Well not quite true, in the beginning I did have fun because things were really exciting back then (in the mainframe world).
I hopped from disro to distro, accidentally landed on a comment regarding puppy so I tried it and thats it. In fact I demo'd it to a few friends, collegues, etc and there are probably half a dozen more puppy users now. All happy, all not bugging me with "how do I"? :-) I like the spirit... Keep it fun. Its a lot more productive that way.



I applaud your approach to this. As a fellow Australian I admire the way you can cut through all the "stuff" and do what you are very good at.

Me, well I'm not the slightest bit interested in politics, whether it's parliamentary, or council chambers, or scout group, or church, corporate, charities and their associated "foundations", whatever... and I've been unavoidably involved in the political ramifications in many of these areas unfortunately...

I've been around the *nix traps for quite a number of years as a user looking for stuff that works reliably and securely, and which can be lawfully shared with friends, acquaintances, associates, whoever.

That's why after trying a raft of other systems, I've really settled on just two; PuppyLinux and PC-BSD, both of which are genuine non-commercial projects, even though PC-BSD now has a commercial sponsor.

I think pizzasgood is right over what he sees Barry's direction as being, as opposed to the genuine "shock, horror" of his heading off or something.

Keep it up fellows. I'm too long in the tooth to learn anything about writing code these days, but for what it's worth I've spent half my lifetime looking at system ergonomics from a user point of view while designing electro-mechanical operations (production lines, etc) and their systems. If I can help with a frequently critical eye, please allow me to help :)

Richard in Adelaide
The Ozzie clever capital
Ozzie is the clever country, after all, if you can believe retired politicians :)

Capoverde (rosinternet<at>libero.it) 
It appears that some kind of political manoeuvering begins as soon as more than one people get interested in the same thing. It's in human nature, I fear.

In primary school we learned a tale about a dispute, the judge saying "That's right" to both disputant's views. The judge's child then said "How can they both be right, dad?", and the judge had to admit "You're right, too...".

Barry's way is Puppy's life, it's the spirit that conquered many Puppy fans like me. But of course there are other viewpoints, not necessarily wrong.

Well, if Puppy is as good as I think, it will easily survive even politics. Thank you Barry!

When you feel very smart, get concerned: it's the distinctive symptom of all victims of stupidity.:RASPBERRY


I hope your statements in this blog post clarify things for people from every side about what puppy means for you.

It was clear to me.

One comment on your participation in the forums:

I agree they are too time consuming but for now it is the only medium for the user to log bug reports, contribute bug fixes and ofer ideas. To me those kind of posts have always been helpful and for what I've seen, they've been helpful to you too.

The problem is that those helpful posts are burried under many more that are rants, requests for help, off topic, etc. The risk under the current format is that if you want to get to the helpful ones you must read or at least scan many others. For my limited time for example, I used to spend more time in the forum than producing contributions.

My recomendation to reduce the noise to signal ratio is to use a purpose specific tool such as bugzilla, that way the recommendations can be discussed and argued in the forum by the interested parties and once there is a solid recommendation it goes there.

I know that it requires someone to volunteer to be the gatekeeper but I think it is no different than the very helpfull people that are maintaining the community Forum.

We already have a couple that have been offered, it's just a matter of start using them.

Don't forget that many times the word "merit" and "contribution" are written in the Murga forum. So it is through hard contributions that people should assert themselves, not simply "politics". MU has a expression for it, "earn your stripes".

Barry shows us that way of life (of endless labours) everyday through this blog. How could a some regulars miss this point?

Mark South 
Barry, I sypathise with your view that politics are a pain. Most of us prefer doing development or testing or fun stuff instead of bothering with politics.

However, several points to note:

1. The Murga forum has become heavily politicised through some of the moderators (John Murga included) adopting a heavy-handed approach, like deleting posts that make different technical or design recommendations. I don't have a solution to that, but until that situation changes that forum will remain a politicised arena.

2. There would be more focus on the development of Puppy by many people if they could be assured that they are not contributing to a proprietary project. The lingering ill-feeling between the various entities calling themselves "foundation" appears to arise from that concern.

3. You have expressed, in previous developer blog or forum postings, an intention to re-license the proprietary core of Puppy using a GPL or LGPL type licence. Nevertheless, up to the present it appears that key elements of Puppy remain proprietary to you.

4. It seems to me that explicitly free-licensing all of Puppy would be a tremendous step towards reducing the political concerns of all the participants in the various Puppy forums, as well as opening the door to numerous other developers. You can take this step unilaterally, and I would appeal to you to do so. To put my money where my mouth is, I would be willing to help with emplacing the licences in the code and reviewing the overall licence structure with you.

Thanks for reading this far.
Best wishes,

PS For clarification, I have no connection to any of the various competing foundations, or to any commercial entity that involves Puppy.

RE Mark's post:
I don't think more people would help develop Puppy if it's licence were changed -- most people don't know (or care) exactly what licence Puppy has. The people who want to help, help, the people who are lazy, don't.

As for the Murga forum, I don't think Murga has any "political" agenda, just idiots for moderators -- thus we end up in a state where the person who gets banned from the forum is one of about ten people on the forum who actually know anything about Linux, while all the babblers are left to continue flooding the forum with pointless messages...

Mark South 
RE Dougal's post:

I strongly resemble the remark in your second paragraph :-) Notice that I was banned for asking people to reply to my posts if they saw them, so that the moderators would not be able to remove them so easily.

Just to clarify, by "politics" I don't mean that it's a case of democrat vs republican, just that there is a lot of discussion about people feeling excluded or their opinions ignored.

As for your first paragraph. Personally, I would like to contribute stuff to Puppy. I would also like to be able to make and distribute a system based on Puppy. But with Puppy remaining proprietary that seems a shaky proposition, legally speaking. Even if Barry is cool with it at present. My email discussions with several others in the Puppy community show me that I am not alone in this perception.

DISCLAIMER: I am not a lwayer, but I have participated in contract negotiations for, and with, several IT companies. Legal exposure is no fun to live with at all.

I forgot to add in my last post that in 2.14 Barry has actualy added "LGPL" at the top of various scripts -- that might help clarify where Puppy stands regarding licencing.

I don't care about it much since it's obvious that Barry is a good bloke and you can probably do whatever you like with Puppy and he wouldn't say anything -- the idea of the copyright is for protection from the evil corporate world...

Richard.a (richard.a<at>internode.on.net) 
Something I've noticed in most forums is when there is an "excommunication", nobody is prepared to talk about what, why, where, how, who, etc.

I use the term "excommunication" quite deliberately, because there often seems little intrinsic difference between the management of forums and the management of religious cults - of which I had the misfortune to belong on one occasion, for 20 years, the last 8 of which being "in absentia" - because they didn't wish to know me.

I'm familiar with the concerns that people (in both) express about "outsiders" - but you know, the world is full of outsiders. Some of them actually know a darned sight more than I do, amazingly <grin> :)

So that's where you disappeared to, Mark!

I had wondered. And now, being in my 70's, I wasn't game to voice any questions, it's all too hard mate, at my age lol.

So sad when those who have something to contribute, can't, for a raft of reasons.

Leave it there, or it'll become political.

Mark and Dougal, I was very interested in your quasi-legal comments.

I was considering creating a distro based on 2.16ce and sharing it around the traps, if I can perfect the customisation and burn.

Maybe I should reconsider.

I too am not a lawyer.

[b]But I've seen enough of bad stuff in probate cases I've been told about, to be highly concerned that anything I expressed as a "wish" does not have to be adhered to when I'm gone, by those who administer my estate[/b].

I think I need to be wary in what I was thinking of doing.

Richard in Adelaide.

ummm by 2.16ce I meant 2.15ce - unlike forums, there doesn't appear to be an ability to edit your post.

Which is why my forum signature always says...

[i]Have you noticed editing is always needed for the inevitable typos that weren't there when you hit the "post" button? [/i]


Mark South 
Richard: thanks for your kind comments, they are appreciated. And while I am not a lwayer (I doubt anyone is), neither am I a lawyer :-)

Dougal and Richard: to contrast your last points. Yes, Dougal, Barry IS a good bloke. That's why he shares Puppy with everyone. And no one else has the right to demand of Barry that he do any specific thing with his creation. But surely we can reasonably make our request to a decent bloke and reasonably expect a decent reply.

Richard has summarised the main issue, which is the question of whether Barry's legal representatives will also always be good blokes. What if Barry falls ill, or gets bored, or receives an offer he can't refuse for the rights to Puppy? What happens then to the effort that everyone else has put into the distro? As long as Puppy remains proprietary, that's a concrete risk. Barry could completely remove those concerns by making everything explicitly GPL, or by clarifying that his own scripts remain proprietary. (Note that, according to the FSF, notes on web pages do not count, the licences have to be embedded in the code they refer to.)

Everyone prefers to avoid legal issues. Sometimes avoiding large legal issues in the long term means facing up to smaller issues in the present.

Everyone prefers to avoid politics. Sadly, those who are left out of the discussion process have no choice but to concern themselves with facing up to issues of politics.

I reiterate my appeal to Barry, as the decent bloke that he obviously is, to end once and for all, and in no uncertain terms, the lack of clarity regarding the licencing of Puppy and the code it contains.

All best wishes,

Er, I thought that the licencing [i]was[/i] settled, some time ago. Puppy does not have a proprietary licence. The only thing I have claim to are the names and logos, whch is quite normal for an open source project. Even Linus has copyrighted "Linux".
There are scripts that had "Copyright (c) Barry Kauler" on them, but I have been changing them to "LGPL". But, the above statement has been made before, so this issue should be dead by now.
The FAQ was changed sometme ago to be clear that there is nothing proprietary.
I'll make a sweep through my scripts right now, make sure the LGPL is on all of them, before the next 2.16alpha.
Then, could we please put this 'proprietary' nonsense to bed?

Okay, I've gone through all the scripts, made sure that a LGPL licence is at the top of them.

Mark South 
Regarding placing the Puppy scripts under the LGPL:

Barry, this is tremendously good news. It may have seemed like an annoying chore at the time (actually, I'm _sure_ it did) but by doing so you have ensured the future health and long life of your creation. This is an even greater contribution to Puppy than any individual piece of code.

Please note though, that you do not have to remove your own copyright to place the code under the LGPL. In fact, the LGPL is the mechanism by which your copyright is protected in perpetuity.

Trademarks, it is understood, are in a different class from licences, and no one would suggest that you should give up the trademark Puppy Linux (and PuppyOS too?). My personal recommendation (but I am still not a lawyer/lwayer) would be that you keep that tightly under control.

Finally, I'm sure that the rest of your readership will join me in thanking you, and raising their tinnies with a proud chorus of "Good on you, Barry!"


Chubby is back! Puppy 2.16experiment3 

If you have been on the Puppy-scene for long enough, you will recall "Chubby Puppy", that was released back in 2005. See the original announcement here: http://www.puppylinux.com/news2005.htm -- scroll down to the "29Sept05" and there it is, only 92MB, with the OpenOffice 1.1.4 suite and Mozilla suite!

This latest experimental iso is Chubby reincarnated, the very latest version of OpenOffice, 2.2.0. With so much extra stuff in Puppy these days, you have to expect the live-CD to be bigger, but 2.16exp3 iso, with the SeaMonkey suite, is just 120MB!

So, the first thing to test in this iso is have I cut too much out of OpenOffice? Can you still use all the components for most normal purposes? Of course, I can provide extra PET packages with the missing stuff, like the help files, Python scripting, dictionaries and JRE (Java).

Note, the live-CD did actually weigh-in at about 135MB, but I have brought back LZMA compression for Squashfs. I want to have another look at it, do some more speed tests.

Please note, current SFS files will not work with this release!!!

This 2.16experimental3 release has another very big surprise... writable ext2 compressed filesystem. I have been communicating with Terry Loveall who has done some more work on the 'e2compr' package to make it more reliable. The kernel and e2fsprogs package needed to be patched. At first shutdown, the /etc/rc.d/rc.shutdown script marks certain directories in the 'pup_save' file with the '+c' attribute, and all files and directories created in those directories will be automatically compressed.

Ext2 writable compression is highly experimental, please beware!!!

The patched 'chattr' can set any file or directory as compressed like this: 'chattr +c filename'. Danger: if yo do this on a ext2 partition, then that partition can no longer be mounted by any other distro or earlier Puppies, only with this Puppy with patched kernel. Even doing 'chattr -c filename' does not restore the partition.
Due to this danger, I recommend test on a PC that you don't mind if the hard drive gets messed up.

When testing this Puppy, how do you know files in 'pup_save' are getting compressed? For any file, do this: 'lsattr filename' and it will report that the file has been gzipped. Do this: 'chattr -r filename' and it will tell you the compression-ratio.

I tested booting from USB Flash, worked fine, but as files are created in RAM, the compression only takes place when files are flushed to the 'pup_save' file. So, install a package then reboot to get all of the package compressed.

I tested booting live-CD on an old Cyrix 6x86 128M PC, and unfortunately the kernel spitted out heaps of error messages connected with the compression while accessing the 'pup_save' file, although it seems to still be working. I have sent those messages to Terry.

Exciting stuff hey? Bearing in mind that the 'experiment' in the name really means it, you can download and test this pup from here:

Our Puppy seems to be getting more adventurous in it's travels through Linux land - getting better each day and 'learning' new things to boot..

Maturity certainly brings out the best in Puppy - yes some saggy skin appearing and some wrinkles - but inside - it still be a fast, proud, and cute little bugger..!!!

It will be great to eventually have all of Puppy as a compressed system - not just the '.sfs' files - even to the extent that it runs in ram in a 'compressed' mode..!

Great work - experimenting is the only way to find out if something will work - so I say "experiment" away..

Good One Barry.

Using it now. (used "Puppy pfix=ram" at boot)
The first thing I tried was the Thesaurus in Write - oops not there. Pretty essential for those of us with limited vocabularies. :)

A pupget of Office 2.2 has just been released on the forum and I could not resize the menus with that. In Chubby, I changed the default font size and restarted 'X'. That went OK. Then set up the NEW express firewall - that is good/simpler. Then connected OK and here I am.

Be interested how others get on. A lot of people will be very happy with a Standard and Chubby release for 2.16

Woof woof

I've been using 2.16exp2 since it emerged and it's fine! Just downloaded exp3. Sounds a little scary, so I unlpugged my regular hard drive and stuck another in the slot. This one happens to have PCLinos with an ext3 file system. Not too sure of all the implications. Anyway exp3 ran fine, OO, internet, etc. I rebooted and the "saved" config file was not found or at least was not used. Wrong file system, I suppose? Does this mean I cannot use exp3 with my normal hard drive, which is all fat32, including all my working data files. Does one have to use compression? Perhaps that's the point of the exercise.

I was rather hoping for an extended version of exp2. This will take a little getting used too, but your stuff always ends up on its feet. Thanks Barry!


When I go to the ibiblio link above, the directory is empty.

Henry, compression only applies to files inside the 'pup_save' file. Your hard drive partition should not be affected. The 'pup_save' file can be saved to any msdos/windows or linux partition as before, no difference. If you creatd a 'pup_save' file at shutdown then rebooted and it wasn't loaded, I don't know why that would be. Perhaps there is some problem with the logic in the 'init' script that is causing it to be missed.

kirk, I just checked the link, the file is there.

OK, I went back to my regular hard drive and upgraded my save_2fs. (I think the reason it didn't save on the other ext3 hard drive was a lack of space. A series or error messages scrolled by.)

Most everything seems to work as before, except that pmount does not detect the four partitions on my hard drive. It does detect the floppy, the CD and DVD drives, a flash usb drive, but not a usb camera memory.


Thesari are add-on luxuries - hard copy is often just as easy to use. Suggest you leave out the Spell checker, too, using the same argument and in the interest of space saving.
But the single most vital requirement remains ditching Seamonkey and all its bloat. 2.16 exptl 1 with Opera was fantastic, shame I still cannot reliably install it, nor get advice on how to mod. it, esp. as it seems only to need trivial editing; I just need to know what and where the editing is required and how to save it back, please. Otherwise it was a masterpiece, Barry.

Henry, if you used your normal pup_save.2fs, it is probably okay as the "+c" compression attribute is only set on certain directories when a new pup_save is created at chutdown. So in your situation compression is not being used, so you should be "safe".
exp3 is using plinej's new 'probedisk' and 'probepart' scripts -- well, I modified the probepart script too. So, could you try them and see if they detect the missing camera drive -- just open a terminal window and type 'probedisk' at the prompt, then 'probepart'. If the camera is shown, post result here and I'll check the pmount script.

Sage, I have new PET package for Opera, used to build the 'exp' releases. If a Puppy 2.16 is released without Opera, the Opera PET package should install and work fine just like it did in exp2. I'm thinking for 2.16 I'll go back to the old concept of three releases, a BareBones, Standard and Chubby. I'll aim for the BareBones to be under 50MB.

Thanks for those really helpful comments and considerations, Barry - much appreciated. Do I detect a strong(?) movement towards Opera amongst Puppy punters?

I used Opera as well as SeaMonkey and found strengths as well as weaknesses (from a purely personal outlook based on the way I set up my systems).
The main problem I had with Opera was in its Mail Handling - which since I store my preferences externally on a fat32 drive for accessibility - is a big impact for me. Opera stores and indexes its mail by using multiple small files and folders. Now each of these will reserve the default AU which leads to a great deal of fragmentation and unusable space. On a 2GB usb drive under very low mail usage this teasted at over 350MB over 2 weeks.
I also found Opera to be slower than SeaMonkey although I distrust speed comparisons on browsers.

Now if the "profiles", cache and mail were contained within the ext file system rather than the fat this might well not be an issue - but woould alos mean that I could not access those items on other systems - which makes htem less portable fo me.

I think what this highhlights for me is that browser preference and use is so individual an item that I feel that the one included in a core should be as basic and as minimal as possible - like Dillo, and that the "heavy duty" ones should be pulled in seperately either as sfs or as pups or pets. I think that the same applies to media and office and game components - which is "barebones" versions appeal to me so much.

I do not think that any particular browser or mediacenter or office suite is better than any other, I think that they can be "better" for an individual based on many different factors. The beauty of Puppy to me is the ease and efficiency with which it can be tailored to meet individual need.


Henry (books<at>henrystrobel.com) 
Good morning, Barry,
Typing probedisk into rxvt I get:
/usr/lib/mut/guess_filetype: no such file or directory
/dev/sda|Direct-Access|JetFlash TS2G3FV30 8.07
/dev/sdb|Direct-Access|Generic STORAGE DEVICE 9335

Typing in probepart I get:
/usr/lib/mut/guess_filetype: no such file or directory

I abbreviated the above, as you can see, (sorry, I haven't learned how to copy out of rxvt ;-) The camera memory is the Generic STORAGE DEVICE.

I found probedisk, probedisk_OLD, probepart, probepart_OLD, but they did not execute.


Two brief points for Barry:
At least subjectively, exptl 3 seems a lot faster?
Your statement of interest will be very helpful to a lot of your followers. Some of us are political animals, others not. Chacun a son gout. When I am King, I will recommend you for a peerage....

As for Opera, it needs tuning - it IS smaller and it IS faster. Although registered for Operamail, I rarely use it and generally load Sylpheed. OOoo I can do without in any form. For scientific work, TeX is unrivalled; to blog my MP with some kind of abuse, Abiword suffices.
As for use of liveCD, it is a good deal less convenient with a static IP, although I recognise that a static address is better overall. Even Klaus now expects a substantial number to install his offerings as an easy way to Debian.

Keep up the good work Barry, thanks and enjoy your travels - roos or deer, I am envious.....

How does the compressed ext2 affect the "resize pfile" option?
Is the compressed ext2 like a squashfs file, or are the files just compressed inside a normal ext2 fs?

I use frugal install on vfat32 partition. I had to move the initrd.gz file from c:\boot to c:\ directory to boot successfully, just like at Puppy 2.16e2.
Puppy 2.16e3 successfully saved my settings to pup_save.2fs file and mounted it at reboot.
A series of error messages scrolled by at first boot.
Puppy 2.16e3 is significantly slower than 2.16e2 on my Intel P4 1.7 GHz with 512 MB RAM.
This is the most unstable Puppy I ever tried. Programs suddenly stop responding and then I must push the reset button on my computer to reboot.
I really miss spellchecker in Writer.
Anyway, this Puppy is an interesting experiment.

Henry, '/usr/lib/mut/bin/guess_fstype' should be there, it's weird that it isn't. Somehow a whiteout file must be hiding it, but I have no idea how that could occur.
It's easy to copy to clipboard from rxvt, just drag the mouse pointer over text to highlight it, when you release the left button the text will be in the clipboard.

Leon, yes, my own experience so far is that ext2 compression works okay booting from usb flash drive, not for live-cd, and in your case frugal install on hd -- both cases have the pup_save mounted directly. Further communications with Terry lead me to believe e3compr is too fussy. In the case of usb flash, access to the pup_save is more constrained, as the working layer is in ram. It booted up and shutdown without complaint for usb flash.

I think that I will put the squashfs-lzma and e2compr patched kernels into Puppy Unleashed, for those who would like to create specialised Puppies. The rc.shutdown script can test that the kernel supports e2compr (it gets reported at bootup by the kernel) and offer it as a choice, suggesting only works for usb flash.

Yes, I haven't fixed that /boot/initrd.gz problem yet.

Squashfs-lzma, yes, slower. Oh well.

Dougal, resize should work. The files are compressed, inside a normal ext2 f.s., but actually the f.s. isn't quite normal as it isn't readable by normal ext2 tools and kernel after a file has been compressed. So, the resize tool provided with the patched e2fsprogs will work, probably not the normal one.

Chubby Puppy looks promising. I hope it can get the latest version of OOo by the time it is released.

All the best. 8-)

Glad to hear that you're having fun, Barry. I sometimes think that developing software and hunting out bugs in computers may have a parallel in the deerstalking world, but at least the computer is inside a warm dry house. At any rate it’s at its best when it’s fun, exhilarating, and fulfilling. How you manage to come up with such a lot of lateral thinking on different ways of running Linux I have no idea, but long may it last.
It may be prudent to limit your comments about your holidays if you don't want visits from thieves. But perhaps you've got a Dobermann to look after the house while the Puppy is away!

Thanks, Barry,

I installed MUT and it seems to detect and handle all the drives.

I'm very impressed with how well everything works. OO loads quickly, very quickly after it's run once.

(Here's a better copy of what I sent earlier just in case I mistyped something.)
sh-3.00# probedisk
/dev/hda|disk|WDC WD1600JB-00REA0
/dev/hdc|cdrom|Memorex 52MAXX 3252AJ1
/dev/hdd|cdrom|Memorex 16X-DDL-IN
/dev/sda|Direct-Access|JetFlash TS2GJFV30 8.07
/dev/sdb|Direct-Access|Generic STORAGE DEVICE 9335
sh-3.00# probepart


Oops - I just noticed that _is_ different. Could installing MUT have something to do with that?


Well, I guess it did, since Pmount is now also working! Sorry about the fragmentary nature of these messages,


the error messages are displayed only at first boot after pup_save.2fs was created. After that there was no problem with boot and shutdown, except when Seamonkey or OOo Writer stops responding during work. In this case the shutdown process doesn't end properly.
I also unsuccessfully tried to copy my desktop background jpg file from another pup_save.2fs or from a Windows directory on vfat32 partition to /usr/share/backgrounds. The file has 221K and the copy in pup_save.2fs has only 12K.
From my experience e3compr isn't reliable.

Don't mean to make a pest of myself, Barry, but thought that it was interesting that I have now uninstalled MUT, but Pmount continues to work. Pkgtool, which got installed along with MUT, is still there. Hmm?


Barry, you just need to make sure you have the updated "resize2fs" binary in the initrd...

G'day. I just posted a response but forgot to save what I wrote... the thread spat the dummy and I have to start over. Oh well.

Just been playing with the 216exp3 CD and it ran like a beaut - just a couple of points/questions if I may.

I heard about the encryption of the pup_save file during the 215ce testing and it looks a great idea. Is is possible to change from any chosen level to another, once it is set? i.e. to go from max encrytption to non encrypted, or from non encrypted to patial encryption, for example?

I can see that could be useful, in the same way as being able to enlarge the pup_save file size as more "stuff" is added to it.

I also like the changes to the start-up menu.

Couple of points which transferred from the 2.15ce developement and I noticed them in this pre-release.

Gxine exhibits a huge amount of video "noise" in the upper part of the window when playing a DVD. This disappears when you go to full frame. This was discussed extensively on the 215ce project.

As also was the Gaim account creation problem which was solved by providing Gaim2 because (from memory) the dependencies didn't support the previous version of Gaim.

And the other was the locale window snapping closed on an earlier version of 215ce, which was fixed by a patch. I never applied the patch as the following rc had the patch already in it, and it worked.

Best regards, good job there Barry,

Richard in Adelaide

Henry, you seem to be using a version of 'probepart' that you have download from the Internet, not the latest in 2.16exp3. Your probepart has an incorrect last line, a fault that my version fixed (or should have fixed). You can copy the correct version to the top from the "pup_216" layer: copy /initrd/pup_ro2/sbin/probepart up to /sbin/probepart.
Your problems are arising as you are using a pre-existing 'pup_save' file, which is unwise for testing the experimental versions.

Dougal, the init script uses your original idea of executing the e2fsprogs utilities from the main filesystem, and the build of Puppy has the patched e2fsprogs, so it is ok.
Regarding PMEDIA, I think it is useful for scripts to know the broad category of media that was booted from -- I found that very useful in something I was coding recently. However, it is increasingly becoming unecessary to specify 'pmedia=' boot parameter as I'm adding more intelligence in the init script that guesses what it is -- not quite perfect yet. So, you can eventually leave off the PMEDIA parameter entirely.

Barry, you wrote:

"Henry, you seem to be using a version of 'probepart' that you have download from the Internet, not the latest in 2.16exp3. Your probepart has an incorrect last line, a fault that my version fixed (or should have fixed). You can copy the correct version to the top from the "pup_216" layer: copy /initrd/pup_ro2/sbin/probepart up to /sbin/probepart.
Your problems are arising as you are using a pre-existing 'pup_save' file, which is unwise for testing the experimental versions."

I compared the two probeparts with Tkdiff and they are identical, by Jason Pline with your mods. No need to copy. I am unaware of downloading any.

I do not have any problems at all (now)that I know of. It's a beautiful program. True, I stumbled into using it without compression by using my existing 'pup_save' file. How unwise that is depends on one's goal - certainly no danger to my securely backed up data. I was just reporting the (to me) interesting observation that Pmount did not work until after I installed MUT using PSI, and then continued to work after ininstalling MUT. Did I unwittingly thereby download a different probepart?

Sorry if I'm gumming up the works here.


Henry, no, you're not gumming up th works, your feedback is helpful. It is is this line in your test of probepart that is the problem:
I got that in plinej's version, as I found the script did not handle extended partitions properly. I fixed that and the problem went away on my computer. So I don't know why you are getting that line. The line is invalid as there is no partition after the '/dev/'. However Pmount will reject that line as it has 'none' for the filesystem type so it doesn't affect Pmount. Even so, it is not good to have there as it may affect other scripts that use probepart.

Here's an interesting development with exptl 3 full install. It has begun to stall at 'keyboard detection' after a couple of days use and a swap to another board and cpu, but not keyboard. Ctl-C sends it on its way again, but I get 'Error saving /root/config/rox.sourceforge.net/ROX-Filer/Options. Permission denied.
'OK', completes the boot up! Not sure whether this is of interest?

...and I'm having to re-enter my (static) IP & Gateway addresses each boot, but, curiously, not DNS. I think others have commented on this strange behaviour which hasn't occurred with any previous installation version.

[b]Houston, we (may) have a problem[/b]

I believe the encrypted pup_save file may be responsible for persistent corrupted desktop backgrounds when new ones are added. This happens during or after the first rebooting or shutting down and subsequent estarting.

This happens every time, even with a new pup_save file created. It's okay until after the initial save when starting with pfix=ram.

I'm looking for somewhere I can discuss this in detail, if anyone could advise which forum and section I should use. I don't see an appropriate one.

I've taken a bunch of screencaps to show what I mean.

Also, several times it has also told me the taskbar size can't be changed due to corruption too, although I haven't a screen cap of that.

Richard in Adelaide

I am having some major problems with this relaease in the HW I use.
I can get the pup to save the first time but on the next reboot on either the Emachine or the Lenovo it crashes
Its done this multiple times nopw in various usb / cf / hd configurations and I am at a loss on how to proceded

exp2 works beatifully on all of them so I am going to stick with that as I dont really see any advantage to me in the exp3


Barry, you wrote,

"Yes, Squashfs-Lzma and e2compr (ext2 compression) are being sidelined for now. They won't be in 2.16 alpha, which is what I plan to release next."

This is reassuring. I am not competent to comment technically, but I have been using 21.6e2 and e3 (without compression) and they seem to be very robust and fast.

As a user - not a developer - I think the time is approaching that Puppy can become not only an amazing Linux but an eminently usable, and widely used one. It needs the thoroughness, unifying vision, and technical discipline that you, and your careful and inspired collaborators (they know who they are) can bring.It already has the nucleus of speed, efficiency, elegance, and adaptability which is why it attracts people like me.(I was not always a violin maker, but a chief engineer at Digital Telephone Systems long ago. Elegance and efficiency were the watchwords. The Autralian PO used our pbx's. I visited them in Melbourne. I digress.)

Puppy has made wide strides with the greatly improved menu and package handling. In some respects it "just works," in others it sure doesn't. Multimedia is by nature a mess, but Puppy needs to have at least one program that will predictably work in all versions. Not for serious me but for other people. It's a necessary evil. Don't get me started on that.

Certain simplifying choices have to be made, and you've been very good at that. I have been a fan and user of Opera since day one, but your choice of the Seamonkey suite is very efficient. For a business like mine good email, email archives and encryption (gnupg) are required, and Seamonkey is one of the few that allows seamless migration from Eudora. Optional add-on packages (as Opera) are desirable too, and the ability to choose from, say, Slackware packages, as you are developing, is very attractive, not reinventing the wheel for existing applications. The other level of large "sfs" add-ons is also key, allowing us to have a small, basic, nimble Linux that can be conveniently extended for different situations. But these things have to be honed to fit smoothly together. Taking a walk through the forums we see how few things really reliably fit.

I envision Puppy as something that works for regular people, that affordably empowers them. Yes, choices have to be made, and they are being made. As a practical matter, wine cannot be relied on, and so we are short of certain applications. Printing is getting there - will scanning ever? These are not problems peculiar to Puppy, nor does Puppy have to be all for all. But what Puppy does it should do right, especially for regular people, of whom there are a lot. Flaky, incomplete releases propagate Puppy's image as one for tinkerers. (Well, it is, and that's great, but not _only_ for tinkerers.) OK, Barry, this is your stated "hobby," so pay no attention to me ;-) But I think it's a plus if your hobby improves the world, too.

Years ago, when I first started dabbling with Linux distros I was struck by the absence of help files. Often they had never been written, or had been left out to save space. Made it look like second class software. Sure, ideally they shouldn't be needed. Puppy is better than most, but nowadays a well coordinated online help system seems to be the answer. In the notorious case of the Gimp it seems to be the only one - well perhaps not well coordinated. These are not Puppy's problems - I am just rambling.


Looking at what I wrote last night, let me add some remarks to help deflect possible flames -

1. Puppy is unique and wildly growing, with the fertile disorder of enthusiasm and inspiration that goes with that.
2. The Puppy community is peerless in spirit, cooperation, and helpfulness to the clueless. (I have often experienced this. ;-)
3. Puppy's online help is extensive and improving. Witness the Wiki. Thanks!


Marty (subitopiano<at>verizon.net) 
Loving Puppy!!! http://www.puppylinux.com/news/interface/e The latest releases have allowed me to get my wireless units online with Linux. Most recently i've been enjoying employing it to recue older pc's. My daughter, a nursing student, considered buying a Mac for its stability. I was happy to put a PII 350Mhz unit back together for her--with 128MB of RAM using a full install of the latest version and many add-ons. She has a winner and it cost her NO money! The time it took me was well-spent--a great learning opportunity. Hats off!

I went with the very fast ABIword on her computer, but one thing i personally use a LOT is OpenOffice. I am VERY glad to see a new cutdown 2.2 "Chubby" in the works!! OO (like Puppy) is a bit of a "swiss-army knife" application and having it already built into the release means i know it's going to be as lightweight as possible. IMHO i like putting the spell-check feature in. It may add to the size, but anyone downloading a Chubby version is already expecting that. However, if it really does slow things down, i will be happy with a pupget/dotpup for the spell-check function. I take pride in my spelling (i have to -- i'm a teacher!) and consistently double-check my work with my eyes AND by hitting F7.

Oh, the CE utilizes the Windows start menu button. What does eveyone think of making that standard? Yeah, i know i can customize the keyboard but for many of us that's rather a pain in the neck...

Anyway, like someone else said, Puppy just keeps getting better! Thank you so much for your "hobby" that you work so hard at and that blesses so many others.

Definitely some odd issues with exptl 3. The stalling at keyboard detection, strange messages about ROX and the disappearing static address are proving reproducible across several different system. Now getting some error message about 'missing mouse', but it isn't and it is always present and working (PS/2, that is). Fun, though!
re. the Opera issue - I'd like to have it instead of Seamonkey, not least because there isn't room for both on some of the old bangers of HDs I'm resurrecting!

'puppylinux' at ibiblio.org back online 

As was announced in the previous post, the hard drive array hosting Linux distros crashed at ibiblio.org.

They fixed the hardware, but I needed broadband2 access to upload everything again (over a gigabyte). So I fast-tracked it, drove to my relative's place overnight, a lovely country drive leaving 10pm arriving 2.30am -- it took a bit longer than usual as I have to be very careful of kangaroos at night. Topped-up the tank at a country station that stays open to midnight, an iced-coffee, and I was right -- quite pleasant actually.
Anyway, by 3.00am I was uploading, and it's all back up now.

P.S., I drool everytime I come here and use broadband2 access (adsl2). Almost makes me want to move somewhere that's got it....

Um, now that I've mentioned moving... I'm heading up to Tom Price later this month -- that's a mining town in the north of Western Australia. I hope my car stands up to it -- two days solid driving to get there. A bit over a week staying with a relative who's making big bucks, then back to Perenjori, then Perth, then down to Yallingup and Denmark in the extreme south of the State, back home about the end of May.
I'll probably have my laptop with me and will keep working on Puppy, but Internet access will be patchy.

Eric Mulcaster (ericmulcaster<at>gmail.com) 
have a good time mate..from Canada and caneri

It must be cool there and traveling will be good. Enjoy. :)

Enjoy your break ;-)


John Doe 
> have to be very careful of kangaroos at night

That made me smile. We have to watch out for deer here in Michigan.

Not sure if it's international but the phrase, "like a deer caught/trapped/stuck in the headlights" is sometimes used as an analogy to describe the behaviour of how they just look at the car (impending doom) as you plow them over.

Have fun traveling. Maybe someday we can get you a motorized, phased-array satellite antenna so you can be online while you drive:

I think download would work constantly but upload might be shaky or limited unless you were stationary.

( a lovely country drive leaving 10pm arriving 2.30am )
Just round the corner really

(it took a bit longer than usual as I have to be very careful of kangaroos at night.)
Horrible thing to happen..nearly 35 years ago we hit one out the back of Dubbo...travelly only 30mph.. thank goodness I'd handed over the driving 20 minutes beforehand

P.S., I drool everytime I come here and use broadband2 access (adsl2). Almost makes me want to move somewhere that's got it..

( Yeah..high speed ADSL and high speed other probs )

( then back to Perenjori, then Perth, then down to Yallingup and Denmark in the extreme south of the State,)

Denmark used to have a fantastic museum 35 years ago but in a red brick house. Western Australia...drive..drive ..Bl...y drive..and that 's why we put that car on the train from Kalgoolie to Adelaide.

Cheers and safe uneventful driving...Chris

Michael (mgorey<at>gmail.com) 
We've got broadband in Kalgoorlie, you should move here :-)

Justin (justinrenoATjustinreno.tk) 
Have a good time.

There should be good broadband in Geraldton by now - maybe that might be closer to move to - but then again it be one of the most windiest towns that I've ever visited - and I used to visit a lot when I lived in Dongara..

Mind you where one lives is generally a 'lifestyle' decision :

Geraldton = mini, mini Perth = lot more people, lot more traffic, lot more noise, lot more pollution, higher crime rate, etc ..

Perenjori = smaller number of people = more friendlier, less noise, clean country air, almost no crime, etc..

And yes - broadband2 is much, much faster- but untill Australian telco carriers get their acts together - we country (and back of the boondocks) people will - as far as they are concerned - be in the "we'll do them when we feel there is enough demand to make money" basket before they even look at making the higher speed broadband available to us..

Anyway safe driving..


This News Blog is acting up, so is my Developer Forum.
Then there's a post on the main forum that puppylinux has disappeared from ibiblio... Ibiblio has posted this message:

   Hello everyone,

The storage array holding most of our Linux distributions crashed hard.
Rather than spend over $600 to resurrect 5 year-old hardware that is out
of warranty and was beginning to show signs of failing prior to last
night, we will be speeding up our migration of the distributions onto our
new Netapp disks.

This means much more space on much more stable hardware, but it will
mean waiting until we hear back on a few small technical questions before
we can create the volume and populate it with data.

We sincerely apologize for this outage, and hope to have the volume
accessible again by tomorrow.

Not sure whether all this ibilblio stuff is responsible, but the 'unionfs' bug is NOT solved for full HD installation.
Last night, I tried to re-d/l exptl 2 - it crashed at 99% after two hours on a normally fast-ish connection. It came down this morning OK, but 'unionfs' still shows as the default location for GRUB and the tray opening and closing feature is back. If I accept 'unionfs' (press <ENTER>), it loops. If I type in /dev/hda1, it pretends to complete, but I still get Error2 again upon rebooting? Will try it on another HD in case it's disc related, but the unexpected appearance of 'unionfs' would not be influenced by that.

And your upload is exceptionally slow, too, as reported.

OK - the GRUB Error is a disc feature. What do you want tested?

I think ibiblio may be waiting on you, Barry. I found this in http://distro.ibiblio.org/pub/linux/dis:

[blockquote] Our RAID controller freaked out!
We're bringing our distributions back online.

We lost nearly 150 distributions when the array storing
them died on the evening of April 9th. If you own a
distribution on ibiblio.org, please visit
http://www.ibiblio.org/help to request that your directory
be recreated. If you have uploaded ISOs to be filed
by our Linux keeper, please do so again. Sorry.

ibiblio admins
April 12, 2007[/blockquote]

There is an empty puppy directory there though.... (?) Well, I'm sure you're glad that you're not on dialup anymore! Hopefully, they can restore from backup though.

Sage, the 'unionfs' GRUB fix was announced after exp2 was released, so it will be in exp3.

This is the reply I got from Netfirms:
[blockquote]Hello Barry,

Thank you for your email.

From your description it looks like it's a scripting issue with PHP. We suggest you
look your script and find out the problem. Alternately you can contact a web
designer or web developer who might be able to help you with your problem.

Considering that both scripts (blog and forum) are totally separate products and have been working fine for several months, and I haven't made any changes to the setup (all this I explained to them), the above response seems somewhat pathetic.

Sometime ago, back when I was new to Netfirms, I setup a wiki that used a mySql database, but it regularly got corrupted and I had to repair it, which annoyed me very much, so I am now using scripts that have their own flat-file database systems. That situation has been fine for several months.

Regarding ibiblio, I have sent a message asking if they have a backup, also told them that our directory is 'puppylinux', not 'puppy'.

So, the status for ibiblio is that I'm waiting on them to create a directory 'puppylinux'. It does seem that I will have to upload everything, but won't be able to do that for another 36 hours approx., as my satellite upload speed is only 64K, plus a limited monthly bandwidth that will cause it to drop to 33K. On Sunday evening I will be at my sister's place and she has broadband2 (adsl2).


Couldn't other folks upload for you? If someone has a download of a particular version, couldn't they just ftp it to ibiblio? Or is it that ibiblio don't want to make it that widely accessible for security reasons?

I'm just thinking that 10 people uploading 10 times faster than you can will save you a lot of bandwidth from your monthly allowance....

There's a gigabyte or so of stuff to upload, not just the iso's, also all the pupgets and pets, and various sfs's. I've got it all together in one spot, so it's easiest for me to do ...not long to wait.

Sorry for the OT:

Dear Barry,

Do you plan to support ISA cards again in puppy 2.16 or forward?
Cannot use my 3c509 NIC with puppy 2.14 :(
Wally (Argentina)

Small bugfix for frugal install, etc. 

I'm continuing to work on 2.16, currently testing installation to USB Flash and "frugal" install to IDE HD.
For any installation other than booting from CD, Puppy is only supposed to look for 'pup_save' file(s) in the same partition as booting from, to avoid conflict with other installations of Puppy. This was not working right, now fixed.
I've tested the USB Flash and frugal HD installs and they are working fine.

As I mentioned in an earlier post, expect 2.16exp3 on Sunday night (here in Australia!). I've got a bit of a surprise for exp3.

I have been processing CD orders, sending two CDs for the price of one. We are not yet organised with an Unleashed CD for 2.15CE, so I'm currently shipping 2.14 Unleashed plus another CD with the 2.15CE iso and all the SFS files -- which fills the second CD.
I'm thinking that I might jump straight to a prerelease 2.16 Unleashed CD soon, as it's looking good.

If you experience any problems using this News Blog or my Developer Forum, something seems to have gone wrong all of a sudden to both of them, a day or two ago. I login, get a blank page, even though the login was successful. In the Developer Forum, I login okay, but when I click the "New posts" button just get a blank page. The fact that it has happened to both scripts (PHP) at the same time indicates that Netfirms (my host) has changed something. These scripts use their own filing system (no mySql) so that one is ruled out. Server change? PHP setup change? I will send a bug report today (again -- my site goes wrong every few months, but they do fix it -- they seem to be always upgrading and changing stuff).

Barry Kauler 
Correction, as Dougal reported, when click the "New posts" button in the Developer Forum, get this:
[code]Parse error: parse error, unexpected $ in /mnt/w0703/d10/s01/b0275d0c/www/forum/data/bd_1.php on line 7[/code]
Ive reported these problems to Netfirms.

Barry Kauler 
Hmmm, when I posted the aove comment, got a "500 Internal Server Error", but I reloaded this page and found the post had gone through. Hope this one does too.

Given that PHP has bugs bursting out its seams it's probably good to hear that your forum host is constantly applying upgrades. See [url]http://portal.spidynamics.com/blogs/jeff/archive/2007/03/19/Month-of-PHP-Bugs_3A00_-Mid_2D00_month-analysis.aspx[/url] for interesting reading.

Continuing the discussion with gdcrane in yesterday's blog, about choice of 'pup_save' file at bootup for usb and frugal hd installations.
Okay, I've implemented a fix that should satisfy everybody. If you install Puppy to usb drive or frugal hd, at bootup the Pup will look wider than just the boot partition for pup_save files. If one (or more) found on the boot partition it will be used (or choice offered if more than one). If none on the boot partition, then choice will be offered to load any others found, but a warning message is displayed that these may not be appropriate and recommend type '0' to load nothing.

gdcrane (vern72023<at>bellsouth.net) 
Good on you, Barry - it was a nice "bug" and it makes the way I play in my sandbox a lot easier - but if you feel or get feedback that it is ,or could be , confusing to others - then please dont hesitate to get rid of it. I can code round it myself now I have looked at it.

I am looking forward to exp3 on sunday as the exp2 is working so well.


exp2 has been the best. Bring on exp3!


Small bugfixes, improvements 

I mentioned some little bugfixes/improvements in the 2.16exp2 comments thread a couple of days ago. Here's some more.

There was a bug when using the Universal Installer to do a full hd install. In 'grubconfig' script there was a dialog box that displayed "unionfs" when it should have displayed the partition to which GRUB is to be installed. Fixed. Other than that, my test install to hd went fine.

Running from a full hd installation, Pmount showed that partition mounted on '/' as a green button, whereas it should be greyed-out (disabled) as that partition cannot be dismounted. Fixed.

Puppy enthusiast lvds (forum name, real name Laurent) has made some nice little improvements to a couple of scripts:

The firewall-generator script wizard (see Setup menu) now has an "Automagic" selection that creates the firewall, absolutely no further questions asked.

The Internet Connection Wizard (see 'connect' icon on desktop) now displays current IP status. There is a box in the window where I had intended various status/config information to display, but didn't get around to putting anything into it. Laurent has now put some useful info in it.

'zepperdude', you registered at my Developer Forum, but the password was sent to your hotmail.com account, which rejected it as spam.

Wasn't going to test exptl 2, but decided to give it a whirl. Strictly from a users viewpoint, retrograde step to revert to the accurse`d Seamonkey as default. Couldn't fathom how to use the separate .sfs file, ie where/how/locate and call it, etc. Otherwise, can't see the joins - perhaps this is a mark of competent coding? Who am I to judge.

gdcrane (vern72023<at>bellsouth.net) 
Running from cf card and usb flash drive I really like what you have done her Barry.
Normally the first thing I do woth the distro is to modify the pup_xxx sfs file by removing the browser and xorg and adding my own customizations to create a new pup_xxx.sfs. In this case I decided just to remove SeaMonkey and Xorg and to create a seperate sfs file for my own custom programs.
This is working very smoothly.
One thing that is working extremely well for me now is the ability to choose what I make my "HOME" during the boot process - for whatever reason prior to this version I would have to physically manipulate the flash drives in order to do this but now I see all of my choices .
0 - no pup=save
1 pup_save.215.sfs on hda1
2 pup_save.215.sfs on sda1
3 pup_save.215.sfs on sdb1
4 pup_save.214.sfs on sdb1
5 pup_save.test.sfs on sdb1

since I use the usb external HD shown as sdb as my playground for testing this is a great improvement for me.

My personal sfs includes my icewm customizations, wine 931 with added libc, and the games and media programs I like. I run seamonkey 1.1.1 out of wine as a browser and keep all my wine and browser config under a "profiles" folder in fat32 on the usb drive since this gives me cross platform capabilities which I prefer.

After a week running this experimental version as my main OS i have found it very stable and very fast.

as always Great Job

Well, I d/l it this morning and got the 'unionfs' bug during full install. I changed this to /dev/hda1 but got Error 2 at reboot. What next?

I just got this message after pressing the "new posts" button on the developer forum:
Parse error: parse error, unexpected $ in /mnt/w0703/d10/s01/b0275d0c/www/forum/data/bd_1.php on line 7

Barry Kauler 
Dougal, gdcrane, see the latest post.

gdcrane, oh no, that was actually a bug!

Barry Kauler 
Hmmm, I'm wondering if I can work out some compromise that would satisfy you. I don't know if your requirement is a common one though, as most people would expect their pup_save to only be on the usb media.
I could have it so that Puppy checks to see if there is a pup_save on the usb boot media, if so will use that automatically. If not, will offer choice of any other pup_saves found ...although this does worry me a bit, thinking of the less sophisticated user accidentally loading the wrong one -- like perhaps the one they use for their live-CD -- it may cause problems mixing them, and confusion.

perhaps the only really satisfactory way to do it would be a boot parameter telling Puppy to cast the net wide when looking for pup_saves, not just the boot media.

Why have a boot parameter for looking everywhere... I re-wrote the file-searching code a couple of months ago and I hardly pay attention to PMEDIA -- I think you put too much emphasis on it.

If you do want a boot param, you can just make it "PMEDIA=none", which will go to the "*" part of the PMEDIA case structure, where everything should be searched.

New probedisk, probepart 

probedisk, probepart, along with test-eide, test-scsi and test-cfdisk, are utilities developed by Antonio Gallo and found in the 'libhardware-20060723' Unleashed package.

A great deal of discussion has been going on about incorrect USB information returned by probepart, and plinej (Jason) has written replacement scripts for both probedisk and probepart. The discussion and scripts are to be found at this URL:

Please go toward the end of the thread for the latest scripts.

I have put these into Puppy, but kept Antonio's utilities, renamed as 'probedisk-OLD' and 'probepart-OLD'. Note also, the initial ramdisk still has Antonio's utilities.

WSCarl (windowsystemcomputers<at>yahoo.com) 
SATA DVDRW to replace ATA DVDRW by year end! Price point change by June current sata 18x DVDRW 38.99 w/sh and ATA 18x DVDRW 29.99, this shall be reversed with ATA costing more. New Mother boards have only one ATA connection are now on the market. Mother boards with out Par. port or PS/2 ports are one the market as well. Can Puppy run/install off a SATA DVDRW and USB I/O's?

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