Linux  and Free Software :: A review of puppy



I lately tried the Puppy distro, 3.01.
Here are my thoughts of it..

It's so polished on top. 48x48 png icons look nice, but it's their stardust gtk2 theme that really hits the sweet spot in my eyes.
There is a wizard for everything.
Nearly every directory includes a README.txt.

And there were *all* nice things about it, I would've thought there's more, but..

When I checked some of the readme.txt's, saw their uselessness. All of them have no instructions, they are just small changelogs of what's happened in that dir. Waste of space.
Non-corresponding menu entries: they have something like "gaim, MSN/Jabber/etc client". But when tried, less than half of those protocols explicitly mentioned in the menu entry are usable, in this case due to missing openssl bindings. Not so polished afterall.
Near-modern tech; squashfs. It is used. But an old and buggy version (3.0) that was released almost a year before puppy 3.01. Very nice decision, when exactly squashfs 3.1 improved the format considerably. I even managed to crash it, using their bootup resolution wizard (!).
NO auto-connecting. WTF does the line "starting network, [backgrounding]" on bootup mean then? I tested on the simplest setup possible, a well-supported realtek ethernet card connected to a ADSL router with a dhcp server. But no, I had to go through a long "connect" wizard before getting a connection.
After that the dock included a windows-like two-flashing-computers connection icon. That's a con in my eyes.

And then the worst spot. After the clean look on top, it hurts to go down. The code is messy, has unused left-overs from earlier versions etc.
There are apps for needs too: puppy-serialdetect, puppy-this and puppy-that. While they are C programs, and fast, user-friendliness is near zero. No help display, with or without any -h or whatsoever switches. And in this case, there's no code to look at.
Due to using busybox init, the boot structure is small, but it's managed to get messed too.


So, it's exactly the contrary of DSL, of well-designed under-the-hood experience, but not too flashy exterior.
Not recommended. Robert, keep up the good work!

You left out one of puppy's most serious flaws: designed to run as root by default. At least one of its spinoffs (grafpup) fixed that.
Yes. Not on purpose though.

Their web page uses the arguments read-only environment, running as user would still let damage into your files, and that the wiki server is run as a normal user.

Not too good ones IMO. Even if the cd is readonly, the HD's in the current comp aren't.

Quote
The code is messy, has unused left-overs from earlier versions etc.


Yes!  This is something that really annoys me about Puppy.  I hate seeing commented out code from alternative or prior versions in scripts - either accept the changes and delete the old code, or disable it and clearly lable the function etc "obsoleted" (though I don't like that either).

The other thing that concerns me is their lack of a central repo for packages.  I raised this over there but they didn't seem to get it - apparently people are supposed to post links to their packages in the forum and that constitutes review - but there's no control.    You have to be "in the know" to find the right version of certain packages and there's no central peer review like with dsl.  If a dsl package is bad, it can (and has been) pulled from the repo or replaced, which to me is pretty much essential.

On the plus side, Puppy has a very clever solution to reducing write cycles to flash, IceWM is good, the gtk theming etc is nice, and they have an energetic team working on releases. Puppy's forum conmunity is big and very active, with a lot of on-the-ball and knowledgeable posters.  They attract a lot of interest.  And the 2.6.xx gtk2 Xorg combination is handy - Puppy can run a *lot* of stuff.

Puppy is largely a true commuity project, so the development and release process is very different to dsl.  Barry was due to hand over the project entirely to the community and retire about now - I don't know if that has happened.

I imagine(?) the commented-out code thing might be to just ensure script  contributors are acknowledged, though there are better ways to do that. With a number of developers ivolved, a git/svn type scheme could be justified.  The best ackowledgement scheme I've seen, which I think must build a lot of community pride, is Vector's linux's "honor roll" during boot up, which whizzes past the nics/names of all the contributors, testers etc.
.

Well, 3.01 had JWM instead of iceWM.

Then the livecd/backup possibility could be compared. DSL saves whatever is in your .filetool.lst excluding what is in .xfiletool.lst. This does not include hardware-based decisions. So if you boot the cd on one comp, save backup to a usb stick, you can boot it on another comps and have only your settings and data restored.

Then puppy. It puts *everything* to the backup. Not a single dir, but everything that's been changed in the whole filesystem. This can make it really big, and also isn't really manageable. It also includes HW based decisions. This means there's a chance it won't boot on another comp, or will have the old keyboard setting, etc other annoyances.

Next Page...
original here.