4.00beta2 has version 1.4.14, however as I have now put libsndfile into Dingo, I have recompiled mhWaveEdit, as it can optionally be compiled to use libsndfile. This adds extra audio import and export formats -- another excellent justification for including libsndfile.
Forum member rerwin submitted some small tweaks for /bin/modprobe and /etc/rc.d/rc.modules. Applied, with some variation.
Loading into RAM
Floborg asked whether Dingo copies the pup_xxx.sfs file into RAM on a 128MB system. The answer is no. A PC with 256MB is required. Most PCs have RAM capacities that are a multiple of 2, so after 128MB there is 256MB, etc. However, some older PCs are configured with a mix of RAM modules and have a total somewhere between 128MB and 256MB -- in that case it is likely that you will fall below the cutoff point and the pup_xxx.sfs will not be loaded into RAM.
For people in the situation where the pup_xxx.sfs is not copied into RAM, when you create a 'pup_save' file, Puppy asks if you want to copy the pup_xxx.sfs file to the same place as the 'pup_save' file. Or, if upgrading an existing pup_save, you can manually copy the pup_xxx.sfs off the CD. Whatever, if the pup_xxx.sfs exists in the hard drive then the CD will be freed for other uses after bootup.
However, you still won't get it loading into RAM. I set the cutoff at 256MB, as some applications, for example SeaMonkey or Firefox, need lots of RAM.
I have removed Gaim from the Puppy2 repository list in PETget, and have removed Pidgin from the Puppy3 repository list in PETget. The reason for this is that these older repositories are intended to be a source of legacy applications, and I have just compiled the latest Pidgin for Puppy4, that works fine. The older versions no longer function properly, as Yahoo changed their login format at the start of April.
I have added via_drv.so, tseng_drv.so, siliconmotion_drv.so, chips_drv.so, s3virge_drv.so, and savage_drv.so drivers to the 'xorg_xorg_servers' package. This is the base Xorg servers package in Dingo. It is cutdown, but I have decided that a few more drivers would be good, but haven't tested them.
I hve added s3v_dri.so, r200_dri.so, tdfx_dri.so and savage_dri.so to the 'xorg_xorg_dri' package. This is a somewhat cutdown package that adds DRI and GL functionality. It is not included in the live-CD.
Comments:Posted on 26 Apr 2008, 19:21 by ANOSage
3.01, which remains the yardstick for the present, will load into 128+64, sometimes 128+32+16! Haven't experimented with Dingo yet, but imagine how much less one could use with Opera!! Even less with Links-2.
Now that SDRAM is more expensive (although there's tons available s/h for the moment) than DDRAM, there's a case to be made for lowering the memory resource as well as the .iso size?
Posted on 27 Apr 2008, 2:48 by floborg
I asked because the mission statement for Dingo mentioned that you wanted to load Puppy into Ram on a 128 MB machine.
Puppy 2 loads into RAM on my 224 MB machine and runs the sloth-like SeaMonkey as well as 3.01, which never copies to RAM.
I did an experiment in VirtualBox with one of the Dingo Alphas: I edited the init script in initrd.gz to lower the threshold from 230000 to 220000. Puppy copied itself to RAM on a virtual 224 MB machine without any trouble. I didn't notice any strange behavior while running a few apps. I didn't use Xorg, though.
Posted on 27 Apr 2008, 8:17 by Raffy
Yes, I am also going to mention 224 MB as the relevant figure, as new PCs eat up 32 MB of shared RAM for video (it can be reduced, but it is usually set at 32 MB).
Posted on 27 Apr 2008, 10:38 by BarryK
Lower RAM threshold
Ok, I'm game to give that a go. I have lowered the threshold from 230000 to 220000.
Posted on 6 May 2008, 2:59 by coolpup