Puppy Linux Discussion Forum

[darrelljon]

I'm still not 100% clear on the pedigree of various Puppies and Puplets so I knocked up this family tree. I'm sure there are mistakes, please let me know what needs changing and I will produce a better one shortly.

[WhoDo]

[Lobster]

Very interesting chart.

1.09CE had an 'official' release number (space was created for it) It was based on 1.08r1

2.03 or 2.03CE also had an 'official' release number (it was basically Hacao translated from Vieitnamese into English)

[jcagle]

Grafpup is currently at version 2.0, just so you know. I'm not sure what version of Puppy that Grafpup 2.0 is based on, really.

[bugman]

I have a dual-boot computer, using Puppy 1.07 and 2.15, neither of which are on your chart. I feel left out and sad...

[yes, mrs. bugman thinks i am a pain in the ass too]

[Lobster]

Our news goes back to 2005 - with Puppy 1.04 - that might give some clues
http://puppylinux.org/wikka/July2005News

also check out the comments section here
http://puppylinux.org/wikka/HistoryPuppy?show_comments=1

hope that provides info and keeps Bugman happy

[Nathan F]

[setecio]

Nice. An informative way of representing the derivatives and gives a quick overview of what is out there.

Another chart which I think would be great would be a chart of derivatives vrs machine power, somehow showing a rough layout (relating to CPU / RAM) of which derivatives are aimed at older lower powered machines, and which at more powerful.

[cb88]

TeenPup is based on 2.14 and Ecopup is based on 2.15ce

[technowomble]

[mbutts]

Great thread and yes it would be nice for members if they knew what was a minimum that each would run on. I have not seen such a tree for other distro's however I might of missed it. I learned a lot about the older 1. versions since I started after the 2. versions were out and never tried any of them. I do use the old 1. game Puppy and it rocks, so I found out that I should not discount the older versions especially for older computers. A chart would make selection a snap to tailor certain versions to hardware. Perhaps a list of "will not work" quirks or list of pups and pets needed for hardware to work with some of the older versions would be nice too.

EDIT
Perhaps for each version people could give a list of computers that do or don't work for a particular version. I know some have problems with video and audio. Wifi and modems have been a problem for some also.

[macadavy]

I, too, would like to make a plea to developers to make a little more info about their Puppy versions available, (Programs included, etc.) and especially useful would be something like what TazOC has on his Download page for Lighthouse Puppy:

[Pizzasgood]

Personally, I try to keep fairly detailed logs about everything I do when making a derivative. To be honest, it's for my own benefit more than anything, because then I have something to refer to when figuring out why something works in Puppy but not Pizzapup. It's also very handy when I want to go back and incorporate things from old projects in newer ones. Or if I'm doing a commercial Puppy, and the "boss" decides he wants the base version changed to something three or four versions newer (that actually happened, and helped motivate me to improve, though I had been documenting already).

But they're also handy for the end user, in case they're wondering what has changed. They're not very "noob-friendly" to read, as they assume you know a certain amount about Puppy, so I still have to make a detailed summary myself. But I can't possibly summarize everything (wouldn't be a summary then either...), so I try to keep all the logs availible in case someone really wants to see what has changed.

For example, these are the logs from Pizzapup 3.0:
http://www.browserloadofcoolness.com/puplets/pizzapup/3.0/
And the "info" page:
http://www.browserloadofcoolness.com/puplets/pizzapup/pizzapup-3.0-info.php

Those logs are sloppier than what I currently do though. Practice makes less imperfect.


One thing that I find makes tracking your changes easier is using Unleashed instead of the remaster script. Mainly because it's persistent. What I usually do is add an extra directory to the unleashed tree, "changes/". Whenever I change something in a package, I symlink the package's directory into changes/. Then I add a textfile named the same as the package and document the changes. If I add a new package, I put it in the packages/ directory, then symlink it. But in that case I tend not to add any extra documentation unless I change something from the "vanilla" package other than basic stuff to make it compatible with Puppy (for example, I don't bother documenting symlinking firefox's binary to /usr/bin, but I document changes to the default settings).

I also keep a todo list in the changes/ directory, with the general list of changes I need to make, and changes I've already made. It helps for planning, and I can go back to get an overview for what I've done. I also make a file listing any packages I've added or removed from the mix (I could just do a diff between the final and original packages.txt file, but my method is more readable).


On the other hand, you have to take into account that most people making a custom Puppy are doing it for the first time or two, and are doing it for "fun". I didn't get very big on documenting my work until I started doing commercial Puppies, the first of which was my fourth custom Puppy if I remember right (preceded by two Pizzapups and Empty Crust). But now I document even the non-commercial Puppies, for the reasons I listed earlier. It has come in handy countless times now.


Hey, I'm just a lazy (but ridiculously busy) 19 year old college kid who hasn't even emptied his trash can in two months (and the garbage chute is literally across the hall from my apartment). If I can spare the time and thought to document my work, anyone can.

[Lobster]

[ttuuxxx]