logoPuppy developer news:

from 2.01 to 2.02

left-arrow Older news

arrow-rightLater news

Puppy version 2.02 released 

The live-CD iso file is puppy-2.02-seamonkey.iso and is 71.8M.
The greatest news with this release is full write support for NTFS partitions. Release notes:
Full read and write support for NTFS partitions. This includes saving of the Puppy session to hard drive.
More thorough checking of system integrity at a version upgrade, to ensure that the system is stable and usable.
The kernel is still version but has been recompiled to support 4G memory and frequency scaling.
Steps have been taken to simplify configuration files, with a single 'state' file called PUPSTATE in /etc/rc.d. This adds to Puppy's already very simple bootup and shutdown scripts -- see how few files there are in /etc!
Various applications have been updated and/or bugfixed, including TkDVD, MUT, Unionfs, Universal Installer, Grubconfig. Startup and shutdown scripts have many improvements.

The live-CD 'standard' iso file, with Seamonkey, is available via the download page:
Some other support files, puppy-unleashed-2.02.tar.gz, dev-202.sfs, all-modules-k2.6.16.7-PUP202.tar.gz are available from:
To discuss anything about the new release, please go to our forum:

Barry Kauler 
Billstclair has kindly provided a host for fast download of Puppy 2.02 and support files:

That was fast, as usual, congratulations!

We'd love a short podcast from you, Barry, to help us encourage a multitude of potential users out there. :)


PS - With NTFS hurdled at last, perhaps network services (like printing and PXE booting) can now be given more attention - Sunburnt already posted his dotpups, too: http://www.murga.org/~puppy/viewtopic.php?t=9729

I had the TORSMO dotpup system monitor in my Puppy1.09 and after I upgrade to 2.02 it starts to blink on and off for seconds at a time and I am using the default settings (used to stay on all the time and just a flash during refresh). It there some sort of display incompatability in 2.0x ?

NTFS write support! This is sure to get a lot more new users to Puppy! And it simplifies so many things for me as well! No longer have I got to use the multisession CD or my MP3 player for saving settings :D
A big hand to Barry for this release! And of course all the people who helped him out :)

I am writing this from Puppy 2.02, and it looks great!
But I got a problem when trying to make wine_202.sfs. The sfs was OK, but Puppy didn't seem to find it. But when looking in /root there was an wine_202.sfs. Bug in the sfs-detection?

Grbic Branislav (gbrane<at>ptt.yu) 
Well done !
I have sugestions ...
My favorite distro is 1.08r1 and is much better to put 10 seconds
not 5 seconds in begining for options !
Options is plane and simple with 1,2,3,4 !
I must to stratch MUT when plug my USB memory stick ?!
Wallpaper is much much plane and simple in 1.09CE then 2.02 ...
All in all good work !
I cant wait for 2.03 !!!!

tomek, Bulgaria 
That's GREAT! The best Linux distro!

John Murga has just released Opera Puppy 2.02 and a separate Wine module, so he must have tested that Wine gets recognised and loaded okay. See the announcements section of the forum.

Regarding boot options, I think most people prefer the 5 seconds. You only have to hit one key then the timeout stops, after that you can type whatever you want at a leisurely rate.

Regarding the 1,2,3,4 menu, the problem with that is that it is rigid,
only four choices. Whereas the way it is now you can enter any params that you want, that is, hundreds of choices. With the 1,2,3,4 system, to get as many choices as we now want would overfill the screen -- and be very confusing to read through.

Everything is done for a reason!

Lewis L. Donofrio (donofrio<at>umich.edu) 
Ok two things:

1.) How do I make a LiveCD from my installed puppy (or is it just copy that loopback file to the iso bootable image from??)
-- I used to this for remastering http://livecd.berlios.de/

2.) How would I put this on a Bart's PE CD (Not that write support is finished) ie http://www.nu2.nu/pebuilder/

make a LiveCD from installed puppy:

Lewis Donofrio (donofrio<at>umich.edu) 
ok but where can I find these packages for puppy: kde or xwin more over mpeg codex's and vlc, and frozen bubble, and xine, and tuxpaint? and about 500+ packages....what distro is this based from (like .deb? or .rpm?)

Am really looking forward to seeing Barebones 2.02 - since the save files are not compatible between Barebones and the full Seamonkey et all version I've held off on any upgrade to the new 2.02. Any idea on when we might see Barebones released?


Robert (info<at>ecomoney.co.uk) 
Superb work to see the latest NTFS support from the NTFS support team going into Puppy so quickly. Is this the first Linux Distro with NTFS support? This is sure gonna liberate a few P.C.'s

Puppy Linux - Everything Windows has but viruses!!!

Barry Kauler 
Yep, Puppy is the first distro to use the new ntfs-3g driver

Puppy has mostly binary compatibility with Vector Linux 5.1STD, which is based on Slackware, so those packages should work. However, Puppy is not "based" on Vector -- we just got many binary library packages out of Vector.
That is changing though -- Puppy is cutting loose and compiling everything from source -- see the T2 announcements.

In some ways I'll have to echo stlchuck's question regarding release of a Barebones Puppy - I've downloaded John Murga's Opera version but at this point don't know if it will be compatible with the save file for Barebones - once I've backed up the existing save file I'll give it a go and find out. Should be interesting and I'll let you all know if it works or not.



Tried John Murgas Mean Puppy with Opera - used it to boot with a save file from 2.01r2 and it worked flawlessly - no problems that I've been able to find - no lost files or applications. Looks like they will work OK together.

Puppy 2.02beta, with full NTFS write support 

This is not for general release. It is for our keen band of Puppy-testers only. The iso file can be downloaded from here:

The main thing is full NTFS read and write support, with hardly any increase in the size of the iso (still around 71M). When you boot the live-cd on a PC without any existing pup_save.3fs file, at shutdown you can now choose to create a pup_save.3fs file on a NTFS partition.
MUT and Pmount will both mount a NTFS partition with full write capability. If Puppy is booted and using a pup_save.3fs file, note that the partition that has the pup_save.3fs file will be mounted on /initrd/mnt/dev_save (symlinked from /mnt/home).

If you boot Puppy and there is already an older pup_save.3fs file, that you used with Puppy v2.00 or 2.01, Puppy now performs a very rigorous upgrade. It takes awhile, and the screen might stare back at you for awhile with nothing apparently happening ...I need to echo some dots to the screen to show processing is going on. Anyway, updating is performed to ensure system integrity, and dubious files are moved to /tmp/versionupdate/ -- a message is displayed informing you of this. Don't worry, it should be painless and you won't lose any customisations.

V2.02 is focussed mostly on NTFS support, and as usual there are heaps of other things not yet done. They are held over until v2.03.

Please, if you have important stuff in your NTFS partition, don't risk it. Either back it up, or wait until there is lots of feedback about the reliability of this latest Puppy.
Technically, there is a problem at shutdown with unmounting the NTFS partition -- it can't be done, can't even remount it readonly -- but the system status at the final stages of shutdown seems to ensure that the NTFS partition is not corrupted. I have been repeatedly testing Puppy then booting XP, and XP has not yet complained -- my understanding is that XP will detect any f.s. iregularity at startup.

Ah, one final and probably most important point: go into XP,
Start-> All Programs->Accessories->System Tools->Disk Defragmenter
and defragment the C: drive *before* saving a pup_save.3fs file to it. I didn't, then when I used the defragmenter it reported my pup_save.3fs file is in 339 fragments! It still worked, but performance must have suffered and it is making the job harder for the ntfs-3g/fuse driver.

Another point: the kernel is but earlier modules (v2.01) are not compatible. A nuisance if you have compiled one for wireless for example. I can help out, post the link here or the forum and I'll download and compile it.

When will the official v2.02 be released?

note that we have no 3D graficscarddrivers for this kernel.

If you need 3D accelleration (DRI), wait for Puppy 2.03 with kernel 2.6.18.


I'm assuming that this is the full version with Seamonkey etc? Will there be a test version for Barebones? Since the save files are not compatible between the two I may sit this one out if there is no Barebones version.



Since drivers have to be recompiled, why not move to 2.6.18 for V2.02 final? I'll be testing 2.02beta with NTFS, maybe even try a frugal install to NTFS. Thanks Barry!

I have just attempted a frugal install into an empty NTFS partition created and formatted with GParted. The install was OK and a "configure" of grub to MBR appeared to succeed. I updated my existing menu.lst to add the new installation. However, when I booted with grub, it reported: "Filesystem type unknown, partition type 0x7" and "Error 17: Cannot mount selected partition."

Barry - will you be upgradiing SeaMonkey to the 1.02 release for the gold release.
The only problem I had was with :-
icewm - i had heavily customized the menu and lost that in the upgrade and the origianl was not saed to the tmp folder. no biggee really as I had kept a copy elsewhere anyway.
radio - I had to revert it to the old guesttoo version as the newer one using the stations.txt did not work after the upgrade
wine worked for me by renaming my wine_201.sfs to wine_202.sfs without any other changes and all the apps i run under it like OO and Money
NTFS is a great improvement

Great job as always

2.02beta Forum thread:
...I've been responding there.

If there is no swap partition, Puppy will automatically create a swap file, in the same place as the pup_save.3fs file.
This seems to be a problem, it runs slow. The issue is being discussed here:

So, probably for the final release I'll disable creation of a swap file if it's on a ntfs partition.
If anyone else has an experience to report, regarding the swap file, kindly post to that forum thread.

Could you please recompile the madwifi drivers for 2.02? I don't know how to "downgrade" puppy easily and wireless is pretty much all I use my laptop for.

File cleanup at version upgrade 

Some people had problems upgrading Puppy from version 2.00 to 2.01, related to files not being upgraded. For example, v2.01 has ALSA kernel modules v1.0.11, later than those in v2.00, but after booting the v2.01 CD the older modules were still there.
The problem is due to the unionfs layers. Your persistent storage (usually pup_save.3fs) is the top layer and the files off the CD (pup_2xx.sfs) are in a lower layer. Thus, an "old" file can hide a newer one. The script /etc/rc.d/rc.update does ensure that all critical bootup and shutdown scripts are updated, however this does not catch all files.
To ensure a proper upgrade, /initrd/sbin/init, the script that executes first at bootup, performs a generic cleanout of all "old" files, and moves them to /tmp/versioncleanup/. Only files that have an older modify date than the corresponding file on the CD is removed. This cleanup should be okay, that is, not stuff up your customisations, but just in case, a message is displayed to examine /tmp/versioncleanup/ to see if any of your customised files have been moved there -- this must of course be done before the next shutdown, as /tmp/ gets wiped.

Which leads me to another problem. Unionfs seems to have a bug, in that it unecessarily accumulates whiteout files. If you don't know what whiteout files are, don't worry -- these are just small hidden files that are created whenever a file is deleted. In /tmp the number of whiteout files keeps growing indefinitely and you can soon find 1MB or more of these useless files cluttering up /tmp.
Now, /tmp/ is wiped at bootup by /initrd/sbin/init script, before the unionfs layers are created.

glenn west (glenn.west<at>aarcorp.com) 
Great work on puppy. Good progress.

One think I am desparate for is CIFS support. (this is the newer SMB support) I commonly use it for ghosting and frorensic activity to a windows server.

The other is support for all of puppy in the ramdisk.
I have seen another who has done this, and I can do it myself, but nicer if you have a "standard" version of it, so it tracks. You ask why. :) Its because then at anytime via PXE, I can boot puppy for recover, or hardware test, or just to have a nice environemtn. Since our shop is totally windows base, there is no NFS server to boot from. A single tftp, and the right patches make puppy bootable. (And I can write a installer that would let any windows installation use puppy.)

Various partition-related improvements 

Antonio Gallo, the author of libhardware, sent me a source snapshot from cvs. This has the fix for detecting ext3 partitions. I added my own fix for detecting ntfs partitions and compiled it statically with Dietlibc. This is now Unleashed package libhardware-20060723. Note, Puppy no longer uses all of the package, only the probepart, probedisk, test-eide and test-scsi utilities.

Jesse found a solution to a problem I was having with ntfs, namely how to determine the device knowing only its mount point (df and mount show the device as /dev/fuse). I applied this solution to /bin/umount, my script that replaces the umount program.

I also did a bit of work on /usr/sbin/pmount, my partition management GUI application. There was a criticism recently on the forum that it only displays 4 partitons of a hard drive, so I have increased that to 6 (not including non-usable and swap partitions). Also, the code has been considerably simplified.

Jesse has also updated MUT, his partition management GUI application, so it now works with the new ntfs-3g driver.
Note though, the new versions of MUT and Pmount will only be applicable when our ntfs-enabled Puppy v2.02 is released.

Bash is upgraded from v3.0 to 3.1. I'm using standard Bash for v2.02 rather than Bash-diff.

Rik (percussivedrums<at>gmail.com) 
i can't find where to put my devx_202.sfs file. i installed on HDB1

Ah yes, if Puppy is installed to hard drive, there is no place to put the devx_202.sfs file where it will automatically load.
There are various ways to use it ...see the forum, there are
a couple of threads on this topic.

Mean Puppy released, more work on the initial ramdisk 

John Murga has released an updated Mean Puppy, a Puppy-flavour that fits in a 50M business-card-size CD. Forum thread with discussion and download link here:

I have recompiled all the applications in the initial ramdisk fully static.

Puppy can now exit to the commandline in the initial ramdisk, which is great for poking around in it to debug the bootup process -- while doing that though, I realised a little text editor would be nice. So, the initial ramdisk now has e3, merely 13K bytes, with symlinks e3ws, e3em, e3pi, e3vi and e3ne, that provide key-binding compatibility with Wordstar, Emacs, Pico, vi and Nedit respectively.

Note, for other distros the initial ramdisk is something that loads into RAM first, then does a "pivot_root" to the main Linux filesystem, and then the initial ramdisk is discarded. However with Puppy I have deliberately kept it in memory and have a long-term plan to utilise it as a kind of super-root security monitor.

Note also, there have been reports on the forum that Busybox vi doesn't work properly in Puppy. So, e3 is a contender to replace vi in the main Puppy filesystem also.

Busybox Vi doesn't work propperly, that's why I replaced it in MeanPuppy.


[blockquote]Puppy can now exit to the commandline in the initial ramdisk.[/blockquote] - How to go to commandline then?
Is there a boot parameter for this yet, like if X doesn't display properly?

Full write support for NTFS filesystems 

Wow, I think we have finally arrived!
For the last 4 - 5 days I've been extremely busy working on this. Testing Puppy v2.02alpha, at shutdown I was able to choose a NTFS partition and create a pup_save.3fs file on it. My Pmount utility can mount a NTFS partition with full write capability. This is using the new ntfs-3g driver, but there was a lot of detail work getting it to work seamlessly in Puppy.
On my test PC the NTFS filesystem has remained okay, even though I had to press the PC's reset button a couple of times while it was still mounted. However, Puppy v2.02beta will be released about Thursday 27th and I would like as many volunteers as possible to test it and find out if your NTFS filesystems survive uncorrupted.

It was necessary to compile a static ntfs-3g driver for the initial ramdisk. Being static, any distro can use it, as long as the distro has the fuse.ko kernel module.

Various other things have also been done:

The 'probepart' program (part of libhardware package) had a couple of bugs. It did not properly recognise NTFS partitions, and the official last release (0.7.4) cannot distinguish between ext2 and ext3 partitions (Puppy 2.01 has an unofficial executable that does, but the author of libhardware seems to have misplaced the source code for it). Anyway, I fixed both bugs. Note, probepart is compiled with dietlibc as it does not work right when compiled with glibc.

I'm gradually working through recompiling all the apps in the initial ramdisk with dietlibc.

As mentioned earlier, /bin/mount and /bin/umount are now scripts, to provide seamless support for ntfs-3g. There are still some issues, but I've got them working okay. /usr/sbin/pmount has also been worked on to support ntfs-3g, also still has some issues, but basically okay.
/etc/rc.d/rc.shutdown needed many fixes to handle the ntfs-3g driver.

A really nice thing that has helped me with getting bugs out when booting. The boot parameter 'pfix=rdsh' will exit to the commandline in the initial ramdisk.
Also, the 'pfix=' boot parameter now accepts multiple options, comma-separated. For example 'pfix=ram,rdsh' will bootup running totally in RAM and will exit to the initial ramdisk shell (and not do a pivot_root). Another example: 'pfix=usbcard,ram' boots from PCMCIA-USB drive and runs totally in RAM.

Lobster (ed.jason<at>gmail.com) 

Good news. Due to the London heatwave I am using a NTFS machine . . . which is downstairs where it is cooler . . . suddenly realised why no writing was occuring. It is not my machine so will allow a few others to test first. This makes a huge difference. Well done. Look forward to the test release :)


Is 2.02 going to have a new version of bash? The current one has problems, see:


Also a small bug, If you crash the system (just turn it off) and reboot it comes up to a prompt. Then if you type xwin, a message comes up telling you to type xwin or run the xorgwizard. Then you have to type xwin again.

Looking foward to 2.02!!

P.S. Would a type 1 install be possible to NTFS?

If/when you post the kernel source, would you consider posting it as a '' or somthing like that. This makes it very convenient to use. Well, unless your using a #2 harddrive install.

sethmeisenberg (seth<at>amnet-comp.com) 
[b]Kirk:Is 2.02 going to have a new version of bash?[/b]
--And if so, will this version have 'less'?

Also, will 2.02 resolve the devx_201.sfs problem, encountered in 2.01? See:


Since 1.07 
Thanks for your tremendous work !
Now Please include ntfsundelete. We always get stuck without!
"If XP sucks - grab Puppy"
Man page here.
From OSDir Ifound this link on the interesting story of ntfs-3g

Kernel recompiled 

I have recompiled the kernel with the following changes:
1. 4GB high memory support
2. CPU frequency scaling
3. Filesystem in userspace support
4. 8KB kernel stacks, instead of 4KB

It is version, the same us used in Puppy 2.01. I wanted to upgrade the kernel version, but there are various issues preventing that. One reason for wanting the upgrade is that the Unionfs project has, for about the last 1.5 months, only been supporting kernel 2.6.17.x -- there are bugs in unionfs, but I had to settle for an upgrade to one of the last versions of unionfs that still support the 2.6.16 kernel.

So, Puppy 2.02 will have kernel with the above enhancements, however I do intend to upgrade to a 2.6.18 kernel after that.

Will you be including support for dual core processors? It appears that is the wave of the future for processor manufacturers.

will we have to recompile existing kernelmodules with Kernel 2.6.18?
One thing I liked in Puppy until now was, that it did not upgrade the kernel as often as others distros do.

So I would suggest to upgrade only, if there is a concrete need.


It is most unfortunate, when I recompiled the kernel, the previous modules (for 2.01) no longer work. It may have been because I changed the kernel stack size.
I wanted to avoid that, as many people have compiled modules,
for example for wireless.
It's unfortunate.

Note, I wanted to change to 8K stack size as Windows drivers used by ndiswrapper may require it. Although, another unfortunate thing is that it seems, as far as I can determine (documetation on this is pathetic, non existent, not announced) that from 2.6.17 kernel support for 8K stacks is being dropped, meaning that most Windows wireless drivers won't work. I don't closely follow kernel development, but it seems that quite major architectural changes are happening for what are minor version number changes (like 2.6.16 to 2.6.17) ...if so, it's disgusting.

The 2.6.18 kernel will have some improvements for libata that I want, so don't want to delay to long to upgrade to it. Plus need latest unionfs.
Meaning, probably for Puppy 2.03.

Hopefully from v2.03 we can stay with the same kernel for

Kernel upgrades are like taxes: inevitable.
I agree that a significant feature or significant improvement justifies a change in kernel.
And I agree that SATA support is significant.
But I don't agree that improved ndiswrapper support is significant.

It seems a shame to ditch current module compatibility for what seems to be only an interim measure, since 2.6.18 is already on the drawing board as a replacement for the modified

May I suggest that kernel changes also gets a more significant version change in puppy ?

Puppy 2.1 with kernel 2.6.18.x

Or do you have specific plans for 2.1 ?

ntfs-3g full read/write for NTFS 

I've compiled the ntfs-3g user-mode NTFS package. This is supposed to provide full write capability for NTFS partitions.

I have also replaced 'mount' and 'umount' with scripts, that provide seamless mounting of partitions. That is, if the partition is NTFS then the 'mount' script will execute 'ntfs-3g', otherwise will execute 'mount-FULL' (the "full" mount program, as opposed to the Busybox mount applet). Ditto for umount, 'fusermount' is executed to unmount a NTFS partition, otherwise 'umount-FULL'.

This means that all existing scripts in Puppy can work unchanged, also users can keep using the familiar 'mount' and 'umount' programs.

Recognition of NTFS at bootup however, that's a different story ...stay tuned.

Simplification in /etc/rc.d/ 

I think it was lior2b who mentioned awhile back that Puppy has lots of little configuration files in /etc that could be consolidated into one or two multiline files. The advantages would be everything in one place and comment lines could easily be inserted.

I've taken a step in that direction. /etc/rc.d/ has six files, DEV1FS, PDEV1, PMEDIA, PUPMODE, PUPSAVE and PUPSFS, that I have consolidated into one file, PUPSTATE. File /etc/rc.d/PUPSTATE has multiple lines, defining each variable, for example:

To include these variables in any script, just place this line at the beginning of the script:
. /etc/rc.d/PUPSTATE

File PUPSTATE is created at bootup by the /initrd/sbin/init script in the initial ramdisk. The files that I had to modify to read this new arrangement are:
/etc/rc.d/rc.local0, rc.modules, rc.shutdown, rc.sysinit, rc.update
/usr/sbin/calcfreespace.sh, delayedrun, remasterpup2, resizepfile.sh, savepuppyd, savesession-dvd, video-wizard, snapmergepuppy

lior2b (lior2b<at>gmail.com) 
That's a great idea, but someone else should get the credit, I don't recall bringing this issue up  Anyway, as I see it, this is a step in the right direction!

As sa further step in standardizing Puppy could be to include 4 more environmental variables to comply with the freedesktop's base directory specification:


For Puppy these variables would contain the following:


Okay, it's done!

Hi Barry,
Saw your note on collecting some of the Linux configuration data in one place. I saw this project recently, and thought it was a pretty good idea, so I'm passing it on to you.


All done in compressed XML, it's a kind of completely open and 'human readable' registry (yeah, I detest Bill's binary MS registry too!) for Linux. Might save having to be a guru and learn all the different locations (granted they're mostly in /etc) and layouts for the many and varied applications' config files. It also has a gui configution editor as well.

Just a thought.


Building Puppy totally from source 

Puppy has always relied upon another distro for the build environment. What I mean by that is the C/C++ compiler (gcc) and the C/C++ libraries (glibc) plus various support packages. We can't just compile these in Puppy and upgrade, as all the other packages would also have to be recompiled to work with the new glibc. Currently we use Vector Linux 5.1STD (based on Slackware) and previously we used Mandrake 9.2.

A major problem that we have is upgrading of packages. Sure, we can compile a new package, but what if we want to upgrade glibc? What if we want a more recent GTK library? There is definitely a need for a streamlined, quasi-automatic way of doing this, that will compile the new GTK or whatever and every package that depends on it.

I have always wanted to be able to build Puppy totally from source, free from dependence on any binary distro., but it is complicated thing to implement. Yesterday I did some research, examining what tools exist that can help with this, and I narrowed it down to the T2 distro. Well, T2 is not a distro as-such, it's a build script that builds a distro from source packages. T2 is based on ROCK Linux. Why not Gentoo? -- the main reason is that Gentoo scripts are written in Python, whereas T2 is Bash scripts all the way. The T2 website has a T2/Gentoo comparison table, to be found in their handbook:
http://dl.exactcode.de/t2-handbook/html ... 2-100002.2

I have only just started to play with T2 and my first impressions are very positive. The scripts are beautifully written, extremely intelligent. Note, I'm running T2 in Puppy, but you must install T2 in a mounted partition with at least 5G space, and you need to install libidn (a PupGet) and the 'cksum' application is required (I got it out of Vector, from /usr/bin).
My thinking is that we can modify T2 to build a Puppy root filesystem, while keeping compatibility with T2 and their very large repository of packages. Note, T2 uses standard source tarballs, and any patches, configure options, etc., are kept in separate files.
If this interests anyone, I invite you to try T2 and report on experiences and contribute with how to modify. This is only the evaluation phase, but if we do decide T2 is the way to go, then we can setup an SVN project.

T2 homepage: http://www.t2-project.org/

I'm testing T2 version 2.2.0-rc, downloaded from here:

Nathan Fisher 
I have not tried T2 (but I will), however I think this would be a good direction to take Puppy on the whole. It would be nice to see a more complete and stable toolchain even though devx does work very well, and I think it's very likely that stability of certain programs would improve as well. All in bash, sounds a whole lot better than Python.

Ted Dog 
I have a toolchain already developed which will run puppy *.sfs I was waiting until I release the guppy project, but I'll post the toolchain to www.puppylinux.com/dev so you can compare work. The toolchain with all sources is about 138M without sources 500K unzip and start with
make sum. You will need the bash & nasm also at the same site to get around the CXX(hhjjj ))) error during ./configure

Kenneth (klhrevolutionist<at>charter.net) 
I'm glad to hear that the glibc issue will be resolved. I'm not sure how I could assist you, as I am a 'self-proclaimed' advanced end-user.

But if you think that I might be able to help out in some area let me know.

I'm glad your going back to your roots and focusing on the core as well as the barebones project. Should be interesting to see how much puppy will advance or gain advantage should this prove to work out.

Mandrake has compatibility libs allowing to run older binaries.
In Puppy too, we have several versions of libstdc++, so this should be no problem?
I'm no expert in this however.

Ted Dog 
after typing the last lost msg this is short, I cannot get past the Anti-spam more than half the trying to post. http://www.puppylinux.com/dev/guppy <=toolchain
forum.puppylinux.com <= guppy talk

Ted Dog, I'm very interested to look at what you have done!
I'm on dialup right now, but will have adsl2 access Sunday night.

MU, there are lots of gotchas in compiling the underlying applications and libraries like gcc and glibc. Very few distros do it, they just rely on some other distro like Slackware or Mandrake. I'm far from an expert in this also, but I did try some experiments to see what can go wrong. I compiled a newer gcc and glibc from within Puppy. gcc compiled and installed okay, but after installing glibc the applications all crashed. The reason, as far as I can determine, is the glibc symlinks all get messed up, so for example libc.so points the new library. Apart from that, gcc has been compiled with the previous glibc, so has to be compiled a second time to work with the new glibc.
...or something like that. Anyway, it's messy.
A toolchain like T2 creates a ext2/3 filesystem inside a file mounted by a loop device and uses that as a 'sandbox' to compile everything.
Ted Dog has created a toolchain, so is more familiar with the issues involved.

A couple of points in favour of T2:
1. A file list is automatically created for each package, which is good for extracting our Unleashed/Pupget devx packages afterward.
2. As compiling is happening in a 'sandbox' environment, compiling can be for any CPU. So, we could build Puppy for any CPU. The T2 'Config' script has a nice text-mode gui (same as menuconfig used in kernel config) to select desired CPU.

Another plus point:
3. Those T2 guys have managed to compile Open Office. Sometime back, I gave up in disgust.

A negative point:
1. Documentation is a bit too light in places. Also it's out of date -- there's a manual, but the latest v2.2.0 T2 has major changes not yet documented. For example, some of the steps explained in the manual are no longer required, and the .gem package format is no longer used (in favour of just using the original .tar.bz2 source files).

Nathan Fisher 
That's great news that the build process creates a file list. Quite handy for our uses. That sells it to me in a lot of ways, I guess it just now depends on how flexible the build scripts are since our package choices are not always what you would call conventional.

Paul (pesch<at>attglobal.net) 
We have used Gentoo now for over two years (for our client / server system at our school) and we have been very happy with it. Before we used Rock Linux which was also quite good. Either one would be great for Puppy.

Puppy 'standard' v2.01-revision2 released 

This is a bugfix release. It has all the bugfixes and improvements announced since v2.01 was released.

Download from here:

The release notes for v2.01 apply. Read them here (June 19):

If you have a functional 2.01, probably no need to upgrade -- wait for 2.02 -- Puppy will not do a proper upgrade anyway, as this release has the same version number '201' and Puppy only runs the upgrade script when the 3-digit version number changes.
For v2.01 users, I do recommend downloading rc.shutdown.gz and install it, as announced in here July 10th.

V2.01r2 'standard' does have GnomePPP, for experimenting with, but note my somewhat negative experiences with it. If anyone discovers some magical fix for it, please let us know!


  I got confused . . . (not unusual) anyways deleted the pup_save.3fs (to have a fresh install)
So am in this now thanks to MU for mirroring which I used as my second - successful - download . . .

One good thing. I choose Xorg instead of xvesa and the resolution choosing pages have been combined into one. Much improved :)

Does the rc.shutdown.gz bug fix apply to Onebone too?

If you have any puppy 2.00, 2.01 or 2.01r1, then it may benefit from the new rc.shutdown script.

John's board has gone down again this morning, so please exceuse this vaguely relevant item in Barry's blog and won't be offended if BK moves it along as and when.
Have been complaining (yes, that's my way of saying 'Hello'!) about issues with the new Universal Installer, for HD installs, that is.
Finally cracked it, and speaking in complete ignorance as usual, I'm guessing that the mods. necessary may be quite trivial from the coding viewpoint?
It seems to improve matters if the HD is cleaned down completely with a debug script or why, then partitioned with a VFAT (and Linux swap, if using one - always a good idea). Then start up P2 in ram only and use cfdisk or w.h.y. to rejig hdax as a Linux partition. Then it has to be formatted with ex2fs command. If the last two steps aren't observed the installer wrongly recognises the hdax as a Linux ext2 partition and will go screwy somewhere down the line - this is new; the older version seemed to recognise that it had to change the FS to ext2 AND format it without asking. This is an essential internal installing mechanism, in my opinion, as a more friendly approach for new converts and total neophytes. Not following this kind of recipe can result in all sorts of spurious behaviour, including installing the GRUB but not the OS, claimimg to have installed the OS and GRUB, but not, and other combos. Couldn't get the thing to format to ext3 or reiser; not sufficiently briefed to understand why. Maybe should've used GParted? Any road up, seems that there is scope for a little tidying that would aid the transition for putative users, who could soon be numbered in the millions now that M$ has been fined €280.5m by the EU for dirty tricks. The fine will rise to €3m/dy from 31July; after that, I guess they'll be banned from trading in the Community. Best news since the proverbial sliced bread.

alienjeff (alienjeff<at>charter.net) 
Does 2.01r2 address the problem some of us have with bkup2cd in 2.0.1-r1, or should we wait for 2.02?

I have a customized 2.00 barebones with customized JWM menu and added my favorite apps. It's working fine, so is there any reason to go to 2.01r2?
Is there any timeframe for the 2.02 barebones?
A small 'backbone' iso (core + only minimal applications) would be a good starting point for the 2.xx CE project, IMHO.

Jim Lyons (lyons<at>canada.com) 
Anyone had problems burning any version of Puppy (including 2.1 R2) to cd using burniso2cd? I haven't been able to get a single good CD using my HP 9300 on a 500 MHz AMD K2 with 500 MB RAM. I haven't found how to adjust burning speed which might be the cause of my problem. Any help or (polite) suggestions would be very welcome. Jim

PS Windows programs burn no problem so I assume my burner is OK.

Jim, this might help you:

6th message.

Jim Lyons 
Looks like I'm not the only one to have problems burning CD's. I guess I'll have to wait for a future release or go back to an older version. Apart from that problem I'm very very happy with the various versions of Puppy and hope one will eventually replace Windows 98 on my machines. Thanks to all involved.

if you have a working and customised 2.00, there's probably no pressing need to upgrade. if you read through all the news since the release of 2.00 and see something added that you really want, then upgrade.

"If you have any puppy 2.00, 2.01 or 2.01r1, then it may benefit from the new rc.shutdown script."
Thanks Barry 

Bug in BareBones 2.01r1 

Thanks to rerwin who found this. It probably won't affect you, but as it can potentially wipe the partition that you are attempting to create the pup_save.3fs file on (the file in which the session is saved on first shutdown), I need to fix it pronto. Version 2.01r2 will be uploaded very soon.

Found the bug. BareBones v2.01r2 is available:

If you already have v2.01r1, download the file rc.shutdown.gz from:
Ungzip it: # gunzip rc.shutdown.gz
and copy it to /etc/rc.d/
...however, it is a bit of the case of putting the cart before the horse. You really should have this bugfix before the first shutdown.

The bug was that when you choose to create pup_save.3fs at shutdown, the partition (in which the pup_save.3fs is to be created) is mounted on /tmp/savepup -- under certain circumstances this was not unmounted, and later in the script all of the contents of /tmp was deleted!!! Sloppy programming. Anyway, it's fixed.
This rc.shutdown script can be used for the regular 2.01 Puppy also.

Wiki news will go straight to 2.01r2

The CE is dependent (for me anyway) on being able to burn to DVD-RW - will this be added for 2.01r3 if possible? Also having problems (confirmed) with the burning . . .

I know these r1-r9 uploads are not always possible but they make a huge difference to the eventual reliability,

Maggie reed 
Can you please check version 2.0.1seamonkey to see if the same bug is there?
i used what they call "poor man's install"" (extracted the ISO contents hen used Linld to boot from dos)after saving i rebooted to find the entire drive was empty.
luckily i use another an old machine to test new release and didn't lose anything important.

I don't know if you hit the same bug. Anyway, if you can install the new rc.shutdown before the first shutdown, that will eliminate that particular bug.
Or, grab v2.01r2 that I have just uploaded.

BareBones version 2.01r1 released 

Puppy BareBones is a lighter build of Puppy. The live-CD file is puppy-barebones-2.01r1.iso, size 46.5M and available from:

This build is a bit bigger than BareBones v2.00, which weighed in at just 39.9M. This time I included a more complete suite of library files, so any application can installed without needing extra library files. I also threw in some extra applications, such as GParted (partition manager). Also included are the Smartlink and Lucent soft-modem drivers. The web browser is only Dillo though.
Note, I do plan to try an get it closer to 40M for the next release of BareBones.

The usual instructions: burn to CD and reboot. However, if you already have a pup_save.3fs file you probably don't want that to be found, as it's menu and desktop icons will be wrong. You can bootup in RAM with the boot parameters "puppy pfix=ram" to evaluate this new Puppy, and perhaps mount the h.d. partition and rename the pup_save.3fs file to something else, say pup_save1.3fs -- then when you shutdown you can choose to create a new pup_save.3fs and it won't interfere with the old one -- at next bootup a menu will appear and you choose the one you want (bug: the menu does not work with usb keyboards).

This version is 2.01-revision1, as it includes the bugfixes and improvements announced since the release of v2.01.

Would your cautionary comment about the save file apply to one for the 2.0 Barebones? Or would it merely be an upgrade in that case? I'll give it a shot but think I'll backup the save file first just in case.



Ah, no, I was thinking of people who have a pup_save.3fs file for the 'standard' Puppy.
If you have a pup_save.3fs for BareBones 2.00, the upgrade should work ...fingers crossed.

Extra note, BareBones 2.00 should upgrade okay, but it doesn't upgrade your desktop wallpaper, so if you have that image with the 'puppy 2.00' emblazoned on it, that will remain.

rerwin (richard_erwin<at>msn.com) 
Beware! Danger! I followed the advice to rename my existing pup_save to something else (I chose pup_save-std.3fs) and then saved the new personal data to a file, specifying one of two available partitions.

Upon reboot, not only did BareBones 2.01r1 not ask me to choose a pup_save, but it appears that the entire partition I specified has been erased!

OTHERS PLEASE READ: Just a heads up in case you are as inclined to cluelessness and running on autopilot as I am - please learn from my mistake...
Yesterday I was booted in ram to check some things and, when finished, I rebooted and without even noticing I'd done it until WAY too late, hit return when it asked if I wanted to save pup_save.3fs... oops. It did what I told it to do: saved the new one right over the old. Lesson learned? (real answer? probably not. optimistic answer...) for now keep normal work in pup_save<something else>.3fs. Barry said this will be prevented in the future, but for now I want to be safe.

Barry, please consider having the ability to set a default and timeout for when it asks which dev_save* to use. For example, if 95% of the time I boot into dev_save9.3fs, but want to also have dev_save.3fs, dev_save1.3fs etc. then I'd like to be able to choose to go with a default after n seconds, and better yet, have the choice of setting the default or using last used dev_save. Would that be possible?

I re-created the erased-partition problem by attempting to save to a full partition. Shutdown spewed many messages; reboot showed the partition to be empty. Lesson learned: avoid saving to partitions showing no free space.

After backing up the save files on the laptop went ahead and booted with 2.01r1 Barebones. Looks like doing an upgrade from 2.0 Barebones is safe to do - so far I haven't lost anything and all files look to be intact. I'll do more looking but the first impression is positive. Nice job!!!



I booted up 3 different laptops with puppy 2.01rc1

Compaq Armada E500: Boots fine with default boot choices.
Autodetects modem "LT" - dials with GKDial.
WVDial says, modem not detected.
One nasty thing I noticed is, after a few minutes the machine goes into sleep mode? (I assume) won't light up again until I press power button. When it comes back to life, the touchpad mouse is erratic & pretty much unusable. Tried ctrl+alt+backspace+xwin, restarts xwin but mouse is still nuts.

Dell CPt: Boots fine with defaults.
No modem detection using LT or SL, no wvdial modem detection, tried saving both choices anyway and dial-up, but nothing works. I should mention that 1.06 works fine with one of the LT drivers on these Dells.

Thinkpad: Will not boot without adding puppy pfile=noirq (or something to that effect) it was answered re: puppy 2.x in old developer forum, but I don't remember now.

hmm, I rather doubt you (Barry) will see this - not sure how blogs work, as I'm stuck in the 90's, and don't know if it alerts you to new comments... in any case, just want to point out that in my previous comment above I meant, obviously, pup_save* and not dev_save*... not sure why I typed that. In fact, I just found out that I had done so now when I googled dev_save and that was the result I randomly picked. How odd it is to get back to one's own posting through google, which usually goes farther and farther away.

Yes, I've seen it!
Latest replies are summaried on the sidebar of the blog, so I can see at a glance if anyone has posted a reply.

TkDVD DVD-burner application fixed 

As reported earlier, v4.0.1 had a bug, that I reported. I am pleased to report that it is fixed, and I expect "v4.0.1r1" (actually it's from CVS) to be in BareBones.

I would like to thank Regis Damongeot for his patience and quick fixes to the bugs I kept finding!
His TkDVD page is: http://regis.damongeot.free.fr/tkdvd/

Note, I personally find TkDVD particularly useful. It is my regular backup tool (well, not as regular as I should be).

Bug in unionfs 

Puppy2 has unionfs version 20060417, which is a nightly snapshot. I discovered this awful bug. I did this:
# cd /root
# mv -f gtkdiffrc my-applications/
# mv -f my-applications/gtkdiffrc ./
# mv -f gtkdiffrc my-applications/

This moves file 'gtkdiffrc' into my-applications folder, then out, then back again.
The end result is gtkdiffrc is in my-applications/ folder, right? I tried it just now, and yes, it's there, but earlier on, running a script that does the same thing as the above, the file just disappeared.

The unionfs layers are /initrd/pup_rw, /initrd/pup_ro2 then /initrd/pup_ro3 on the bottom. After running those three mv's, what I see in /initrd/pup_rw/root/my-applications/ is two files:
.wh.gtkdiffrc and gtkdiffrc

The first one is "whiteout" file, meaning that gtkdiffrc is erased. It seems that under certain circumstances the unionfs sees this only and reports no file.

Anyway, right now I'm downloading the latest released version of unionfs, v1.3, released 20060626.

[pre].wh.gtkdiffrc and gtkdiffrc[/pre]
...this is actually quite mysterious. I have tried to think of some justification for the whiteout file being retained when 'gtkdiffrc' is moved back into the directory. I considered various scenarios, such as another 'gtkdiffrc' on a lower layer, but no can't think of any valid reason why the unionfs management didn't delete it.
Which would explain something... whiteout files seem to proliferate, particularly in /tmp, and if unionfs management is not deleting them when they are no longer required, that explains the proliferation.

Nathan F tried to post a comment earlier, but my site was down, so he sent a p.m. to me at the forum:

[blockquote]Anyway, I saw the post about the unionfs bug. I think I have an inkling what is going on. I think this might have something to do with the script being run from within the union. It doesn't make sense at first that something like this is happening, but I think that when you try to recreate the file it causes a little 'hiccup', for lack of a better word, in the filesystem, which is enough to stop your script from running. Remeber I was having the same type of problem with the script I was working on for hotplugging branches into the union? In that case the workaround was to move the script itself to somewhere outside the union, so my solution was to move it to a tmpfs. Actually I might not have come up with that without your help.

The other thing is that I'm not too sure unionfs-1.3 will work with kernel-2.6.16. I have been working on a custom kernel-2.6.17 and remeber reading that for 2.6.16 unionfs-1.2 is required. I hope I'm wrong. [/blockquote]
Nathan, I'm afraid you are right, 2.6.17 is required ...which I compiled last night, and ran into some 'issues' ...but that's another story ;-)

Shankar Gopalakrishnan (shankargopal<at>myfastmail.com) 
Oddly enough I have a very similar problem - but in my case I'm not moving the script back, it seems to do it itself!

Here's what occurs. There's a script called tom_print.sh in /root/Software. Then I do:

mv /root/Software/tom_print.sh /root/my-applications/bin

Works ok. Then, I type

tom_print.sh output.ps

from /tmp, and it works - given that tom_print.sh is now in the PATH.

But then...

tom_print output2.ps


sh: tom_print.sh: command not found

And, what do you know, tom_print.sh is back in /root/Software!

This has happened three times. The "script" - not really a script- itself is just a one line smbclient command so it can't be doing
anything. I had meant to post on the forum, but thought this would b better.

Nathan Fisher (nfisher<at>grafpup.com) 
I'm interested in what problems you had with, since it's giving me some headaches also. I had to revert a patch for my sound driver and I can't get the console to work except with 'vga=normal'.

I was unable to compile the Smartlink and Lucent modem drivers.
Ndiswrapper may be broken, as far as I can see the kernel has gone to 4K stacks only for modules. Earlier 2.6 kernels allowed a choice of 4K or 8K (2.4 kernel has 8K). I searched for further info, couldn't find much, except a comment from one of the kernel developers that "I don't care about ndiswrapper".
Many Windows wireless drivers need more than 4K, maybe as high as 16K. What will happen is they will load okay, but later crash.

Nathan Fisher 
Whoahhh...now that sounds like some real problems. Combine those issues with the trouble it's already giving me and 2.6.16 is looking better all the time. I still might try to get the lucent and smartlink drivers working myself, but if I run into problems like you did I will probably revert back. I still need the lucent driver for my laptop.

Speeking of which, that driver loads fine in OneBone and connection is really easy with eznet. I was impressed.

Misc. fixes and troubles 

Dougal asked why ~/.thumbnails is no longer a symlink into /tmp, as was done in Puppy1. At first I couldn't think why I had taken it out. The rationale in Puppy1 is that /tmp is running in fast RAM whereas /root may be the slower save-file on h.d. However in Puppy2 the entire '/' is the save-file, so there is no reason to make /root/.thumbnails into a symlink.
However, the contents does keep growing, so there is a need to delete, probably at shutdown. Will do.

I found that /etc/rc.d/rc.shutdown can get it's kn***ers in a twist on a PC with only NTFS partition and you choose to save the session to a save-file but there's no suitable partition, not even any plugged-in Flash pen drive. I don't have such a PC, but looking at the code theoretically it looks like rc.shutdown would go into an endless loop. I fixed it so it shuts down gracefully.

I'm having reliability problems with GnomePPP. :-(
Testing the latest iso build, with latest ppp package, GnomePPP repeatedly failed to negotiate properly with the ISP. After many attempts, I tried Gkdial which worked first go. Finally got GnomePPP to negotiate correctly and it's running now. This is not good. If I can't isolate the cause, Gkdial is going to remain as the main dialup app.
It costs me 35c per local call, to repeatedly dialing and hanging up is going to cost me.

TkDVD just does not work anymore. It had a bug before, with Tcl/Tk 8.4, in which it reported that "growisofs is busy" then refused to do a burn. The author thought that he had fixed it, but no, it isn't, and I find with Tcl/Tk 8.5 the bug has got worse to the point where I can't burn at all.
I've informed the author, so hope he resolves it. He is responsive and has downloaded Puppy 2.01 to test on.

After several more attempts, gave up and connected with Gkdial.
My ISP accepts plain-vanilla pap protocol and Gkdial works flawlessly.
GnomePPP goes through the motions, sends username and password, starts pppd, but the protocol seems not to have been properly completed and I don't get the dynamically assigned IP address and after a short time the pppd hangs up.

On the TkDVD front, Regis has released v4.0.1, which fixes the "growisofs is busy" error, but now there's a new bug: the 'Advanced Options' button no longer works --- sigh.
Anyway, I've reported it to him.

ppp requires IP address dynamic or static along with user account and password?

Gkdial isn't broken, so I for one will be happy to keep it (it has been my only dial-up service for Puppy in many places and a long time).

BTW, as this topic is MISC, may I suggest this background image? http://ph-islands.net/puppy/sky1.jpg

It is an original shot, and the whitish portion in the region of the icons is able to highlight colors.

You can reduce (resize, cut) it to your preference. Thanks.

Ben Wise (pdn2006.20.wiseowl<at>spamgourmet.com) 
Hehe - yep I experienced shutdown's endless dialog loop when I shutdown on an NTFS PC at work... Nice to know it's fixed now (though I was just playing around so it didn't matter).

The endless loop seems to happen in general when the user chooses "SAVE TO FILE" but there are no suitable partitions (for example, small systems with no HDD at all). [tested with qemu]

Desktop 'connect' icon improved 

I have changed the desktop 'connect' icon to one of those Rox-filer applet thingies. It resides at /usr/local/apps/Connect/.
What this means for the end user is you get a mouse-over popup tooltip, that is a message summarising what the icon is for, and a right-click on the icon offers a menu.

The action of the 'connect' icon is configurable, and it can be made to launch the Internet Connection Wizard, GnomePPP, Gkdial, or Roaring Penguin PPPoE, whatever you need to connect. But, if set to launch Gkdial, you can go back to the Connection Wizard at any time by right-click on the icon and choose from the menu.

It is intended that Puppy 2.02 will have Gkdial, GnomePPP and Xeznet dialup applications, as well as Roaring Penguin, and some juggling is required to get these to play nicely together. It was necessary to start gnome-ppp application from a script, gnomepppshell, and some modifications were required in the wvdial-1.53 Unleashed package.

I am unable to test any software modems with GnomePPP, and this will need to be tested, maybe will require further mods. There is report that the Lucent modem works, but we don't know about Smartlink modems yet.

I see you are working on 2.02, do you have plan for a BareBobes-2.01 ?

I put BareBones on the back-burner.
I was thinking that John would be bringing out his little
50M Opera Puppy 2.01, but he must be otherwise engaged.
Yeah okay, will see what I can do, maybe Mon - Tue.

Great, thank you.
I have an old Dell 200-Mhz with only 32-MB of RAM. And as I can not find any RAM to upgrade (it requires special RAM), this machine has been sitting in my garage. I managed to install BareBone-2.00 in it (with a swap partition) but it runs very slow. I was hopping 2.01 will have better memory management.

Me again 
Another thing I may add is : older machines (like my old Dell) do not work with isoLinux. Since one of the reasons for using BareBones is to run on older equipments, it will be nice to include version with sysLinux (DSL usually releases both isoLinux and sysLinux versions)

Gnome-ppp dialup gui app 

Despite the name, Gnome-ppp does not require Gnome libraries. I was puzzled about this, as about 1 -2 years ago I had exhaustively searched for and tested dialup programs, and Gnome-ppp was rejected. Looking in the changelog, I see that dependence on the Gnome libs was removed about mid-2005. Three cheers for Vladimir Djokic, the author of Gnome-ppp, for doing that :-)

Gnome-ppp is very nice, a contender to replace Gkdial. It needs the wvdial package, and that's a whole new story. Wvdial is a commandline dialup program, and Gnome-ppp is a GUI frontend for wvdial.
We currently have two Unleashed wvdial packages, v1.42 and v1.53. We have never been able to compile these from source -- GuestToo found the 1.42 binary, and I got 1.53 out of Mandrake 9.2. I downloaded the latest wvdial (and wvstreams library), still impossible to compile.

Anyway, v1.53 works fine with Gnome-ppp. I used it to get online to type this blog. It also works with the Lucent linmodem, see discussion on the forum:

Expect Gnome-ppp to be in Puppy 2.02, perhaps as the main dialer, supplanting Gkdial (I'll leave Gkdial in for awhile).

Huge sigh of relief from DUN users! Thanks, guys.

If ppp has modem installation, then it is worth while. Otherwise gkdial seems bext for external modems. Perhaps adding acmo for USB external modem drivers would be interesting?

GNOME PPP looks nice and initially worked OK in 2.02.
After two or three dialups the pppd daemon died.
GNOME PPP will not thereafter negotiate properly with my ISP after dialling up using CD boot.
I reverted to using old faithful GK dial. Thanks for retaining it.
Ran a subsequent test using GNOME PPP on RAM only install which was OK.

Matter is unresolved.

Mouse middle-button emulation fixed for Xvesa 

Rerwin discovered a bug with emulation of the middle button on a 2-button mouse when using the Xvesa Kdrive X server. When the Mouse Wizard was used to turn on emulation, the right button no longer worked.
I fixed this by a small change in /usr/X11R6/bin/xwin, the X startup script. Basically, for a 2-button mouse with middle-button emulation turned on, the commandline to start Xvesa has to include this:
 -2button -mouse /dev/mouse,3

What was amiss before was the last parameter was '2'.

A few technical notes on this. /etc/mousebuttons is the number of buttons on the mouse. In the case of a 2-button mouse, the value is '2'. The extra parameters passed to the X server are in /etc/xextraoptions and this has '-2button' if middle-button emulation is turned on. Now, if mousebuttons has '2' and xextraoptions has '-2button' then the last value passed on the commandline to start Xvesa has to be '3' not '2'. The reason for this is it appears that last parameter must be the effective number of buttons.

This discovery also requires correcting the input (mouse) wizard, per my Bugs-forum post.

Bugfixes for Universal Installer (hd installation) 

As already reported, I have overhauled grubconfig, the GRUB installer. Now I have looked at the Puppy Universal Installer, script /usr/sbin/puppyinstaller. I tested installing to hard drive and integration with grubconfig.
There have been many problems reported relating to the full hard drive installation.

One person has reported on the forum that the value in /etc/puppyversion is the character zero. This causes various problems. It should be '201' if running the latest Puppy. I fixed it.

The Installer was not properly detecting a previously installed Puppy. It is supposed to offer choice of overwrite or wipe the previous installation, and in the former case to also run the /etc/rc.d/rc.update script. In my tests it was failing to do both. Now fixed.

The options for creating a boot floppy disk or a USB 'boot disk' were muddy. I clarified this, and integrated the usage of grubconfig so that it is called in a loop, allowing both a GRUB boot disk and installation of GRUB to the h.d. MBR to be easily done.
The Installer currently uses Syslinux to create a USB 'boot disk', and grubconfig is currently limited to only creating a boot floppy -- but in the future grubconfig could be 'modernised' to also create other boot media.
Note, the Installer still offers WakePup, but that is only for Puppy booting off FAT or iso9660 partitions, so does not apply to the full h.d. installation.

When doing a #1 frugal install it would be nice to display a sample entry for grub. Here's mine:

title Puppy 2.01 frug (on /dev/hda9)
kernel (hd0,8)/vmlinuz root=/dev/ram0 PMEDIA=idehd
initrd (hd0,8)/initrd.gz

And mention that the Grub installer can be ran from Start - Control Panel - Grub Bootloader config.

My current work has only been on the full install.
Yes, some info displayed like you suggest would be helpful,
I've made a note of it.

I doubt this helps with what you are doing currently, but with the focus on booting in general I figured I mention it in case you haven't checked it out yet. There is a new grub 2 called, confusingly, grub 1.9x with grub legacy, as they now call the original, being grub 0.9x. It is a complete rewrite and appears to have some major added functionality, including ability to script with loops and conditional logic and such. I imagine this is not new news to you. When I read about it I was wondering when that would be useful, then started thinking about how Puppy is booted in so many ways by so many different people, and in different ways by the same person in some cases, so it might help. Some of the features that might come in handy in some cases:

-Graphical interface. (a nice option, especially for making less threatening to the uninitiated)

-Internationalization. This includes support for non-ASCII character code, message catalogs like gettext, fonts, graphics console, and so on. (could help Chinese, Vietnamese pups and their littermates)

-Modular, hierarchical, object-oriented framework for file systems, files, devices, drives, terminals, commands, partition tables and OS loaders. (not sure exactly how this would improve things in puppy but it caught my eye, along with scripting)

Rescue mode saves unbootable cases. Stage 1.5 was eliminated. (Hey, always nice not to be completely cornered)

There were others as well. However, the documentation is not complete yet.

Figured I'd toss this out there...

One more thing I forgot to mention (the reason I started to write the above in the first place): I just redid my drive and am in a good position to test things like this since I won't lose much at all if I screw it all up and have to wipe the drive and start completely over... I have backups of everything I would need. If you have any need for test cases just let me know what to try and what to look for. I'm currently running a frugal install and haven't tried the universal installer since I first ran into trouble/confusion with it some time back. In redoing everything I set a few spare partitions up for just this sort of thing: working with unleashed, comparing frugal vs. full, trying custom puppies, making my own, etc. This means I would have to really screw up to hurt what is on other partitions, and as I said even that would not be stressful I'd prefer to not kill my HDD but better this old HDD that is about to be replaced than somebody who didn't back up the 10 years of family pictures on their drive properly! Not that I expect your code to go wild :)

I didn't know about grub2.
It will have to stay on the 'back burner' for now, so much
else to do.

Improvements to grubconfig 

The Puppy Universal Installer run grubconfig script at the latter phase of installing to a hard drive partition.
The use of grubconfig has some problems, now resolved.

There were "Please wait" dialog windows with an OK button, and users did not know whether they had to click the OK button or not. In fact, they did, or the script would not continue. The script now has information dialog windows without any OK button and they disappear automatically.

The choices to be made in the various windows now have extra
clarification, so there is no longer any uncertainty.

grubconfig is capable of creating a boot floppy. Unfortunately, the script has a dialog window that offers to create a boot floppy or install GRUB to the hard drive. It is a choice of either, not both. If you choose to create a boot floppy, then you don't get to install to the MBR on the hd.
I made the script into a loop, so that you can create a boot floppy, then install GRUB to the MBR.

As grubconfig can create a boot floppy for Puppy installed to any Linux partition, I next need to tidy up the main Universal Installer script to clarify this.

Joel Carlson (Fox7777<at>CarlsonCo.net) 
There should be an option to exit grubconfig and do neither. Often users already have grub set up to boot Puppy and are just installing a new upgrade. Currently it is a little awkward and counterintuitive to exit grubconfig without doing anything.

More on selectable size for pup_save.3fs 

Modified Dougal's code a bit.
I extended the selectable range to 32M - 1280M. A dialog box offers sizes 32, 64, 128, 256, 512, 768, 1024, 1280, except if the limit of free space in the partition is reached, that becomes the highest offered value.

A definite step in the right direction - the only change I would make is to add a provision after the option for 1280M for the file to take over the entire partition that it is on space permitting. In my case the save file is on a 4.2GB partition that is used for nothing else - it is where the maker of my computer put some backup/save files that I deleted acct. I did not want all the "value added" bloat that their recovery software included. I had enough problems getting rid of it the first time around!



Fred Doolie 
Why not post the new file so impatient boogers like me can add it to our puppies now? Please?

Regarding release, I haven't tested it yet.

Regarding filling the partition, yes, I forgot to mention that that is also the last option.

Thank you for that clarification. If you need someone to test how it works drop me a PM and I'll send you a good email addy. Looking forward to working with it.



Perl module required by PDQ 

There is a PDQ script that requires the Perl module 'socket'. The script is: /etc/pdq/tcp-port-2.0.
We have been discussing this on the forum:

In that thread I asked what files I would need to grab from Vector to install 'socket' module. Nobody answered, so I'm guessing. Into perl-5.8.6midi Unleashed package I have added:
/usr/lib/perl5/5.8.6/IO/Socket/INET.pm, UNIX.pm
/usr/lib/perl5/5.8.6/i486-linux/auto/Socket/Socket.bs, Socket.so

Lobster (ed.jason<at>gmail.com) 
Barry any thoughts and an announcement on the new Community Edition Project just starting would be welcome :)

Choose size of save file at first shutdown 

Dougal sent me a modification to /etc/rc.d/rc.shutdown so that the user can choose the size of the pup_save.3fs file (the file that has your saved personal data/files). Previously it was fixed at 512M or smaller if not enough room in partition.
Looks like a good feature, so it will be in 2.02.

Ben Wise (pdn2006.20.wiseowl<at>spamgourmet.com) 
That's fantastic! I for one will certainly use that feature. I currently use a 32Mb pup001 file so I'd want to create a 32Mb pup_save.3fs :)

Glad to see this modification - being able to set the size of the save file is something that Puppy has needed for a long time. It does bring to mind a question though - Is there still an upper limit on the size of the save file? There was a limit size wise of about 1GB in previous versions - seemed that you could increase the size beyond that but Puppy would not recognize or use more than that 1GB amount.



I resized mine to 1.5 Gigabyte, works ok :)
In puppy1, resizing worked for some people, for others not.
I also had no success, so I had created this pup001-collection manually then.

But in Puppy2 it works good for me (but I have another computer now).

Great! I use Puppy on an old laptop with a small hard disk. It is crazy to have a 70MB Puppy installed that tries to create a 512MB work file. I haven't installed Puppy 2 because of this problem.

It would also be nice to be able to resize the pup_save.3fs file if you change your mind about how much space you need for it.


DotPups menu entries update fixed 

When users upgraded from Puppy 2.00 to 2.01, any DotPup entries in the menu got removed. This is now fixed, so when upgrading to 2.02 they will remain in place.
MU posted the bugfix here:

Smartlink modem, further improvements 

rerwin posted some more improvements to those implemented in Puppy 2.01. I have implemented these. This affects scripts /etc/rc.d/rc.network, the pinstall.sh script in the slmodem Unleashed package, and /usr/sbin/modem-wizard.

rerwin's original post is here:
http://www.puppylinux.com/nfphpbb/viewtopi ... =1533#1533
rerwin sent a post-2.01 follow up p.m. to clarify final steps.

Bugs fixed in Universal Installer 

There is more to do, so this is just today's progress report.

One bug was that for some dialog boxes if they were closed by clicking on the top-right close box, it should terminate the program, but it didn't. Fixed.

If an install is made to any vfat/msdos partition, a 'marker' file is now created, for use by WakePup. This was not a bug, just a convenient addition.

A couple of people have asked on the forum about installing to a USB Flash drive partitioned with an ext3 or ext2 partition. They tried to use the Installer to do so, and failed.
I have now fixed this. If you create a single ext3 partition on the Flash drive -- let's say the drive is sda and the partition sda1 -- you can now install Puppy to it. I recommend GParted for doing this, which is pretty easy, and make sure the 'boot' flag is set for the partition.
The Universal Installer now sails through installing to the ext3 sda1 partition, and when I tested, it booted fine, using BIOS setting 'USB-HDD'. One of my PCs only has 'USB-ZIP' option and this does not work -- for that, you need to format the drive as an ext2/3 'superfloppy', which the Universal Installer also handles. Regarding the ext2 superfloppy approach, I tested that way back in the News for Jan 9, 2006:
Note: the superfloppy approach is somewhat non-standard, so avoid unless you have to.

Having installed Puppy to ext3 partition sda1, the usual thing happens on first boot, Puppy runs totally in RAM. Now, it gets interesting at shutdown, as you are offered two choices how to save the session:
1. The usual pup_save.3fs file.
2. Direct to the sda1 partition.
For option 2, the saved files are written directly to sda1, just like any normal Linux partition.
Note, I found a bug also in rc.shutdown when choosing option 2.

So, why would you want to format the Flash drive as ext2 or ext3? You do loose out in a couple of ways. One loss is that Windows cannot natively read a ext3 partition, hindering data transfer. Another loss is that it may be more difficult to boot, particularly with older BIOSes.

sda1 raises some interesting questions, Barry, because that is tradionally the first scsi drive! Maybe your first guess about DSL was correct that they have a generic solution for scsi? Could it be that you have unwittingly solved the scsi problem, too? I will try again, but my knowledge of SW is nil, except that I know the kernel to be able to cope with scsi - always could. So what else is required by way of drivers, etc remains a mystery to me. I was lucky enough to get hold of 2.01 recently - how do I need to patch it with this latest mod.?
Incidentally, some cameras are recognised as scsi devices.

dw (1) 
Marker file is a nice addition. It was the only manual step requiring a little extra knowledge. Now it too is automatic. My old WinNT/Pent II machine can now boot from USB via floppy.

My external USB CD/DVD writer (which I haven't yet been able to boot from, so I can't try multi-session) now seems to be 'seen' by programs after boot in 2.01. I formerly had to cycle it on/off before it was 'seen'.

XfreeCD, new audio CD player for Puppy 

Puppy has had the audio CD player Gplaycd for a long time. It is very simplistic and I have wanted a replacement.
XfreeCD is very nice. It supports CDDB, which is mostly what I was after. It can also display without the 'decorations' that the window manager provides, such as titlebar and borders -- I have set that to on, but it can still be dragged around by pressing the right mouse button and dragging.
The default device is /dev/cdrom, so as long as Puppy correctly identifies the CD drive at bootup, you're off and running with nothing to manually setup.

Probably what we should think about as a next step is to have it launched from the mini-volume applet in the taskbar.

I've always thought that the gplaycd is ugly but from the authors comments it's clear that it was intended as an application to hone his development skills.

And you are correct. It's very simplistic. I've even made some mods to both make it look nicer and to have it as a tray application.


It would not be difficult to add CDDB functionality to it.

Are you interested?

rarsa, yes, I recalled that you had done that, after having made the post.

Rethinking it now, a standalone CD player is still required. XfreeCD has a lot more in than can be provided in a tray applet -- but of course that can be made to display more by clicking on it. Having the choice of both seems good.


OneBone Puppy version 2.01 released 

Finally I have access to high-speed Internet connection and can upload OneBone version 2.01. The live-CD iso file is puppy-onebone-2.01-elinks.iso and the size is 28.0M.

For release notes, please see the release notes for OneBone v2.00r1 at http://www.puppylinux.com/news2006a.htm (June 9).

To download OneBone: ftp://ibiblio.org/pub/linux/distributions/puppylinux/

Please do note that OneBone is very specialised, as does not have X graphics, commandline only. The major apps included are Elinks web browser and Midnight Commander file manager, but note that I have not extensively tested them, beyond confirming that they startup okay.
If you are interested in OneBone, keenerd has collected a large number of CLI (Command Line Interface) applications:
Another project that is very interesting and for which testing can be done is a CLI PupGet package manager, developed by Nathan:

I have provided OneBone as-is, and please see those guys about developing it further and getting out the bugs. OneBone can probably develop into its own Community-supported branch of Puppy.

Oh boy, Barry, you are a genius. Any chance of reducing the size by half?!
Only thing we need now is a brief, readable compilation of CLI commands. Over the centuries, have downloaded several, printed them out, lost them........

Ben Wise (pdn2006.20.wiseowl<at>spamgourmet.com) 
I can't wait to try out BareBones 2.01 with my 128Mb RAM laptop (no hard disk, just a 128Mb USB stick with a 32Mb pup001 file). I might download OneBone 2.01 in the meantime just for fun!

One happy puppy 1.08 user :)

I will second Ben Wise above. I have been using barebones vs 2.0 since I use Firefox and TB programs. Now I have two other users interested in barebones since they also use FF & TB. This is what makes your barebones distro so wonderful. One user that uses IM can add it and the other will not even have it installed. Most of the community can not use command line, but building a puppy with barebones to suit their needs is a pleasure and easy.

Thanks again

Paul M

Nathan Fisher 
Quite brilliant in many ways, I'm especially pleased to have the gpm mouse support in this one. And also happy about Midnight Commander. Booted up fine on the old K-6 and ran at lightening speed (as anticipated), aquick 'dhcpcd eth0' and I was online. It would probably be beneficial to have gpm come on automatically, I'm sure with the autodetection that is available in Puppy2 it would not be too hard to manage that.

I will have to do some more work to pkgtool, I needed to pull it out of svn but needed pkgtool to install the svn client, so I had to tar up what I had on the other computer and trasfer it over. Also I noticed when I fired it up there was no livepackages.txt file, I guess it needs created first so I will add a line 'cat packages.txt | grep " off " > livepackages.txt' to the script, if it finds that the file does not exist. After that was able to search and install unleashed packages again without issues.

I like the isea of turning OneBone loose as a community project, it would free up some time for you I'm sure and also be a nice project for the community to work on. There's already a lot of interest in it.

From some of the comments above, there appears to be confusion between OneBone and BareBones.

OneBone is commandline only.
BareBones is a basic X graphics system, with a lightweight web browser (for v2.00r1 it was Dillo).

I haven't released a BareBones 2.01, as I thought John Murga's 50M live-cd will probably fill that gap.

Ted Dog 
The OneBone forum is added to forum.puppylinux.com

I really feel that keeping a current with all bug fixes version of Barebones Puppy in the lineup is something very worthwhile to have for those who must download via a dial up connection and/or those who like me prefer not to have to deal with a lot of extra stuff that we don't need or want. Frankly, not having to remaster to get rid of unwanted stuff is a huge plus when we are setting up or updating our Puppy. I would much rather spend a little extra time on downloading my prefered applications than deal with remastering the whole thing! Many thanks for your efforts and time - Puppy is a thing of beauty that runs rings around any other distro I've tried.


Me too 
I second Alice, and waiting for the updated BareBones

CD burning gets an overhaul 

There are still some issues with CD burning and the 2.6 kernel. So, I have upgraded cdrtoools to version 2.01.01a10, which is the latest alpha release. The cdrtools package contains the cdrecord program. I also upgraded cdrdao (a PupGet) to version 1.2.1.

Puppy currently uses the CD/DVD burner program Graveman version 0.3.8, and I (again) tested the latest version, in this case 0.3.12-5. Unlike earlier releases, this one does detect inserted media, however I tried a couple of test burns of an iso file to a CD, and it went right through, including fixation, then reported "Operation error". It seems to be using cdrdao to do the burn (I had installed cdrdao for testing Graveman, but cdrdao is not part of the standard live-CD), which seems to be the problem.
I have filed a bug report with the author of Graveman.

I have studied the use of '-pad', '-tao' and '-dao' parameters for cdrecord, and found that for single session burning the '-dao' parameter should be given, and for open burning the '-multi -tao -pad' parameters should be given. Awhile back I had removed the '-pad' parameter, but after research have determined that it is necessary in some cases to prevent cdrecord from reporting an "I/O error".
Accordingly, I have modified /usr/sbin/remasterpup2, /usr/sbin/burniso2cd, /etc/rc.d/rc.shutdown and the createpuppy script in Puppy Unleashed.

Yippee! Our phone company, Telstra, has fixed my line, and I'm now back to the blisteringly fast dialup speed of 21,600 bps! As reported earlier, my connection speed had dropped to 14,400 bps -- compared to that, 21K is fast.

Great news for a great feature - multisession CD. While searching for a question about this feature of Puppy, I saw that Puppy's multisession has been in Knoppix and Slax discussion boards since March and April last year (2005).

Now my question (still unanswered as my search was unsuccessful): why would the first save of multisession eject the CD first?


I'm not 100% sure, but it may be that Puppy first uses cdrecord to query the CD as to how much is already stored on it, to determine if there is sufficient space to save the current session. Maybe that query causes the eject?
Puppy1 did not have that query.

At this stage i don't know how to prevent the eject. But, as there is a now an updated cdrtools, perhaps behaviour will have changed...

dw (1) 
I have never been able to use graveman since it first replaced gcombust. Each new version of Pub, I upload gcombust and Torsmo and I'm good to go. Perhaps the graveman problem is that I have no linux partition on my disk, and operate from a swapfile not a swap partition? Does gcombust write straight to disk and graveman create a file first? (Although, now in 2.01, it seem a swap space is set up "automatically" on dev_save?)

Yes, I think that Gcombust can burn files to CD without creating an intermediate iso file.
That's one of the annoying things about Graveman, it creates an intermediate iso file, and the default directory for that is /tmp. Many people expect Graveman to "just work", and run into this problem of running out of space in /tmp. If you have a partition, any non-ntfs partition, that can be used, but then it has to be mounted.

One thing to look forward to is TkDVD, which can now also burn to CD. V4.0.0 has just been released, with some bugfixes that the author has done at my request especially for Puppy, but there is still another bug so I'm waiting for v4.0.1.

ppp package upgraded 

The ppp package used in Puppy 2.01 and earlier is v2.4.3, with a mppe-mppc patch. I have compiled v2.4.4b1, without any patch, which will be in Puppy 2.02.

The earlier patch was specifically for the mppe-mppc module, which was not part of the official kernel source. This was for Puppy1, using the 2.4.29 kernel.
However, with kernel 2.6.15 and later, a mppe module is provided as part of the official source, and pppd (program from the ppp package) works as-is with it. Note though, this official module does not have mppc, which provides decryption.

I also included all the plugin modules provided with the ppp package. These include 'rp-pppoe', 'pppoatm' and 'winbind'. I've never included these before, don't know how useful they are. You need to read the docs, as it seems a plugin has to be explicitly loaded for it to be used.

Well Done.

Have you ever considered to get the onebone migrate to uClib to further reduce its size?

By the way, the elinks one bone puppylinux in the download site is only 1.7 M. Is that right?

John Doe 

Can't wait to test it.

The 1.7 MB size of OneBone 2.01 seems not right - the md5sum is different from the published value.

Actual: 5a2bb630083ecc3fa1181fe96eb9324d
Published: 3a4e02e2ec57dceced18d169bc36c27e

Barry Kauler 
No, I better delete that. I was attempting to upload it to ibiblio from my 14K dialup connection.
I'm going to Perth today, so will upload it tonight.

Boot from USB drive plugged into PCMCIA-USB adapter 

pakt (paul) has worked on this. He has a PCMCIA - USB2 adapter and a USB2 Flash drive. The forum thread:

I have implemented his idea and it will be in Puppy 2.02.
The advantage is, for an older laptop with USB1 or only PCMCIA, there can now be fast boot from a USB2 Flash drive, also fast operation.
You do need to read the forum thread though, as at this stage the syslinux.cfg file has to be manually edited to insert an extra parameter.

A silent PC with Puppy pre-installed 

These guys are offering a tiny barebones PC with RAM and CF card, 600MHz CPU, with Puppy pre-installed:
I guess people in the UK and Europe will be well catered for now, and the NTAVO unit covers USA and Canada.

Recent Convert 
Gorblimey! looked at that, good value or what!!

Very interesting, and, unusually, not the expected rip-off we have come to associate with packaged VIA mini-ITX products.

David (enquiries<at>zerocarbonfootprint.co.uk) 
Thanks Barry for the help in getting Puppy running so smooth and fast on the Tranquil PC T3. We certainly hope that the PC users of the world can see the benefits in running this smooth and efficient application on our equally efficient and environmentally friendly PC platforms.

i could make my own for about $103+shipping at newegg this is a rip off. dont buy it.
remember £1 is about 1.82 USD.

sorry $103+shipping.

there's a problem with this blog. The dollar character gets treated as something else, hence the above missing values.
it looks like you have to post as 123 dollars.
I'll let the author of simple php blog know about this.

There's a TV-out in that device (the mobo specs say so). Great device for the home, even in the living room.

Via c7 are starting to sell on Newegg,might be worth the wait. http://www.newegg.com/Product/Product.a

Very slow Internet access 

Oh my, I am having technical problems. My forum, now this...
At my home, in rural Western Australia, I connect to Internet by dialup, at a connection speed of 19,200 bps or 21,600 bps.
Note, if you use GKdial in Puppy Linux, the connection speed gets reported in the text file /etc/ppp/connect-errors.
That's low enough, but on the 14th of June my connection speed suddenly dropped to 14400 bps and has remained at that. Then today it dropped to 12000 bps, which is what I'm using right now.

Sunday today, tomorrow I'll phone Telstra, our telephone line provider.

I've been in Perth lately, and my friend-in-Perth has upgraded to 'broadband 2', which is ...well I can't recall the speed, but it is incredible. I got absolutely spoilt, now to come down to 12000 bps ... :-(

I'm home until the end of this week, and I've got OneBone all ready and can't upload it until probably Saturday.

This 'Simple PHP Blog' is very nice. I reckon it can be the new Developer News page. Note though, I might change the url -- I'll do that soon. I don't like my news page being called a "blog" -- I would rather the url was ..../news/

Another PHP blog that uses plain text files, named 'Pivot' has been recommended to me. Yes, very nice. More features than Simple PHP Blog. Anyway, I like this one, can always more to something else in six months it I want to.
Pivot home: www.pivotlog.net

I did report that wireless broadband was going to be provided locally, but the installation company still hasn't contacted me. I'll chase that one up too. I suspect I'm a bit too far out of town.

I feel your pain!
And that's not all. John's Forum is playing up again this morning. Always happens on the weekend! Presently not accepting postings: Error message is 'URL not found'. Not sure whether Mark's multiple postings is related? As you know, I've experienced this when things aren't going quite right.

yeah, I'm getting that "URL not found" right now, using John's forum. I was able to post by waiting awhile, retrying a few times.
Right now, though, I've got three posts waiting to go... will try again in a few minutes.

Forum is working now, at least from here.
Barry: how on earth do you manage to upload everything via dialup? I guess small files only take minutes, but do you head elsewhere to post new iso's and such? Do you expect them to get broadband out to you soon, just not right away, or is it on indefinite hold?

Fitzhugh - recent and total convert :)

Similar to your situation, Barry, I live in a rural area in Sweden and also visit a friend with broadband in the nearest city to download larger files. However, a broadband solution has been worked out for us and should be up and running by next summer. I can't wait! They plan on sending data via Wimax to an antenna on our local telestation and then via ADSL through copper to our home. Apparently we won't be able to receive the radio signal directly because of surrounding hills.

atang1 (atang1<at>yahoo.com) 
Not all external 56k modems are the same. Pctel for internal 56k is fastest.
Most modem depends on the input circuit. You might want to try a few newer dislup modems with different input dividers some inductance, others capacitance. The input circuits cur down noise and compensate for line length from Pots central office to you(5,000 to 15,000 feet without repeater amplifier). You might request one and go 56k.
On older modems the relay switch may ruin your connection if points are damaged or simply worn out. Radio Shack may have replacement.

Compiled some console apps for OneBone 

The gpm package, version 1.20.1, that provides mouse support for console applications, is now in Puppy.

I compiled Elinks version 0.11.1. To obtain Javascript support, I had to download the Spidermonkey javascript library (v1.5) from ftp://ftp.mozilla.org/pub/mozilla.org/js/ and expand it inside the Elinks source then patch it with a patch file supplied with the Elinks source. I then compiled and installed Spidermonkey first.
After configuring Elinks, it reports:

gpm ............................. yes
zlib ............................ yes
bzlib ........................... yes
idn ............................. yes
Bookmarks ....................... yes
XBEL bookmarks .................. yes
ECMAScript (JavaScript) ......... SpiderMonkey
Browser scripting ............... Perl, SpiderMonkey
SSL ............................. OpenSSL
Native Language Support ......... yes
Cookies ......................... yes
Form history .................... yes
Global history .................. yes
Mailcap ......................... yes
Mimetypes files ................. yes
IPv6 ............................ yes
BitTorrent protocol ............. yes
Data protocol ................... yes
URI rewriting ................... yes
Local CGI ....................... yes
Finger protocol ................. yes
FSP protocol .................... no
FTP protocol .................... yes
Gopher protocol ................. no
NNTP protocol ................... yes
SMB protocol .................... yes
Mouse handling .................. yes
BSD sysmouse .................... no
88 colors ....................... no
256 colors ...................... yes
Exmode interface ................ no
LEDs ............................ yes
Marks ........................... yes
Cascading Style Sheets .......... yes
HTML highlighting ............... yes
DOM engine ...................... HTML highlighting
Backtrace ....................... yes

Midnight Commander version 4.6.1 has been compiled. Configure reports:

  File system:                Midnight Commander Virtual File System
cpiofs, extfs, tarfs, ftpfs, fish
Screen library: ncurses library
Mouse support: gpm and xterm
X11 events support: yes
With subshell support: yes
Internal editor: yes
Support for charset: no

Elinks and gpm packages are expected to be in the next OneBone. Perhaps not Midnight Commander, but it can be a PupGet pkg.

John Doe 
Elinks looks great. I was going to ask if there was some way to do NNTP and HTTP from the console. You beat me to it !

June 24, 2006

The gpm package, version 1.20.1, that provides mouse support for console applications, is now in Puppy.

I compiled Elinks version 0.11.1. To obtain Javascript support, I had to download the Spidermonkey javascript library (v1.5) from ftp://ftp.mozilla.org/pub/mozilla.org/js/ and expand it inside the Elinks source then patch it with a patch file supplied with the Elinks source. I then compiled and installed Spidermonkey first.
After configuring Elinks, it reports:

gpm ............................. yes
zlib ............................ yes
bzlib ........................... yes
idn ............................. yes
Bookmarks ....................... yes
XBEL bookmarks .................. yes
ECMAScript (JavaScript) ......... SpiderMonkey
Browser scripting ............... Perl, SpiderMonkey
SSL ............................. OpenSSL
Native Language Support ......... yes
Cookies ......................... yes
Form history .................... yes
Global history .................. yes
Mailcap ......................... yes
Mimetypes files ................. yes
IPv6 ............................ yes
BitTorrent protocol ............. yes
Data protocol ................... yes
URI rewriting ................... yes
Local CGI ....................... yes
Finger protocol ................. yes
FSP protocol .................... no
FTP protocol .................... yes
Gopher protocol ................. no
NNTP protocol ................... yes
SMB protocol .................... yes
Mouse handling .................. yes
BSD sysmouse .................... no
88 colors ....................... no
256 colors ...................... yes
Exmode interface ................ no
LEDs ............................ yes
Marks ........................... yes
Cascading Style Sheets .......... yes
HTML highlighting ............... yes
DOM engine ...................... HTML highlighting
Backtrace ....................... yes

Midnight Commander version 4.6.1 has been compiled. Configure reports:

  File system:                Midnight Commander Virtual File System
cpiofs, extfs, tarfs, ftpfs, fish
Screen library: ncurses library
Mouse support: gpm and xterm
X11 events support: no
With subshell support: yes
Internal editor: yes
Support for charset: no

Elinks and gpm packages are expected to be in the next OneBone. Perhaps not Midnight Commander, but it can be a PupGet pkg.

I'll put this news into my experimental News blog http://www.puppylinux.com/blog/ as well.

June 23

Yippee, my Puppy2 Developer Forum is working again! My host, netfirms.com finally fixed it. Here is their email, dated June 22:

We have reviewed your request it appears your table had been corrupted. We have
repaired your table. In the further if you encounter this issue.

1. Log into CP
2. Log into phpmyadmin for the db in question.
3. Click on DB name
4. Click the SQL tab
5. In the box, enter the following query:

repair table table_name

replace the table name listed in the error. Once you do this you table should be
repaired and the error will no longer display.

June 21

My Puppy2 Developer Forum is still broken. I have had communications with customer support at netfirms.com (my host) and they say the forum works for them. At first, they told me to clear my browser cache, then they told me to test the forum via an indirect url. Nothing works, yet they insist it is working. I can see the main index page of the forum, but cannot browse nor login. It seems that others are browsing, but I see that there have been no posts since June 17th.

My Developer Forum is here: http://www.puppylinux.com/nfphpbb/

I would like to get feedback, whether you can browse the forum, see if it is a location problem. I've posted a topic to my experimental News blog: http://www.puppylinux.com/blog/  -- kindly post a feedback comment there.

Simple PHP Blog is looking good. I may migrate to it as the permanent Developer News page. But, still in the testing/evaluation phase.

June 20

Simplephpblog has been recommended to me, so I set it up. This one also has flat file storage, no SQL database. Gee, it sure is nice. Excellent security features. This is also for evaluation. URL:

June 20

I have setup a blog. It's not the official Puppy News blog, just a plaything for now. It is an ultra-simple blog, as I'm fed up with these sophisticated forums and SQL databases that are so complicated to configure and just aren't reliable. Okay, I'm probably over-reacting! Anyway, I like this blog. Stop by and play with it:

UPDATE: My Puppy2 Developer Forum is still down. John Murga's forum is back up (for now).

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