So what you suggest, add that package to linux-firmware from Arch, or use some different source. You mentioned 4mb package from somewhere, but please add link to it.
@mavrothal: I had to copy some libraries from /usr/lib to /lib, couldn't just move them because then compiling would not work.

this is the firmware from traditional puppy. it's the /lib/firmware folder from out of precise. i'm thinking rather than using it as a separate sfs....it would be 'a load off' to integrate/mksquashfs it into archpup-12.12.sfs

wireless should just work shouldn't it? presently it's the exact same as having to install a driver on windows, to get wireless working.

mavrothal...the udev u posted in the last thread works. what makes it stop after a reboot though is the file /lib/libudev.so.0 gets overwritten. so my workaround for it was edit the /etc/init.d/start-pup-volume-monitor file to look like:

After having urged for the creation of a Puplet having the capabilities of Archlinux, now that its here I'm not sure how best to use it. Basically my questions have to do with function of Pacman as it's being implemented under ArchPup's structure and capabilities. Please correct me if I'm in anyway wrong in my assumptions or conclusions.
Archlinux, itself, is designed as a “Full” install, with arch-packages installed into it via PacMan. As such, PacMan is able to keep track of Archlinux's kernel, what applications have been installed, and the dependencies used by those applications and, consequently, able to upgrade each of the foregoing when possible and desired.
ArchPup, on the other hand, may be a “Frugal” install, and for the balance of this post please assume that it is. As a frugal install, arch-packages would be installed to ArchPup's SaveFile, if one is in use. Can Pacman keep track of what has been installed to the SaveFile? Does it matter if the application was installed via Puppy Package Manager? Or the use of a Pet? Can packages (including dependencies) installed to the SaveFile also be upgraded?
The great advantage of SFSes are that they can be loaded when needed and unloaded when not, so that Puppy (which runs as much as possible in RAM) might make use of a multitude of applications even on a system whose resources are so limited that it could not load and use all applications at the same time. My recollection is that ArchPup can load-on-the-fly up to 26 SFSes. Can PacMan keep track of what applications (and their dependencies) are part of the merged system when an SFS is loaded? Does it test for what's already on the merged system if, for example, you decide to install a package to the SaveFile? Will it install any dependencies even though they are already in a loaded SFS? And If not, how will it handle applications broken because their dependencies would be absent if the SFS that contained those dependencies is subsequently unloaded?
Does ArchPup have an SFS-builder/Editor for creating SFSes from Arch-packages?

Possible adverse answers to these questions (except the last) should not be taken as indicating a weakness in an ArchPup system.

Personally, I think that the best way to make use of ArchPup is with the core file consisting of those packages necessary for the system to function; (at most) a small SaveFile, sufficient to hold settings, configurations and symlinks or scripts to SFSes (preferably package suites –such as one for Graphics Work, another for playing and editing videos, etc.) with the SFSes, themselves, containing all their dependencies; symlinks or scripts to Program Folders (Folders containing applications with all dependencies) external to both the Core file and the SaveFile, except for the symlinks or scripts necessary to call them; and external datafolders, also connected via symlinks.

My idea is to always make frugal install, if you want full install then just download archlinux installation cd, it will be the same, except systemd and different system services startup. For installing applications you have choice - you can make bigger savefile and install packages to it, or you can apply makesfs script that will use pacman to download Archlinux packages and after that will convert them sfs module. SFS module will be gzip compressed, block size 512K, to speed up converting process and therefore noticably larger than Archlinux xz compressed packages. It's important to point out, that this script will automatically create proper entries for all converted package, so pacman will recognize them as installed. ArchPup can load 20 sfs modules, but if you later unload SFS file that contained dependencies for target package, you will have to find those missing packages and install them manually. Pacman will install dependencies according to .PKGINFO file inside package, it will not run ldd to find missing libraries. That pacman behaviour is right way if you ask me.

My idea is to always make frugal install, if you want full install then just download archlinux installation cd, it will be the same, except systemd and different system services startup. For installing applications you have choice - you can make bigger savefile and install packages to it, or you can apply makesfs script that will use pacman to download Archlinux packages and after that will convert them sfs module. SFS module will be gzip compressed, block size 512K, to speed up converting process and therefore noticably larger than Archlinux xz compressed packages. It's important to point out, that this script will automatically create proper entries for all converted package, so pacman will recognize them as installed. ArchPup can load 20 sfs modules, but if you later unload SFS file that contained dependencies for target package, you will have to find those missing packages and install them manually. Pacman will install dependencies according to .PKGINFO file inside package, it will not run ldd to find missing libraries. That pacman behaviour is right way if you ask me.

Wouldn't it be useful to place explanations like this also on top of the thread as there is, for as far as I know, not much "howto"

alright, now that wireless and pup-volume-monitor has been figured out...i'm thinking you should add the fixes to the main iso and edit the first post with big red letters, "WIRELESS NOW WORKING!!!"

the linux-firmware.sfs looks about as foreign as the md5sum.txt.....they both get totally ignored.

The "linux-firmware.sfs" bit is a bit cryptic. Does this mean that the firmware must be in the main sfs or that the firmware sfs must be configured differently?
Also the "wireless working" is it with Pwirless2, pns-tools, Frisbee, all of the above, other?

Regarding udev, I have a hard time seeing why v175 does not work 100%. I can only think the language of the build system that as with aufs-utils may up messing up gtk-doc, acl, attr or something else during compile time_________________Kids all over the world go around with an XO laptop. They deserve one puppy (or many) too

The "linux-firmware.sfs" bit is a bit cryptic. Does this mean that the firmware must be in the main sfs or that the firmware sfs must be configured differently?
Also the "wireless working" is it with Pwirless2, pns-tools, Frisbee, all of the above, other?

Regarding udev, I have a hard time seeing why v175 does not work 100%. I can only think the language of the build system that as with aufs-utils may up messing up gtk-doc, acl, attr or something else during compile time

as far as the firmware...a lot of ppl don't know what 'firmware' is, or what it does, how to use it, and so on. putting myself in other's shoes, "i don't know what firmware is, md5sum, or nothing else. i do know iso though, so i download the iso file, load it, if it works...i'll keep moving. if it doesn't, i have 399 other puppy isos to pick from, hopefully the next one works right."

it works perfectly fine as the sfs file that it's in now, but everyone might not want, or know how to use sfs files the way we are. especially to get something like wireless working. Java..understandable to read and learn how to use an sfs for something like that. java or wine etc, those big packages. but to get wireless to work? it should work out the box. i shouldn't have to download this driver/sfs file and install/sfs_load it....to get wireless working. So in so many words, it works fine as a separate sfs, but i feel as though it should be included in the main.sfs.

and as far as "wireless working" i was referring to Frisbee. after i saw Frisbee working solidly, i didn't think it was necessary to even test pwireless2. Frisbee is the better choice. the notification in the panel is nice to have too. it let's u know if u're still online or not. pwireless2 doesn't have that. so if u're webpages aren't loading, u're either not online, or something is wrong with your browser. having Frisbee and it's notifications tells you which one it is.

now pup-volume-monitor and udev....the default volume-monitor and udev (aka systemd) in arch works perfectly fine. using pup-volume-monitor saves a few MBs...but it's also a futuristic issue for if someone wants KDE.....it doesn't work in Dolphin. the default does.

mavrothal:
OK, will add this if you want, I changed some lines to use notify-send command, because gtkdialog splash is not installed. Thanks.

Nice.

You might want to keep the original name though because a) some puppy apps are checking if snapmerge is running (Frisbee for one) b) you might still use usbsave in other settings.
Is your call._________________Kids all over the world go around with an XO laptop. They deserve one puppy (or many) too