logoPuppy developer news:

from 2.17.1 to 2.20alpha

left-arrow Older news

arrow-rightLater news

Puppy version 2.20-alpha available for testing 

This is not a general release. It is for our Puppy-testers to test. It will most likely be followed by a beta then a final. The iso file is 93.4MB, and you can get it as well as the 'devx' file from here:

This alpha is not intended to be perfect, nor representative exactly of what will be in the final release. I did have a time constraint, as have to upload it today while I have ADSL2 access. From my limited testing though, it looks good.

There are a few things that I have not yet put in, such as the improved Network Wizard that Tempestuous and Dougal have been working on. Also, some packages will be updated by the beta, especially Abiword and Gnumeric.

I have thrown in the Atol 2-pane file manager, just for something to play with, though I doubt it will be in the final.

Some libraries may still be updated. The 'devx' file may not be complete, but it worked okay for a couple of packages I compiled.

Although Xine has its own in-built ffmpeg, I have left in the separate ffmpeg package, as various applications need it, such as Grafburn.

To find out about what is new and can be tested, read down through this News Blog. One new feature is the improved handling of frugal installs -- use the Universal Installer and you will be offered to install into a folder.
Basically, whatever area of interest you have, web browsing, chat, multimedia, installation, boot media, etc., give this pup a go and let me know the outcome.

Of course, the usual thing. If booting on a PC that already has a 'pup_save' file, use the boot parameter 'puppy pfix=ram' to avoid it being loaded. Though, if you have more than one 'pup_save', you will get a menu and you can choose none of them. We don't really want to load an old pup_save just yet, as the upgrade may not be quite right.

Note that the kernel is compiled with loglevel=7, meaning that you get lots of stuff displaying on the screen while booting. This will be changed for the final. I also intend to build 2.20 with the earlier 2.6.18.x kernel, as some people have reported the 2.17 pup not working properly and it appears to be a kernel version problem -- I'm not sure about one thing, dialup dropout may be a problem with the 2.6.21.x kernel, which we will verify when we compare the two kernels.

When using frugal install it fails to boot during the boot process.

See details at:

Happy's a great name and all, but is it possible that the appearance of the following link was timed perfectly with this release?


Perhaps this alpha (or the beta) should be renamed "Heart-kun?"

Somebody's gotta do a puppy derivative based on this little guy!

Hi Barry,

I got a kernel panic "not sync/attempt to kill init" at the line .... loading pup 2.20.sfs...then froze the lappy.

I had a 2.17 full hd install (ext3) on my laptop and 2.20 tried to use it even with puppy pfix=ram...so I checked spelling redid the attempt several times and still got the kernel panic.

I went to another pc without puppy loaded on it and 2.20 booted fine.

Then I deleted the partition with puppy 2.17 and the boot into 2.20 was fine on my lappy.

I'm not sure why this happened, or if it is just my machine..but there you go eh.


not sure about dialup in 2.17 but it does work in 2.16 on me laptop! kinda makes all the work people have done compiling drivers for 2.21.5 less valuable if you revert the kernel to 2.18.x quite a dilemma you have there.

Please note that this is a gripe at BLOAT not any of the devs unless of course they wrote the bloat!!!

Imho web-based apps are not the way to go first of all older computers can't even run semonkey! second there are security issues. third they are slow on dial up should i go on? On my laptop it was useing 74mb out of 64 meaning 10mb was in swap that is very bad. bad seamokey bad bad....BANG!!! it locked up my laptop so i had to kill it. i hope you realize that puppy linux is now slower than windows 98! which ran firefox 1.5 like a slugish charm(slowly but surely). seamonky is unusable. if you have got 128mb or more maybe it is ok but eventually it won't even run on that.

we need to do something!!! hv3 even locked up (could be just a bug).
if mozilla wants to make apps that are too heavy to run on 64mb ram which was plenty back in 98 then we need to drop thier browser.

look i don't need an html composer email app and web broweser all rolled into one i need small apps that get each individual job done. unless such an app is actually more efficient and seamonkey is not.

while i realize that 64mb is not enough to load puppy in ram it should be enough to run it and ALL the apps as a frugal install.

i really don't see how people can use it with 48mb if 64 is not enough my main gripes are with seamonkey and gxine and the pdf viewer are very slow. eventually abiword will become to fat.

hope you figure it all out and put gaim back there was nothing wrong with it! you may not use it but lots of people do far as that goes i never use grisbi or that brainstorming app ect... what is the big deal with pidgin anyway i would like gaim better if only it wouldn't hide my offline contacts! we need to stand our ground on the size of the apps if they get bigger then they should not be upgraded and the developers should be contacted is that to much to ask is that bloat not be put in puppy?

sigh................. i enjoy using puppy linux but enough bloat is enough!

look at what meanpup can do can the standard puppy do twice as much?

wolf pup 
thanks barry, now i can use an updated puppy that works with dialup :-)

F M Lynch (fmlynch2<at>comcast.net) 
2.20 does not recognise my prism2_usb module, even after installing the Linux-wlan-ng PET package. Cannot install the Prism2_usb driver, either.

F M Lynch (fmlynch2<at>comcast.net) 
eth0 does not work either. Cannot load any driver manually.

Hi Barry.

Bad news I have the same setup as Eeric - (HD Install of 2.17 on hda1) - and experienced the same kernel panic.


....Later that same day :-

Booted OK on a system with no puppies, though it did report searching for puppy save file. This boot was normal whereas the one that froze was verbose with yards and yards of messages flashing by.

I observe that CUPS is slightly different, and at the end of the 'Add Printer' dialogue asked for a userid and password. Eventually I canceled and got

401 Unauthorized

Enter your username and password or the root username and password to access this page.

I haven't got past that so no printer added.

That's all for now.

..... Exit pursued by a bear.

Awhile ago it was mentioned that there would be a release suitable for low-power machines. I have 1.09CE but am wondering if it's still the game plan to bring out a 2.X release for low-power (in my case, 48MB with 256 swap) -- ??

This is the firt Puppy that's been able to use my Viewsonic N3250w LCD at its full resolution of 1360x768. Thank you, Barry!

installed on usb hd, frugal
nothing works, boot fails ...
i have to hide all pup_save.2fs (renaming)
then it boots...
but xorgwizard failed.
(i use an old b/w monitor, but 2.16.1 works (but i have had sometimes trouble with 2.16.1 ))
i connect a newer 2 year old monitor for xorg wizard - nothing.

i give up.

another problem with 2.16.1
the same files (all puppy and pup_save) behave totallydifferent on internal cf-card and usb-flashdrive

"free" and the freememapplet report totally different values
with a 256 mb cf-card and a 65 mb pup_save i have more ram and freemem reported than with the SAME files booting from my 4gb usbstick.
even after resizing the pupsave to 128mb it reports 26 mb avaible.


regards :-)

hardware is alix1c http://www.pcengines.ch

OOPS!! Just read the release page -- THIS is the version for low-RAM pc's -- SORRY!!

john biles 
Barry K,
I also experienced Kernel Panic with 2.20alpha while booting it up live.
I also have a version of Puppy (2.14) installed to HD, so it seems to only effect those users running Puppy on their HD's?

Boot from CD with pfix=ram seems OK. It seems to pause for quite a while at the fsue init stage. Get the keyboard selection screen but no country selection prompt.
When it comes to saving to disk it decides instead to save to CD (hdc) and computes the file space as -1MB. This doesn't work of course. (Menu/Shutdown/Reboot goes to SaveToFile, Normal, and Final Sanity Check without prompting for the disk to write to.)
I am using a 450MHz CPU 160MB memory Acer 4100 PC with hard drive split into hda1 (100MB ext3) hda2 (3.7GB ext3), and hda3 (300MB swap).
I get exactly the same problems whther I use pfix=ram or select 0 when prompted for which pup_save (created by previous Puppy versions) to load.
I'll try it on another machine and see how it goes...

[blockquote]OOPS!! Just read the release page -- THIS is the version for low-RAM pc's -- SORRY!![/blockquote]
No it isn't ...what release page are you referring to?

WN2A (wn2a<at>qsl.net) 
OK, Here's the scoop (2.20-alpha-seamonkey Live CD):

1) Tried 2.20 first on the workhorse Dell XPS R400 (PII).
CD boots, screen goes blank after setting up Xorg for 15" CRT.
Video card: Diamond Fire GL1000. Same card does fine with Puppy
2.14/2.15CE/2.16/2.16.1/2.17 (and 98se/XP)

2) Replace video card with Trident 3Dimage 975 on same PII. Now
Xorg sets up OK, desktop appears. Puppy 2.20 looks great,
and all other OS's also OK.
(I use multiple HD mobile racks)

3) Another test, different PC. This time HP/Compaq d530 (P4).
No problems, 2.20-alpha-seamonkey Live CD runs super.

OK with Trident card on the PI, but what changed from 2.17 to 2.20?
Could it be Xorg or Xwin desktop ? Test repeats same result.

Looks like another fine Puppy!

Hi Barry,

Like in 2.16 and 2.17 there is still the bug with foreign keymaps in 2.20-alpha, when using xvesa.

There seems to be always the US keymap instead of the DE keymap for instance, which cannot be changed in the settings. When you switch to Xorg, everything is ok.

As due to hardware I sometimes have to choose xvesa, I sometimes cannot use the special german letters "ö,ä,ü,ß"


On an ASUS 500MHz 160MB PC it goes through the normal save session screens, so that's good.
On an Acer TravelMate 603 laptop it fails at "Loading the pup_220.sfs" stage with "Kernel panic - not syncing: Attempted to kill init!". (I have Puppy 2.14 installed and working fine on this machine although I had to use "puppy pnpbios=off" to avoid a kernel panic early in the boot process.)
On an HP Compaq d530 (2.8GHz, 512MB) it showed "Making the filesystem useable failed", gave some ISO9660 messages in red, paused for 60 seconds, continued to start X OK, but again couldn't find a hard disk to write the save file to.
My impression is that 2.20 is significantly slower to boot than 2.17 and not very reliable. The painful price of progress?

FreeBasic, TkDVD updated 

FreeBasic, TkDVD updated

FreeBasic compiler is in the 'devx' file. I have updated it from v0.17b to v0.18.1b.

TkDVD is a CD and DVD burner application. I have updated it from v4.0.3 to v4.0.6 and also fixed the window-size problem that cutoff the "Burn" button.

Would it be possible to have the kernel headers back in the devx. My reason for this can be found at http://www.murga-linux.com/puppy/viewto


Found a source for the rtl8180 wifi card that builds on

Size reduced 

Okay, I have reduced the live-CD ISO file to 93.2MB, about the same as 2.17, and I'm aiming for even lower.

Nothing drastic has been done. Gaim/Pidgin is gone, replaced with the online chat system, which gives access to Yahoo, MSN, IRC, etc.

Perl is retained, or rather the cudown Perl package that has just enough functionality to satisfy Ndiswrapper and CUPS ..hopefully it works, as I had to upgrade it for Slack compatibility. Although Slackware 12 has Perl version 5.8.8, same as Puppy 2.1x, there are some layout differences. I just created a 'perl-5.8.8tiny' with the different directory layout but all the same files taken from Slack.

ESP Ghostscript from Slackware 12 has an extra dependency, Gnutls, so I had to put that in, along with its dependencies, libgcrypt and libgpg-error. I wish they had compiled it to use SSL instead ...oh well, I guess Gnutls is good to have, as there are other packages that use it and can now be plonked straight in.

I took out SDL. We have never had this in previous puppies, but it would be nice to have for the gamers amongst us. It's not all that big ...maybe if I can do some size-hacking elsewhere, I can sneak it back in.

I discovered that the 'createpuppy' script in Unleashed has a bug. I had 'xorg_BASIC-7.0' and 'xorg_BASIC-7.2' packages in the 'packages' directory, with only the latter "on" in 'packages.txt', however createpuppy blended both packages into the live-CD. I had to remove the old one from the 'packages' directory. Right now I don't have the time or inclination to sift through the script and find why it's doing that. So, for now, I need to whip up a little script to put into Unleashed-core that only downloads packages in 'packages.txt', not everything from ibiblio. Just a warning for people who use Unleashed, in case I don't get around to fixing the bug before the 2.20 final.

Maybe this unleashed downloader script could be of use.

Also on createpuppy script bugs
There is an extra "exit" after the line that reads
[blockquote] [ ! "$yabbo" = "" ] && exit[/blockquote]

meebo doesn't have IRC, as far as I can tell


Various updates 

I have a backlog of stuff that our Puppy-enthusiasts have sent to me or notified me about. Well, here's a start:

From Tempestuous: dhcpcd-3.1.4. This fixes a bug that was in 2.17.1.

Forum member 'gray' has been learning how to use Gnocl (enables writing GTK2 GUI apps in Tcl). He has rewritten 'cdburner-wizard' ("Setup-->CD/DVD drive wizard" menu), 'set-xftdpi' ("Desktop-->Global font size" menu), and 'video-wizard' ("Setup-->Xvesa video wizard" menu). These will all be in 2.20pre-alpha for testing.

Gray also created a little app called 'Roxpatterns', that can set the background pattern in a ROX-Filer window. I will upload this to ibiblio.

John's murgaLua has been upgraded to version 0.5.5 and I have upgraded the PET package. That will also soon be uploaded to ibiblio.

'915resolution' is a little app that enables widescreen support for Intel graphics chips. I have upgraded to version 0.5.3, which supports more chips than the version we previously used (0.5.2).

Here's a new script to launch pureftpd:


and Dougal's Hotpup would make a fabulous addition.

I just thought of batmon - battery monitor for Puppy. 10 kb. It's not even in ibiblio.



Barry Kauler 
What's the link to Dougal's Hotpup? I'm so busy, I haven't been following the forum closely recently.

Is this it?



" I think the problem is that Barry ended up using the binary versions of probedisk and probpart, rather than the script alternatives...

I re-wrote them and they should work ok."


" srlevitt

Guys, thanks for your help. Dougal has saved the day by letting me test a "HotPup" script he has in test. I'm sure it will be forthcoming in the fullness of time."

Regards Chris

Test post

A project for a Perl programmer 

We have had a problem for a long time. This is mentioned in the previous post. The program /usr/sbin/ndiswrapper is a Perl script. It is used just once by someone to install a Windows wireless network card driver, and for that we need an 800KB (compressed) cut-down Perl package in the live-CD. Other than that one use, it is just dead weight.

It would be truly great if someone with a smattering of Perl code knowledge (or willing to learn) would translate the script to Bash, PuppyBasic, FreeBasic (compiler), C or Tcl.

Aaarrgh! Pakt has just reminded me that CUPS needs Perl! So, before we can dump Perl, any Perl scripts in CUPS would also have to be rewritten :-(

what about murgalua is it the right kind of scripting language? smaller and is portable if it works well it might even get picked up by the cups developers.

Here's the way I see this shaping up:

1) There are a limited number of Perl scripts required, and they are probably mostly of a fairly simple nature for filters and such.

2) Perl itself is big, complex, ugly, and has a well-deserved reputation as a "write-only language", so it should go.

3) We have other scripting languages (such as tcl) that are far more "strategic" for Puppy (with all due respect to John, I don't see (murga)Lua as mainstream enough to replace tcl here. Lua appears to be a fine scripting language, but the bar is set pretty high if you've got to beat tcl to start with, and tcl is widely used, unlike LUA.

4) There are some tools available to do automatic translation of Perl, such as "perl2tcl": http://www.bin-co.com/tcl/ , so perhaps we can automatically convert the few Perl scripts required and eliminate Perl!

Caveat: I have not actually tried the converter above (I just found it!), so I don't know how well it works. Given item 1 above, though, there should be a decent chance of success.

Eventually, Barry may need to provide guidance for the community on the "strategicness" of scripting languages for various applications in Puppy. If we *need* a "heavier" scripting language, I vastly prefer Python to Perl, but think tcl is probably a better fit for Puppy than either, without any real downside except being a bit less popular.

Perl to go also? 

Okay, I have tentatively done something else controversial, I've removed Perl. We have our 'perl-5.8.8tiny.pet' in Puppy, but it is still big (0.8MB compressed). The only place it is used is for ndiswapper installation -- a one-off use only. To have such a big package for just that one-time occurrence has always annoyed me. We do of course have the full Perl in the 'devx' file, so my suggestion is those who want to use ndiswrapper can download the devx file first (via some other Internet access!). After all, the native wireless drivers are supposed to be maturing and cater for most people??

I'm trying to remember... Is ndiswrapper itself a petget? If so, maybe package perl with it. If not, maybe we should make it so? Ndiswrapper is a sort of last gasp when standard drivers don't work. One hopes most users will not have to resort to it, and for those who do, they are already "digging in deep" and shouldn't be bothered with having to add a petget to get it. Standard drivers are getting a lot more reliable lately, it seems.

Back to the original question, losing perl should not be a problem. Outside of ndiswrapper (solved by the above suggestion - if feasible) only developers will be messing with it. Shouldn't hurt the "just works" paradigm for regular users.

Can perl be both in an ndiswrapper package as well as in devx? Or would they trip over each other if both were present?

Please dump something else. I need ndiswrapper to connect.
A 60+ mb download for a 100k program? Surely you jest.

I hate to see ndiswrapper/perl go. Puppy is one of the few distros that seem to have the ndiswrapper installation somewhat automated. I don't think the wireless card drivers are as mature as you think.

Notice that the XAMPP package which has been popular among Puppy users already contains Perl in it

Wolf Pup 
barry, could you LZMA compress some parts of puppy and gzip others to save space?

Maybe it could be moved to the zdrv file. I don't use it, but I think hardware support type items should be included if possible. Could probably put Xvesa there too and load it if needed.

I'm assuming the fat cutting is for 128mb machines and not for download size.

make Puppy smaller and add facilities . . .
one web page - many online services
other examples . . .
online antivirus
media conversion
image editor
Puppy search (log in and double click to see javascript code between "")
more resources . . .

Barry, don't forget CUPS needs Perl!

Hi Barry,

I understand the need to cut the fat as one of the features most people like about puppy is its size but from all the posts I've read what people like the most is the "just works" part of your goal for Puppy.

Although Tempestuos et al. work has made many native drivers available, it is far from covering all the addapters out there. I added Ndiswrapper support to the wizard as it was one of the "most requested" features.

I think that the suggestion to create an ndiswrapper package with a dependency on a very minimum perl package would be the way to go.

The network wizard can be updated to show a message advising installing the package if the user decides to use ndiswrapper.

Regarding Gaim/Pidgen: Chatting (Msn/yahoo) is one of the most (if not the most) popular uses of the computer for people here in North America. Actually people asks you for your MSN address instead of yo

Rarsa, haven't "seen" you for awhile on the Puppy forums/blog! You'll be interested that 'gray' has also taken to Gnocl, further cementing it in as part of Puppy.

Yes, tiny-Perl is staying. I have also had to fall back to Ndiswrapper on one of my PCs.

Reports are that the Meebo online chat system works well. I've set it up to use a cutdown browser window without any toolbars or menus, so when it starts up it looks just like an application.

New "devx" file 

I have created a new 'devx_220.sfs' file for Puppy 2.20. It has a few things wrong with it still, but basically works. I was able to compile these:

NoteCase v1.5.6. This is an outliner application and I love it. Pup 2.17 has version 1.5.8.

HomeBank v3.5 personal accounting. Pup 2.17 has v3.2.5 and we weren't able to use v3.5 then as it requires GTK 2.10.

Some features for developers, Pidgin to go? 

We have been comparing Unionfs and Aufs for sometime now, and the jury is still out. Puppy 2.20 will be able to easily switch between the two by a boot parameter "layerfs=unionfs" or "layerfs=aufs". This is intended for developers only, but if anyone tried this, Puppy will work regardless of which one is chosen -- it is just that there may be performance/reliability/stability differences.
Currently I have set the default to aufs, but that changes from day to day.

The boot parameter 'pfix=rdsh' drops you into a shell in the initramfs (the "initial ramdisk"). Now I have added the ability to continue and switch to the main filesystem and startup Puppy as normal. After being dropped to the shell and doing any debugging required, type this (a message is displayed to inform of this capability):
# exec switch

I'm unhappy about Pidgin, as it is about 4.5MB (uncompressed, after considerable trimming, originally it was about 7MB), whereas our old Gaim was about 2.5MB (uncompressed). The Slackware SeaMonkey package is also very big, as it has been compiled with every option enabled, including some that users are very unlikely to use. One thing that it does have is ChatZilla, an IRC client, and since it's there I'm thinking of moving Pidgin out to a PET package and just have ChatZilla in the live-CD.
I rarely use real-time chatting, and on the few times I do, it is with the #puppylinux IRC, so ChatZilla would do for me. Pidgin would just be a few clicks away for anyone who needs it. Note, removing Pidgin would probably knock about 1.5MB off the size of the live-CD. Anyone have strong thoughts either way about this?

Barry, how do ordinary users tell whether it is Aufs or Unionfs their Puppy is using? (In case they have what they think is a problem caused by the filesystem layering program.)

As far as the chat client, the only time I ever use one is when I talk to my brother in Yahoo chat, so I don't use any of the chat clients in Puppy. I used to go to the #puppylinux chat every now and then but I got disgusted and gave it up.:-(

Hi Barry,

Gaim is good...many use Xchat...some Chatzilla...or Opera

As you said...it's only a few clicks to get a personal app that the user is familiar with.

Gaim is smaller though...and works for me.


How about keeping the old gaim instead? nothing wrong with it - and to many converts, all they know (and care) is how to connect with their MSN friends, Yahoo friends ... IRC is a foreign word to them.

The puppylinux chatroom #puppylinux is and has been dead for quite a while. I would consider ##puppylinux Feel free to look into that yourself or ignore..

How about no gaim|pidgin but www.meebo.com instead. There is also webmessenger.yahoo.com and webmessenger.msn.com.

Haven't ever used giam, won't miss it.

Flash, AUFS runs as a module. Do a lsmod and if you see aufs listed, you're using AUFS.

Marty (subitopiano<at>verizon.net) 
I really like having IM included and agree that keeping the old Gaim is a good idea if no licensing restrictions apply. Otherwise, a similar IM program would be fine. Kopete is fine, but i don't know about dependencies. I think a lot of newbies expect an included IM program.

I've used several IMs and I always go back to Gaim/Pidgin because it's reliable and fast. I would update to Pidgin though because of some new feautures it has and they can't harm.

If you were making Puppy specifically for me, I'd say drop anything related to chat. But it isn't and I think it would probably be nice to have for the rest. On the other hand, there's always PETget for the people who want it. 1.5MB off the cd is pretty good for removing a single app. Especially since Puppy sounds like he's gaining some weight with all these upgrades.

But he's your dog, so feed him as you see fit.

Incidentally, how much does having both UnionFS and Aufs add? Since having booth is only a temporary thing until you decide on one, that means the added weight is also temporary.

Perhaps you can make some notes about cross-version incompatibility owing to the layer used?

As to WebMessenger (Yahoo), I've tried it and it works well. So it will be good to use http://wwwm.meebo.com/

POSTING HERE - I wasn't able to post via Firefox, so I unchecked "Disable context menus" in JavaScript.

Since the only way you can use chat is to be connected to the internet, I think including a link to meebo makes good sense. Chatzilla is very capable for basic irc as well. This is unlike Abiword which you can use offline and cannot be simply replaced by a web-based application. You can save quite a bit of overhead this way. Just my 2 cents.

Keep up the great work Barry!

Raffy, that's an interesting question. I can swap between aufs and unionfs without apparent ill effects.

Thanks for that meebo link guys! Yes, that looks like the way to go. I can make the desktop chat icon launch the web browser at the meebo site.

"Flash, AUFS runs as a module. Do a lsmod and if you see aufs listed, you're using AUFS."

I wonder if it would make sense to additionally put this info into PUPSTATE? At least that is a logical place to look for such things. I don't know if a script would need to distinguish between the two though; I guess PUPSTATE is mostly used by scripts...

I never use chat, so I have little opinion, other than "if it ain't broke, don't fix it". I suspect a lot of users would be annoyed not to have chat as standard though. Puppy's supposed to "just work"...

What I'd like to see is a pupget or sfs of the most up-to-date gnumeric, even if it is not in the "stable" tree. It's a long wait getting to the next stable release, and a lot of stuff has been added since v1.6.3.

Pardon my lobbying. ;-)

well pigin and gaim go :-( well i guess i'll have to install them when i need them (mostly im in windows anyway since i'm on dialup)

Barry Kauler 
I will update Abiword and Gnumeric for 2.20 beta.

I just did a quick check of meebo.com and don't seem to find support for IRC. Am I missing something here?

You are right to keep only small progs, to keep a small iso but also for better running on old hardwares.

Gaim is lighter and faster than pidgin.

You can replace seamonkey with opera and dillo (seamnonkey is 14mb. opera is 5 mb and so much better. dillo is 0.5mb)

And also why 2 file finders ? 2 files editors ? 2 calculators ? 2 cd ripper ? 2 dvd writer ? etc.
--> make menus simpler for beginners :-)

Dbus is in, more upgrades 

The Slackware 12 CUPS package needs Dbus, so I decided it's in. This is Dbus version 1.0.2.

CUPS has now been upgraded to v1.2.11 and Gutenprint to v5.0.1 (which has more printer drivers than v5.0.0 used in Puppy 2.17).

To meet the dependency needs of Slackware packages, various new libraries have been added to Puppy, including startup-notification, acl, aspell (and the aspell English pack), attr, cyrus-sasl, librsvg, libxcb, openldap_client, and dbus, dbus-glib, dbus-qt.

Some libraries that previously had not been in the default live-CD but were PET packages, I am now including: sdl, libwmf, wv2 -- at least for now, it depends whether I need to trim the size.

Package gperf, version 2.0.2, has been added to Puppy, as requested.

Pidgin version 2.0.2 replaces the older version, which was called Gaim.

When packages are upgraded, they are nearly always bigger, and this is a massive upgrade. SeaMonkey, Pidgin, you name it, bigger. Coupled with all the new libraries mentioned above, this Puppy is going to be bigger, right? Puppy 2.17 is 93.2MB, my latest experimental build is 98.7MB, so yeah, there is some bulge. Tonight and tomorrow I'll work on trimming some fat.

An extra note: the Slackware Pidgin package also requires Dbus.

Please include numlockx, a small program (6072 bytes) that turns NumLock on or off.

numlockx [on|off]
on - turns NumLock on in X ( default )
off - turns NumLock off in X
toggle - toggles the NumLock on and off in X



According to this threads many Puppy users expressed interest for it:

Maybe the idea of loading all of Puppy into memory needs to be revisited, with this bloat.

Would it make sense to split Puppy into two sfs files, one that has frequently-used stuff and is loaded into memory, the other that has the rest and is left on the hard drive?

Paul is right! Sometimes one can be so close to an issue that the obvious can be overlooked. Puppy was originally a super-compact OS with innovative methods of access. As it approaches 100Mb, it could revert to an also ran. Time to stand back and decide what it should be. Sometimes you just can't be all things to all men. There will always be considerable interest in 50Mb ("credit card") OSes that are fast but adequate with no overlapping apps. and capable of running on ancient kit. Too many demands of it have been registered, if not to say, expected. Attempts to get it running on the latest HW is a different project and belies the lack of determination (especially from one nation!) of some users to work with what they have and be satisfied rather than chase after every gizmo the industry can tempt with. The trade isn't going to mute their siren voices any time soon. The smart guys do more with less - to date that has marked you out from the herd.The Forum consistently shows the immense interest that exists in getting the oldest, least powerful HW to run Puppy.

You didn't want to engage in politics, Barry, but such considerations along with social mores & co. are all part of the big picture! Perhaps you need a young protege to run a parallel project?! I have little faith in committees reinventing the wheel, elephants or even Community Editions. Evidence indicates that the best results are produced by single committed individuals with vision.

Otto (otto<at>sistemasorion.com) 
I agree with Sage. I appreciate very much your work Barry.
I see your effort of being kind of Slackware compatible as a way to reuse some of the integration work done by Slack and concentrate on what makes Puppy special, like compactness, hw detection, innovative ways of using hw resources.
You are going to get tons of opposing reactions to this decision, but I see it as a necessary step for you to stop bricklayer chores and to focus on architectural and engineering chores where you are a genius.
I dream of a kind of Puppy Unleashed Online, where I would get to custom build a Puppy by point and click, all done on a commercial server of yours and get an email telling me my ISO is ready. I would gladly pay US$5.00 for each build I want, given rights to ISO redistribution which are not granted by the GPL. Over the past two years the Puppies I have downloaded would amount to about US$60.00 which I think you could give good use. Your standard Puppy would become the "trial" version, not "trial" in the commercial software sense, but a good trial: the current version of Puppy. I would like to use your custom build service because I want Firefox on it, spanish localization, no games, Ruby, things like that. People that want OpenOffice could get a custom build too. I know these things can be done right now but to get some of them working, like spanish loc, I have to read and do much. I know the scripts to automate them all are already in your head. Check with the community about this, maybe they are interested.

Sorry to see the flack you're getting, Barry. I certainly don't agree with it. I was never more pleased than to hear you were going to Slackware 12 package handling. 80 or 100Mb - doesn't matter to me, or to a lot of people. DSL or sililar is OK if you need a rescue disk or want to browse on an antique computer. What attracts me is the speed, compactness, and elegance of Puppy in a real, workingman's computer. Sure, a little compromise is needed. But without good application packages and handling it's no good for serious work.Presently I'm frequently frustrated by the patchwork, Russian roulette package handling in Puppy. Sure, there's some excellent, brilliant work here, but not enough resources to reinvent the repository. Proceed to make not only a windows killer but an ubuntu killer! Godspeed.


I hope my comments are not misconstrued. I do not want to discourage recent development directions. I'm not all *that* concerned about a 100MB Puppy compared to an 80MB one; we are still very far from the bloat Muckrosoft customers deal with! I was just commenting on the one specific point about memory size, and suggesting a possible tack to improve several things at once: 1) reduced Puppy memory footprint, 2) faster boot, 3) room to grow Puppy a bit more as these latest changes do. The cost would be only that little used applications, or applications where speed is not so important (e.g. anything having to do with printing) are slightly longer to get running. I don't know enough to say if my suggestion is feasible.

I generally favor the ability to get packages from another distribution.

As to very old machines, there will always be Puppy spinoffs that are smaller.

"I dream of a kind of Puppy Unleashed Online, where I would get to custom build a Puppy by point and click, all done on a commercial server of yours and get an email telling me my ISO is ready. I would gladly pay US$5.00 for each build I want..." That is another solition to this problem, one I would like as well.

Flack? I think not and neither does WordNet. To wit:

From WordNet (r) 2.0 [wn]:

n 1: a slick spokesperson who can turn any criticism to the
advantage of their employer [syn: {flak catcher}, {flak},
{flack catcher}]
2: intense adverse criticism; "Clinton directed his fire at the
Republican Party"; "the government has come under attack";
"don't give me any flak" [syn: {fire}, {attack}, {flak}, {blast}]
3: artillery designed to shoot upward at airplanes [syn: {antiaircraft},
{antiaircraft gun}, {flak}, {pom-pom}, {ack-ack}, {ack-ack

Hello to all, especial to Barry.
I knew Puppy since 3 or 5 month and i now use it on a brandnew hardware:
The Alix1C from http.//ww.pcengines.ch.
A Geode LX based mainboard with only 5 Watts Power Consumption with no other devices. Power supply is 12 Volt DC, but rumours talk about 7-13 volts. I am in Contact with the manufacturer and recommended puppylinux.
I think its a very good Combination and can beat this:
(Google 100-Dollar-Laptop)

Projects in Work
Using the combination Alix1C & Puppy & XAMPP as Personal Webserver.
(added PHPFusion)
Test: http://dyndns.numweb.de (german) (only 64 kbps)

Works - not yet remasterd, estimated 256 Flash
Using Alix1C & Puppy & ToddyJoes Music as Synth
Remastered Beta, runs on 128 MB Flash

Regards from Germany an thanks for the work


Sorry if I made a poor choice of the word "flack." What I intended was something like "expressed disagreement. I didn't look up the word ahead of time. I see now that in Moby Thesaurus the first words are advocacy, advocating, antiaircraft fire, bruiting, buildup, . .
(Clearly I didn't mean anti-aircraft fire ;-) Bruiting apparently means "reporting." I was not familiar with it.

Anyway, we all feel enthusiastic about and protective of Puppy. Inevitably there will be some disagreements about emphases and directions. I just think Barry has the right direction.


let's stop sending barry "flack" and send some well deserved flack to those who are working on making the packages in puppy bigger by the megabytes and more "funtional" wish they would relize that things CAN be BOTH small an functional it seems that the size is creeping up all the time

Is there room for BareBones, Mean, smaller puplets. Sure.
The purpose of a an OS is to run software. Puppy comes with software. Slackware has more. Puppy + Slackware software. Works for me. Will work for the majority of new users we attract too.
Have fun.

Hey Barry,

Any chance of JWM 2.0 now that its not broken anymore?

(Love Puppy BTW, great work!)

Barry Kauler 
The 2.20 pre-alpha due on the 4th is mostly for proof-of-concept and testing the new apps, init script (frugal install, etc). The package selection will not be final, and JWM may get upgraded for the alpha or beta.

Hi Barry,

For all the people that will not like the Slackware additions...they can just drop back a few versions to the likes of 2.14 etc (one which I personally like very much).

I say go for it and see what shakes loose....this is lots of fun you see, for me and many others. Love having CUPS.

I have requests for Puppy with Open Office and some without...some with 3D and some without... frugal and USB installs...2.14 to 2.17 some with EZPup...each one is loved by their owners and are used daily....also, I mostly have nothing to fix after the install...which I love. Each change makes Puppy a different size so what's the problem.....

Many people run on more modern systems...thus a few mb here and there isn't an issue when the benefits are a smooth system with functions that people use.(You know, much like Puppy is now)

I'm in for the long run and look forward to the next set of trials...be whatever you can dream up, and have fun at all times.



More package upgrades 

I have upgraded SeaMonkey to version 1.1.2, Xine-lib to 1.1.7 and Gxine to v0.5.11, amongst others.

One thing I am undecided about is whether we should have Dbus in Puppy. Some Slackware packages require Dbus, so if I choose not to have it then I won't be able to just grab the Slackware binary tarballs and will have to recompile them from source without the Dbus dependency. Anyone have an opinion about whether we should hve Dbus in Puppy?

Another thing that I have to think about is Xine -- I'm currently using the Slackware package which has 'ffmpeg' compiled-in rather than as a separate library. Current releases of Puppy have a separate 'ffmpeg' that is shared by other applications.

Warren S Carl (windowsystemcomputers<at>yahoo.com) 
When does making Puppy compatible with Slakware parkages become making a Slakware cone - the slippery sope has begone!

Hi Barry,

Bluetooth would be nice built in....I think it needs dbus daemon...I hope that is what you are speaking on...


you could upload it as a .pet and if a program requires it then the dependancy checker will get it if not then it won't i think a lot of the programs in puppy could be even smaller than they are so making things bigger kind of defeats the whole perpose guess we can always back up and start over if it gets too big.

perhaps put a new entry in the puppy help about installing slackware packages explaining that there may be additonal dependancies and how to get them

and bluetooth that is not likely to be part of most people's everyday use but interesting non the less. what about wireless usb and UWB links

Ffmpeg is a pain to compile (and have everything work), lots of dependencies. It's kind of broke in 2.17.

Barry have you tried slap-get/gslapt with your new puppy?


I would have dbus built in - it is needed by Xfce and many other packages. It is also better to have ffmpeg separate, as several packages use it (eg Kino).

Unless it is somehow possible use ffmpeg to convert things with it built-in, it is much better separate.

The as-is Xine from Slackware with inbuilt ffmpeg seems to be working quite nicely, which is why I'm reluctant to recompile it with the external ffmpeg library.

Kirk, if you guys want to try the new Puppy with gslapt, go for it. It might be quite a nice marriage. I've got my work cut out for me getting the 2.20-pre-alpha ready to upload by the 4th, then you can grab it and play with doing stuff like that.

Yes, more and more packages are requiring Dbus. Some of the basic Slack pkgs, such as CUPS need it -- or probably in the case of CUPS it is a config option before compiling.
Dbus is a daemon, and I cringe when I read that word "daemon" ...but, well. It's not a big package, just that it's one more daemon.

These packages use ffmpeg: Grafburn, Pupdvdtool, Soxgui. These are developed by our own guys, Nathan, Zigbert and Pakt. The plugin in Xine that does the ffmpeg thing is 'xineplug_decode_ff.so'and it is 2MB. As it works nicely, I'm reluctant to recompile Xine to use an external shared ffmpeg library. The ffmpeg packge has an executable that our guys use, but it would be good if someone can write an equivalent executable that uses the 'xineplug_decode_ff.so' library instead.

Anyway, regarding these apps Grafburn etc., how crippled would they be without the ffmpeg component?

Ted Dog 
I found xine to compile easy, and DBUS is used a lot but I agree demons are bad

There should be a button in browser where you can remove all surfing data. Cache, history etc. in one click.

John Biles 
If the inbuilt ffmpeg makes xine such a nice player to the point where I see you want to include it, then leave it in.

Who said you can't also have the separate ffmpeg already in Puppy.

At the end of the day useability of any product (Yes Puppy is a Product) must also come into account.

Maybe one of the calculators or some other app included in Puppy could be dropped to make way for ffmpeg.

Yes it's a hard one and we've all watched as Puppy keeps growing with each release.

What can you do if there are more and more system dependancies that are required as time goes by to keep Puppy usable.

Maybe reduce the amount of Apps in the original iso and rely on the pet installer to add the additional required apps used by a Puppy User
Just thinking out loud, as always your the master!

In reply to Andy, you can download Monkeymenu to Seamonkey which includes a clear data button. This avoids adding to the base iso

Xorg upgraded to version 7.2 

Well, there was I lot of messing around, but I got there. Slackware 12 has the Xorg package installed in the /usr path prefix, so it mingles with everything else, which I'm personally not entirely happy with. But, some Puppy scripts and perhaps some apps expect it to be in /usr/X11R7. I did try using the Slackware Xorg in it's default /usr location, but ran into many problems. So I relocated it in /usr/X11R7 and fixed various problems with Xorg not being able to find stuff by creating symlinks -- not many symlinks were needed. One example, is the Xorg server runs 'xkbcomp' at startup and looks for it in /usr/bin, and there does not seem to be anyway to tell the Xorg server to look for executables in /usr/X11R7/bin -- which is odd, as other paths, such as the path to the modules, can be specified. Anyway, a symlink fixed it.

Finally, I got Xorg to run without spitting out error messages in /var/log/xorg.0.log, except for one -- it reports that the 'synaptics' module is missing.

Over the next few days I intend to upgrade a few more libraries and applications, and create a 'devx' file. Let's see, I have to be in Perth (our State capital city) on the 4th of September, where I have access to adsl2, so I will aim to have the 2.20 'alpha' release ready. Apart from all the library and application upgrades, this has my new 'init' script, and a normal separate 'zdrv' file.

The synaptics touchpad driver in Puppy 2.17.1 is at


Beem and self thrashed-over the synaptics driver's control in xorg.conf (i.e., how to turn the touchpad off), in a side-conversation at


Barry Kauler 
Okay. I'll upload 2.20-pre-alpha (better not even call it an alpha yet) on the 4th and you guys can have a play with it, see if the Synaptics support can be bolted on okay.

Binary compatibility with Slackware 12 

For the last 5 - 6 days I have been working on this. What I'm aiming for is getting all the base libraries in Puppy to match those in Slackware 12.0. The reason for doing this is so we can grab most Slackware binary (compiled) packages and they will work in Puppy. Note, this does not mean that Puppy is becoming another clone of Slackware, just moving to library compatibility.

Anyway, my first attempt, which was to replace all Puppy's libraries with those from Slackware 12, suitably cutdown, had so many problems that I become very disgruntled. Instead, I approached it a bit at a time...

Firstly, I upgraded Puppy from glibc 2.3.4 to 2.5. This is an important first step, and it solves the problem many people have experienced when they grab a binary package from a recent distro and get an error message about "GLIBC 2.4 missing". I had some teething troubles with this upgrade, but after a couple of days sorted it out, and all Puppy apps seemed quite happy with the new C libraries.

Then I upgraded GTK from 2.8.17 to 2.10.13. This was quite straightforard and existing Puppy GTK2 apps seem to work alright. However I did read somewhere that some apps compiled for GTK 2.8 may have problems with 2.10.

I have not yet upgraded Xorg, as when I tried, Xorg would not start. One problem is that the Slackware developers in their wisdom decided to compile Xorg with a different layout instead of into the traditional /usr/X11R6 or /usr/X11R7 directory. It seems that the upgraded Puppy Xorg package that I created has problems with paths. Anyway, I'll keep working on it.

The official Slackware package repository does not have extra packages like Abiword and Gnumeric ....does anyone know of repositories of Slackware 12 compatible binary packages with these and other extra packages? It will save me much time if I can just grab precompiled packages where-ever possible.

Pitagora (pablo.pita<at>gmail.com) 
Probably you want to look at http://www.slackware-current.net/index.php for unofficial slackware packages (I found out after googling and checking their site).

have look to http://www.linuxpackages.net/packages.php

try this one :
sorry it is in italian.

ehud (allhuda<at>yahoo.com) 
try this too may be will help

john biles 
Hello Barry K,
As I play around with different packages from different distro's, I'm getting the errors you talk about more and more so what you are doing seems to be the way forward for Puppy.

Just one question, will this effect user's of old hardware in any way?

Once again, without your magic in creating a wonderful base in Puppy to build upon, I would have gone back to Windows long ago.

I just find all other major distro's are too full of bloat like Windows is.

So thank you Barry K for sitting down all those years ago and deciding to create this thing call Puppy Linux.

Hi Barry,

Being an old Slackware-addict, I am more than happy with this move. Slackware has been very stable, reliable and consistent over years, which is precisely what I wish to Puppy Linux.

Keep up the good work!

I've been trying out slax modules, renaming them to sfs files.
I have lazarus and free pascal working, needed one line
change in fpc.cfg


Small upgrades to web pages 

I have added a link contributed by Johann Loefflmann to:

There seemed to be some inconsistency in the wording of the licencing statement in the FAQ, so I have attempted to tidy that up:

Henry (books<at>henrystrobel.com) 

Can we expect that Seamonkey will soon be upgraded to accommodate gnupg.

This has been a long standing hurdle to adoption.


I was just going to plonk in the Slackware-12 SeaMonkey package, as I'm moving to Slakware-library compatibility. Slackware 12 has SeaMonkey 1.1.2. I have not tried it yet, an have no idea about it's features, such as gnupg.

That's great news, Barry, about the Slackware packages in general, and will probably fix the Enigmail/Gnupg problem.

Background info is in this thread, suppose you've seen it.



Unleashed: building with different kernels 

I am enhancing Puppy Unleashed to make it easy to build with different kernels. For example, to build with the kernel used in Puppy 2.16 and earlier.

I am almost there, except that some PET packages are "kernel version sensitive" and it may be necessary to substitute the exact PET package that was used with that kernel. I have tentatively composed this list:
k2.6.18.1 p216 aufs-20070423
k2.6.21.1 p217 aufs-20070621

k2.6.18.1 p216 dhcpcd-1.3.22
k2.6.21.1 p217 dhcpcd-3.1.0

k2.6.18.1 p216 ndiswrapper-1.33
k2.6.21.1 p217 ndiswrapper-1.46

k2.6.18.1 p216 ppp-2.4.3
k2.6.21.1 p217 ppp-2.4.4

k2.6.18.1 p216 rutilt-0.13
k2.6.21.1 p217 rutilt-0.15

k2.6.18.1 p216 unionfs-20060916
k2.6.21.1 p217 unionfs_utils-0.2.1

k2.6.18.1 p216 wireless_tools-29.pre10
k2.6.21.1 p217 wireless_tools-29.pre22

k2.6.18.1 p216 wpa_supplicant-
k2.6.21.1 p217 wpa_supplicant-0.5.8-rt73patch

If you can think if any others, or think that one of the above doesn't need to be in the list, please comment.

would it be possible to make a 2.4.x kernel? or is puppy 2.x too reliant on 2.6.x features for that?


No, we can't go bck to a 2.4 kernel, too many things changed.

Alfonso L. 
Great feature, because I has been troubles with versions 2.0, 2.16 and 2.17 for booting, on my DELL latitude. I am working right now with version 2.15 CE for that. Maybe some option to compile the kernel for legacy equipment.


Barry, I don't think wpa_supplicant is kernel-sensitive. The current version of wpa_supplicant in Puppy 2.17x is the one I compiled earlier under Puppy 2.16 (with Ralink patch), and it appears to be working just fine in 2.17.

If anything, wpa_supplicant might be sensitive to the particular version of wireless-tools it was compiled against, though it's difficult to know, because the version of wireless tools in Puppy 2.17 is not the same, but VERY CLOSE to the version contained in 2.16.

Does anyone know about minix3 operating system created by Tanenbaum? I don't know if this kind of OS will help? Just a guess.

since the 2.4 linux kernel is different enough that barry does not want to bother supporting it the minix 3 which is a microkernel and therefore very different from linux in any form is not really an option unless some one really want to port puppy scripts to it. which would probably be pretty difficult but that is a guess.

could swaping the kernel be made easier for already installed puppies as well?

barry you may want to check out the updated MugaLua 5.5

This has nothing to do with kernels (more about the kennel).

Isn't it time to upgrade the fun-section. We got MUGGINS - the right man for the target. Why not ask him to rate the 5 best games for Puppy.

sorry was kind of tired from college starting back up when i read this

some small and big games not sure if they will work though


Games are not really my area, but the exceedingly old Penguin ping-ping is still none of the best. Small, fast, fun and probably a headache for Barry to incorporate!

'none' ?!!! New k/b - read 'one'.

..or even ping-pong.

I agree with cb88, that it would probably be nice to upgrade murgaLua

the problem is nobody is posting apps for it

zdrv: can we have it both ways? 

Guys, how is this for an idea...

One reason that I put the zdrv files into the initial ramdisk is so that all the modules will be available, so we can have recognition and booting from a wider range of devices, such as SCSI and PCMCIA drives.

But, then of course there was the problem how to make the zdrv files available to the main filesystem after switch_root. My first solution was to copy them into the pup_save.2fs file, which works, but of course the downside they take up a lot of room, and they would have to be in every pup_save file.

Then suddenly the light came on. Just before doing the switch_root, after the pup_save file has been loaded (so that Puppy knows where /mnt/home is), just check if a zdrv_220.sfs exists at /mnt/home, if not create it. It's easy, the entire zdrv is inside the initial ramdisk, and it would require 'mksquashfs' to be in the initial ramdisk to create the zdrv file.

There is a side benefit to doing this. As Puppy has created the zdrv file, Puppy knows exactly where it is, so the big /usr/sbin/zdrvfind script that is called by modprobe would no longer be needed. All issues about the zdrv file not being found, that have been reported on the forum, would no longer be issues.

If anyone can think of anything wrong with this idea, let me know. It seems to me like we would be having our cake and eating it too.

Adding another thought to the above. There is no need even for 'mksquashfs', as zdrv does not actually have to be a squashfs filesystem. It could be plain ext2, as the modules are all individually gzipped. In fact, the initrd.gz file could simply be mounted and treated as the zdrv file, as is, except that initrd.gz is a cpio archive and I don't know how to mount that directly as it's not a filesystem.

I like to have pup_save.2fs files as small as possible. I have few off them because I like to try and use every new version of Puppy and when doing my frugal install I usually choose only 64 MB pup_save.2fs. I think that zdrv inside the initial ramdisk is better solution than to have it inside pup_save.2fs.

Barry - why not just convert the 'cpio archive file' back into its component parts under the current folder - '/initrd' - and then change it to ext2 or squashfs then do the [i]mount[/i]..

The following command line can extract a cpio image back into its component files:

cpio -i -d -H newc -F initramfs_data.cpio --no-absolute-filenames


where the - 'intramfs_data.cpio' - is the "initrd.gz" file name..

Maybe 'extract' into a tmpfs then delete the original cpio..

Just a thought..


Don't know if you've seen this :-


might be usefull..!!


this is not really related to zdrv (but then again it is!) but it is related to puppy 3.0 as xorg is getting upgraded and crash issues (xine and mplayer both crash with wow's xorg 7.2 when resizing i think mostly just an annoyance)with the media player may/will? come up.

include xmms for audio it supports a wider range of music files including modules (most but not all) which i recently discovered

a sound theme could be implemented using modules since they can be extremely small and contain lots of music kind of like midi only way better at the very least it would give users an initial music file to play to test operation of sound drivers
www.modules.pl and www.modules.org

lose gxine in favor of mplayer? vlc? Helix? preferably something small and fast not gtk based? console frontends?

just found this might make a good .pet addition for an ultimate multimedia puppy looks like it is big source is 5+mb

here is a good list of video players and frontends


and finally MPlayerXp looks very promising it is an enhanced portable MPlayer would likely show more benefit than standard MPlayer with realtime or scheduler patched kernel but that is only a guess

Might be clutching at straws here.....


Mounting & unmouting 'cpio' archives..!!


Or even this :-

'extractig contents of cpio archive and then deleting the archive'
say the archive is named - cpio.out - and is located in folder - /tmp

cd tmp
cat cpio.out | cpio -iv --quiet --make-directories
rm cpio.out

you now have the 'expanded' contents of the cpio file in /tmp - so can use them as needed..


I switch between a frugal install boot and booting from CD, which allows me to do general work under Puppy and also internet banking with a clean boot from CD (albeit with a pup_save file). In the CD boot I get both the general and banking pup_save files displayed to choose from. If I choose option 0 (ie no pup_save file) the boot prompty fails when it loads the zdrv file system. If, on the other hand, I interrupt the CD boot with "puppy pfix=ram" it boots up fine. It therefore looks like there's room for improvement in the CD booting with multiple pup_save files. This may be something worth testing with your new init script, Barry.

yes, I have known about that bug if you choose '0' (no pup_save file), and I have fixed it in the new 'init' script.

Barry, you're amazing!

Half-size 'init' script 

I have expanded the 'init' script (located in the initramfs, a script that executes first when Puppy boots) to support the full range of PUPMODEs.

I have gone back to PUPMODE 13 when the pup-save-file or pup-save-partition is on a Flash drive, meaning that it has a tmpfs top layer. I will investigate further some issues that we have with flushing.

It is amazing what a difference... I rewrote the 'init' script from scratch, I just started from line 1 and kept going. Putting in all my accumulated experience to-date, plus a fundamental rethink on how the script should be structured, has resulted in a script that has all the functionality as before and better, and is more logical, yet is only 911 lines, compared with 1890 lines in Puppy 2.17.

Correct handling of frugal install in a folder 

The 'init' bootup script now has rigorous handling of this, so a frugal install of vmlinuz, initrd.gz and pup_220.sfs in a folder, say 'puppy220', will be recognised. Puppy will automatically search partitions one-deep, however the 'psubdir=puppy220' boot parameter can be given to prevent Puppy from searching anywhere else.

I have updated the Universal Installer to offer to install to a folder when doing a frugal install.

I also modified the shutdown script rc.shutdown so that it recognises that Puppy has booted from a folder and on first shutdown will create the pup_save.2fs file (personal storage file) in that folder.

This is all good news for those who like to have multiple Puppy installations in their PC.

Dear Barry,

It would be great if you can add a boot parameter (or new PUPMODE) for booting Puppy in the QEMU envinronment. In such case all *.sfs files are mounted as virtual block devices.

I made a little hack of bootscript to be able to run Puppy under QEMU, but I think it is good idea to add such option to the "official Puppy".

Example of command line to run Puppy in QEMU:
qemu -L ./share -initrd initrd1.gz -kernel vmlinuz -hdc zdrv_215.sfs -hdb pup_215.sfs -hdd pup_save.2fs -m 48 -localtime -append "root=/dev/ram0 PQEMU=1"

Best regards, Vayu


Thanks for this very useful improvement.

Experimental new puppy under development 

I've been working very intently on an experimental new Puppy. Here are some features:

zdrv_xxx.sfs has been eliminated. one less file to worry about. It is now inside initrd.gz, but is handled in such a way that it doesn't take up ram space after puppy has loaded.

very simple and fast boot scripts. I completely rewrote the 'init' sript and it is now much smaller. It has a logical linear progression with very few functions.

all modules (everything from zdrv) is now in the initial ramdisk, so all modules available -- compared with before when a very small selection were in the initial ramdisk. For example, all the SCSI modules are available, the complete set.

in a running puppy, the complete zdrv is saved inside the pup_save file (personal storage file) (space permitting) so all the modules are available while puppy is running. these can be deleted if the pup_save gets full.

I have changed the "initial ramdisk" to an "initramfs". This is because of the improved memory management of a initramfs. The zdrv components inside the initramfs get deleted to free-up ram before the pup_xxx.sfs is loaded into ram.

Searching for puppy files at boot is now very rigorous and precise. puppy files can be in any subdirectory and puppy will find them. But, only one directory deep, to minimise search time. That is, you can have files initrd.gz, pup_220.sfs and pup_save.2fs in say '/pup220' in a partition.

I have kept everything mostly the same as before, so users will not have to relearn the basic installation and setup procedures. still have the 'pmedia', 'psubdir' and 'pdev1' optional boot params. Examples:

pmedia=usbflash #choices: usbflash|usbhd|usbcd|ideflash|idehd|idecd|idezip|satahd|scsihd|scsicd|cd
pdev1=hda7 #partition puppy is installed on.
psubdir=pup220 #folder containing all the puppy files. even pup_save.2fs will be here.

....these are all optional. you use them to narrow down the search as much as you want. for example, booting from a usb flash drive, use 'pmedia=usbflash' so that puppy won't waste time probing the cd drives and other drives (CD probing especially is slow). Or, for a frugal ide hd install, use 'psubdir=pup220 pmedia=idehd' so that puppy will only probe the ide hd's and will only search inside folder 'pup220' -- this is particularly good for multiple frugal installations that want to keep themselves apart.

Periodic batch-flushing when boot from a Flash drive has now been eliminated. I am trying a different approach, that totally avoids the problem. Now, the pup_save.2fs file is directly mounted from where it is in the Flash drive via loop device onto the top layer of the unionfs f.s. There is no top tmpfs layer. Instead, heavy writes are identified and a tmpfs mounted on the offending directory -- for example /tmp, and in that case it doesn't have to be saved. Other directories, for example containing cache files, are also identified and symlinks into /tmp created -- they can be saved manually or at shutdown, or not saved.
Currently puppy is only using PUPMODE state values of 5 (first boot or pfix=ram), 12 (normal mode), or 77 (multisession cd).

Currently I have /tmp as a tmpfs and /var a symlink to /tmp/var, which takes care of much of the writing. It also has a couple of advantages for booting off cd or frugal-hd. Previously, /tmp and /var were in the pup_save.2fs which is on the hd, whereas now they are in ram, hence should run noticeably faster. Currently i am not saving /var at shutdown, which has the advantage that stray lock files are not saved, also there are some log files in /var that grow indefinitely. Oh yes, whiteout files tend to accumulate in /tmp and /var also, so these will also not get saved.

The initrd.gz file is now 22MB. After loading into ram at bootup, and prior to performing the 'switch_root' to the main filesystem, 'free' shows that about 40MB of ram is being used. So, will it boot on a PC with 48MB of ram? ...I don't know yet. Certainly nothing less than that.

Regarding Unleashed, I have changed things to make it easy to swap kernels. Previously, the 'createpuppy' script did have a question what kernel do you want to use, however the initrd had modules for one particular kernel manually placed in it. Now, you choose a kernel and the correct modules will go into the initrd.
We are not entirely out of the woods though, as diferent kernels may require different PET packages. Some PET packages are compiled to work with certain kernel versions only.

Having the entire set of modules in the initramfs is unique and very exciting. We can really "go to town" over this, and support booting from SCSI, PCMCIA, whatever ...potentially anyway. Network boot possibilities also.
I have been testing booting from a usb pen drive, works nice, but quite a few things to work on still. I hope to upload v2.20experiment1 soon. Note, I have also started work on Puppy v3.00, but very premature to say anything about it.

Matt B. 

Sounds exciting! I can't wait to try it out.

I particularly like the ability to specify a subdirectory, so I can fool around with the latest version and keep it separate from 2.17.


--Matt B.

Very exciting! I wondered when you'd be likely to go for a ver 3.

Good luck Barry - and thanks for everything so far.

Subito Piano 
48MB RAM?? Yes, version 2.17 works on my P1 w/ 48 MB RAM, albeit slowly, but better than some earlier versions. Interesting, with most OSs, the newer versions require newer, more powerful hardware. With Puppy, the opposite is true. Bravo!

Wolf pup 
barry, may you make fsck.ext2 check encrypted files, the one in puppy 2.16 cannot check encrypted saves.

Very exciting stuff! And so soon after releasing 2.17! Keep up the good work!

Wolfpup, to fsck an encrypted pup_save you have to apply losetup first, then fsck.

Barry, don't you ever get tired? :-)

I was going to complain about the zdrv going into the pup_save, but maybe at 18MB it doesn't matter that much. So if I understand correctly, it starts out in initrd.gz and then is copied down into pup_save during the version upgrade? Does that copy add any complication when you are upgrading to a ".1" or ".rc" version, not a full upgrade?

I am a little concerned about /tmp being in ram. If I'm downloading a big file into /tmp I'm probably going to run out of ram, especially in a small-ram machine, where I (usually) would have more available room if /tmp were in the pup_save. Is there a way to mount another piece of /tmp from somewhere, maybe in the pup_save, to take care of that condition? Hope that makes sense to you... I do like the notion that /tmp really does disappear on reboot, rather than being somewhere on disk where an "undelete" sort of operation can get to it.

Your item #8 is probably going to make people who boot off USB flash on a USB 1.1 port unhappy. Performance might be very slow, unless I'm missing something. Also this makes me wonder: "Other directories, for example containing cache files, are also identified and symlinks into /tmp created -- they can be saved manually or at shutdown, or not saved." It seems to imply a need for user awareness of the internal workings of applications.

ttuuxxx (ttuuxxx<at>gmail.com) 

Hi Barry

I spend countless hours in the puppy irc chat room helping people, One of the main concerns of people is security, The majority of people want to have a automatic user account with admin password, booting into root automatically to them they find is just wrong, maybe as an option or a seperate pet packages, So people want to use puppy as a LAMP or XAMPP server, how unsafe would that be? Well i'm not trying to tell you how to do things, but i see the number of potential puppy users leave the chat room and go and try other Distro's. And if you think about it, the ones wanting to make servers and worry about security, aren't newbee's to linux, they are well rounded linux people, and just the type of people we need in the irq help room. Its a waste of potential resources. Plus when we chat about the lack of security with puppy the rest of 20+ people in the channel also reads the whats going on.

The other thing i would like to ask you is I really liked the icewm themes that 2.15ce had, Can we please have icewm as the default theme?
I made a whole lot of Start menu buttons for it, if you have time open my site up www.ttuuxxx.com also i have a Chinese puppy 2.17 posted there, i don't know Chinese but i just wanted to help them with the hosting of it. Feel free to use any of my puppy related buttons.

Barry do you think that some way your could get it to boot in 32mb(only 8 less than 40 and much more common!)? I mean does dvb need to be in ram a boot time (I think no?)? Booting an advanced O/S in 32mb would be an extremely noble goal. Also consider moving to ice weasel browser and dropping some of the heavier apps. if you can get lightweight apps and low ram usage then great!

I was reading an article in the HUGI diskmag www.hugi.scene.org (readable from browser if you don't have windows)and they were talking about how there used to be all these cool effects that people wrote for amigas and comodore64s and how now[then] the same effects are being made only 10x slower and with crappier code on what should be a processor powerful enough to handle anything(pII 300mhz).

The main point was was that people don't take the time to know their code. what ever you do in 2.18 and beyond put some fun in the odd releases and love in the even ones barry. Puppy Linux can only rise if it is truly better. What makes it better is all up to the user.

especially if you consider that barry is a user LOL

Hi Barry - you certainly work hard at your hobby..!!!

The only concern that I can see re removing the zdrv_xxx.sfs and putting its contets into the initrd.gz - is the potential of a whole heap of redundant unused modules being included and taking up valuable RAM space..

I can see where you are coming from with the new approach - but the old one of using an zdrv_xxx.sfs file (with all the modules ever likely to be used) I feel gave the user's computer system the ability of choosing those modules it only required or needed and loading them from the 'zdrv' file on demand - thus saving on RAM space..

I also feel that with the '.sfs' file methodology that has been adopted with the later versions of Puppy (up till now - of course) - the ability of Puppy being able to load them and then copy what it needs from the them and then unload them on demand WITHOUT taking up any large amounts of RAM space - is definitely an huge advantage to the overall running of Puppy as a Linux OS - we do that for the other '.sfs' files (OOo_217.sfs; web_217.sfs; pgs_217.sfs; devx_217.sfs..etc..) with greate success..

Maybe the 'init' script could be amended to include a function such that once the 'user's machine has determined and loaded all those "modules" that it ONLY needs to have loaded (specific for that machine's operation) - that all other 'unneeded' modules are then deleted from ram and the ramspace then made available for use to Puppy..!

Just a thought..


Barry Kauler 
I think it's quite common for distros to mount a tmpfs on /tmp. If you have a swap partition or swap file, the max size of the tmpfs can be set to use that space also, not just the physical ram -- I will modify the init script to do this, currently I only have it set to 1/8 of physical ram which is not satisfactory.

Yes, doing away with the top tmpfs layer for flash drives solves one problem (no need to periodic save) but introduces a new set of problems. This is an experiment, I can go back to a tmpfs if it doesn't work out. I've been testing it, it isn't slow. The main slowness that one notices is application loading, and if there is sufficient ram the pup_220.sfs is loaded into ram at bootup (as before), so apps start fast.

For people who want non-root login, recommend Grafpup.

The 'zdrv' file probably has a lot of esoteric modules that we would never need. I can have a go at trimming it. Also, many of the modules are for newer PCs, so I could release an initrd.gz with all the 'new' modules removed, which would be great for older PCs with little ram.

Regarding the zdrv stuff going into the pup_save, it only does so if there's plenty of free space, and gets removed automatically if free space in the pup_save is getting low.

The initramfs is dumped when the switch is made to the main f.s., so it doesn't take up ram space when puppy is running. Also, the zdrv components in the initramfs are deleted before the pup_220.sfs is loaded into ram.

Well there goes the forum.

No Sage with his verbal jousts now that you are fixing everything.
Just when I was getting used to wheels being square.
Ah! there's always Vista I 'spose.

" very simple and fast boot scripts. I completely rewrote the 'init' sript and it is now much smaller.
It has a logical linear progression with very few functions.

After loading into ram at bootup, and prior to performing the 'switch_root'
to the main filesystem, 'free' shows that about 40MB of ram is being used.
So, will it boot on a PC with 48MB of ram?
...I don't know yet. Certainly nothing less than that.

Having the entire set of modules in the initramfs is unique and very exciting. We can really "go to town" over this, and support booting from SCSI, PCMCIA, whatever ...potentially anyway.
Network boot possibilities also."

Regards Chris

Thanks Barry for clarifying that.. So all the zdrv components are now included in the pup_220.sfs file - so when it is loaded into ram does not the "unneeded" modules still take up ram space..?

Just trying to get my head around this..!


what happens when modules need to be loaded after boot and unneeded ones have been dumped is the initramfs reloaded? like in the network wizard? will probing still be possible will a reboot be required?

It is always funny to wait for news in this blog. It has been quiet for several days, so we all just knew: Big stuff is coming.

"[i]Currently i am not saving /var at shutdown[/i]"
This will clear all crontabs in /var/spool/cron/crontabs/root/. Sounds not too good. Maybe they could be temporary saved somewhere else, and loaded at boot into /var.....


I think this is a pretty bad development.
Puppy is in very bad need of an updated filesystem and bugfixing...I was hoping that's what the quiet spell indicated.
This is just a source for more confusion for users and leaves unattended a lot of the problems existing (for example, those with Xorg-7.0).

The lack of a zdrv will also make 32MB pup_save files unusable.

I'm sure this will cause some confusion, but there are some potentially very good things in there. I put 2.6.23rc2-mm1 in 2.17. Not fun with the current setup, you have to change the modules in initrd.gz, zdrv, and pup_217.sfs. I'd like to see some newer base packages too, glibc and gcc are getting kind of long in the tooth. Guess you can't have everthing at once. I enjoy puppy's fast development. I think a slow development just spreads the same pain of a longer period of time and makes it a lot less interesting. I'd get REAL borded with slackware. Hang in there Dougal, we need you!

Barry, that's a good point about swap. Probably didn't think about it because I don't use swap (due to encryption). Encryption users will still have a problem though. I guess they can buy more ram. ;-)

Of course if the kernel and other pieces are built to include support for loop-aes and dmcrypt then we can have encrypted swap and that problem is fixed too. :-)

The thing I liked about zdrv (what little I understand) is that it could hold everything but the kitchen sink. If it (or its replacement) is now to be trimmed, are we thus reducing our range of hardware support? It wasn't that long ago we jumped on zdrv as a great new idea...

I think experimenting is good, and there comes a time when you have to dump the old code and rewrite. But I also hear Dougal's wish for a good, solid version of Puppy that conservative users can camp on for a while.

You could just download to a location other than /tmp. I usually have a /mnt/home/tmp also, for the big stuff or things I want to be persistent for a couple reboots without cluttering the normal filesystem. I know that won't cut it if you want everything encrypted though, but you could still create and use /tmp1 or something.

One of the things I thought was cool about zdrv was that you could replace it with a newer one without any complicated installing and whatnot. On the other hand, I'd probably prefer having more options to boot from if it came down to it. It's easier to add drivers in a bootable Puppy than a non-bootable one.

The simplified init script sounds great. That would make stuff like Pebble (my bootsplash program) easier to install.

@craftybytes: They get copied from the initramfs to the pup_save, not the pup_220. Since pup_save isn't loaded into ram, it would only affect the ram usage at the very first stage of booting when only the initramfs is present. Then it gets copied to pup_save and deleted from initramfs. Thus the ram it took is freed. Next the pup_220 is loaded into ram (if you have enough ram) and mounted. Then the filesystem pivots over to the pup_220 and pup_save, and the initramfs is freed from ram. So in the end, you'd have the pup_220 in ram, the pup_save on the harddrive (or flash drive), and the zdrv stuff in the pup_save. I hope that clears it up for you, and I hope I understood it correctly myself ;)

Oooo... Puppy [b]3[/b]... one of my three favorite numbers....

what happens with low ram (like 40 mb ) and no pupsave?

Upgrading of the filesystem, later Xorg, GTK, GCC, GLIBC etc... that's what v3.00 is all about. That's underway also.

Guess we can have everything! :-)

Barry Kauler 
[blockquote]I think this is a pretty bad development.
Puppy is in very bad need of an updated filesystem and bugfixing...I was hoping that's what the quiet spell indicated.
This is just a source for more confusion for users and leaves unattended a lot of the problems existing (for example, those with Xorg-7.0).[/blockquote]
I am fixing bugs. For example the finding of Puppy files at bootup has been very buggy, and that is the main thing I have tackled. I have also been tackling other buggy areas in the 'init' boot script, not specifically menioned in my post. I am also working on upgrading the filesystem. The fact that I am also trying some experiments along the way is my perogative. None of these experiments are set in stone, they are [b]experiments[/b]. This is my developer blog, where I can post about ideas that I am experimenting with. These experiments are all designed to tackle particular problems in Puppy, ie bugs, for example andrei and I still have not got unionfs flushing to work reliably.
So, as I've said to you before, lighten up. Instead of a totally negative post, it is far more constructive to simply identify one thing that you see as a problem such as the small 32MB pup_save, and raise that as an issue.

Thanks Pizzasgood for that clarification..

Pizzasgood said:
"One of the things I thought was cool about zdrv was that you could replace it with a newer one without any complicated installing and whatnot. On the other hand, I'd probably prefer having more options to boot from if it came down to it. It's easier to add drivers in a bootable Puppy than a non-bootable one."

Yep - just replacing/deleting/adding driver modules to 'zdrv' was easy if one needed to do such - then just replacing the old one with the 'new' one [i]without any complicated installing and whatnot.[/i] and rebooting - almost a 'no-brainer'..

"[i] It's easier to add drivers in a bootable Puppy than a non-bootable one [/i]" - well maybe {for the more experienced Puppy user}... With no 'zdrv' would not one now have to [i][b]update[/b][/i] the 'initrd.gz' file (with all its included driver modules) instead - something that a lot of us still-green-around-the-gills Puppy users would find daunting..

Barry - as an old 'electroics' tinkerer, I found that [i]experimenting[/i] was really the only viable way to 'prove/disprove' one's ideas, and by the end of the day you generally only ended up keeping one or two (or maybe even only half) of an idea for actual use.. Also you might start off with one idea but end up with a completely different idea based on the results of the 'experimeting'..

And having a [i][b]sounding[/b][/i] board such as this developer blog to bounce thoughts and ideas around also helps to "gel" the ideas into more usable streams..

Just my 2 c's worth..


Barry Kauler 
[blockquote]And having a sounding board such as this developer blog to bounce thoughts and ideas around also helps to "gel" the ideas into more usable streams..[/blockquote]
Yeah, that's what it's all about. Some of the guys have raised good points, that I have taken onboard.

As I mentioned before, there's nothing for me to "cool down" about.
I don't get emotional over mechanical apparatuses (well, except maybe for my bicycle...), so all my comments are made in a dry, technical tone...

I could argue nomenclature, saying it makes more sense (and is in line with Puppy's history) to increment a minor version number when upgrading the filesystem (2.10) and a major version number when making structural changes (2.00), but don't see the point.

I think, if you're going to modify an experimental setup (=restructure how Puppy works) **and** upgrade the HW you're using (=filesystem), it is more sensible to first upgrade the HW, using the new HW with your old setup (so you can find any problems with it), and only afterwards try the new setup.

Doing it in that order will also have another benefit: there are still users using Puppy1, since they prefer the way it works (has anyone seen Sunburnt lately?). That will, undoubtedly, happen again when such major changes are applied. So upgrading the filesystem before making those changes will leave such users with a more up-to-date filesystem (and maintain compatibility of packages).
(There is also a use on the forum now trying to create a 64-bit Puppy -- if the filesystem is updated now he will be able to do so easily, rather than have to struggle with the 2.10 PFS scripts…)

All that said, the main reason for my post was to "open a door for dissent", so to speak.
Saying "great" does not contribute to the development and improvement of what you're doing -- it's the contradictions that will make you notice weaknesses and give you ideas. So my comment showed people they needn't be afraid to be negative...
(As for specific examples of possible problems, I can think of many, but this isn't the time to start going into them -- I simply think such major changes require time to develop and mature. Wasn't the gap between 1.0.8 and 2.00 about 5 months?)

Dougal, on the contrary, perhaps you can't see it, but your posts are sometimes not just "dry and technical" but aimed at a personal level and quite caustic.
I don't mind criticism, in fact that's the kind of feedback I need, but you go lower than that, and make it more of a personal attack.

Just my thoughts as a relative outsider to the technical issues:

Dougal said: "I think this is a pretty bad development."

and I can see that the wording could be seen by Barry as personal and caustic. It might seem like I'm suggesting a "politically correct" approach, but even if someone thinks something is bad, a more constructive comment might help, e.g. "we need to be careful that we don't introduce another problem when fixing an existing one."

Dougal also said: "Puppy is in very bad need of an updated filesystem and bugfixing."

Well I don't know anything about filesystems, but I do think a more rigorous approach to bug fixing would be good. For an earlier Puppy version and also for 2.15CE, I suggested finding expert volunteers (with non-expert assistants) to test each main area, e.g. wireless, frugal installation, graphics cards, etc, on a variety of hardware and confirm and isolate bugs and only then advising Barry, but didn't get any support.

Clearly there is a trade-off between cutting edge and trouble-free....

I cannot think of any occation in which I made a personal attack.
When I say something is "bad", there is no reference to the people involved.
Hell, I don't even complain about peoples coding style!
My comments myght be blunt at times and that is usually intentional.

RickRandom wrote: "...I do think a more rigorous approach to bug fixing would be good. For an earlier Puppy version and also for 2.15CE, I suggested finding expert volunteers (with non-expert assistants) to test each main area, e.g. wireless, frugal installation, graphics cards, etc, on a variety of hardware and confirm and isolate bugs and only then advising Barry, but didn't get any support."

The community support was there and continues. "Expert volunteers" and "non-expert assistants" are still testing and advising Barry. However, Rick's logical, well-intentioned and well-thought out "more rigorous approach" as outlined runs contrary to Barry's recently documented modus operandi:


The unavoidable bottom line remains: any testing, reporting, compilation, documentation and/or patching system that even remotely resembles "formal" will be shunned like the plague by Barry. The BK Puppy is his baby. And the loosely "established" modus operandi on which the distro is based is his to "dictate" (contradictions intentional).

Paul Simon's project statement:


Point taken, of course, alienjeff. It's up to people to make suggestions and constructive criticism, and Barry can then make his own informed decisions. It's his Puppy, and he can bring it up how he likes. Without his freedom, I guess there wouldn't be any Puppy, let alone one that offers so much, even if we criticise some things.

Stop your silly arguing you haven't even made any suggestions to barry in the last few posts it is really embarrassing that you would go on this way and rehash the old arguments this way.

Start having fun already and if you want a distro that is perfect for you go get a computer degree that is what I am doing if you can't do that then be helpful and people like barry will help you otherwize your arguing puts them in a bad mood!

Sorry to be blunt but enough of peoples lives have been wasted arguing please don't waste any more.

I haven't met a person on the forum yet that has been intentionally mean and i have been lurking/posting on the forum for the past year

cb88 :P have fun that's an order!

P.S @whoever and anybody please be polite not that you haven't to date

This is a welcome set of changes. I look forward to the introduction of 2.20.

I too have noticed that Pupmode 12 on a USB flash key does not reliably update the directory structure inside pup_save.2fs.

I would suggest that gperf be added as a standard inclusion. Not only Beryl needs it, but Scribus needs it too.

Working on "stuff" 

I have been rather "quiet" lately, but just to let you know, I'm working intently on a few ideas.

So, I haven't had anything to announce here, and I haven't had much input on the forum. Also, various people have sent emails and p.m.'s and I haven't responded, so my apologies for that.

barry just looked at jinx a 44mb distro for 64mb PCs it uses qvwm window manager pixel identical to win9x how about throwing that in a couple alhpa versions or an odd numbered version.

didn't actually run it just looked at the site since i am on dialup. I wonder if the icon pack for jinx is open source?

Ted Dog 
Interesting find CB88, I did DL and gave it a try. very close to win98, about vers. 0.99 of puppy (with jinx having better graphics selection, looks like a direct rip of icons, including names of programs on its icons, like excel, word etc. I have a new laptop with vista {arg!! it did not have a calculator program = worthless)

[blockquote]I'm working intently on a few ideas.[/blockquote]

....... How very tantalising! We wait with bated breath.

Glad to know you're having some "quiet" moments. :-)

Here's the forum link about Jinx:

Rang you up at 11:50 AM - please check your email. Regards.

Hi, Barry,

Missed your frequent notes. Hope things are well. Still very pleased with Puppy!

You're probably familiar with the new Wolvix 1.1 live cd. This is somewhat puppy-like and very impressive in it's appearance, slackware package handling, and general ease of use. Can load to ram (if, like me, one has enough). Simplifies storing the config and added programs on the hd, etc. Definitely one to watch.


Might want to read the review of newcomers to Linux in the current issue of LinuxFormat?
The two outstanding issues were installation and packaging. Puppy does rather well on the latter, varies on the former, recently. To those, I would add - easy upgrading. Folks are loathe to lose previous data! Even F7 has EZupgrading, although it does take 3 - 4 hours. Maybe you're ahead of me as you "working intently on a few ideas" ?!

Raffy, ha ha, was that you? I have been pestered by telemarketers lately and when I heard office sounds in the background when I answered the phone, I hung up. I just checked my email, nothing there -- did you send to bkaulerATgooseeDOTcom? -- perhaps the spam filter ate it.

PET packages for 2.17.1 uploaded 

I've been a bit slow, but have now uploaded the PET packages that are new/different from 2.17. If you want to use Puppy Unleashed core v2.17.1, then it should be fine now.

These are the packages I have uploaded:

0rootfs_skeleton-2.17.pet busybox-1.01.pet coreutils-5.2.1.pet cups_espgs_gutenprint-1.1.23-8.15-5.0.0-2.pet cups_pdf-0.3.pet dhcpcd-3.1.0.pet fdisk-1.0.pet pdq-2.2.1-1.pet squashfs_tools-3.1r2-1.pet squashfs_tools_lzma-3.2-r2-1.pet util_linux-2.12q-1.pet

Someone on dialup reported that they appreciate having the latest pup in five parts for easy download, but they couldn't find a Windows application to join all the parts together. There is such an application, called SFK, available for Windows and Linux, and you can get it from here:
http://sourceforge.net/project/showfile ... _id=160478
I can't give you instructions on using it. Also, you can open a terminal window in Windows and there are Windows commandline tools to join the files, but again I can't help. Note, Windows probably has the 'cat' command, but I'm just guessing, thinking back to my MSDOS days long long ago. Note, my ibiblio download page with the 5 parts also has a script for joining the parts but that is designed to run in Linux -- but could probably be adapted for Windows commandline -- but Windows does not have the md5sum program, I presume a Windows version of that is available somewhere.

don't know how to binary split, but use binary copy should put them together, open a command window, type

c:\temp> COPY /B p1+p2+p3+p4+p5 ALL

this will join all 5 into the final named ALL, use MD5SUM verify check sum, it's also public domain downloadable.

I'm glad someone else posted "copy file+file+file file". It means I'm not the only one who remembers the DOS days!

Chaos md5 will check md5sum in Windows. Small exe file to download do a search for "chaos & md5"


RE: md5sum

Here's one that I found quite a while ago...'md5summer'


there is an md5sum checker for windows on portableapps.com

it will run from a usb drive as does all the software there

From my experience the simplest program with graphical user interface to create and check MD5 checksums is MD5Check (55 KB only).



It works fine in Windows and in Puppy 2.17.1 using Wine-0.9.28_212.sfs renamed to Wine-0.9.28_217.sfs.

The file 0rootfs_skeleton-2.17.pet appears to have a problem in it. All of the mirrors that I have check, when downloaded the file fails the md5 check.

Here is a sample DOS/Windows batch file that can do the job of appending the five parts automatically (sorry about the comments wrapping):

:: Barry Kauler 3 Aug 2007.
:: Puppy Linux live-CD is 94MB total, split into 5 files for easy download.
:: Run this script to join them after downloading.
:: Linux newbies: you need to be running Windows to execute this script!
:: Barry's script was converted to a DOS/Windows batch file on 2007-08-13
:: by Kenneth Cate. If you need a copy of md5sum.exe try the links at the
:: bottom of the web page:
:: http://www.openoffice.org/dev_docs/using_md5sums.html
:: Note: some versions of md5sum.exe use '--check' while others use '-c'.
@echo off
set fn1=puppy-2.17.1-nolzma-seamonkey-fulldrivers.iso
set fn2=md5sums.txt
if exist %fn2% goto :MD5

echo a691c2c91396c7cbd53e19a661823469 %fn1%.part1> %fn2%
echo aa7e3783be9b3256cc479e6c01cfd01f %fn1%.part2>>%fn2%
echo ea46726596e109ea21409c369b5fc74d %fn1%.part3>>%fn2%
echo 71e8424879416c9b940e8027145bd65b %fn1%.part4>>%fn2%
echo 32355c0b3ae99a1b9619d23682f982d2 %fn1%.part5>>%fn2%

md5sum.exe --check %fn2%
if not errorlevel 0 goto :EXIT
copy /B %fn1%.part1+%fn1%.part2+%fn1%.part3+%fn1%.part4+%fn1%.part5 %fn1%


True flushing at last! 

Wow, I'm testing the '2007aug06' experimental Puppy. Booting from USB Flash, I have modified PETget to install packages direct to the save layer, and it works beautifully.

When Puppy is booted from Flash drive, the Unionfs layers are like this:
/initrd/pup_rw working layer in tmpfs (ram)
/initrd/pup_ro1 the pup_save file, on the Flash drive
/initrd/pup_ro2 the pup_217.sfs file, on the Fash drive (lowest layer)

Previously, when PETget or any other package installer installs a package, it goes into the 'top', which is the pup_rw layer, but that is a problem if your PC doesn't have much RAM.

There is a background 'daemon' program called 'savepuppyd' that periodically calls 'snapmergepuppy' which copies-down the contents of pup_rw layer to the pup_ro1 layer, or you can do it on-demand by clicking the 'save' button on the desktop. But, that does not free-up RAM space, as it is only a copy-down, not an actual move of files.

With the new Unionfs v2.0, direct manipulation of the layers works extremely well. As a first step. something to experiment with, I have modified /usr/sbin/petget to install packages direct to the pup_ro1 layer. Unionfs2 recognises changes in a layer and automatically dumps its cache and re-evaluates the layers, so that files saved direct to pup_ro1 will immediately appear at the 'top' of the union.

If you would like to try this, read the previous post. Install to Flash, bootup, reboot so that you have a pup_save file, then grab 'petget.gz' from the same URL:
http://distro.ibiblio.org/pub/linux/dis ... 2007aug06/
Gunzip it at /usr/sbin, make sure its execute-flag is set, then find some PET packages to install. You can examine the layers in /initrd to see how packages have installed, and also run them to confirm visibility on the 'top'.
Run 'df' to see the free space in pup_rw and pup_ro1.

Note, the free-space indicator in the taskbar is not necessarily the best guide, as it will show the lowest of the two. So, if you have small amount of RAM space in pup_rw and big amount of space in the pup_save file, the taskbar will show the former.

The next thing we have to do is see if true flushing can be introduced to 'snapmergepuppy'. To see the changes in 'petget', look for "v2.17.2".

Burry, some of us cannot even boot with puppy 2.17 and 2.17.1 while everything was absolutely fine with puppy 2.16. Wireless in 2.16 (orinoco_pci) was fine while in 2.17.1 (prism2_pci) loads and wireless cannot get and ip through dhcpcd. All I want to say is that we will not be able to enjoy all those nice stuff coming with the next release unless major booting and/or network issues are resolved.

Barry - is there any difference between the 'pup_217.sfs' @ ibiblio.org ...2007aug06/ - and - the original on the Unleashed CD..?


initrd.gz and zdrv_217.sfs are different. The pup_217.sfs ....ahhh, can't recall any change fro 2.17.1. Well, there's the new petget, but I have supplied that separately.

Yes, I want to try an experiment. I'll upload the latest Puppy, but with a kernel (2.16 had and you can report if that fixes booting.

OK - will try with the original 'pup_217.sfs' - just substitute the other files as needed - then try reboot..

Will advise as to outcome..!!


"Note, the free-space indicator in the taskbar is not necessarily the best guide, as it will show the lowest of the two."

I wonder if it makes sense to put both values (remaining mem space and pup_save space) in that little box, one on top of the other (there appears to be room). Of course I don't know if the software that creates that box allows such a thing. Maybe I will look at it...


This might help throw some light on the workings of puppy.

Also is there a way to flush to nowhere and properly release all RAM?

Clockwise or counter-Clockwise I hear flushing goes opposite in the Southern Hemispere.

I think this is an urban legend. The flushing takes a few seconds, and the Earth rotates 1/240 degree of arc every second. Also, take into account the latitude. Australia is not the South Pole. You will get of the order 1/1000 of a degree change in the direction of the velocity. This is such a tiny angle, obviously there are more important factors determining the direction of rotation. Such as the shape of the sink and unionfs bugs.

Experimental Puppy with Unionfs v2.0 

This URL has an experimental Puppy:
http://distro.ibiblio.org/pub/linux/dis ... 2007aug06/

Unionfs v2.0 is very interesting. It is now merged with the '-mm' kernel source and will sometime be merged with the main source. There is a patch available for the kernel, and this is the very latest version of unionfs (the 'u4' patch).

Andrei and I have been studying how to improve the 'snapmergepuppy' script, and this new unionfs2 has a new mechanism for updating the cache when branches are directly changed. The 'unionctl' utility is still there, however now everything can be achieved by the 'mount' utility -- read the 'usage.txt' file at the above URL.

This is for testing with a USB Flash drive. If you already have Puppy installed, download the new vmlinuz, initrd.gz, pup_217.sfs and zdrv_217.sfs, to the Flash drive. Get rid of the existing pup_save.2fs file.

Any Puppy-developer who wants to experiment with the enhanced branch management is welcome to play with these files.

Works fine with my old pup_save.2fs file created with Puppy 2.17 as well as with the new one.

Barry Kauler 
Well, it gets better ...perhaps. The docs (usage.txt) state that the 'incgen' remount option is requied to force the cache to be cleared and the layers re-evaluated, however, I searched the unionfs mail-list and came up with these two posts. See how there has been a change since the bottom one which was posted in April:


Erez Zadok ezk at cs.sunysb.edu
Fri Jul 13 12:38:56 EDT 2007

Lenard, what version of Unionfs have you been using? I assume by "newest"
you mean something in which we added the mtime-based cache-coherency
support. Are you? All of our recent releases include that automatic
cache-coherency support.

With the mtime-based cache-coherency support, you do NOT need to use the
incgen explicitly any longer. That was needed in the past in order to force
Unionfs to invalidate all lower objects and re-get them; it had to be done
manually by users after they've modified lower objects. But now, Unionfs
automatically figures out when a lower object had changed, and it will
re-get the lower objects as needed.

Using the 'incgen' remount option should be a last-resort; it will cause
unionfs to purge all lower objects, and then they have to be re-gotten
incrementally; this could affect your performance. And if we add an option
to always re-get lower objects, performance would suffer greatly.

So I'm curious, if you're using the latest unionfs2 code, why you still
find it necessary to use the incgen option?


Erez Zadok ezk at cs.sunysb.edu
Fri Apr 27 11:40:02 EDT 2007

> Seriously though... one can safely and freely write directly to branches
> of a mount and it will be visible on the mount automagically?
> Were the rumblings I had heard about doing that being unsafe untrue?

Brian, what you describe is possible, with important caveats.
Fundamentally, the main problem is cache coherency, b/c stackable file
systems cache data at one layer, whereas users can go to the lower f/s and
modify it directly. The linux OS has no mechanism for synchronizing b/t the
two layers.

For now, the safest thing to ensure data consistency is to force unionfs to
flush its caches, thus re-getting newer/uptodate data via the lower layers.
This is done by incrementing the generation number of the unionfs
superblock. In your sequence of ops, you'll need to add the following
"incgen" operation:

$ cd /home/un-backedup/brian/
$ tar xzvf linux-1.2.3.tar.gz
# mount -t unionfs -o remount,incgen none /home
$ cd /home/brian/linux-1.2.3

The above assumes that /home is unionfs mount point.

Incidentally, that is a subject of much discussion that we've had with the
kernel community. This is also the #1 item on our plan to discuss in our
upcoming OLS 2007 talk. The good news is that the kernel community is
receptive to ideas which'd provide cache coherency for all stacked layers.
It's our hope that once the community settles on which direction for
cache-coherency they'd like to see, we'll go ahead and implement and release
it (we have some prototype code we've experimented with already).


John Doe 

if this works and you plan to include it, i'll will work it into wakepup2 for testing in next couple days for 2.18.

a quick PM on murgas forum with noswap=yes or noswap=no, or reply here will work to let me know.

implement it as you see best.


i'm guessing you're following this.

crash had a great idea which i believe will really help the end user that relies on wakepup with a custom config.

will pounce on this soon.


kernel config:


you mentioned having maybe would you please post thoughts about testing and using the config in that post? (Dougals config options should probably be included also)

hope to dig up a 133 or 333 with 128megs ram to test the boot times. i don't think anyone here other than me is using my silly 75mhz set up. if you look back throught that thread you will see boot time only increased 10 seconds over my ridiculously old machine from the 2.17.(maybe 1) kernel config to the control i set up with hyperthreading and smp.

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