I'm coming to this thread late, and I haven't read all 18 pages of it either (mea culpa). Just wanted to get my druthers out there.
Most secure Puppy ever.
The firewall on by default
Browser run as spot (non root running)
Security dialogue on first booting, including unmounting, benefits of encryption, use of passwords, education rather than FUD, Running from DVD benefits etc.
If we really want to be serious about security, cryptoloop has got to go. We should be encrypting pupsaves with dm-crypt (maybe accessed through cryptmount). I mean, come on guys, cryptoloop was already deprecated when we first started using it! About time to give it a decent burial.
Another problem with cryptoloop is that we have to keep telling users not to have a swap volume. That is just lame. Who knows how many miss that message and have their passphrases sitting in swap in cleartext...
We need to build encrypted pupsaves and any other encrypted volumes using /dev/urandom, not /dev/zero as currently.
Oh, and we need to make "pfix=fsck" work for encrypted pupsaves too.
Might be nice to make a noob-friendly script that creates other encrypted volumes for personal files. All volumes should be mounted at boot using a single password, not one for each volume.
Should have a facility for md5sum checking the unencrypted boot files (e.g. the Puppy sfs) after boot to ensure it has not been covertly modified by adding malware, such as a keylogger.
Also, outside of security, I think we should move in the direction of standard linux structures and configuration files (as standard as it gets anyway). I don't mind having user-friendly scripts to modify those structures, but people should be able to edit them directly if they prefer doing it that way. One obvious advantage of this approach is that if the script is broken, you can still manually get things going. Maybe use Arch Linux as a model for these structures.
Oh, and I like Seamonkey and JWM, at least as options or pets. I like the 525 approach of not having a main browser until one is selected though. I always have liked the zdrv approach. Slackware, Ununtu, Debian, Arch, I don't care, as long as it has a nice, big, well-tested repository.
If it is not to late to suggest, why not leave all of 5.x as Ubuntu based. This will leave room in the numbering for updates.
Make Slack base 6 series.
After all if I remember right, 3.x was Slack, 4.x was T2, 5.x is Ubuntu.
Makes sense to me. I doubt 526 is the last thing we will see of Ubuntu around here. You are making it impossible for them to move to their own 5.3 release. That means you are restricting them to only bug fix releases from now on.
As to the suggestion of adding "spup" or "upup" to the designation, I don't like it. Why the added complication? It's not like we are going to run out of numbers any time soon. The precedent established by Barry is a major number change for a different base. Let's continue that. The designation of what we are working on should be "Puppy", not "spup". Can you imagine the confusion it would cause, adding this extra non-numeric designation to Puppy? What would distrowatch do with it?
However, I reserve the right to change my mind about that.
Well Lucid development can take up the entire 5.2.0 to 5.2.9999999999 range.
Um, maybe not. There seem to be places in the code that use things such as "525" (not 5.2.5), and may depend on 3 digits being there (and keep in mind the upgrade facility can't now handle distinctions like spup and upup - or can it?). Anyway everything from 5.2.1 to 5.2.9999999999 would just be bug fixes of 5.2.0 (theoretically anyway, although this is violated routinely). No more major revisions allowed for the Ubuntu Puppy...
Actually I now realize that I don't care.