logoPuppy developer news:

from 2.14 to 2.15ce

left-arrow Older news

arrow-rightLater news

Puppy Linux 2.15 Community Edition released 

The Puppy 2.15CE (Community Edition) is the result of collaboration of a team of Puppy enthusiasts. It is built upon version 2.14 but with many enhancements. In particular the guys have worked on an improved user-interface and nice out-of-the box first impression. They have also developed some "SFS" files that add OpenOffice, web and graphics applications -- SFS files are "combo packs" of applications that can be installed and uninstalled with a few clicks.

The release announcement is on the Community News page:

The file 'puppy-215CE-Final.iso' is 131MB and is available from our primary host ibiblio.org:
http://distro.ibiblio.org/pub/linux/dis ... uppylinux/
Ibiblio also has mirrors, that are often much faster, see links here:

Various Puppy enthusiasts are providing downloads. See the Forum thread here:

Note, if you are unable to download (perhaps being on dialup) and want to purchase a CD, I won't be processing orders for another 5-6 days as I am preparing a new CD (and having a bit of an Easter break!).

Barry - will your proposed 2.15CE CD also include all the relevant '.sfs' packages that can be used with the "Community Edition" ..?

If so - yes please for the purchase of a CD ..!!

Also - will there be a different price for the '2.15CE' CD vis the $AU9.00 for the 'Unleashed" CD's..?

PLUS - when do you expect to release the 'final' for v2.16..?

Just curious as if it is within the same timeframe as for the preparation of the '2.15CE' CD - then I would also be very interested in purchasing a copy of v2.16 Unleashed CD as well..- will help to keep the postage costs down if both CD's could be sent in the same postpak..!!

Good work being performed all around for our favourite linux distro..


Craftybytes, ha ha, I'm in Easter-holiday mode right now, haven't thought out all those details yet. Possibly some of the other guys, like Nathan, might be offering a CD with 2.15CE and SFS files, so stay tuned to Forum announcements.
2.16 ...don't know any release dates yet.

For folks in the UK, I would provide some 2.15CE CDs if asked...contact me via the main forum.

Barry - hope you are having a good Easter break ..? OK - will have to wait and see then what transpires - eh...!!

Enjoy your well earned break..

We already have some patches and updates for the just-released Puppy 2.15CE. See this forum thread:

I am not too sure how to use these notice boards, but sorry if I am in the wrong
place. I posted a question at " Beginners Help" - Puppy V2.15CE FINAL!, maybe someone can solve the problem for me regarding the detection of my onboard
e-net chipset. Tui. Is this a problem of software download or my finger trouble ?

This is truly a remarkable distribution. Thank you to all the participants that contributed to making Puppy 2.15 Community
Edition a reality.

Your time and efforts are greatly appreciated.

Puppy is amazing. . .


Nice edition but is there a problem saving to SATA drives on shutdown? My copy just hangs after it says it is Saving to SDA1, please wait. After half an hour it still hasn't shutdown and I have to manually close down my Notebook. When I re-boot it says the Puppy File System is corrupt. I then have to utilise Windows to delete the pup saved sfs file.

I have also found that I can no longer run my WiFi Network link, as it doesn't recognise my WEP Key, even though it is a good Key. My WiFi hub uses 64bit WEP. It will however run my Ethernet link, so I can still use the Internet, albeit via Ethernet Cable.



I resolved both problems by running Puppy 2.14 and then 2.15. File now saves to SATA drive and RutiL now recognises my WEP Key.

New look is much better than previous versions. Keep up the good work.

Donaldo Cuellar (udafmcd<at>gmail.com) 
;-)excellent version, Puppy rules!!!!!!!!

Trouble with 2.15CE, pupsave does not work right. The network driver would not load the proper driver (forcedeth) -2.14 loads it just fine. How do you install OpenOffice..sfs to an ide hard drive. Like the look and feel of the distro ...but there is work to do.

Puppy v2.16experimental2 for testing 

Available here:

THis is not a general release. Ihe 'experiment' uploads are for testing various new ideas. The main new feature since exp1 is the SFS boot management. The above link also has 'openoffice-2.2.0.sfs' which is designed to work with 2.16exp2.

Preferably test without any prior 'pup_save' file. If there is one, boot with 'pfix=clean' to force an upgrade. Not recommended to use with a 'pup_save' that you rely on for daily use.

The default is to load any suitable SFS files that are found at /mnt/home (same place as the 'pup_save' file). The BootManager, found in the System menu, enables you to change to whatever you want to load.
'openoffice-2.2.0.sfs' has /root/Choices/ROX-Filer/PuppyPin and globicons, also /etc/profile.d/openoffice.sh and these are enhancements that Puppy now recognises. The first two files specify desktop icons, and you should see these appear on the desktop when the SFS file loads, and if you choose not to load it then the icons should disappear.

I did some work on the frugal install to hard drive, but it still isn't right. Boots okay, but doesn't recognise a 'pup_save' file when booting. I'll get that fixed soon. So, frugal isn't suitable for testing the SFS Boot Manager. Works when boot from CD and USB though.

One pont if doing manual installing. Get rid of the 'root=/dev/ram0' if you have it as a boot parameter, as the ramdisk is no longer used. Another point: although I refer to it as 2.16 it is internally 2.15, so 'devx_215.sfs' will work.

Lobster (ed.jason<at>gmail.com) 
Should really be testing Viz but could not resist - like the stardust theme very much :)

Puppy 2.16e2 works well.

I use frugal install on vfat partition. I had to move the initrd.gz file from hda/boot to hda/. That was not necessary for Puppy prior to 2.14.

Puppy successfully saved my settings to pup_save.2fs file and mounted it at reboot.

I recommend to use 8 characters long sfs filenames to avoid problems when moving them from one directory to another on vfat by using batch files in Windows to manage more then one frugal install configurations .

The new sfs file BootManager and OpenOffice.org works well. That is really nice improvement.

I immediately change the new GTK theme to Default color theme.

What I'm still missing in Puppy is English spell checker for AbiWord and numlockx to have a choice to turn on Numlock key at X start as I suggested at Puppy Developer Forum.

My Puppy 2.16e2 hda/boot/menu.lst frugal install file:

default 0
timeout 0
title Puppy-p2.16e2
rootnoverify (hd0,0)
kernel (hd0,0)/boot/vmlinuz PMEDIA=idehd
initrd (hd0,0)/boot/initrd.gz

My old Puppy 2.14 hda/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

Wolf Pup 
Since the ram disk isn't used anymore, does WakePup2 need to be fixed?

Wolf Pup, yes, the reference to /dev/ram0 will also have to be removed from WakePup. Actually, I tested with WakePup and Puppy still booted, so perhaps that parameter just gets ignored if the kernel sees that initrd.gz is a cpio archive.
But, to do it properly, the param should be removed. Pakt probably has a later test version of WakePup2 so can incorporate this change as well.

Leon, I mulled over it, but I don't understand your comment that you have to move initrd.gz from /boot to /. If GRUB/LILO specifies it as in /boot, that should be it.

Ah, interesting that the 'pup_save' does work with your frugal install!

Regarding a full install to hd, the Universal Installer has a bug. The bug is in the 'grubconfig' script, which comes up with a dialog box saying that GRUB will be installed to 'unionfs', whereas it should come up with the partition that s being installed to, for example '/dev/hda7'. It can manually be changed in the dialog window, but I'll get it fixed soon.
Apart from that, Puppy did a full install and booted up fine.

A little bug in BootManager. It has a checkbox that has a text stringstating that it will cause all SFS files to load, which is the default. But, it only loads those with '_215' -- the correct version number -- in the name.


I use grub4dos 0.4.2 on Windows 98SE.

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:

After Puppy mounted openoffice-2.2.0.sfs file I renamed it to 8 character long filename ooo_220.sfs but BootManager reported:

Sorry, there are no SFS files in directory /mnt/home
You will need to download and place one there first.

Then I renamed it to ooo-220.sfs. BootManager found it and Puppy mounted if at reboot.

After reboot I noticed that my desktop background that I set before reboot changed to the default.

[/url]I'm sorry, I made a mistake by typing HTML tag for:


Ah, I understand both problems now.

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.

When the BootManager and init script see '_220' they think it refers to Puppy version number, and reject it. Change to something like 'oo-2.2.0.sfs'. ...that needs to be clarified in the BootManager.

seamonkey sucks ):

Notes posted here:


Sine Nomine 
Hi Barry,

Enjoy your Easter Break!

For "spam".

Use semonkey to go to mozillazine.org. Find links to FF3(Gran Paradiso Alpha3)

release notes.

Click on the link then download the *.tar.gz to my-documents.

When the download is complete, close seamonkey.

Open a terminal window, cd to my-applications

mkdir ff3

cd ff3 use pupunzip(?) to unzip the alpha into the ff3 directory.

cd firefox


Fishy (barrowjo<at>gmail.com) 
Downloaded > HD install > installed Opera 9.1 > working beautifully.
Now to figure out how to install the OO.sfs. Please advise if anyone has the time. I do note that Barry mentioned grub wanting to save to unionfs as mine did the same.

Living life on the edge as I am not a programmer but really good at formatting partions and starting again.

Followed instructions - downloaded openoffice-2.2.0.sfs and moved it to / (where puppy had automatically put the pup_save file). I renamed it ooo-220.sfs and used System > Boot manager to select it for inclusion with no result. I then made a /mnt/home directory and moved the pup_save.2fs , ooo-220.sfs and zdrv_215.sfs into it.

When I tried the boot manager after the above movement I got an xmessage box informing me that there were no .sfs files in /. I am a lttle confused. I accepted the basic structure during the install and am getting confused. Pup_save.2fs and zdrv_215.sfs are added to / not /mnt/home as some comments suggest they should be. Are the .sfs files supposed to be in /mnt/home or in /?

DennisF, I've made a note about that background image setting getting lost. Will see what I can do about that.

I'd like to try this one, but before I bother with the download, I wanted to make sure that there is some way to use the SFS files with a hard disk install.

So far, I've not seen that this is possible - I've certainly seen no docs on how to do it, although I presume there's some way to do it manually. If I understand this correctly, the boot manager still might not let me use and/or control SFS files if I'm booting from an installed hard disk image.

Any pointers to how to do this, if it's possible now?

Leon and DennisF reported some usability issues with BootManager.
I think that I have fixed the problem of the background image reverting to the original.
The checkbox in the BootManager has been renamed to explain exactly what it does, to avoid confusion.
The popup-help window has extra explanation, in particular explains not to name a SFS file with '_xxx' (where xxx is three numeric digits) as Puppy interpretes this as a Puppy-version number and will reject the file if the xxx is not the same as the current version of Puppy.

Note, I'm planning 2.16exp3 for this coming Sunday night, and there is a very big surprise ...I keep finding more bunnies in my magician's hat, and this time it is an Easter Bunny! ...well, to be released a bit after Easter, but it was inspired over Easter.

I'm not quite understanding what is going on with the sfs file management, but it occurs to me to ask, is the "How Puppy Works" page still accurate in 2.16? Also, is this enough of a change to be calling it 2.20 instead? Just a thought...

PaulBx1, exp3 is only an experiment. I have placed Squashfs-lzma and e2compr patched kernels in Unleashed so anyone can build and experiment with these spcial Puppies. However, the 2.16-final will most likely have the plain ordinary Squashfs and no ext2-compression. So, 2.16-final is the same as 2.14 (with input from 2.15ce) with incremental improvements, but architecturally the same.
I have emphasised that the 'experiment' in the name means that.

jade (katwoods96<at>aol.com) 
hey who wants to talk puppye :-)  

'ls' command with color 

I was scratching my head, why no colors when I type 'ls' in a termnal window? Color-coding of directories and special files was there before. I checked V2.14, same problem.

Then the light came on. I changed from Busybox ls to the full ls program, and the Busybox ls was configured to have color turned on by default. So, I have place this line into /etc/profile, which should fix it:
alias ls='ls --color'

Oh no, a trap for the unwary. It has to be this:
[code]alias ls='ls --color=auto'[/code]

It seems that Busbox ls works like the 'auto' option. That is, ansi color codes are only output when printing to a tty, not when ls is used in a script. Without 'auto', the '--color' defaults to '--color=always' which will break some scripts.

duh (w.hetschko<at>t-online.de) 
in rxvt nogo
in rxvt bash well done
kind regards

John Doe 
Does 'ls -d' work in the new version or still just give a period?

I'm looking forward to that working with fingers crossed.

Geany, Firelog updated 

These PET packages are now on ibiblio:


Our Puppy enthusiast NoobieDoobieDo has now got a home page for Firelog:
See also the Forum thread:

Barry, I noticed that some of the files now have NLS in their name such as: geany-0.10.2, geany_NLS-0.10.2 do we need to download both files or just one or the other and what does the NLS stand for ?

The _NLS files have international language support, if the package offers it. You only need it if you want something other than English.

Pmount "improved" 

Pmount, our drive-mounter alternative to MUT, has undergone an operation that presumably improves its appearance. There have been a few requests on the forum that it would be nice if the Pmount window did not disappear after a button is pressed. A little splash window comes up, informing that a hardware probe is in progress, then the Pmount window returns.

To achieve a constant window like in MUT would require a complete rewrite of Pmount, and probably not using Gtkdialog. Instead, I have retained the window after a button is pressed, and when the new window is ready to be drawn, the previous is deleted and the new one drawn immediately. What you see is a brief flicker, at least with a fast CPU ...maybe that is still going to be annoying.

Gee, I just looked at the clock, I started this at 6am and it's now 1pm. Well, I'll have lunch then forget about Puppy until this evening.

"too big" icons in JWM fixed 

Quite a few people have reported this problem in Puppy 2.14. If a package has a .desktop file which specifies an icon that is bigger than 16x16 pixels (the correct size for the sub-menus in JWM), then all othe icons get scaled up to the same size as the biggest icon.

Wihout going into lengthy explanation, to problem is the 'jwm-xdgmenu' utility. I modified the source of this and updated the Unleashed package, it is now 'xdg_puppy-0.7.6-3'. I also uploaded rarsa's source, with my small mod., to http://puptrix.org/sources/alphabetical/x/ which is the source repository for Puppy,courtesy of Ted Dog.

For the user, what this fix means is that the problem just goes away. It doesn't matter what size icon is specified in the .desktop file, it will get scaled down to 16x16.

Rarsa, if you read this, could you grab that and put the small mod into your svn repository... you will see my initial "BK" in the source where the mod is.

Will do.

FreeBasic, murgaLua, Glade 

These are all now PET packags, available from ibiblio.

FreeBasic is a compiler, and is in 'devx_216.sfs' (not yet released). Docs also, but it is recommended to read the docs at the home website.

murgaLua runtime interpreter 'murgaLua' is now in Puppy, and the GUI-builder 'fluid' is in the 'dev_216.sfs' file.

Glade is a GUI builder for GTK2 applications. This is now in 'devx_216.sfs'. Glade generates XML files that can be used by Gtkdialog3, GINS and FreeBasic, as well as C/C++ apps.

There is a need to create an up-to-date guide to rogramming in Puppy, with all these new tools to choose from. Well, in the meantime, here are some links (also read down this blog):

Gnocle/Tcl introduced here:

GINS introduced here:

MurgaLua introduced here:

Some discussion comparing Gnocl/Tcl, GINS, murgaLua, Gtkdialog here:

There is a helpfile at /usr/share/doc/gtkdialog.txt We are now using version 0.7.18 and the executable is 'gtkdialog3'
-- do NOT use 'gtkdialog' or 'gtkdialog2'.
If you have the 'devx_215.sfs' loaded, there are examples at
/usr/share/doc/gtkdialog/examples/ -- it is essential to study these to understand how to use gtkdialog -- please note though, the examples run 'gtkdialog' executable which you will have to change to 'gtkdialog3' -- temporary messyness only.


GINS with PuppyBasic:

Example app using GINS:

If you have the 'devx_216.sfs' module, it has Glade, otherwise, Glade is a PET package that can be downloaded from ibiblio.

Lobster (ed.jason<at>gmail.com) 
I am VERY glad to find the MurgaLua interpreter in Puppy. I would recommend a friendly scouring of DSL for any code we might share for 2.16. Lua is a very powerful front end to C and I wonder what caused this change of mind?

Is anyone up for maintaining (going through Barrys developer blog and adding updates) the 2.16 page?

Any thoughts on a codename for 2.16 - I favour Puppy "Love"?

Viz goes well, thanks to Warren and to those contributing code. I am using Viz + Open Office, Web and packages .sfs. It really is a pleasure to use and in future a window manager .sfs might be possible? A new programming sfs would also be a worthy project.

A new T2 has just been released incidentally.

One last comment before I forget, I am using the Firefox program adbocker in Seamonkey 1.8. How? Well I just installed on the offchance it would work and it does . . .

Maybe there are other firefox addon programs that will work with Seamonkey, in particular the newer version? Anyone available for testing?

Now that puppy has murgaLua, dvw86 has a really cool looking control panel:


Don't know how much is working, but sure looks nice!

Here is a Puppy Forum thread where we discuss GINS:

What came to light in that thread, posted by Billcnz, is another GTK2 binding that works with all languages:

Hey, does anybody else hate their laptop keyboard? I have to type vey carefully, else keypresses don't register -- when posting here I have to go back and fill in missing characters. ...see 'vey' above?
And I have to be very careful my hand doesn't go anywhere near the touchpad.
I've got an Acer Aspire 3681WXMI.


You probably need the Synaptics/Alps setup in Xorg. See:


My wife has an Acer Aspire 3690, it uses the synaptics touch pad.

The Tap to click function will drive you insane. Dougal added it to his xorgwizard modification a week or two ago.

No, I think the Aspire 3690 uses an Alps touchpad. Doesn't matter scroll down to last couple of posts on that link and download the synaptics-alps.pup.

User customisation of the desktop 

This has always been a problem. A user can customise the desktop, that is, move icons around, delete icons, add new icons. However at a version upgrade the customisation may be lost. The reason for that is the same as for the menu, the latest version of Puppy may have have different applications, so the previous desktop icons may not be relevant. For example, there may not be a HTML editor, when there was previously.

Then, as we have been discussing in recent reports in this Blog, if SFS files are loaded they may also want to have deskop icons. For example, 'openoffice.sfs' may have desktop icons for its wordprocessor, spreadsheet, etc. Then if Puppy is booted with an SFS file removed, the desktop must no longer display those icons.

I have implemented a generic solution for all of the above. I'm pre-announcing this as it is written but not yet tested. At a version upgrade or change in the SFS layers, the desktop is upgraded, retaining user customisations. If any icons overlap, they are shifted. Any icon that is no longer valid is deleted.

In the case of SFS files, they can have their desktop icons in /root/Choices/ROX-Filer/PuppyPin and /root/Choices/ROX-Filer/globicons. For the openoffice.sfs example, these files would only have the information for the OpenOffice icons, and the first bootup with this SFS layer enabled, Puppy will merge these icons withthe main PuppyPin and globicons files.
Actually, it doesn't matter if SFS files have duplicate entries (pointing to the same executable) as in the main PuppyPin, as duplicates are removed.

It won't be absolutely perfect. For example, you may have a custom icon that you created on the desktop. After a version upgrade or new SFS file loaded, your custom icon may get moved -- but, at least it is still there!

Well done Barry.
I've created scripts to generate the dsktop icons for a new version of Puppy because I often re-install and don't want to repeat all my work. But if the underlying desktop files or formats ever change my script wouldn't work, so I'm glad to hear of your solution.

Sounds great. Guess puplets may be a thing of the past, replaced by .sfs files. Any thought about raising the maximum number of sfs files that can be unioned? Or would it be too much of performance hit?

I think that we (puppy users) should 'take a step back' from wanting many, many, many '.sfs' files to be loaded at the same time - and 'take stock' - as to - "how" we as users - actually USE puppy on a day-to-day basis .. !!!

What I mean is - do we need to have 'multiple' .sfs files loaded - if we only use 4 or 5 "applications" at a time - the ability to load 'multi' .sfs files looks attractive - BUT - DO WE REALLY NEED TO ..??

I would suggest that instead we think about the possibility of - "REMASTERING" - .sfs files such that as users - WE - can make up our own .sfs files to suit our own 'usage' preferences - and still be inside the "limitations" of the unionfs system that puppy is built on ..!!

Currently the existing - 'unionfs / .sfs / initramfs / .2fs' - structure WORKS VERY WELL for Puppy - so if it works - WHY TRY AND FIX IT IF IT AIN'T BROKE ..??????

If we have 'remastering' for puppy - why not 'remastering' for .sfs files as well..?

Would simplify things I'd say..

Just my 2 c's worth..

It seems like the sfs system is evloving to a modular system for expansion.. good work Barry.

Maybe, if there ever is a PuppyPC on the market, the Puppy Foundation could distribute/sell these on a memory stick.. eg the Development-on-a-stick, OO-on-a-stick, etc, and when the stick is intserted, it is dynamically loaded. Kinda like an expansion cart for a console.. only cool.

anyhows.. good work Barry. The only thing I can see wrong with Puppy is integration (minor) and lack of shinyness (minor). But still... GOOD WORK!!!

it is possible to easily switch between multiple desktop configurations (icons, wallpaper) ... with one click

for example:

gxmessage -timeout 30 -center -buttons "_1,_2,_3,_4,Cancel" -default Cancel -bg lightgreen " Choose a desktop"

case $? in
exec rox -op /root/Choices/ROX-Filer/PuppyPin ;;
exec rox -op roxdemo1 ;;
exec rox -op roxdemo2 ;;
exec rox -op roxdemo3 ;;
*) exit ;;

this could allow you to have the standard Puppy desktop, and also to have the choice of one or more personalized desktops which Puppy should leave alone

I've been testing it, works well.

User additions to the desktop are retained, but deletions are a problem. It's okay if you delete an icon that you yourself had earlier created, but if you delete one of the "official" icons, that is one of those that were there originally, it will come back later at a version upgrade or when you change the SFS layers. I thought that I could keep a record of user-deletions and prevent them from returning, but then they would be blocked forever, and I didn't think that was good.

I think the most important thing is that you won't lose icons that you have created. If you delete official icons and then they come back later, well, that's just a bit of an annoyance only, and you can take a few minutes to delete them again and re-arrange the icons.

Menu updated when SFS files loaded 

Pakt posted a response to my earlier blog report on scanning for invalid whiteout-files when new SFS files are loaded. He asked about updating desktop icons.

Well, it started me thinking, and coding. I simplified the previous code, so that if Puppy boots up and finds the unionfs layers have changed, then a purge of whiteout files is done -- the logic of that is slightly simpler than before.
The current and previous unionfs layers are recorded in /etc/rc.d/BOOTCONFIG, and after the switch_root, /etc/rc.d/rc.update reads BOOTCONFIG and if it sees that the layers have changed then the master help page is regenerated and the menu is regenerated (by the fixmenus script).

So, if you bootup with a new SFS file loading, let's say 'kde.sfs', then the help page and menu will be correct.

Desktop icons though... not so easy. I'll leave that one for now. Perhaps it would be sufficient just to test if any are invalid and delete them -- if for example the 'kde.sfs' file is removed and some user-created desktop icons then become invalid. I could add that, unless someone has a briliant idea how to do it better.

Another thing, an SFS file might need to run some config script at every bootup, maybe to setup environment variables.

There is a directory, um, /etc/init.d (is that it?), in which scripts can be placed. Puppy can then run ll scripts that are found in that directory. This is a standard Linux thing, I think... anyone know the details on this?

Looking in Vector Linux, /etc/profile.d directory seems the right place.

/etc/init.d is usually reserved for services and daemons like httpd or ftp, or event things like gpm. I'm already using it that way in Grafpup. It sounds to me like /etc/profile.d might be better.

I have played around recently with adding/removing desktop icons and have thought of a way that icons can be added for sfs files -- the only question is whether it's worth the effort (maybe people will create more .sfs addons, now that you have the new options?).

Anyway, here it is, you decide:
If an sfs needs to add icons, it will contain a script for doing it, located in an agreed-on directory, say /etc/profile.d/pinboard. [I can make a template for it, I already have the code]

There will be a special script, say /usr/sbin/refresh-PuppyPin, that will
1) remove from the pinboard any "dead" icons (if a sfs is no longer used) [I've also got code for this]
2) run the scripts in the directory above

This file can be run **in the background** either in rc.local0 or in xinitrc, after the pinboard has been started (this is good if people want to add sfs files on-the-fly… maybe when we have Aufs?).

All this shouldn't be hard to implement, it's just a question of if there's a point in doing it…

Barry Kauler 
Okay, it's done. I lifted code straight out of /etc/profile in Vector and put this into /etc/profile in Puppy:
[code]#v2.16 this need arose when considering SFS files that may require special env. variables.
#this code is lifted straight from Vector...
# Append any additional sh scripts found in /etc/profile.d/:
for profile_script in /etc/profile.d/*.sh ; do
if [ -x $profile_script ]; then
. $profile_script
unset profile_script[/code]
This is inserted near the end of /etc/profile, after everything else is done.

Here is an example file from Vector, /etc/profile.d/seamonkey.sh:
if [ -d $PREFIX ] ; then
export PATH="$PATH:$PREFIX/bin"

The way that Unixes general work:

/etc/init.d (System V at al) contains scripts to start and stop services (cron, nfs, inet, etc) with /etc/rc.d/rc[0-6].d directories containing symbolic links to the services to be started or stopped when entering or leaving a given run level. So for run level 5 (multi-user with NFS) I would expect to see /etc/rc.d/rc3.d containing a symbolic link from say S40nfs to /etc/rc.d/init.d/nfs (with /etc/init.d and /etc/rc.d/init.d being linked together). The "S40" part of the symbolically linked filename indicates that this script is to be run to Start a process (when going to run level 5) and it is ordered such that it wll start after other ones prefixed S00-S39 and before any prefixed S41-S99. There are corresponding K00-K99 scripts for stopping (Killing) services when changing say from run level 5 down to run level 2.

/etc/profile.d contains scripts to be run when a user logs on. These scripts are executed in-line by the /etc/profile script itself,
for i in /etc/profile.d/*.sh
if [ -r "$i" ]
. $i
This is a suitable place to initialise variables for particular applications, eg by creating /etc/profile.d/vim.sh. It is also common to have a vim.csh in case the user is logging on with a csh in which case the script would be called from /etc/csh.login instead.

On AIX (IBM's Unix) there is a very nice feature in the /etc/environment file, which is read by every process as it starts. So if there are system-wide environment settings that need to be made this is a great facility. This feature is more relevant when a Unix machine is used as a server than a single-user workstation so it is less relevant for Puppy Linux.

In your case you may as well use /etc/profile because you have set Puppy up to log on after booting automatically, so /etc/profile gets executed at the end of the boot process.

[I see that you've just decided to go with the /etc/profile.d standard, which is good. It allows for easy and clear customisation to be added to Puppy without having to edit the base /etc/profile file. Thanks.]

Barry Kauler 
Pakt has made a start with loading desktop icons when a SFS file is loaded:

I am running with this ball now... I've added code to /etc/rc.d/rc.update that generalises this loading of extra desktop icons:
[code] #v2.16 if unionfs layers have changed, may need to fix menu (etc)...
if [ -d /initrd ];then #test it isn't full hd installation.
. /etc/rc.d/BOOTCONFIG
echo "Unionfs layers have changed since previous boot, fixing menu..."
#master help index has to be updated...
#Reconstruct configuration files for JWM, Fvwm95, IceWM...
#pakt suggested we can also add more desktop icons...
#create master files so original desktop icons can be restored. first, backup...
[ ! -f /root/Choices/ROX-Filer/PuppyPin0 ] && mv -f /root/Choices/ROX-Filer/PuppyPin /root/Choices/ROX-Filer/PuppyPin0
[ ! -f /root/Choices/ROX-Filer/globicons0 ] && mv -f /root/Choices/ROX-Filer/globicons /root/Choices/ROX-Filer/globicons0
#this is the awkward part...
cp -f /root/Choices/ROX-Filer/PuppyPin0 /root/Choices/ROX-Filer/PuppyPin
cp -f /root/Choices/ROX-Filer/globicons0 /root/Choices/ROX-Filer/globicons
for LAYERNUM in 3 4 5
if [ -f /initrd/pup_ro$LAYERNUM/root/Choices/ROX-Filer/PuppyPin ];then
grep -v -E 'pinboard>|<\?xml' /root/Choices/ROX-Filer/PuppyPin >/tmp/PuppyPinTmp
grep -v -E 'pinboard>|<\?xml' /initrd/pup_ro$LAYERNUM/root/Choices/ROX-Filer/PuppyPin >>/tmp/PuppyPinTmp
echo '<?xml version="1.0"?>' >/root/Choices/ROX-Filer/PuppyPin
echo '<pinboard>' >>/root/Choices/ROX-Filer/PuppyPin
sort -u /tmp/PuppyPinTmp >>/root/Choices/ROX-Filer/PuppyPin
echo '/<pinboard>' >>/root/Choices/ROX-Filer/PuppyPin
if [ -f /initrd/pup_ro$LAYERNUM/root/Choices/ROX-Filer/globicons ];then
grep -v -E 'special\-files>|<\?xml' /root/Choices/ROX-Filer/globicons >/tmp/globiconsTmp
grep -v -E 'special\-files>|<\?xml' /initrd/pup_ro$LAYERNUM/root/Choices/ROX-Filer/globicons >>/tmp/globiconsTmp
echo '<?xml version="1.0"?>' >/root/Choices/ROX-Filer/globicons
echo '<special-files>' >>/root/Choices/ROX-Filer/globicons
cat /tmp/globiconsTmp >>/root/Choices/ROX-Filer/globicons
echo '/<special-files>' >>/root/Choices/ROX-Filer/globicons
So, for a new permutation of unionfs layers at bootup, this code block will run and update help page, menu, and desktop icons.

Thanks for the attention our developers and Barry are giving this matter. It is very timely for the Puppy 2.15CE where sfs is expected to be used a lot. Of course Barry started the version 2 series with the loading of multiple sfs in mind. :)

I hope we can translate this soon to the Diskless Remote Booting feature of Puppy...

It's all very well having a BootManager, but people have to know it's there. It's existence in the "System" menu is not quite good enough. So, I added code to /usr/sbin/delayedrun, a script that runs just after X has started. If a user has not used the Boot Manager before, and has downloaded an extra SFS file, the BootManager will launch automatically, with the SFS-selection window open. The user may not do anything, may just exit, but at least will know of its existence (it has its own help file that explains its purpose).


A slight problem with 'menu' in 2.14 - that maybe also in 2.15CE (& could be 2.16) - is when a new prog has been installed and needs an "icon" in the menus - if there is not a 'designated' icon (in the prog installer) of the required size - the icon selected for use in the menus looks to "default" to the global size - which could be 48x48 or 32x32 .. :-(

This tends to make the pop-up submenus vary in size when 'displaying' icons - if one icon is of incorrect size (larger) - then all icons in that menu are displayed as larger - even if they are listed as the correct size ..

There is a 'special' xml file in /Choices/ROX-Filer for 'globicons' - so maybe we need a similar xml file to be set up for "menu" icons as the default.. :-)

Just a thought..

Craftybytes, there is a fix for this, at least for JWM. It just hasn't been implemented yet. I've made a note though, this must be fixed for 2.16 release. The fix is that it won't matter what size the icon is, it will get scaled down to 16x16 to match the others -- the .jwmrc file can be made to do this.

as I mentioned before, I've already messed with adding/removing icons and it's not as simple as the method you and Pakt are using:
What if different layers have icons in the same place??
You cannot just assume that the creators of different sfs files will choose "unused" locations, since the user might have changed the locations of the default icons.

You need to have code that tests to see if there's no existing icon where you want to put the new ones and if there is, look for a free location.

As I mentioned, I have code I can send you, just don't hastily implement something like happened with 2.14 -- in the end it just causes disasters.

Thanks Barry - hopefully you'll have a 'Unleashed' CD for the 2.15CE versions + a 'Unleashed' CD for 2.16 ..?

Am awaiting in much anticipation for the - v2.16 Unleashed CD - so as I can 'play' once again with Puppy & see what advances and improvements have come our (puppy users) way since versions 2.13 & 2.14..!!


I don't know about an Unleashed CD for 2.15CE, as I don't know where all the packages are. That is, we have PET packages at ibiblio, but the 2.15CE developers have some extra ones, in particular the core package,'0rootfs_skeleton-2.15'.

Dougal, I have already implemented a solution. The code I posted earlier was just an initial experiment. If you have code for me to consider, feel free to send it.

Puppy 2.15 Community Edition Release Candidate 2 available 

This is for testers to try out. Read my Blog report below about RC1. To find out more about RC2 go here:

Is there a seperate devx_215.sfs available for download. I have found 215.sfs files for:


but nothing for devx

Okay, look here:

Thanks Barry :)


A Boot Manager for Puppy 

Sunburnt has experimented with this, and that is what inspired me:

I've done it differently, and only implemented the choice of what SFS files to load (so far). I created script /usr/sbin/bootmanager, and a menu entry in the "System" menu. The script reads from and writes to a configuration file /etc/rc.d/BOOTCONFIG, which contains variables. The only variable so far is EXTRASFSLIST, which is a space-delimited list of SFS files to load at bootup.

For this to work, the init script reads from (and writes to) BOOTCONFIG. If variable EXTRASFSLIST is missing, it defaults to the normal auto-loading. If EXTRASFSLIST exists, the specified SFS files are checked that they exist and if they have version-number that it is correct, then the files are added to the unionfs layers.

What was immediately good about this for me personally, is I sometimes want to bootup but not load the 'devx' file. The BootManager GUI makes doing this a piece of cake.
I have just tested booting from USB Flash, I put 'devx_215.sfs' into it, booted and it got loaded, then ran BootManager and choose not to load it, rebooted and it did not load. Great!
If you have multiple SFS files, you can also choose order of loading, that is what Unionfs layer each is on.

/etc/rc.d/BOOTCONFIG can be extended indefinitely with variables as required. For example, the "underdog Linux" can now just be a variable, like this:
...not implemented yet though.

I can't just release the 'bootmanager' script right now, as it needs the bootup 'init' to work with it. Well, 2.16exp2 should be out in the not to distant future.

while you're at it, you might want to create in the dotpup a file containing a list of ALL sfs files already loaded with that pup_save and remove the part that changes the mod of the extra sfs files.

The way it is now, your init script sees that a certain sfs file has already been chmod-ed and so it doesn't do the NEWSFS loop... but the sfs could have been chmod-ed with a different pup_save.

Idea: have one of the boot scripts check if the mounted SFS file has its own PuppyPin file - if so, copy it over /root/Choices/ROX-Filer/PuppyPin and add its icons to Puppy's icon directory. It not, restore the default PuppyPin file. This way the desktop can change showing the correct icons for whatever SFS file is mounted ;)


Of course with multiple SFS files, the desktop could get a bit messy. The icon layouts would have to be coordinated somehow...


Hi, Barry -

Just want to say that I hope this new 'experimental' branch will be a permanent feature for puppy development, so there is less pressure to release betas, just different 'blue-sky' stuff for us to have a go at, before committing to an actual package and release date. As long as we have CDRWs and broadband, there's absolutely no problem with more testing!

I apologise if this comment is out of line...

Dougal, at first my response was "Aaargh, complications!", but then I figured out a simple solution. I have abandoned the chmod'ing of the .sfs files, and all code related to NEWSFS is now commented out in init script.
Intead, I'm saving each unique configuration of layers in BOOTCONFIG, so when a new configuration is encountered, the whiteout-file check is done.

Opera font rendering in 2.16exp1 improved 

Thank you very much GuestToo, for this post:

This showed me how to fix some crappy rendering in Opera. If you are testing 2.16exp1, open /etc/opera6rc and insert this line:
Enable Core X Fonts=0
into the [User Prefs] section. Then restart Opera.

This prevents Opera from using bitmap fonts, now my Blog renders nicely.

Oh yes, My eyes thank you. :-)

No luck with Flash 9 and opera, yet.

Flash 9 does not work in opera. Use Flash 7 instead. It works for me.

Yes, 2.16exp1 has Flash 7.

init, pmount scripts improved 

I have done a bit more work on the 'init' script in the initial "ramdisk". I have rewritten and extended the record_fnd_func and analyse_pupfound_func functions. I also added code to copy all .sfs files from CD to same place as a pup_save file on HD -- in the case of pup_xxx.sfs this speeds booting.

Plinej and Dougal did a lot of work awhile back on Pmount, my original drive mounter script, still alive as an alternative to MUT. You will find it in the Filesystem menu. The script is /usr/sbin/pmount. Plinej updated it for gtkdialog3 and posted it to me on 5th March -- finally I have got around to looking at it.
There was just one small thing, clicking the Refresh button caused a crash, which was easily fixed -- a bit of exta updating to gtkdialog3 was required.
I made one other small change -- the main "Please wait, probing hardware" box is done with gxmessage, but quite frankly gxmessage doesn't look so good. I have replaced it with yaf-splash, just that one message box (yaf-splash is also used in PETget).

Dougal's and Plinej's improvements are nice, it looks real good, especially with the H2O Stadust (modified) theme. I had better post the latest script somewhere... okay, here:

Have posted an updated pmount script with some user-interface tweaks.


could you please give pmount a setting to stop it from scanning the CD drives when it starts up. This appears to be in MUT (by editing the script) but isn't.

Barry, I couldn't find the puppyserialdetect source code in the repository.
Do you know where I might be able to find it?

Dougal, I have uploaded puppyserialdetect-1.0.tar.gz source to http://www.puptrix.org/sources/alphabetical/p/

Puppy 2.16experiment1, bleeding edge, for developers only 

This is not intended to indicate in any way what will be in 2.16. It is for Puppy developers who want to examine the latest bleeding edge ideas.

This Puppy has the "humongous initrd.gz" which has the pup_215.sfs file inside it (the version number is still set at 215). It also has a subset of the full drivers built-in, just as before we had the "zdrv" file -- probably the only thing you will notice missing is some wireless networking drivers.

The initrd is now a cpio archive and a ramdisk as-such is no longer used.

Encryption of the pup_save file is supported, with the choice offered at shutdown.

Various other things, as reported earlier in this Blog.

This build has Opera, not SeaMonkey. Gaim missing also, as Opera has its own IRC chat.

One interesting thing, for a developer who would really like to walk on the wild side. The 2.6 kernel supports the "initrd.gz" file being compiled into the kernel. This is done by specifying the path to the "initrd.gz" file during configuration. This is only if the file is a cpio achive. The initrd.gz file in this experimental release of Puppy already has the pup_215.sfs and drivers inside it, so compile inside the kernel and you get just one "vmlinuz" file of about 69M! This has to be the utlimate simplicity for newtork booting! (plus a new world record for biggest Linux kernel)

Download from here:

ted dog 
Too good, yet it is still in a iso? strap a bootloader to the front and only distribute the single file ready to run

I wonder what if any GRUB install line will be, for user with fugile types of install.

OH did you included the missing DVB in the recompile that I wrote about a few weeks ago.

ted dog 
The operation timed out when attempting to contact media-nf.puppylinux.com.

feel free to upload it to puptrix, you should still have the account setup as before

I'll place my DOTconfig (with the corrected DVB modules) for this current kernel, and a version of DOTconfig for [ which is faster than current used kernel ] that I got to work with a HD installed version of 2.14

Ted Dog 
[missing SFS & UNIONFS]

http://puptrix.org/DOTconfigs/linux- (all included)

Ted Dog 
Ok OK some even worse bleeding edge ideas for the single-file-kernel has-it-all. Multiple cpio archives can be attached to the end of a kernel, so say multisession would be a single cat >> to the end of a existing kernel.
If my memory is correct linux kernels can be lauched directly from windows boot.ini the option passing was the problem using windows boot loader directly.
[boot loader]



[operating systems]

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect /NoExecute=OptIn

[b]multi(0)disk(0)rdisk(0)partition(1)\HUGEPUPPYKERNEL="puppy linux 3.0- mega kernel"[/b]

Ted Dog 
(from http://www.thinkwiki.org/wiki/How_to_setup_boot_loaders)

Using the NT Boot Loader to boot Linux

The NT boot loader is not able to boot anything else than NT type Windows systems. However, other systems boot sectors can be stored in a file on the same disk that the NTLDR files reside on and can be chainloaded from there.

Hence, the procedure to integrate Linux into your NT boot menu is outlines like this (we assume that the NT boot loader is properly installed already):

* Install a Linux boot loader (LILO or GRUB) into the boot sector of your Linux partition.
* Copy this boot sector into a file.
* Copy that file to the root level of the Windows partition.
* Add an entry to chainload that file to the NT boot menu.

Ted Dog, the config used for the kernel in 2.14 and later is here:
I can't remember if I enabled what you wanted, so if not can do so next time. I plan to jump Puppy to a later kernel version sometime but in no hurry for now as there are some issues with some third party modules not compiling.

Yes, Ted Dog again !! 
mirrored (faster download for most)




Don't usually look at exptls, alphas, betas, being a mere user, but the incorporation of Opera was too promising to miss. For what it's worth, this exptl. version, for me, far surpasses v2.14 - I like it. Absolutely nothing wrong with the Opera fonts. Bit of tidying at boot up - the dots could be confusing? Otherwise, everything a regular user could ask for. Opera certainly speeds things up; in a compact distro this [b]the[/b] [i]rational[/i] choice.

sad ted dog 
nope my DVB drivers are still left out
# CONFIG_VIDEO_CX88_ALSA is not set
# CONFIG_VIDEO_CX88_DVB is not set


sniff, sniff

Not to worry, Ted, that should be in when the newer kernel is used.

Downloading now but it is slow so will resume in the morning...

Sine Nomine 
Thanks Barry,

I am not a developer but I am using pre-alpha 2.16 on 667mhz celeron

with 192mb RAM.

I used Opera to down load firefox & after saving to the hard

drive & rebooting puppy thinks that I have 1.2G of RAM & I cruising

the web!!

Thanks again.

Sine Nomine

Posting this from 2.16E.

Made an encrypted pup_save, worked well.

Did a frugal install, grub boot.

Symlinked zdrv_214.sfs to zdrv_215.sfs zdrv_216.sfs, didn't know which one. Rebooted and had my wifi drivers loaded.

The network wizard doesn't save profiles and doesn't seem to work with WPA anymore or I don't know which of the new options to choose.

The Fonts on this page don't look as sharpe. Maybe Opera?

Don't care for the grey background in ROX windows.

Not sure how low ram computers will handle the big initrd.gz.

One problem that's been around for the last few versions, when booting with multiple pup_save files, if you choose "0 -- none" don't use a pup_save file, then your prompted again with the same options. With 2.14 this would happen twice. With 2.16E I had to enter "0" four times. Not a big deal though.

Maybe the optional kernel modules that are currently "not set", should be set to M. I needed the saa7134-dvb module. Although, might make the zdrv file too big.

Does boot fast. Nice to see ext3. New theme looks sharpe. Nice work Barry.

kirk wondered about low RAM computers. Testing suggests that the lower limit is now >128Mb, but addition of another 32Mb will suffice. Furthermore, this one doesn't like overclocked Intel boards, but is happy with massively clocked AMD ones - another reason I always avoid Intel! Concurring with above, this version offers a substantial speed improvement.Probably good enough as is for most of my needs.

Hi Barry

is there any chance in the near future to update GParted to a newer release, something like 0.3.3 or 0.3.4???
Also, recently, I had a chance to test a backup/restore/cloning tool:
DRBL/Clonezilla (http://clonezilla.sourceforge.net/) in the form of a LiveCD (Clonezilla Live & DRBL-Live...). It proved to be one heck of a tool. I cloned an XFS based system from an 80GB disk to a 320GB disk.
I really wonder if it is possible to have Clonezilla as a PET package...
What do you think???


...except I couldn't install to HD. hdc seems to be mounted by default and the Installer complains it cannot find hdc. Trying to unmount hdc via MUT causes a lock-up.

This baby is quick. With Opera running, I still have 10% of 256 MB RAM free.

Tried frugal install first but failed. I will try again...

John Doe 
Kernel Modules

Please consider these three also:

<i>Miscellaneous filesystems</i>

<i>Multi-device support (RAID and LVM)</i>

Runs fine on live CD but nope, "can't find Puppy" in frugal install...

I hate Opera and it played up on some of my bank sites.
I still use Puppy 1.07 for most banking and ISO burning,
because it's just so good..gone but never forgotten.

Mozilla in Puppy Viz RC1 ran very fast..so why are we
going backwards. At least some Windows refugees have heard about
Firefox or used it..so Mozilla shouldn't be too hard.
Your Xvesa worked first time as usual..
Mr Never Fail of Puppies,
I wish some others would learn the Xvesa lesson.
Otherwise fab as usual...The Ian Thorpe of Linux developers.

Glad you were able to confirm that Installer has an issue, Raffy - doesn't seem serious, just that it can't see the source. Probably an easy fix for BK.
Cthisbear seems unfamiliar with Opera, which is infinitely superior to all other browsers in respect of which he complains as it can be set to emulate any other browser. It's the only one that will render every website no matter whatever bizarre or undesirable SW was used in their construction.

On the frugal install, I just copied the two files to hard drive, and edited grub, Didn't try the installer. I like new stuff to play with like Opera. Don't know if I'd want to trade it for Seamonkey & Bluefish.


I beg to differ, Opera will not work on my bank site. I have tried every emulation setting and still no go. I know puppy is not a democracy and I understand the reasoning for switching to Opera but I prefer Mozilla or firefox.


this version does not seem to work pxe. I keep getting an error pup not found hdd
is there something new to be added to the pxelinux.cfg default file ?

John Doe 
The crypt password selection dialog absolutly MUST have a validation entry dialog. Perhaps this is in the works?

I've got some logic around if you need it, I could dig it up.

John Doe, yes, okay, I've made a note of that. Should be easy enough to implement.

was curious about "cpio archives" did a search and came up w/this

thought it might help out?

also came here to upload this experimental version of Puppy Linux,but realize this is Not for the masses.

Please keep up the great work and Thank You for Puppy Linux!

[blockquote]just an end user[/blockquote]

Puppy 2.15 Community Edition Release Candidate 1 

Probably not quite ready for an announcement on Distrowatch, but looks like it's getting close! Puppy 2.15CE is based on 2.14 but with many enhancements. In particular the user interface has received much attention. 'CE' releases of Puppy are created by a team of Puppy enthusiasts, not by myself personally. It does mean that a lot of new ideas get implemented that users would like, whereas my Puppy releases tend to be more spartan. Also, I am sometimes a bottleneck as all new features have to come via me, but the CE release is an opportunity for a developer to have more direct influence on the outcome.

Amyway, find out for yourself. Go to the Puppy Forum where there are many threads discussing 2.15CE. To download, go to this thread:
...note, the "standard' edition is 120MB.

Changing the subject, I have uploaded Opera v9.10 PET package to ibiblio. I'm using it right now. One thing that I'm not happy about is font rendering. The font setup in Opera looks quite good, on the surface, allowing the font to be set for just about everything. Despite that, plain-text pages render to small and nowhere could I see how to change that. Then, this News Blog renders in a bitmap font without any antialiasing and it looks crappy.

You can set the minimum font size in Opera by going to the advanced tab of the preferences window and selecting fonts over on the left. This will ensure no fonts render below a certain predetermined size. In almost every browser I'm aware of right now this setting is at 9 for some reason, while in today's market a more sane choice would be at least 12 and maybe even 13. A font sized at 9 is only going to be handy with 640x480 resolution.

While there you can also set things like the the default forms font, things which aren't very easily configured in Mozilla based browsers.

Barry Kauler 
Nathan, the font problems exist after I have tweaked all the advanced font settings. I already had minimum font size set to 12. If anyone else wants to play with the settings, please do -- Opera is in the 2.16experimental1 build.

I found that if you install the "bitstream" fonts pup, then change to 'bitstream' for the fonts in Opera - text on rendered pages appears quite crisp and clean even down to the minimum of '8' that I've got set in my Opera install (v9.10) - which I have been running for the past few weeks in Puppy v2.14 with no probs at all..

I usually st most of the font sizes in Opera at '12' for standard sizes - gives clean, sharp text - good for general surfing needs..

Found that many of the other 'standard' fonts rendered rather badly almost unreadable in Opera - whereas 'bitstream' is mainly the one that I come back to ..


DejaVu is extended Bitstream fonts. But, Puppy only has the DejaVue Sans (no serif) font, not the mono or serif. Opera is set to use the DjaVue Sans as the main default and where that is used, it looks quite nice.

i have these options in the [User Prefs] section of opera6.ini

Enable Core X Fonts=0
Enable Xft Fonts=1

Helvetica does not look good in Opera, and many web pages specify Helvetica as second or third choice, or sometimes even as first choice ... disabling the use of Core fonts disables fonts like Helvetica

the fonts for Opera menus can be tweaked in $HOME/.qt/qtrc

Opera also can start with various command line options ... type:

opera --help

also, setting the env variable:


might make a difference ... some of the tweaks that worked with older versions of Opera no longer work, there are different ways to tweak the settings now, but i'm not sure which still work and which no longer work

Many PET packages updated 

These have all been uploaded to ibiblio:

Plinej: transmission_gtk-0.6.1-r1518

Plinej: pupctorrent-0.7

Plinej: soxgui-0.9

Rarsa: remotedesktopclient-2.15-2

Rarsa: pvolume_mixer-0.3

Plinej: pbcdripper-2.5

Plinej: pawdioconverter-0.6

Rarsa: net_setup-2.15-1

Glipper, snapmergepuppy, H2O-stardust 

GuestToo has compiled Glipper for Puppy, a little clipboard manager. Works nicely in JWM. I've put this into Puppy. Forum thread:

Zigbert has adapted the H2O Stardust GTK2 theme to work in Puppy. It is very small and looks nice. I have lightened up the blue buttons and made it the default for my next Puppy. Forum thread:

Andrei has done some work on /usr/sbin/snapmergepuppy. This is a script that writes the tmpfs unionfs working layer to permanent storage at regular intervals. This is done when booted from USB Flash and for multisession CD/DVD. It is an ongoing battle to eliminate unionfs whiteout-file bugs, and andrei has identified and fixed some in this script. I've given it some preliminary testing and it looks good, so it is going into the next Puppy. Forum thread:

Pbackup, Pfind, Pupdvdtool updated 

I have uploaded these latest PET packages to ibiblio:

Zigbert: Pbackup v2.0.0
Zigbert: Pfind v1.0
Plinej: Pupdvdtool v0.8

Of course you won't see these in the 2.14 PETget package-selection 2-pane window, as these are later versions. They are uploaded for developers to access. However, anyone can download them individually and click to install.

John Doe 
I decided to give these a test, so I remastered with them and I get this:

sh-3.00# pfind
/usr/local/pfind/pfind: line 799: gtkdialog3: command not found
sh-3.00# pbackup
/usr/local/pbackup/pbackup: line 728: gtkdialog3: command not found
sh-3.00# pupdvdtool
/usr/local/apps/pupdvdtool/main: line 34: gtkdialog3: command not found

Did I leave something out?

Barry Kauler 
I think ibiblio has the latest gtkdialog, with gtkdialog3 executable.

John Doe 
Thanks! That was it. Sorry for the stupid question, I should have just searched the package directory.

All three work great.

Problem with swap partition in initramfs 

I encountered a serious problem with the new cpio "initial ramdisk" -- from now on I'll refer to it as the 'initramfs'. Anyway, the problem is that the 'init' script in the initramfs executes 'swapon' to load a swap partition, if one exists. However, after switch-root it gets all screwed up.

With the previous ramdisk system, pivot_root made the new f.s. as '/' and the ramdisk became /initrd. If the 'init' script had executed 'swapon /dev/hda5' (for example) then after pivot_root the swap partition is then seen as /initrd/dev/hda5. This is confirmed by 'cat /proc/swaps'.

With the new initramfs, after switch_root, although the swap partition seems to still be working, 'cat /proc/swaps' shows it as '/dev/hda5\040(deleted)' --which totally upsets swapoff.

I puzzled over this, spent a full day searching the web for a solution. Eventually I contacted Rob Landley, who wrote the Busybox switch_root applet. Rob also wrote this:

After some discussion, Rob tentatively thought that it is a kernel issue, a bug. He suggested a quick and dirty hack to fix it for now, that I have implemented. This requires creating /dev as a tmpfs in the initramfs and create all the device nodes in it. Then before doing the switch_root, execute 'mount -o move /dev /pup_new/initrd/dev', which moves the mount-point of /dev into the main filesystem that will be active after switch_root.
I'm not happy with having to do such a hack, but at least it works -- now 'cat /proc/swaps' shows the swap partition as '/initrd/dev/hda5', exactly as in the earlier ramdisk system.

Does the swap partition / file have to be loaded in the 'initramfs' - could it instead be detected & loaded in the secondary 'init' script or even in the 'rc.sysinit' script ..?

If one can "turn" swap on / off in MUT - then there must be ways to to turn it on/ off in the 'init' script after the initial 'initramfs' has completed ..?


Barry, is the new initrd still remounted rw, even though it's not a ext2 fs?

Dougal, yes, but switch_root destroys it, so it doesn't exist after that, so you cannot chroot into /initrd as before. However, /initrd does still exist, but it is just a directory into which I have moved the important stuff from the initramfs. For example, the mount points, pup_rw, pup_ro1 etc are moved to pup_new/initrd so that they are still accessable after the switch_root.

Note, Rob's opinion about the problem with the swap partition getting lost after the swith_root is that the kernel is tracking the inode of /dev/hda5 (for example) instead of the partition, for compatibility with swap files. Although /dev/hda5 exists after switch_root, the kernel is looking for an inode that has been destroyed. Rob considers that to be essentially a bug.
My hack is to mount a tmpfs on /dev and do a "mount --move" (or "mount -o move") but it would be nice if there was some way to move just the inode.

craftybytes makes a good point. Do we really need swap so early in the process? If not, then isn't all this problem with the bug/hack bypassed, by turning swap on later?

I guess that depends on what happens with small memory systems. It may be that some memories are so small that swap actually gets used during boot, although that would be a little surprising.

Yes, there are situations where we turn on swap in the initramfs. Low-RAM situations, for example the multisession CD where we want to load as much as possible from the saved sessions from CD into RAM at bootup.

Barry, you might also want to copy the log file from /tmp in the initramfs to the /tmp in NEWFILESMNTPNT...

Barry Kauler 
Dougal, yep, that's already done, plus I've created some extra log files to help with debugging.

The 'pup_save' file may now be ext3 filesystem 

There has been on-going discussion about whether the 'pup_save' file should have an ext2 or ext3 filsystem inside it. The filename is 'pup_save.2fs' if ext2 and 'pup_save.3fs' if ext3.
A long way back, in the 1.x series, the pup_save was always ext2, then we moved to ext3, then in recent Puppies back to ext2. Read down this blog for further information.

The next experimental Puppy (2.16pre-alpha) will create a pup_save that is normally ext2, but if the pup_save file is on a fast hard drive that itself has a journalled f.s. (ext3 or reiserfs) then the pup_save will be ext3. The reasoning for this is dicussed at various forum threads, including here:

At bootup, a f.s. check is only done at every bootup if it is a ext2 f.s. in the pup_save. If encrypted, then it is not done at every boot either, regardless of whether it is ext2 or ext3.

The automatic logic at shutdown as described above does allow for creation of a encrypted pup_save with ext3 f.s. I don't know whether we should bar all encrypted pup_saves from being ext3. Probably best to try it and see.


As puppy already [b]knows[/b] what media types are being used in the session (from the boot scripts) - then maybe one could allow for [i]selecting [/i] if 'pup_save' file should be saved as ext2 or ext3 ..?

- I would suggest that it should "default" to what format the 'pup_save' file was originally [i] loaded [/i] by the boot scripts - but a 'selection' should be possible ..!!

This would make most puppy users happy..

Barry, while you're working on init, perhaps you should finally consider adding the Puppy version to the pup_save file, e.g. 'pup_save_216.2fs' (or with 8.3 'save_216.2fs').

This would be consistent with numbering of 'pup_216.sfs' and 'zdrv_216.sfs' and make it easier, e.g. to dual-boot two Puppies and for the user to tell which Puppy a save file belongs to (without having to loop mount it first - also making the init logic a bit simpler).


"I don't know whether we should bar all encrypted pup_saves from being ext3."

I don't quite understand this statement. The only connection that this ext2/ext3 choice has to do with encryption, is that fsck's are slow with encryption. Otherwise, the only reason these discussions show up around encryption forums is that encryption often uses file-backed loop devices.

Here is something I dug up earlier that explains what configurations are dangerous:

Jani Averbach wrote:
> Is there any way to mix loop-device (and in particular) loop-AES and ext3
> together in data journaling mode?

Device backed loops (ext3 -> loop -> device) don't have issues with ext3 or any other journaled filesystems.

However, if loop is file backed (ext3 -> loop -> ext3 -> device), the underlying file system must be mounted data=journal or data=ordered. If underlying filesystem is mounted data=writeback or if it is plain old ext2,
write ordering expectation by journaled filesystem (ext3, reiserfs, jfs, xfs, or whatever) on top of loop driver is not guaranteed, and journal replay may corrupt data. Use of non-journaled file systems on top of file backed loop don't have above mentioned write ordering issues, as they must
be repaired using fsck, not by replaying journal.

Jari Ruusu <jari.ruusu@pp.inet.fi>

As you can see, just having ext3 as the underlying fs does not protect you; you also need data=journal or data=ordered. Who knows what happens when the underlying fs is ntfs or reiserfs; maybe that is OK. FAT is not, I think.

This is why I thought it made sense for any file-backed pupsave to be defaulted to ext2. It just makes everything easier. And let those who don't like ext2 go ahead and use ext3 if they want.

See also this thread, where we hashed over this before:

'pfix=nox' boot parameter 

John Doe suggested it here:

I've implemented this in Puppy. The boot parameter 'pfix=nox' means "no X", so when Puppy starts you will just get the commandline. This is different from 'pfix=rdsh' which drops you out to the commandline in the initial-ramdisk, whereas 'nox' drops you out in the main filesystem after the initial ramdisk has done its thing and gone. At the commandline, you can run any cli apps, like the 'mp' text editor, and you can type 'xwin' if you want to start X.

I implemented it a bit differently to the way posted in John's thread. In the 'init' script, if 'pfix=nox' is detected, the script creates /tmp/bootcnt.txt', an empty file. /etc/profile, which is the script that executes when Ash/bash is loaded, will only execute /usr/X11R7/xwin (the script that starts X) if bootcnt.txt does not exist (this is a mechanism to prevent X from restarting when you exit from X to the commandline, as /etc/profile gets re-executed everytime that Ash/Bash starts (that is, at an axit from X, Ash/Bash gets started so that you have a prompt and /etc/profile also executes).

That's awesome. You've done it in such a way that it won't mess with my login manager setup in Grafpup, which also uses bootcnt.txt.

Upgraded losetup and ls to full versions 

In the main Puppy filesystem (not the initial ramdisk) I have replaced the Busybox 'losetup' and 'ls' with the full versions. We already had 'lostup-FULL' alongside the Busybox 'losetup' but losetup is now a symbolic link to losetup-FULL -- the 'losetup-FULL' name is retained as many scripts use it.

floordog (floordog<at>yahoo.com) 
Does PuppyOS support multiple (4-5) GIGALAN ports on a Core 2 duo mobo?

That's interesting. The Busybox "ls" seemed pretty good. The Busybox "ps" on the other hand is a sadly crippled beast, reporting neither parent PID nor total CPU time accrued for each process. If it's not enormous its addition would make Puppy Linx look more like a Linux/Unix OS to a command-line guy like me.

Yes, but if we just dumped ps in there without thinking it would cripple a lot of scripts that use the busybox version. Best to do it the way Barry has been doing, add it in alongside the Busybox version, at least for a few releases, then perhaps take it out later after people have had a bit of time to port their scripts.

Goodbye ramdisk 

Thanks to craftybytes who suggested this in a comment to a recent post in this blog, I decided to investigate using a cpio archive rather than an ext2 filesystem for the initial-ramdisk. This is something that I have been meaning to look into for ages.

In Puppy Unleashed, it is easy enough to build a cpio archive from the contents of boot/initrd-tree rather than a ext2 filesystem. The created file is still named 'initrd.gz'. Only small changes had to be made, mostly for the 'init' script -- it had to be relocated at '/' in the filesystem instead of /sbin, and the script has to use 'switch_root' rather than 'pivot_root'. I modified the script so that after the switch from the "initial ramdisk" to the main filesystem, there is still an /initrd directory as before, with the unionfs layers mounted in it, as before.

One advantage of the cpio "initial ramdisk" is that it doesn't actually use a ramdisk. Previously, Puppy used /dev/ram0. The new system is actually a 'ramfs' which has more efficient memory management and can be any size. So, the boot parameter 'root=/dev/ram0' is no longer required, and also for large initrd.gz files there is no longer any need for the 'ramdisk_size=' parameter. The only kernel parameters I need now, for example I just tested booting from USB Flash:
initrd=initrd.gz pmedia=usbflash

After the switch_root, the "initial ramdisk" is totally removed, which also means very efficient memory usage. Anything wanted to retain, such as the mounted unionfs layers and other filesystems mounted while in the initial ramdisk, are moved to a directory /initrd in the main filesystem.

I'm trying to set it up so that everything looks much like it did before, so everything should work as before. Any scripts that look into /initrd will see the same stuff, as least what matters. The user won't even know there has been a change ...so, why do it? More efficient memory usage is good for PCs with less RAM, plus removal of the ramdisk size limitation does open up some future possbilities.

Sounds excellent! I'm just curious on how this affects full/normal hd installs....

Barry, this seems great.
Does it mean that /initrd will only have the few used mountpoints in it? I think some of the other mountpoints are needed for the idea of mounting/umnounting on the fly (what they're discussing in the Aufs thread).

And what about trying out Aufs while you're playing with such fundementals? (or will it have to wait until you also recompile everything?)

Aufs... no, I would like to take one step at a time, bring out a release with just the changes so far, make sure it's rock solid. Besides, one of our Puppy enthusiasts, andrei, has tracked down some unionfs whiteout bugs in the 'snapmergepuppy' script, which I am about to test, so we might have unionfs working pretty good. Aufs looks simpler though, so probably good to migrate to it sometime.

I'v setup initrd.gz to it works just as before. Install to h.d. is as before, all the mountpoints as before, every as before (touch wood).
The 2.6 kernel is able to create an 'initramfs' as part of the kernel, not a separate file, which caused me some confusion at fist. Then I found that it can be a separate file, just like we have been using so far, and some major distros do it this way. So the new 'initrd.gz' looks almost identical to before. It took me awhile to get 'switch_root' to work, and at first I actually had the old 'pivot_root' working which is not supposed to work in that situation. Anyway, I figured out the mods needed to the 'init' script to get switch_root to work.

I'll upload a 2.16pre-alpha for people to play with soon. This is not intended to compete with 215CE, it's still rough, just for those who want to see and test the new scanning in the 'init' script, new encryption and the new cpio archive in action. Oh yes, the "humongous initrd.gz" also.

And here I thought I was just some deadwood floating around on the fringes .. :SURPRISED

My research into the 'initRAMFS' method also suggests that [i]encryption[/i] using "cryptoloop" with "AES" - and - file [i]swapping[/i] (re:- '.sfs' & '2fs' files) either using "unionfs" or "aufs" - should be much easier to implement..

Also there may be possibilities of not needing to use the current '2fs' / '3fs' (ext2/ext3) methods for [i]saving[/i] a session - one could actually save using the '.sfs' (squashfs) method - thus making the 'saved' files much smaller ..

Anyway - I'm glad I could make a contribution - small as it was..

Barry, you might as well just upload the new initrd.gz, since it has all the modifications in it... (just set the version to 214 and we'll be able to use it with the old sfs...)

To expand on craftybytes' comment, I had an idea. Compressing/decompressing on the fly would obviously slow down Puppy, but what about on bootup uncompressing from SquashFS or similar to and using a pup_save same as we have been but with size dependent on free space and on shutdown compressing back down? Could be same as is but on bootup/shutdown would compress/decompress and pup_save would auto-resize. Of course if Puppy crashed and didn't shutdown then an on-boot cleanup would be needed. Just an idea to consider or experiment with....

Dougal, no, I had to make some small changes in /etc/rc.d also. I'll upload in a few days.


J_Rey made comment re - Puppy crashing ..!

Is the 'pup_save.2fs' file always mounted and open whilst Puppy is running ..?

If the contents of 'pup_save.2fs' are [i]copied[/i] to the r/w layer of unionfs - then one would think that the [b]real[/b] 'pup_save.2fs' file on the CD/USB/Hard drive media could then be [i]closed[/i] AND [i]unmounted[/i] till actual shutdown/reboot - whence it can then be [i]remounted[/i] and [i]opened[/i] ready for doing the [b]save[/b] of the session ..!!

Another thought - if the contents are actually [i]copied[/i] - then does the [b]real[/b] 'pup_save.2fs' file need to be retained on shutdown/reboot ..?

- could not the [b]save[/b] be done to a NEW 'pup_save.2fs' file and if the 'write' was OK then the ORIGINAL file can then be deleted ..?

Random thoughts just [i]flashing[/i] around in my [b]degrading[/b] vacant brain space ..

Normally the save-file is mounted directly. In a USB-setup, it's only mounted read-only and any new files are stored in ram and copied to the save-file every thirty minutes and on shutdown.

Lock up your Puppy! 

Our encrypted Puppy is looking good! Kirk and others have done heaps of work investigating this. See these forum threads:

I built support for loading an encrypted pup_save file into the 'init' script in the initial-ramdisk, see previous post.

Over the last couple of days, I have built encryption support into the shutdown script, /etc/rc.d/rc.shutdown. Now there is a dialog box that asks if you want to encrypt the pup_save file, and you can choose 'light' (xor) or 'heavy' (aes) -- reason for this is that heavy can have a performance penalty.
The shutdown script also asks for a username and password -- yes, an optional username, that gets put into the pup_save file, like this: pup_save_crypta-fred.2fs. At bootup, if there are multiple pup_save files, the choices are now displayed with these usernames, as well as the names of the pup_save files. We could have a boot parameter to further reduce boot messages and only display the usernames.

These encrypted files are a step toward solving the problem of users who want to share the same Puppy-installation with spouse and kids -- now they each get their very own pup_save file to play in! Normal multiuser Linux can't do that, but of course we don't don't have the 'group' protections, to for example prevent little Johnny from mounting a partition and wiping everything. Not yet anyway ;-)

The losetup program is odd. I had to put it into the initial ramdisk, but today I found out how it could probably be made to work from the main f.s., by use of the '-p' option. Will investigate that further.

John Doe 
Can't wait to try it out

Just can't convince myself that this is the best approach for 'family' use of Puppy (or other distros), especially if even more size penalties are incurred.
The obvious solution is one HD per person on a caddy system. It's not as if the average user is needing a 500Gb drive! Average users I encounter find it difficult to fill a 2GB unit. Photo, video and music phreaks would be best advised to used twin drives? Or better, boot Puppy from an USB keyfob and place data on an HD.
However, we are always advocating Puppy for use on older HW, so it's not difficult to find one entire PC per family member by picking out something from a roadside skip or the local amenity tip!
Sorry if you think this isn't sufficiently technical for your blog, Barry, but it does address very directly the issue you raise under today's title!

Encryption and multi pup_save file system are two important and useful Puppy features.

Leon, yes, there's virtually no overhead to provide this encryption feature, and it offers yet another way that Puppy can be used. One catch though, is that the password input at bootup is only going to work for a qwerty keyboard -- perhaps a kernel boot param would be needed for other basic layouts, that PKEY parameter.

Barry, no problem. Instinctively, I never use any of specific Slovenian characters in my passwords and also never use 'y' or 'z' character to avoid possible problems with the keyboard layout.

Does this support the encryption engine in via's c7 proc? I don't have one but users of mini pc's and some laptops would greatly benefit since I have heard that it is really fast up to 20Gb/sec at 2 Ghz using an infinite random number generator to make files nearly impossible to crack or so I have heard.

It's very unlikely this old cryptoloop (I assume that's what Barry is using) will support any new hardware designed for encryption.

Barry, are you creating a new encrypted pupsave, leaving the old one alone? Or somehow encrypting the working pupsave? Did you retain random numbers in the generation of the pupsave, as was done in my convert-pupsave? If not, the "heavy" encryption is not really very heavy.

I am happy to see this getting into standard Puppy. The size penalty is very small, and as to performance I have only noticed a slightly longer boot (when using encrypted pupsaves - no penalty without).

John Doe 
I too would like to make sure that Paul's research on saving the file is followed. What he worked out was very specific in order.


Haven't seen the current implementation but just wanted to mention that:

zcat /lib/modules/${KERNVER}/cryptoloop.ko.gz | insmod -

Probably doesn't need included or loaded. If it's still there, that's my fault. After all our posting, I think loseup only uses aes (or other crypto mod) and not cryptoloop (it's something different).


Where is 'pupsavefunc'? I still can't find it.

Barry Kauler 
Oh, I'm loading the cryptoloop module. Yes, also the 'heavy' encryption is not so heavy. It would be good if I uploaded Pup 2.16pre-alpha soon, with all this new encryption and cpio initrd and improved scanning in the init script. You could then use that as a basis to work on, and make further refinements.

The cryptoloop module is needed.

The encryption is pretty strong, if you use a strong password. I've seen a lot of theories about how to crack it, but nothing concrete or close to easy.

MDD (mdd<at>fios.com) 
Has anyone suggested adding the capability to mount encrypted 2fs files as individual drives using MUT? This would really make Puppy a lot safer to use for applications that deal with sensitive data (medical, military, corporate, etc.) than any of the Win alternatives.


esmourguit (esmourguit<at>tele2.fr) 
Barry wrote
"Now there is a dialog box that asks if you want to encrypt the pup_save file, and you can choose 'light' (xor) or 'heavy' (aes) -- reason for this is that heavy can have a performance penalty.
The shutdown script also asks for a username and password -- yes, an optional username, that gets put into the pup_save file, like this: pup_save_crypta-fred.2fs. At bootup, if there are multiple pup_save files, the choices are now displayed with these usernames..."

Thank you Barry, it is exactly what I hoped for.

"Has anyone suggested adding the capability to mount encrypted 2fs files as individual drives using MUT?"

I believe this is relatively easy to add to MUT and pmount, given the work we've done on the pup_saves. We focused on the latter just because there was a big desire to protect "everything" by default. If you go the other route you have to be aware what data is in what place, but now that we have the information this change you suggest is probably well worth doing. I'm too busy right now though.

BTW this encryption is trivially easy to bypass if you use swap, as your passwords can show up there in cleartext (I read an article where someone researched this on a big system, and was amazed at the info he found in the swap file). Perhaps a warning ought to be given somewhere, at least if the user has both swap and encryption? Or maybe some work on scrubbing swap on shutdown, as we talked about earlier; although that would slow shutdown significantly.

Major reworking of the initial-ramdisk 

It's a work-in-progress and this is a report on what is happening. The 'initrd.gz' file is loaded into RAM at bootup and this becomes what we call the "initial ramdisk". It's a complete little Linux environment, and it does preliminary hardware detection and setup prior to loading the pup_xxx.sfs and pup_save.2fs files.

I have spent a lot of time rewriting the code that scans the computer looking for the various Puppy files, making it more systematic. Along the way I am attempting to fix various things like saving to Zip drive, and boot from USB and SATA CD/DVD drives. Some little things too, like pakt suggested the boot parameter 'PMEDIA' should also be allowed to be lower-case, 'pmedia'. I have also implemented 'pmedia=cd' for booting from any IDE, USB or SATA (maybe even SCSI soon) CD/DVD drive, and the 'init' script will determine which one and set PMEDIA to the exact type of drive -- what this means is that we can distribute a CD with only 'pmedia=cd' on it and it will boot from all those different types of drive.

Dougal did a major rewrite of the init script to bring down the size of the 'initrd.gz' file. He got it down to 811K, whereas in Puppy 2.14 it is about 1240K. He achieved this by taking some of the executables out of the ramdisk -- when the pup_xxx.sfs file gets loaded, it's executables are then available to be used while still running in the initial-ramdisk, before having done the pivot-root to the pup_xxx.sfs filesystem. Executables that he was able to remove are fdisk, sed, probedisk, mke2fs, resize2fs, touch, grep, probepart, stat, and e2fsck. For various reasons, I wanted to keep some of these in the initial ramdisk, and I have retained fdisk, probedisk, sed, touch, grep, probepart and stat. My 'initrd.gz' is 815K, but I achievd this by upgrading to the latest Busybox, v1.4.1. The initrd did have the full versions of fdisk, sed, grep, stat and a few others, as the Busybox versions were not "good enough" -- however they have improved enough in the latest Busybox. There are a couple of exceptions, for example 'cp' is still the full version.
Anyway, the end result is what matters, the initrd.gz has dropped from 1240K in Puppy 2.14 to 815K, which makes the live-CD that much smaller, and is better for old PCs with limited RAM.

One thing though, Dougal had put Kirk's encryption stuff into his initrd.gz, the two modules and modification to init script, but he still had the Busybox losetup. I will do the same, and I'm wondering, whatever the problem is with the Busybox losetup applet, perhaps the v1.4.1 Busybox has a more satisfactory losetup?
...I'll implement this tomorrow, no today as it's after midnight here. Will implement support for USB keyboard in the initial-ramdisk also.

I've posted to the forum with details on the config options chosen to compile Busybox 1.4.1 for the initial-ramdisk. It may be that we need to modify this for future possibilities with network booting, or for some other reason. In particular if network booting interests you, please read this forum thread (I think that I have hijacked sunburnt's thread somewhat):

Ah, I made an incorrect comment. Dougal has used the "full" losetup for encryption:
/pup_ro2/bin/losetup-FULL $CRYPTO /dev/loop1 $SMNTPT$SAVEFILE
...what this is doing is using the losetup from the pup_xxx.sfs file, as at this point in the script it is mounted on /pup_ro2.

Yawn... I got up at 4.30am and worked on implementing Kirk's encryption, noting Dougal's improvements. Okay, it's done. I also did some work on Kirk's 'pup-save-encryption' script and have placed it in /usr/sbin and created a '.desktop' file so it will be in the menu (Utilities menu). Um, it's now 8.15am, I'll have breakfast!

The busybox losetup didn't support the -e (encryption) option. I tried Dougal's init script a few weeks ago. At that time it wasn't finding the losetup-FULL, guess he got it fixed. Thanks Barry and Dougal!

P.S. GuestToo has a good solution for the fsck problem:


Kirk, same problem with losetup in the latest Busybox.

Kirk, your problem with Puppy not offering choice from multiple pup_save files when booting from USB Flash is fixed. The fix is generic, meaning that you will get the choice regardless of media booted from.

After implementing Kirk's pup_save encryption, with the cryptoloop and aes modules in the initial-ramdisk and using the full losetup out of pup_xxx.sfs, the 'initrd.gz' file is now 813KB.

I played with the script (makeinitrd.gz) that is used to build the initrd.gz file. There is a peculiar problem, that although initrd.gz is 813KB, it is 2264KB when expanded, with about 1000KB free space in the filesystem. It's the expanded size that is important, as this is what takes up space in the physical RAM and is critical for old PCs. There is something very strange here, but I have managed a hack so that the expanded size is now 1564KB, and when the initial-ramdisk is loaded into RAM it still has about 300KB free space in the filesystem, more than enough I think.

I'm wondering about the schedule for 2.15CE. The guys working on that will probably be thinking that they want all of the above in their 2.15CE release.... the builds that I am creating are "2.15", and I can bring it to the alpha stage soon and you could sync with that, but that would be a step back perhaps as you would then have to bring out another 2.15CE-alpha. Or, if you plan to release 2.15CE-final soon, you could go ahead with that and I'll rename mine as 2.16 and will bring out an alpha at a more leasurely pace, sometime after your 2.15CE is released.

There are some very disturbing messages appearing about being essential to update the kernel to the new version released mid-week(?). According to reports, [b]large numbers of bugs[/b] are fixed. Ominous! Hope it doesn't throw everyone's plans into disarray.[Please don't ask where I saw these comments. I scan hundreds of documents daily and only skim most unless they impinge on my main interests of HW. Sorry.]

what did you change in the makeinitrd script? I always thought we can't fill the initrd fs more than 70% because it's full of empty files (thus a lot of space is taken to "register" them, compared with the actuall space used..).
BTW, which static libc did you use for compiling Busybox? I wanted to compile it a while ago but couldn't find Uclibc or dietlibc in the devx...

Okay, I've implemented support for a USB keyboard in the initial ramdisk. This means that if you have to choose from multiple pup_save files, both a ps/2 or USB keyboard will function -- at least I think so, don't have access to a USB keyboard until tomorrow when I get back home.
The initrd now has the 'usbhid' module, bringing the initrd.gz file up to 833KB, but I tweaked the expanded size to 1488KB, which has 202KB free space in the filesystem.

Dougal, it used to be that the makefinitrd script allowed to fill up the filesystem to 90% or more, but some version change, I think it was at Puppy 2.02 or maybe earlier, introduced this huge empty space. However, I overrode it by first creating the bigger initrd, then using resize2fs to reduce the filesystem in initrd, then used 'dd' to copy the reduced portion of initrd. I tested it at 80% full and it worked fine. I've just upped that to 87% but haven't tested it yet.

I compiled Busybox with uClibc. There's a uClibc complete ext2 filesystem, that you can mount with a loop device and chroot into. It's at Ted Dog's site, puptrix.org/sources/initial-ramdisk/. It doesn't have much spare space, but root directory has some stuff that can be deleted.

In scanning the thread you linked to, I noticed that the buxybox mount applet is compiled without the ONFIG_FEATURE_MOUNT_FSTAB flag being set. I wonder if there would be any negative effects to this? Just going on the name alone it sounds like there would be some real uses for this, but I would have to read the docs a bit more. In a few of the scripts I'm working with I have to use mount-FULL, and I've had problems with umount also, related to using fstab.

Sage - about the kernel - I'm running the very latest stable kernel and yes, it has fixed a lot of bugs. They also implemented the little patch to set loglevel right into the kernel. But while they fixed some bugs they introduced some others, which is usually the case. I now have sound on one computer that didn't before, but another one which had broken sound lost it's sound altogether. Also, the regular Lucent modem drivers will no longer compile and it is necessary to use the Martian drivers for these modems now, which is frankly a bit of a pain. Basically I wouldn't rush out to change kernel versions without a good reason, especially since it will break compatibility with a lot of custom modules people have compiled, and could very well introduce new bugs.

Hi Barry

right on the spot about the "pmedia" option...we are 100% in sync about this. In order to go to a more flexible (and multi-hardware tolerant) boot procedure this is a "must-have" item...


John Doe 
[b]re: Encyrption, PLEASE CHECK OUT THIS POST:[/b]

Here is some SOLID logic for selecting encryption on shutdown. I just don't know where to put it.


I think that ideally the bootup should default to 128 and allow a pfix arg for 192 or 256. This could also be nested to the 3rd degree logically and init could simply fail up the ladder.

[b]re: Busybox Upgrade[/b]

I jumped up out of my chair and just about did a back flip after reading about the busybox upgrade. Now I can try to do LUKS encrypted save files. Also a T2/Puppy/PowerPC build is MUCH more likely in the future.

[b]re: PMEDIA[/b]

Will I still be able to move zdrv_214.sfs and pup_214.sfs to the USB then type in 'puppy PMEDIA=usbhd' for fast booting?

After all the reading, I'm still confused if they are going in initrd.gz by default or if that is just an option for unleashed users.

I wonder if a "noramsfs" option can be introduced (experimented on by Pakt and me), meaning not to load sfs in RAM, which solves a way out of a crippled Puppy when the RAM is just enough to load the sfs (ie, there is not much extra RAM for running applications). There could be some other ways to avoid this situation. Thanks!

It would also be nice to be able to specify something like "tohd", which would copy pup_xxx.sfs to hard drive and run them from there. DSL does this and it is a godsend for low power machines. The same can be achieved by copying the files after you boot, and then rebooting, but it makes that first run painfully slow on some of those marginal machines (of which I own two).

Nathan, I think Puppy1 used to do it automatically -- I booted it on a 64MB machine and I'm quite positive it copied the sfs on it's own (rather than me copying it...).
Maybe Barry cancelled it as part of the "zero footprint" idea with Puppy2.

Nathan, the busybox config file and the upgrade to 1.4.1 is only for the initial ramdisk. The config file is setup specifically for that environment. I haven't got around to doing it for the main part of Puppy yet, mostly because I'm nervous it might break some scripts.

A 'noramsfs', yes, or alternatively it might be good to revisit the logic that decides whether to copy the pup_xxx.sfs file into ram or not.

Barry - just thought I'd ask as to the reasons for using the "initrd" init-ramdisk method versus the "initRAMFS" method for puppy's 'initial-ramdisk' ?

I stumbled across some info which might be pertinent:


initRD vs initRAMFS:
initRAMFS is, as it's described in the kernel documentation, 'a chunk of code that unpacks the compressed cpio image midway through the kernel boot process.' The files contained within that image are then used to populate the root filesystem. Initramfs is a part of a bigger concept called 'early-userspace'. It's described in detail in <kernel-sources>/Documentation/early-userspace/. The general idea is "if it can be kept out of the kernel, let it stay that way".

I'm not going into any huge debate about the pros and cons of these two but one thing I will mention is that initRD is [b][i]old generation[/i][/b] and there are plans to supersede it. "With what?" you ask. Currently there are two options being looked at that I know of, one is yaird (name speaks for itself) and the other is initramfs (which I will be talking about here). If you want to know more try Google but for now there is a Debian comparison available at http://wiki.debian.org/InitrdReplacementOptions

With initramfs you'll not notice any significant differences, in fact if you install it correctly, you should not notice any changes.

Simple really, firstly I was tired of upgrading the kernel and replacing the unionfs.ko module with the latest revision and getting all those out of space errors becuase it was to big to fit in minirt. Secondly, I've added the fbsplash patch, to to my distro and to get the live splash screen working required an initramfs image.

Another benefit that comes out of it for me, is that I can edit my 'init' root image at any time, and rebuild it with one line of code. There is no immediate size limitations and i'm all for making things easier and simpler.


Another thing that may be useful is that 'initRAMFS' has inbuilt code to allow for boot splash screens and such ..!!

Just my 2 cents worth..

Interesting ..Huh..???

Barry Kauler 
craftybytes, yes, that has been on my todo list for ages! I must get around to checking it out soon.

Raffy, I presume your 'noramsfs' problem is with PCs that have just 128MB of RAM and no swap partition. Puppy copies the pup_xxx.sfs file into ram in this situation, and with recent Puppies this is a very tight squeeze! I've changed the logic so that it does not copy into ram and is mounted from where it is. A 50MB Mean Puppy will have a small enough pup_xxx.sfs file and the logic will copy it to ram.

Craftybytes, perhaps it is very easy to do a quick conversion to the initramfs. Instead of building our initial ramdisk as a ext2 filesystem, we build it as a cpio archive, and the kernel should just load it as normal -- if support for booting a cpio initrd is built into the kernel. Anyone want to investigate this? Quite an interesting little project I think.

Here's an interesting reference on initramfs:

Looks like we need the Busybox 'switch_root' applet. I'll recompile Busybox with that applet enabled.

It's so interesting, thought I would have a bit of a play. In Puppy Unleashed,

# cd boot/initrd-tree
# find . | cpio -o -H newc > ../cpio

...this is following the instructions in the above link, however this creates a 'cpio' of 18MB!!! gzipped it becomes 11MB. So, what is wrong, why so huge? The list of files created by 'find .' is okay.

Okay, found out the problem. The 'newc' archive format understands symbolic links, but a very recent cpio program is required. The version in Puppy is too old. I grabbed 'cpio' from Vector and it worked. Did this"
# find . | cpio -o -H newc > ../tmp2/initrd
...ah, just 1216KB.
I'm gonna play with this some more tonight!

Yes John Doe, I too thought of dmcrypt when Barry said a new Busybox was coming in. I recall the dmcrypt development dead-ended when we discovered the old Busybox would not support it with one of the commands. Modern crypto, cool!

But we should still keep kirk's cryptoloop of course. No need to complicate Puppy further at this point.

Now that everyone is making the case for boot parameters, I might ask for "noswap" again since cryptoloop security is defeated by swap. In fact I wonder if no swap might be the default with an encrypted pupsave? Just a thought (likely to cause howls of outrage).

Hi Barry,

You might want to try this to make the 'cpio' file even smaller:

#cd boot/initrd-tree
#find . | cpio -0 -H newc | gzip > ../initrd.cpio.gz
# cd..

Can be a goodly reduction in size..

You can then pass this 'initrd.cpio.gz' file to Puppy's kernel during bootup using the normal boot scripts..

And you can extract the 'cpio' archive into the current directory with:

# zcat initrd.cpio.gz | cpio -i -d -H newc --no-absolute-filenames


Have been researching this - dl'd many pages of info on 'initramfs' and how to use it in various linux's - does look to be a much easier method to possibly use for boot-up in Puppy - also allows to use 'unionfs' (or even 'aufs') and for 'encrypting' systems ..

One major advantage that I see just from reading the available info is that it has in-built mechanisms for allowing 'dynamic' memory allocation / reallocation by the kernel ONCE the initial root file system files have been loaded and finalised - the space in RAM used by the 'initrd.cpio.gz' file can then be reallocated for use for other progs AND NOT TIED DOWN as is the case with Puppy's current 'initrd' file which is kept in RAM taking up space but is not actually used by the main system .. (mind - correct me if I'm wrong with this)..

If we really decide to go this way - we don't need to recompile the kernel to use it as the 'standard' in-built 'initrd' function in the kernel will take care of running our new 'initrd.cpio.gz' file automatically..

Anyway, I hope I've got people to at least think about the possibilities..

just noticed an error..

should be:

#cd boot/initrd-tree
#find . | cpio -o -H newc | gzip > ../initrd.cpio.gz
# cd..

I had a '-0' (numeral) instead of '-o' (letter) after the 'cpio'..


You might also possibly consider that if you go with using the "initRAMFS" method - that you could then break up the existing 'initrd' script into smaller [i]function[/i] specific modules that can be used to "finish off" the system boot-up & configuration - instead of including them in the 'initRAMFS' init script - just a thought..

Barry I'm having a Problem w/ ACPI on M' Toshiba Satyrlite M50 1.4 GHz Celeron, How is it on Y'r Acer Laptop?

SATA and USB CD/DVD drives: request for info 

I don't have either of these, so rely on feedback.
We are attempting to get Puppy to boot from these CD/DVD drives. Feedback on the forum is that these types (SATA and USB CD/DVD drives) are showing up as /dev/sc*

What I need to know is whether the 'sr_mod' kernel module is affecting this device naming, and/or the availability of these drives. For anyone who has these drives, if you are able to get Puppy 2.14 or 2.13 running, could you open a terminal window and do this:

# lsmod
# probedisk
# rmmod sr_mod
# probedisk

I would like to see if removing sr_mod has any affect. I put the 'lsmod' there so you can check that sr_mod is loaded. If for some reason it isn't, try probedisk then load sr_mod (modprobe sr_mod) then run probedisk again. Thanks.

NOTICE: This blog script is rather buggy, and I'll be upgrading it very soon, so it could be offline briefly (or more than briefly if there's any difficulty with the upgrade!)

Should there be another drive I/F included in your list, Barry??!!
Seriously though, since USB appears to be a scsi emulation and SATA is somehow implicated in the scsi scenario, one wonders whether getting to grips with real and imaginary scsi might pay dividends in the long term? or not?!

HP Compaq nc4010 (doesn't boot puppy from its usb cd):

[pre]sh-3.00# lsmod
Module Size Used by
usb_storage 83904 0
usblp 13680 0
evdev 10016 1
kqemu 115236 0
snd_mixer_oss 17328 0
lp 12520 0
parport_pc 32100 1
parport 35080 2 lp,parport_pc
apm 20100 0
yenta_socket 27516 4
rsrc_nonstatic 12912 1 yenta_socket
tg3 105748 0
i2c_ali15x3 7700 0
i2c_core 21408 1 i2c_ali15x3
wlan_scan_sta 13968 1
ath_pci 92144 0
ath_rate_sample 14256 1 ath_pci
wlan 194268 4 wlan_scan_sta,ath_pci,ath_rate_sample
ath_hal 191216 3 ath_pci,ath_rate_sample
slamr 434056 0
snd_ali5451 23164 1
snd_ac97_codec 90448 1 snd_ali5451
snd_ac97_bus 2128 1 snd_ac97_codec
snd_pcm 77592 3 snd_ali5451,snd_ac97_codec
snd_timer 23540 1 snd_pcm
snd 51396 6 snd_mixer_oss,snd_ali5451,snd_ac97_codec,snd_pcm,snd_timer
soundcore 9408 1 snd
snd_page_alloc 10008 1 snd_pcm
fuse 44388 0
unionfs 77792 1
nls_iso8859_1 3984 0
nls_cp437 5648 0
sr_mod 17412 0
ide_cd 40100 0
cdrom 39424 2 sr_mod,ide_cd
ehci_hcd 30200 0
ohci_hcd 20564 0
usbcore 126116 5 usb_storage,usblp,ehci_hcd,ohci_hcd
sh-3.00# probedisk
sh-3.00# rmmod sr_mod
sh-3.00# probedisk
sh-3.00# [/pre]

Hi Barry,

I can again highlight my unusual problem with the PUPSAVE file causing bugs ... Hope this helps. 915 notebook with external USB DVDRW-CDROM.

Puppy 2.14 Frugal with PUPSAVE
USB DVD-CDROM connected during boot
#probedisk = /dev/scd0|CD-ROM| etc etc
#rmmod sr_mod
#probedisk = no scd0

Puppy 2.14 Frugal with PFIX=RAM
USB DVD-CDROM connected
Also tried with USB DVD-CDROM not-connected during boot
mounting /dev/hda8 on /mnt/dev_ro1 failed: Invalid argument
unable to identify CDROM format
expr: syntax error
-gt: argument expected
mounting /dev/loop0 on /pup_ro2 failed
kernel panic

Puppy 2.14 Boot from USB DVD/CDROM with PFIX=RAM
sr_mod loaded
#probedisk = /dev/scd0|CD-ROM|HL-DT-ST DVDRAM GSA 4082N
#rmmod sr_mod
#probedisk = /dev/scd0 etc etc as above

Pizzapup 3.0 Frugal with PUPSAVE
USB DVD-CDROM not connected during boot. Connected after boot.
sr_mod loaded on boot
#probedisk = only hard disk
#rmmod sr_mod
#probedisk = only hard disk

Pizzapup 3.0 Frugal with PFIX=RAM
USB DVD-CDROM not connected during boot. Connected after boot.
sr_mod loaded on boot
#probedisk = /dev/scd0|CD-ROM etc etc
#rmmod sr_mod
#probedisk = /dev/scd0 etc etc as above


Further to my message above, I have had no problems at all booting any puppy releases from my external USB DVDRW-CDROM drive. ie from the 1.x series to 2.14.

Only external USB CDROM problems have been:
- when trying to use the USB CDROM with a Frugal harddisk install and pupsave file.
- when I can use the external USB CDROM (ie from a pfix=boot) burning seems to have problems maybe related to cdrecord?

Blog upgraded. Simple PHP Blog, version 0.4.9.
Test post.

railpostau (railpostau<at>yahoo.com.au) 
Hi, not sure if this is what you wanted, AMD64 Trurion Compaq v6000au notebook..

sh-3.00# lsmod
Module Size Used by
snd_pcm_oss 46336 0
snd_mixer_oss 17328 1 snd_pcm_oss
lp 12520 0
parport_pc 32100 0
parport 35080 2 lp,parport_pc
usbhid 40736 0
forcedeth 39284 0
snd_hda_intel 18404 0
snd_hda_codec 152368 1 snd_hda_intel
snd_pcm 77592 3 snd_pcm_oss,snd_hda_intel,snd_hda_codec
snd_timer 23540 1 snd_pcm
snd 51396 6 snd_pcm_oss,snd_mixer_oss,snd_hda_intel,snd_hda_ codec,snd_pcm,snd_timer
soundcore 9408 1 snd
snd_page_alloc 10008 2 snd_hda_intel,snd_pcm
i2c_nforce2 7024 0
i2c_core 21408 1 i2c_nforce2
usb_storage 83904 0
fuse 44388 0
unionfs 77792 1
nls_iso8859_1 3984 0
nls_cp437 5648 0
sr_mod 17412 0
ide_cd 40100 0
cdrom 39424 2 sr_mod,ide_cd
ehci_hcd 30200 0
ohci_hcd 20564 0
usbcore 126116 5 usbhid,usb_storage,ehci_hcd,ohci_hcd
sh-3.00# probedisk
/dev/hda|cdrom|MATSHITADVD-RAM UJ-850S
/dev/sda|Direct-Access|ATA TOSHIBA MK6034GS
sh-3.00# rmmod sr_mod
sh-3.00# probedisk
/dev/hda|cdrom|MATSHITADVD-RAM UJ-850S
/dev/sda|Direct-Access|ATA TOSHIBA MK6034GS

railpostau .. are you using an external USB CDROM?

By the way, of course probedisk recognised my harddisk but didn't include these details as this is not related to what you are testing. I only included the relevant info.

rmonroe36 (rmonroe36<at>gmail.com) 
Trying to get my friend to try Puppy Linux but he has Plextor 755SA (SATA CD/DVD)CDROM. Boot stalls with error: cannot find idecd. We will keep tuned to your progress and thanks again for all your hard work as well as those other important contributors!

off topic
  blog looks great!

By the way, just boot with PEMEDIA=usbcdrom.
I also need to disable pcmcia.

sorry typo .. PMEDIA=usbcdrom

Hi Barry!

The good news (about Puppy) just keep on coming!! (as always...)

About the SATA & USB CD/DVD drives...I would like to remind of a specific issue (somewhat related...) with standard IDE CD/DVD drives on motherboards based on Intel 865/875 & ICH5 chipsets. These motherboards have both SATA and IDE and when you have both SATA and IDE hard disks you may operate the motherboard in two distinct modes:
> (For WinXP only) True SATA mode in which all SATA devices are identified as SATA and IDE as IDE
> For Win2K/WinME etc as legacy or emulated mode in which SATA devices "pretend" to be IDE in the hardware level...

If one has the latter mode on - typical on a Win2K installation - it seems to be impossible to boot Puppy LiveCD, because device probing identifies the optical drives as SCSI devices and the init script crashes...The only solution is to manually change BIOS settings every time Puppy is needed (which is a pain in the !@$%^$!)

Is this problem (easily or relatively easily) fixable????

(It is possible to boot from USB flash and the optical drives appear in MUT with error)

Forum thread to continue this discussion:

Humongous initrd, just like Puppy 1.x 

A long time ago when we were on the Puppy 1.x series, we were able to build Puppies that were composed of just two files, which had advantages for network booting.

Well the 2.x series is about to get that capability. Anyone with PXE or NFS or any kind of remote booting or interest in said topic, please read and respond to the forum thread:

Cool ... That's something I really miss, because it also allowed booting on some devices with weird PCMCIA SCSI cards and stuff ...


Xorg Video Wizard much faster 

Dougal has waved a magic wand over my Xorg Video Wizard script and made it much faster, plus fixed a couple of bugs. We would like to test this on lots of different video hardware!

Download 'xorgwizard.gz' to /usr/sbin
Perhaps rename the original, and uncompress the new one:
# gunzip xorgwizard.gz
# chmod +x xorgwizard

To test, exit from X and just type 'xorgwizard' at the prompt.

Forum thread with download link (see latest attachment) and discussion:

No need to exit from X -- selecting to run the wizard in the big dialog exits from x and runs the wizard.

The latest version I posted did not contain the extra resolutions added in 2.14, just in case this is the same one...

Ok, just saw the post -- the second part of my comment can be ignored.

Unfortunately the new Xorgwizard didn't solved the problem with missing resolutions in display resolution list for my ATI SAPPHIRE RADEON 9200SE ATLANTIS 128 MB graphics card and Sony SDM-M51, LCD, 15" monitor.
There are still only this two resolutions listed:

Works like a charm, what a difference:-)

alienjeff (alienjeff<at>charter.net) 
On which versions of Puppy is it "safe" to test this new xorgwizard?

good one Dougal

this link not working

where is the latest file?

Barry Kauler 
The forum thread has an attachment, with latest version.

Ok I found it (It is in Barry's post for 4th March as an attachment)
OK I tried it in 2.15 Viz Alpha. It is faster as advertised. Good work.
I am using an AOC LCD at 1280 x 1024 and an in built VIA AGP graphics.

A note on LCD monitors - the refresh rates are set quite high and have to be hand modified for a friends LCD (or xvesa used) I think 70mhz is the norm for LCD's - anyway thought I would mention that.

Will add to 2.15 Beta priorities . . .

caneri (ericmulcaster<at>gmail.com) 
Xorg wixzard works well on my HP nx9420 with ATI Radeon X1600 with 256mb discete video memory.
horizontal sync...65khz
It's almost instant when booting.
Thanks Dougal

alienjeff (alienjeff<at>charter.net) 
Ed Jason recently wrote: [i]"A note on LCD monitors - the refresh rates are set quite high and have to be hand modified for a friends LCD (or xvesa used) I think 70mhz is the norm for LCD's - anyway thought I would mention that."[/i]

Good luck with a 70-MHz refresh rate ... that's [i]just a tad[/i] too high ...

John Doe 
You're right, it sure is FAST!!

Too bad it doesn't work for me

xorg won't work, xvesa is fine.

I tried several different resolutions and monitor type.

I'll try to figure out how to report what isn't working.

//Slightly Off-Topic


I just got a triple Monitor configuration using the Xinerama option running: I have some hints I want to mention for the script, as can be read here:

3rd post

Maybe it is possible to alter the script so it will add the "missing" entries by itself, mostly in the "Screen" section.

Keep up the good work, I am really impressed about the performance of puppy linux.


John Doe,
after running the wizard, try looking at /tmp/xorgwizard-errors.log and see if there's anything there that can help us find the problem.

John Doe 
Hey Dougal, Sorry about the delay! I've been driving around the state for two days).

Here is what I get:

/usr/sbin/xorgwizard: line 308: 3251 Aborted Xorg -configure >/tmp/xorgprobe.txt 2>&1
cat: /root/xorg.conf.new: No such file or directory
mv: cannot stat `/root/xorg.conf.new': No such file or directory

That means that "Xorg -configure", which is where Xorg probes your HW, has failed... So obviously Xorg has some problem with your HW.
Maybe you should try and search for info about Xorg and your HW -- see if there's a known problem with it.

John Doe 
Strange, xorg's been working with that HW since Barry added it.

I forgot to mention it's a Mobility Radeon 9000

Maybe it was the 3D driver I added. I forgot about that. I'll try again without it and report back.

John Doe 
Nevermind on all that, it works fine on a clean install.

I do some stupid forgetful stuff sometimes.

SeaMonkey 1.0.8 

This is a message that I have posted to the SeaMonkey developer newsgroup:
Okay, a fresh start this morning, after a cup of coffee. I compiled SeaMonkey 1.0.8 with exactly the same config as for 1.1.1, I specified 12pt menu DejaVu Sans font in userChrome.css, and perfect, the menu text, plus all dialogs, render at correct size. I have gtkrc set to the same font and 12pt, but SeaMonkey has never read the GTK2 settings properly, so setting the font and size in userChrome.css works. The point here is, I specify 12pt in userChrome.css and that's what renders, the same size as menus in all other GTK2 apps.

This is the point. SM 1.1.x compiled exactly the same, installed in a pristine system with no other Mozilla to interfere, exactly the same environment, renders the menus and dialogs too big. As mentioned before, I have to set the size to 10pt in userChrome.css to get the right size. This should not be. The default behaviour should be consistency with other GTK2 apps.

With normal GTK2 apps, I can set the menu font in the /etc/gtk-2.0/gtkrc file, except for SeaMonkey (all versions). I can also scale the menu and dialog text up or down by changing Xft:Dpi: setting in $HOME/.Xresources, and if I recall rightly, this works for SM 1.0.8 as it does for all other GTK2 apps. However, not for 1.1.1, which seems to ignore that setting.

Another point that makes 1.1.x unusable is the error messages that keep popping up when composing and sending mail or news msgs. 1.0.8 does not have this problem -- I'm happily using it right now.

So, SM 1.0.8 will be in the next Puppy!

You can access the SeaMonkey newsgroups here:
http://www.mozilla.org/projects/seamonk ... unity.html

I am currently recompiling various packages. These have to be done in a certain order.
1. SeaMonkey, now with Accesibility and TypeAheadFind extensions.
2. ffmpeg, with all the extra goodies.
3. xinelib
4. gxine, kazehakase, gaim
Xinelib uses libraries from both SeaMonkey and ffmpeg. Gaim uses libraries from seamonkey.
I'll upload them as soon as compiling completed.

Eddie Maddox 
Thanks for the hard work, Barry.
Could M3U MIME type awareness be added to SM, too, please?

Thanks again,

Rox 2.6 is out...

from the Rox 2.6 changelog:


- Don't try to thumbnail zero-byte files. They're either empty, or special and
may cause us to hang (Thomas Leonard; reported by Barry Kauler).

- Don't display a warning about deprecated options; it just confuses people ... (it still seems to popup a warning if the -o option is used ... it's easy to remove that by hacking the source, though)

Not sure if I see enough reasons to upgrade, except for the one major bugfix with zero-byte files.

Something that definitely need upgrading is Geany -- there were quite a few bugs in 0.10, so they've been had to bugfix versions, now at 0.10.2.

I don't see the new pkgs on ibiblio yet. Were there some unresolved compiling problems or just haven't uploaded yet? Just wondering on a status update... thanks!

No, just hadn't got around to it. Will upload more stuff soon.

I'm trying out SeaMonkey 1.1.1. to see if I get the same problems with the mail and newsgroups. Could you please specify exactly which font sizes I should change in the userChrome.css file? I'm using 2.12. Thanks!

Nathan found that font sizes and perhaps other things are different if you use the official build, compared with compiling it yourself. We don't know why. Perhaps the fonts are okay and Mail & News works properly in the official build of 1.1.1?

Thanks for answering!
I downloaded Linux GTK2, English (14MB) from http://www.mozilla.org/projects/seamonkey/ and it ended up in
/usr/local/SeaMonkey1.1.1./seamonkey-installer. (Think I made that folder myself...)
Then I clicked the installer and the program itself ended up in /usr/local/seamonkey 1.1.1 and runs from there. The fonts are huge, I haven't had time to really check the mail client yet.


Updated multimedia applications 

Our keen Puppy programmers have upgraded the following applications/applets:

Nathan: Grafburn 0.9.1
Rarsa: mini-volume 0.6
Plinej: PBcdripper 2.4
Zigbert: Pfind 08
Plinej: Pupdvdtool 0.6
Plinej: Soxgui 0.6

They are all uploaded to ibiblio for system builders to access:

Billcnz found out why SeaMonkey was crashing with Flash Player v9. It required the MOZ_PLUGIN_PATH global variable to be set. I have done this in /etc/profile. Added this:
export MOZ_PLUGIN_PATH="/usr/lib/mozilla/plugins"
...it could probably have a bit more intelligence to detect more plugin directories.

export MOZ_PLUGIN_PATH="/usr/lib/mozilla/plugins"
...no, that should be enough, as SeaMonkey is the only one of the Mozilla family that I am starting up with my own scripts. Firefox and others would normally be started via their startup scripts -- I suppose.

putting MOZ_PLUGIN_PATH would affect Firefox as well as Seamonkey, if it were in /etc/profile ... for example, if a person installs Firefox in /root or /mnt/hda11 etc etc etc, that would cause Firefox to look in /usr/lib/mozilla/plugins for plugins ... one problem with that, is apparently using the wrong libnullplugin.so can cause the browser to crash ... so putting MOZ_PLUGIN_PATH in /etc/profile might cause Firefox to crash, if it were installed (it's easy to install ... just download, unzip, and run)

by the way, apparently Gxine is not compatible with a newer library file that is in Firefox, and Firefox sets it's own LD_LIBRARY_PATH to use it's own library file first, so if gxine is started from Firefox using the gxine plugin, gxine will crash ... i worked around this by replacing the gxine binary with a wrapper script that sets the LD_LIBRARY_PATH back to the original one

i looked at the Seamonkey crashing problem, and i noticed that Seamonkey is not being started by running run-mozilla.sh ... run-mozilla.sh seems to set some env variables before executing mozilla-bin ... the way Puppy is starting Seamonkey, these variables are not being set ... and this might affect other parts of the suite ... for example, i have heard at least one complaint that email had been lost

what i did for my SP214 Seamonkey bugfix, was to compare the env vars entering and exiting run-mozilla.sh, and i added the env vars that run-mozilla.sh seemed to set to mozilla-bin ... i thought this might fix the crashing problem, but it still seems to need the MOZ_PLUGIN_PATH workaround ... i think Mozilla intentionally or unintentionally changed the way the plugin path works ... my Java installer package used to put the plugin in /root/.mozilla/plugins, but that seemed to stop working with newer version of Firefox ... i think the plugin path problem seems to affect other distros, as well

see SP214: [a]http://murga-linux.com/puppy/viewtopic.php?t=15772[/a]

by the way, run-mozilla.sh seems to have a few bugs in it anyway ... though it might be better to start Seamonkey by running run-mozilla.sh ... then mozilla-bin could be the original binary again


When configuring JWM, please add the mixer parameter to the mini-volume launcher

-mixer <whatevermixer>

e.g. -mixer zmixer

With that the mini-volume will launch the selected mixer from the right click menu.

speaking of updated applications, i recompiled gdmap with large file support ... see: http://murga-linux.com/puppy/viewtopic.php?t=15594

i also compiled gdmap on Puppy 108, and added a Quit button as a workaround for ctrl+Q not working ... i think the quit button makes gdmap more convenient to use ... i haven't had time to look closely at the source, it's possible that ctrl+Q does not work because the keypress event is not properly linked with the action, i would think it would be easy to fix

Rarsa, you'll have to spell it out for me, I don't understand the example. I haven't had my morning coffee yet.


VIZ meeting - Developers welcome
Thursday 1 March 12 noon to 2.00 PM GMT
meet at #puppylinux-foundation

enter #puppylinux-foundation without any spaces in the appropriate location in your IRC client.

10:00pm to 12:00 midnight - Sydney time
yep short notice but let us see what happens

Greets, meets and introductions
Progress reports
2.15 core priorities
plans - how does Viz fit with 2.16, using GIN, Using the 3 GTK dialogs
priorities for the Beta
Next meeting (more warning)


Here it is the .jwmrc-tray swallow section for the mini-volume

<Swallow name="mini-volume.tcl">
mini-volume.tcl -bg gray90 -mixer pvolume-mixer.tcl

Of course if you are not including pvolume-mixer you can specify any mixer applicaiton you want. e.g.

<Swallow name="mini-volume.tcl">
mini-volume.tcl -bg gray90 -mixer zmixer

Jason Pline 
Nice rarsa, works great. I was wondering how to do that.

New wireless firmware 

Tempestuous (forum name) got together extra firmware for various wireless drivers in Puppy v2.14. The link for downloads (courtesy of MU) is:
http://puppyfiles.org/dotpupsde/dotpups ... 2-to-2.14/

I have updated the "zdrv" module. Added the firmware for the bcm43xx.ko , hostap*.ko, prism54.ko and rt61.ko modules. In the case of hostap and prism54, there was already some firmware, so topped it up with the eatra firmware files.

I did not add the zd1211.ko and zd1211b.ko modules as they cause 'depmod' to crash. This may be because the kernel has been recompiled for 2.14 -- the source was patched a bit more, and the '.config' file is different (the latest patched source is at http://puptrix.org/sources/kernel- courtesy of Ted Dog. Latest '.config' file is to be found at /lib/modules in Puppy.

Ouch! A 2.14 kernel incompatible with the one in 2.12/2.13 is something none of us wants.

But I'm happy to report that I just booted into 2.14 from CD, loaded the "standard" Zydas driver with "modprobe -v zd1211rw", then installed my "community" versions as well, and they all co-exist happily.
"depmod" works fine, and "modinfo zd1211" does not indicate any unresolved symbols.

Barry, maybe there's something installed in your development environment that's causing the problem?

Exploring the issue futher, I compared the 2 kernel configs with diff. The only differences (apart from the patch) are the addition of extra modules, namely - ieee80211softmac, bcm43xx, zd1211rw, and several bluetooth modules. There's no change to the kernel itself.

And by coincidence, a new version of the community Zydas driver has just been released: "r85" from http://zd1211.ath.cx/download/
Barry, maybe you could compile this and add it to Puppy's ever-expanding module collection?

rarsa reports here http://www.murga-linux.com/puppy/viewto
that the community Zydas driver seems to work better than the "rw" version.

Barry Kauler 
Hm, yes, something must be amiss in my environment. I thought it mighty odd that depmod actually crashed. I removed those two modules, and depmod worked. But, Ive been compiling all sorts of things, so probably some strange conflict there.

New Gtkdialog PET package 

We use Gtkdialog to create GUIs for scripts. Many Bash/Ash and PuppyBasic scripts in Puppy make use of Gtkdialog. The problem has been the lack of compatibility between different versions of gtkdialog. In Puppy 2.14 and earlier we have Gtkdialog v0.58.8 and v0.59.8, the former having executable 'gtkdialog' and the latter 'gtkdialog2'. We have scripts that use both.
The author now has a new series, latest is v0.7.18, and this is different again. Our scripts may or may not work. I looked at one of my older scipts that uses 'gtkdialog', and it does not work correctly. Other programmers will face the same problem.
So, I've re-uploaded 'gtkdialog-0.7.18.pet' PET packge to ibiblio, and the executable is named 'gtkdialog3'. I propose that all three of the Gtkdialog packages will be in the next few releases of puppy. Wasteful, yes, but they are very small executables. Any new scripts, please use 'gtkdialog3' -- there is a 'gtkdialog_DOC' package with examples that show how to use this latest version. Authors of current scripts, there's no hurry, but do plan to move over to 'gtkdialog3'.

The latest 'gtkdialog-0.7.18.pet' is here:

V2.15CE guys, could you put this package in also?

Have added the new .pet to the Beta priorities for Viz

[blockquote]Also of interest may be this email from
Peterpaul Klein Haneveld

I wanted you to know that i released the sourcecode for the linux version of linoleum. If you're still interested you can download it from the thread in the linoleum forums:


Also if you know any developers through the puppy linux comunity, who might be interested in developing this RTM, please point them to this thread.


for those unaware of Linoleum it is a an easier to use than 'C' cross assembler language


Is there a list somewhere of scripts using gtkdialog? Are all Puppy scripts under /usr/sbin so I can grep for gtkdialog?

I would certainly have a look to convert as many scripts as I can to gtkdialog3.

The initial "cost" of migrating to gtkdialog3 may be high, but I am convinced that in the long run it will simplify maintenance.

I considered this exact scheme when I started development of Grafpup-2.xx but rejected it, on the basis that not only is it wasteful by including 3 versions of the same program it also makes migration more complicated. Now we will have a whole new crop of scripts written that reference "gtkdialog3", along with the older ones that use "gtkdialog" and "gtkdialog2", so when everything is eventually ported over we will have to either change all scripts using gtkdialog2 and gtkdialog3 so they call just gtkdialog, or else leave symlinks in place pointing from gtkdialog2 and gtkdialog3 to gtkdialog. Confusing if you ask me, which is why I didn't do it. If this is the official word I will of course follow along, but I would rather have a few developers go through and fix all the problems now than leave it for a later release cycle to sort it out. I was all set to volunteer some time as a matter of fact. Basically I'm not in favor of procrastination, and I think we should take the plunge if we're going to upgrade the binary.

Jason Pline 
I don't think it'll be too hard to port the gtkdialog2 stuff over to 3. I've been working on PBcdripper since last night and I think I finally figured it out. Just have a couple more buttons to change. After I get done I'll post a 2.4 version that depends on gtkdialog3.

Jason Pline 
I have PBcdripper 2.4 all packaged up in a dotpet but I just thought of something neat I'm going to try that I saw in an example of the new gtkdialog. New version should be posted soon.

Jason Pline 
I didn't think my idea thru and realized it wouldn't work so here's a link for PBcdripper-2.4 depending on gtkdialog3.


Barry Kauler 
Nathan, I don't think it will be too difficult to convert all scripts that use 'gtkdialog3' to just 'gtkdialog'. In Puppy Unleashed (to answer Rarsa's question), use Turma (or Pfind!) to find all scripts that have 'gtkdialog3' in them, and if we don't trust Turma to do an automatic replace then can open up each file and do it manually.

That was my thinking, take the easy way out for now, then by say v2.16, everyone should be onto using gtkdialog3 and we do the search and replace. And for the release of 2.16 there will only be the one executable, 'gtkdialog', no symlinks.

Barry Kauler 
...er, no, not Pfind, that's for finding files, not for looking inside files!

Jason Pline 
I just revised Soxgui & PawdioConverter to work with gtkdialog3 and new dotpets have been posted in the community forum. I'll work on Pupdvdtool later in the week followed by my other programs. Barry, not sure if you saw my PawdioConverter but I took the audio conversion part out of Soxgui and just made it a link to PawdioConverter because I believe it's superior and it has support for more formats (only listed if correct executables are installed). Just figured I'd let you know so you can add it to future Puppy's.

Pfind also grep inside files, but not as default. Use advanced settings.

GINS improved 

The original author of GINS only created one release, 0.1beta, and some things were left incomplete. Puppy enthusiast BradC (forum name) has stepped in and improved GINS.
I have ported the "Set global font size" applet (in the Desktop menu) from Tcl/Tk to Bash with GINS. Very simple. This was only possible due to Brad's improvement to gins.
Forum thread (with latest GINS and my example code):

Am playing with v2.14 at the mo - looks a big improvement over previous 2.x versions ..

Just a quick one - with these 'redone' (or new) scripts - where do we put them for puppy to use.? ...

And Q2:=

I see that in the 2.14 Unleashed CD - in the 'packages' folder - you have changed the packages to the '.pet' format - I assume that they are the same (in reality) to the packages in the 2.13 Unleashed CD..?

What I was trying to do in 2.13 Unleashed was to add any "new" packages that I really wanted in my 'final' Puppy version to the 'packages' folder plus add a 'files' text file for each new package in the '0pkgs_db-2.13' file AND update the main 'packages.txt' file - so as I didn't have to load them as 'Dotpups' or 'Dotpets'..

If I want to do the same in v2.14 Unleashed - do I need to do anything different .? ...

AND:- In 2.14 Unleashed - have any of the 'updated' scripts that were found/done before v2.14 final was released - been included .? ..or .. do they need to be added still ..? ..

Other than the above - all looks a winner..

Also meant to ask - are ALL the '.pet' files on "ibiblio.org" useable in Puppy v2.14 - or could some of them "BREAK" it ..?

At the mo - none of the current crop of 'Dotpups' or 'Dotpets' indicate as to what versions of Puppy they will reliably work (or not work) in - nor is there any list or guide as to what 'pups/pets' are recommended to be installed to the likes of - v2.12/v2.13/v2.14 - at least something that would give us "dumbed-down" puppyites a guide as to what each 'pup/pet' is supposed to do - WOULD BE A BIG HELP ..

No, they are not all guaranteed to work in latest Puppy, due to lack of testing.

Ibiblio still has the pupget_packages-1 directory, which has all the PupGets designed or 2.13.
Ibiblio has the pet_packages-2 directory with all the PET packages, and PETget package manager will look here first. These are for 2.14.

We don't have space to keep repositories for older Puppies. The pupget_packages-1 directory has packages that may or may not work on older Puppies.

The intention is, when we move to 2.16, 2.17, that new PET packages will get added and the pet_packages-2 directory will have packages to support a few Puppy versions.

Some folow ups to yesterdays comments section . . .

Tcl-visual is written in tcl
- it is just a script started with

"wish tclv" form Bash

Visual tcl

Learning tcl in Puppy


gtkdialog2 is added as a priority for Beta2 - make sure it appears or is added by Warren (whodo)

Vincent is cute :)

The AMD motherboard is one of many that can be flashed with a Linux Bios - yes we should (if purchasing motherboards) support those with such a capacity

I would also consider John Murgas Lua which comes with an IDE and has already been adopted by DSL who are solving many similar problems to Puppy. For many reasons I feel his is a very good choice.

I got Gin working (with Barrys example) OK with 2.15 Alpha.

Other options are also open to us XUL, javascript and actionscript. XUL is used (can be used in Seamonkey too) to create added tools, many already available for Firefox - some, as was mentioned on the forum, which might be superior to Puppys existing programs

New developer PET packages 

I have uploaded these packages to ibiblio:
freebasic-20070112-i386.pet (2424KB)
freebasic_DOC-20070222.pet (3691KB)
gins-0.1beta.pet (8KB)
glade3-3.0.3-i486.pet (334KB)
glade3_DEV-3.0.3-i486.pet (32KB)
glade3_DOC-3.0.3-i486.pet (92KB)
glade3_NLS-3.0.3-i486.pet (109KB)
gtk2_reference_DOC-2.x.pet (3443KB)
gtk2_tutorial_DOC-2.x.pet (444KB)
gtkdialog-0.7.18-i386.pet (53KB)
gtkdialog_DOC-0.7.18-i386.pet (14KB)

They are to be found at:

Most of these are going to be in the next "devx" module, however you can download and install them individually right now.
I have decided that the packages used to create the "devx" module will also be kept at the same "pet_packages-2" directory as the rest of the packages used to build the live-CD. I am planning to automate creation of the "devx" module, and having PET packages for it is the first step.

The freebasic_DOC package has examples for creating GTK2 applications, including using Glade. Note, the User Manual was in CHM (Compiled HTML) format, and I had to use a Windows shareware converter to convert to HTML and it wasn't a perfect conversion -- the docs are also online in a wiki.
The gtkdialog version 0.7.18 package is the latest, supporting Glade. The gtkdialog_DOC package has the full set of examples from the source pkg, including a Glade example.

I would like to move Puppy to using the latest gtkdialog. Currently Puppy has two older versions, with two different executable names 'gtkdialog' and 'gtkdialog2'. If the new pkg is installed, it will overwrite the previous 'gtkdialog' in /usr/sbin.
Anyone who has a script that uses gtkdialog, could you please make sure it works with the new version? If your script uses 'gtkdialog2', could you install the new version and change the script to use 'gtkdialog'. The objective is that future Puppies will only have the one 'gtkdialog' executable.

Gnocl provides a GTK2 GUI frontend for Tcl scripts. Nathan and Rarsa are keen on it. It has an overhead of about 470KB (uncompressed) required at runtime, so from my point of view if four or five Puppy apps use it then it would be justified in the live-CD.
I have uploaded these PET packages to ibiblio:

gnocl-0.9.91.pet (148KB)
gnocl_DOC-0.9.91.pet (451KB)

When the docs install, you will find them in /usr/share/doc/gnocl/.

...well, probably justified anyway ;-)
I personally think Gtkdialog and Glade is the way to go, as it will work with any script, Bash, Tcl, PuppyBasic, or compiled code (C, FreeBasic) ...but of course we don't yet know how complicated it will
be to use and if the minimal docs will be enough. Gnocl looks well documented.

Barry Kauler 
Changing the subject totally, here's Vincent:

A problem with the CVS version of FreeBasic, so I've removed it and uploaded 'freebasic-0.16b.pet' to ibiblio, which is the latest official release.

Jim Lyons (lyons<at>canada.com) 
Puppy gets better and better BUT I can't actually use it until I can print using my HP 1610  My old HP 600 works fine though. Hoping that one day I can leave Windows behind.

I started last night porting a couple things over to the updated gtkdialog. One gotcha is that it no longer accepts the <wtitle> tag, so not only will any scripts that currently use it to set the window title fail entirely but it is not possible with this version to set the window title, unless that can be accomplished by using a glade file. But going that way is probably not going to happen overnight since most people are used to the status quo at the moment.

When you get to the Qt package that will be used to create the "devx" module, please make sure it has the libqt.so, libqt-mt.so, libqt-mt.so.3 symlinks correct and the actual shared object file (e.g. libqt-mt.so.3.3.8). The reason being is that with Puppy 2.14 and devx_214.sfs only 2 out of the three symlinks were there but the .so was not. Thanks!

Actually I like Glade very much. I didn't know that you could do gtkdialog UI's with Glade. When I was writing the network wizard UI and banging my head, I was thinking "I wish this could be done with Glade"

While looking for a decent toolkit I also considered Glade but I backed of because:
- I remember that the libraries weren't in Puppy
- I tought that scripting was more accessible to a broader audience than C code.

Now with the libraries in Puppy It may be time to revisit this. Specially with the nice Glade GUI designers out there.

Even with Glade I think that gtkdialog is suitable for fairly static UIs. If you want to hide/show buttons or labels or otherwise dynamically change the interface, the challenges of gtkdialog are evident.

Gnocl allows for programatic control of the interface so dynamically modifying it is a breeze. Gnocl is not a 100% complete toolkit but I think that it has most of the functionality one will ever need. On the size side, the applications that I've converted to Gnocl have ended up being smaller.

For 100% control of the UI now writing C with Glade with be possible.

This news post from Barry is quite uplifting. Thank you,

Jason Pline 
I've messed around a bit with the new gtkdialog and can't seem to get anything to work.

Jason Pline 
anything meaning already written gtkdialog scripts.

Puppymirror uses gtkdialog, and worked out-of-box with the new gtkdialog package.

Nathan mentioned <wtitle>, but I thougt it only worked with gtkdialog2.

I've looked through the examples. I see some good stuff, and of course some missing stuff.

Nathan, you need to install the gtkdialog_DOC package, which has examples. Gtkdialog has come a long way:
[pre]export DIALOG='
<window title="Example Window" icon-name="gtk-dialog-warning">
[/pre]...not only a window title, but icon too!
The extra functionality in the new Gtkdialog means more powerful GUIs even without using Glade.

I'm wondering though, is the new Gtkdialog going to be in 2.15CE? Perhaps we should aim for it to be in 2.16. If your script needs changes, that's awkward -- perhaps do a version test:
[pre] gtkdialog -v[/pre]
and have some conditional mods to the xml.
Or, we could put the new 'gtkdialog' executable in 2.15CE, leave 'gtkdialog2' there for awhile, until 2.16. Reasoning is, some features in gtkdialog2 were abandoned by the author, I think he went back and used an earlier version as the basis for further work -- meaning scripts currently written for 'gtkdialog' may all still work

...as Zigbert found with his puppymirror script. So how about it, the new 'gtkdialog' in 2.15CE, keeping the old 'gtkdialog2'?

Jason Pline 
Yeah, leave gtkdialog2 in for now. I'm working on making PBcdripper work with the new gtkdialog and have part of it working. It doesn't seem to like the $PROBEDRIVES part in the combobox and there are lots of other little things that need to be changed. The docs definitely help, lots of good examples in there.

The 2.15CE version has been out a few days now and I`m running it at this moment. I think I`ll try my hand at this Tcl/Tk programming see if I can make sense of it, I understand theres a Visual Tcl can we have a Pet Package of it please? One problem is the PetGet Manager losing its list, it goes empty after a while no idea why and I have to copy a new copy of it into the directory. Is there a way of downloading a new list of pet packages - a mirror script - so that users get the latest list.

SouthPaws (jaguar1<at>netzero.net) 
RE:Changing the Subject...Vincent seems pretty cool...Hey Barry and developers...Check this out...I don't know if or how useful this would be to anyone?


Thanks for the tip about setting window title. I have been looking over the docs a bit but hadn't seen this. They really need a good man page rather than just all these examples.

I may try my hand at using glade next. I was going to dig into Gnocle and might still, but this new gtkdialog is looking better to me all the time.

I think it was not good to suggest the names gtkdialog1 gtkdialog2 a while back.

In the meantime, I switched to use binary-names like

So they represent the version.
Maybe Puppy should start using such a concept with the new one?
Not so important though.

Some thoughts on programming 

I have been very busy for the last few days! Rarsa got me thinking about programming for Puppy, as he has started to use Gnocl, which provides GTK2 GUIs for Tcl. Rarsa has created a GUI mixer.
Mixer: http://www.murga-linux.com/puppy/viewtopic.php?t=15640
Gnocl: http://www.murga-linux.com/puppy/viewtopic.php?t=15639

I think that we need to be aiming for a consistent look-and-feel for GUI apps, and this means to use GTK2 as much as possible. Ash/Bash/PuppyBasic scripts can use Xdialog, Gxmessage and Gtkdialog for simple GUIs, however I would like to be able to create arbitrarily complex GUIs for scripts.

The solution is GINS. This is a remarkably simple and small (12KB) application that adds the power of Glade-created GUIs to any script.
GINS home: http://freeweb.lombardiacom.it/kirsoft/gins.html

Glade is a graphical GUI builder. I have compiled version 3.0.3 for Puppy and plan to put it into the "devx" module. Glade creates XML files, and an applcation uses libglade (which Puppy already has) to read the XML GUI-definition file. GINS does this.
I also plan to put GTK docs into "devx", as indepth knowledge of GTK widget signals is required to use GINS.
Glade home: http://glade.gnome.org/
Libglade home: http://www.jamesh.id.au/software/libglade/

Sophisticated GUIs for any script! Yes, but I thought further. I have a particular dislike of C, and am quite taken by FreeBasic. Glade-created GTK2 GUIs can be created with FreeBasic. The Freebasic compiler creates small executables (hello world GUI app is 15KB) and can use any shared libraries just like C, without needing special "binding" modules. I plan to put FreeBasic, with docs, into the "devx" module also.
FreeBasic home: http://www.freebasic.net/

Your thoughts on this most welcome!

vanchutr (vanchutr<at>yahoo.com) 
Your thoughts are talent thoughts.
`basic means create great jobs'
Many thanks. God save you
I think: It is good thing to save Puppy flat, quick, clear (like your Puppy 214 final approx 60-70MB)
(Sorry for my bad english)

A nice start - I hope Mark Ulrich (MU) comments about PuppyBasic, which he has been using in Puppy.

It will be good to begin the scripting exercise on Samba server setup and client printing via a Samba server - this will be a big boost in getting Puppy into LAN environments.

A PET for this will surely be cool.

This is a great idea to get the community involved in learning to program puppy and a PET setup with icon on the desktop would be great.
I notice there are IDE drivers for windows fbide fbedit but none for linux - can geany be integrated and used?. Maybe we can have learning programing scripts and after completion people can download a puppy driver license, a certificate that someone can design called `walkies`-- a puppy walkies license -- sounds fun yes?.

I am using a CVS snapshot of FreeBasic, that has Object Orientation freatures. Yes, no IDE for Linux, but Scintilla has syntax highlighting for FreeBasic, and Scite editor uses Scintilla. Geany does too I think, so I sent off a request to Geany developers.

I have been using murgaLua for some of my Puppy programs that I have yet to release. So far I find it very powerful and easy to learn. It is very small and fast. FLTK is used for the GUI. Our very own John Murga is the maintainer, and I chose it for the same reasons that he put it together.

Using Basic in any form (I like the Freebasic w/Scite flavor myself) for a general, standardized scripting language in Puppy is about as perfect a combo as could be made. Good plan!


GINS PET package here:

GINS home page and download Last-Modified: Sun, 02 Jan 2005. Is it maintained somewhere else?

Have you had a look at GTK-server GTK-server? supports both gtk1, gtk2, and glade. I've compiled it on puppy and the binary is 43k requires a ffi, I compiled CINV C/Invoke (lib binary 51k). Looks well supported, and you can use any scripting language by using one of the invication methods (stdin, tcp, udp, pipes).

Dan Bachmann 
I'd go for C/C++, but I can live with Basic. If the system you choose can write to the serial port that would be fantastic to drive further hardware. If you could compile a little program that would auto-run at Puppy start up you might find this becoming a main stream robotics and home appliance OS!

the latest version of Gtkdialog too supports Glade:

But I had no time yet to play around with it.

Also had no time to look how it could be used with Puppybasic.

I'm curious to see some first examples of all those new tools we get now


Guys, this is really great, you are opening my horizons even further!
Gtk-Server: I can't see any mention of Glade on the webpages.
Gtkdialog: Now supporting Glade, oh wow! I'll create a new official Gtkdialog PET pkg for Puppy.

here is the dotpup because dotpups.de is down at moment.

I also just tried to run gini with Puppybasic, but there seems to be a problem, it does not react to the events correctly. Must have a closer look in the next days.


gins with Puppybasic example


This GINS program looks great. Puppy needs to have a uniform look to it and this will go along with that.

I will be playing with this tonight and see what happens.

Well, we may discover problems with GINS, as the auhor never got beyond one beta release. I ran into a problem with radiobuttons -- I want to preset which button is selected, instead of the default top one. I have sent an email to the author about this -- if he is responsive, then great. Otherwise, now that Gtkdialog supports Glade, despite the poor documentation that may be the way to go.

MU, looked at your PuupyBasic with GINS posts -- great stuff.
I've created 'empty.glade' which is just a window, has some settings to make it work with GINS (the correct callback). This can be opened in Glade and added-to. I'll post it later.

Could not get GINS to work with Glade 3.....

It has to have files created with Glade 2. Glade 2.12 builds fine on my system.

Just a note for anyone trying out GINS.

Another reason to go for the newest gtkdialog is the change from the old style file selector to the new style, which in itself is a huge improvement. The old style is basically two panes, directories on one side and files on the other, with no file icons, memory pf the last open directory, bookmarks, or anything that would be useful in a file selector. The problem of course is that just about every release of gtkdialog seems to break existing scripts in some way, so either we have three versions or we port some existing code over.

I compiled gins myself but right now am having trouble getting it to work properly in Grafpup. Perhaps it doesn't like gtk+ greater than 2.8? That and the fact that it seems unmaintained are a cause for alarm in my book. I'd go with some other way of reading glade files, like the newer gtkdialog.

I'm also developing a keen interest in what Rarsa is doing with Gnocl. I think the potential here is really great. I looked over the widgets available and it's pretty much wide open, as can be seen when looking at the two applications Rarsa has already created using it.

As for C versus Basic that is a matter of choice, and I'm all for having more choices. Either way, having binary programs for complex tasks as opposed to scripted programs is a plus, as reliability and speed are usually better. Interpreters, even Bash, have been known to get a big flaky at times.

Gnocl is about 470KB uncompressed, so to justify putting it into the live-CD there would need to be a few apps using it.
Anyway, I'll upload a gnocl PET package to ibiblio also.

Bradchuck, I have used Glade3 for GINS and it works. Did you set the callback right? I have re-uploaded 'gins-0.1beta.pet' to ibiblio, with /usr/share/doc/gins/empty.glade. This is an empty window that works in GINS and can be opened in Glade3 and stuff put into it. I created a free-layout grid and then created some text, radiobuttons, ok and cancel buttons, and GINS displayed it okay, returned signals okay, at least for initial investigation.

Joe (puppyfan12) 
That looks interesting. Would you recommend it for someone who wants to learn to do programming for puppy to start with Gnocl/tcl or gins/glade/freebasic? Or is there a better solution for someone with no programming experience aside from basic html/xhtml/css markup?

Barry Kauler 
Joe, it depends what level you want to work at. The system-level scripts are all written in Ash/Bash. So are a great many applets, and some applets are also written in PuppyBasic and Tcl.
So, if you like to work at the nuts and bolts level then Bash is a good starting point, and you can think about the GUI interfacing later.

I'm a late commer to this thread. I had a lot of work yesterday.

Here are my thoughts:

- There are many different alternatives for a development toolkit for Puppy.
- Standardizing on a single toolkit or a couple of toolkits will help make the code more maintainable.
- Having each application using a different toolkit has a lot of bad side effects: Code gets stale, creates dependencies on specific contributors, It is difficult (if not imposible) to unify the UI Look and feel.
- The more we standardize the more people will start using those tools to contribute to Puppy.
- The toolkit choosen must be mature enough to know it's going to be around for a while and that it will evolve with time.

- I like C and C++ and compiled languages, but for a project like this I 100 times prefer a scripted language as it does not require to have the source code separate from the executable. Also, although the initial "cost" of including the interpreter may be high, the resulting programs are smaller. Using Barry's example of free basic "hello world" 15Kb, the same tcl/tk or tcl/gnocl or bash/gtkdialog would be less than 200 bytes

- Obviously this is an open project and people will try to contribute with whatever they know, but for what I've seen through out the years, people use "whatever they know" because there is no standard.

- I looked at Gnocl just because it was the only GTK widgetset for Tcl. Tcl is a very mature language with tons of support, examples and tutorials. AND it is already included in all versions of Puppy.

Again, I think we should look at murgaLua. I just wrote a little "Hello Wolrd" program and it was 269 bytes. According to John Murga, the murgaLua executable is all you need to run the scripts. The Linux executable is only 312K. It works very well with C and C++ programs. In fact Lua was designed to be an extension of compiled applications. MurgaLua also works with SQLite which is already a part of Puppy and it has LuaSockets for network applications. John also has FLUID and a script for converting FLUID to Lua. This gives a GUI front end to Lua programing. However I prefer to just use Geany. Here is the code.

-- Define the main window.
window = fltk:Fl_Window(200, 50, "Hello World")
-- Define the box for the window.
box:label("Hello World")
-- Show and run the window.

Can't remember where I saw the glade stuff for GTK-server, but I have used it to load and use a glade file e.g in awk:

function GTK(str)
print str |& GTK_SERVER
GTK_SERVER |& getline TMP
return TMP


# Start GTK-server in STDIN mode
GTK_SERVER = "gtk-server stdin"

# Get Glade file
GTK("gtk_server_glade_file demo.glade")

# Get main window ID and connect signal
WINDOW = GTK("gtk_server_glade_widget window")
GTK("gtk_server_connect " WINDOW " delete-event window")


Puppy 2.15CE project has been launched! 

The next release of Puppy is going to be 2.15 Community Edition, incorporating improvements and ideas that Puppy enthusiasts want. Official releases of Puppy are created by me, and everything gets filtered through me, which is good from the point of view of maintaining a unified development of Puppy. However, now is the opportunity for users to have a more direct input to the final product.

Here is a forum thread, supervised by WhoDo:

Note, I'm still here, and will test the alphas/betas on all my hardware and also offer suggestions and contributions.

How about a simple cd/dvd burner? Something we can just do a COPY CD/DVD such as k3b.

And one that works!

[blockquote]How about a simple cd/dvd burner? Something we can just do a COPY CD/DVD such as k3b.[/blockquote]
Would it satisfy the need if I add that capability to Grafburn? I've been thinking about doing that anyway.


I would certainly welcome this functionality. I tried Grafburn the other evening (in Pizzapup) anticipating this was already there.

I think this would flesh it out rather well - provided it isn't too much work! :)

BTW - Grafburn is a beautiful little app. Good work, mate!


Nathan: Yes! By all means! I'm referring to adding the COPY CD/DVD as an option to Grafburn. I'm sure others would like that too.

Thanks Nathan for listening! And I will add that I admire the untiring efforts and good will of Barry Kauler and his supporting developers. Cheers!

The best one can do for 2.15CE in my opinion, apart from new
applications e.t.c., would be the following 2 enhancements:

1) support for SMP systems (all the new laptops are dual core and
in the near future we will see quad core ones).

2) support for 64bit platforms (AMD ATHLON 64 X2, Intel Core 2 Duo)

Why shouldn't we be able to install and enjoy puppy on brand new
hardware? Why should we have to stick in old Pentium4 e.t.c.?

So guys lets try to convince Barry, to go for it, such that
puppy is not a pleasure for owners of old hardware only.


If 2.15 is to be a Community Edition, perhaps 2.16 should be a stable, bug-free release for puppy. Changes have occured so quickly recently there always seems to be something broken. It would also be nice to have the current GCC compiler.

Is anyone working on a service pack for 2.14? There are a number of updates and bugfixes that didn't make it into 2.14.

Perhaps we should first concentrate on getting these 'cracks' in the foundation fixed before starting to build a new house on it? ;-)


The First 2.15 "V" / "Viz" ALPHA now available

Alpha Viz 2.15 (based on 2.14 Final core) please mirror


It's a great start guys and theme looks good!
I've tested it with the flash-9 fix from the dev forum and that works though I see firefox has got flashblock which is a good idea also.

Just wondering if we're going with firefox instead of seamonkey shouldn't that be in /usr/lib and linked to /usr/lib/mozilla or if we keep seamonkey maybe we can do some customisations like adding the home button extension and a theme with nice icons.

Jim Lyons (lyons<at>canada.com) 
I'd just like to be able to print using my HP 1610.

Erik announces Qemu-Puppy 2.14-1 

Erik is very quick, already a Puppy-flavour based on 2.14! Web page is a nice read:
Freshmeat announcement:
http://freshmeat.net/projects/qemupuppy ... _id=247639

we also have a Manual in 3 languages for 2.14
from Oli and the translators

Oliver, Lobster, and translators, that's great too. I have just been looking through it, there's more there than I realised! ...in fact, an incredible amount of effort has gone into it. I will have to link to your manual from my site -- it's worthy of being linked from the main page at www.puppylinux.com I reckon. Don't expect the link immediately, I'll redo the page soon.

Forum thread for discussing Erik's Qemu-Puppy:

Forum thread to discuss 2.14 manual:

Barry: Please enable isa support into the next kernel ! Thank you.

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