test results for alpha puppy2

[BarryK]

3.
I think that that latest puppy2 has fixed those errors. So, not having any
PMEDIA, puppy should now be able to locate the files.

4.
I think that is fixed now.

7.
The .sfs files are now versioned, that is, for puppy version 2.0.0, all the
.sfs files must have "_200.sfs". This can be prefixed with anything you
like.
pup_200.sfs is reserved as this is puppy himself.
devx_200.sfs I'm using as the development/compiler environment.
So, apart from those two, you can have anything_200.sfs.

They are expected to be located at the same place as the pup_save.3fs file.

Here is the code that loads them:

Code: Select all

 CNTLOOP=3
  for ONESFS in `ls -1 *_${PUPPYVERSION}.sfs | grep -v "^pup_" | tr "\n" " "`
  do
   losetup-FULL /dev/loop${CNTLOOP} $EXTRASFS/$ONESFS
   mount -r -t squashfs -o noatime /dev/loop${CNTLOOP} /pup_ro${CNTLOOP}
   [ $? -eq 0 ] && UMNTRO="${UMNTRO}:/pup_ro${CNTLOOP}=ro"
   CNTLOOP=`expr $CNTLOOP + 1`
  done

and a bit further down:

Code: Select all

 echo -n "Creating unionfs..."
 mount -t unionfs -o dirs=${UMNT1}${UMNTRO} none /pup_new;check_status $?

EXTRASFS is the mount point of the partition that has pup_save.3fs.
The only thing loaded prior to the above code is pup_200.sfs, so the rest,
including devx_200.sfs, will be loaded in alphabetical order.

[J_Rey]

OK thanks. I'm now wondering how you plan to ensure that say an OpenOffice.org 2.0.2 SquashFS file has future and backward compatibility? Renaming the file seems ackward, but changes between releases might cause errors also. Hmm....

Also, according to the boot message I quoted above there is a maximum of 8 loop devices. So, to trap potential unrecognized errors, with ^Cricket^/Anacari's scripting help, I recommend something like:

Code: Select all

   if CNTLOOP=8 then `echo ERROR: maximum amount of loop devices reached` fi

before

Code: Select all

   CNTLOOP=`expr $CNTLOOP + 1`

[J_Rey]

I just remembered! Is there already or could we have the ability to add the contents of *.sfs files when remastering a new CD image? That would be great if implemented!

[BarryK]

I just remembered! Is there already or could we have the ability to add the contents of *.sfs files when remastering a new CD image? That would be great if implemented!

Interesting question... in the case of the multisession CD/DVD, that would
already work, as the CD/DVD is where the save folders are. So, the above
code would look on the CD/DVD -- but then, it would have to stay mounted.

Yes, in general, I think it is feasible. If *.sfs files are found on the boot media,
they can be copied to the partition that has the pup_save.3fs file ...hmmm, I
may have already implemented this, or was that back on puppy1?
Anyway, will check it out.

[Marv]

3 or so weeks on puppy2a. Very smooth for a pre-beta. This is a syslinux install to a cf card on an ide-cf adapter. Intel 815 mobo, PIII 667, 512 Mb RAM, ATI rage 128 video.

A few comments and a question:

Xorg works well.

I set height=20 in the jwm configuration file. Better looking menu.

I had some problems with the machine being locked up or veeery slow after waking from sleep. Disabling sleep and suspend in gxset seemed to fix this. Probably an ACPI issue. The same machine ran fine with the default sleep and suspend under puppy-1.0.7.

Installing alien apps is much smoother than under 1.0.x. Opera 9 installed perfectly using the standard opera install.sh.

The question:

On my system, X memory usage rises as the system is used longer and eventually reaches 80 or 90% of available and the system slows to a crawl. This seems to be true for Seamonkey use as well as Opera and under puppy2a does not return to a few percent when apps are shut down as it does under 1.0.7 on the identical machine.

Could someone try the following in puppy2a?
Fresh boot, look at top processes. (my X mem use 1.7%)
Browse, use machine and recheck X memory use as above over time when apps are open and after shutting them down.

Thanks

[BarryK]

On my system, X memory usage rises as the system is used longer and eventually reaches 80 or 90% of available and the system slows to a crawl. This seems to be true for Seamonkey use as well as Opera and under puppy2a does not return to a few percent when apps are shut down as it does under 1.0.7 on the identical machine.

Could someone try the following in puppy2a?
Fresh boot, look at top processes. (my X mem use 1.7%)
Browse, use machine and recheck X memory use as above over time when apps are open and after shutting them down.

Thanks

What time period are you looking at here?
I ran puppy2 for two hours, surfing the Internet, and it did seem that when shut
everything down, X did not drop as low as before. Maybe, hard to say, %
mem usage is all over the place. But after 2 hours and after quiting Seamonkey etc., it was about 3.5%. Whereas at the start it was 2.2%.

I don't recall, maybe puppy2alpha has the faulty version of Blinky, but then,
if you run top, you should see blinky climbing up quite quickly.
Easy solution, kill blinky.

[Marv]

What time period are you looking at here?
I ran puppy2 for two hours, surfing the Internet, and it did seem that when shut
everything down, X did not drop as low as before. Maybe, hard to say, %
mem usage is all over the place. But after 2 hours and after quiting Seamonkey etc., it was about 3.5%. Whereas at the start it was 2.2%.

I don't recall, maybe puppy2alpha has the faulty version of Blinky, but then,
if you run top, you should see blinky climbing up quite quickly.
Easy solution, kill blinky

The rise was over a couple of hours of Seamonkey use (to 77 or 80%). Things slowed way down at that point. I am pretty sure I had blinky killed but will have to switch back to puppy2a to check. I did reboot and replicate several times so Blinky could have been on again. The high memory % seen in Top was definitely reported as X, not Blinky. The kind of slight rise you are seeing in 2a is just about what I see in 1.0.7 and seems pretty much down in the noise.