A review of puppy

Forum: Linux �and Free Software
Topic: A review of puppy
started by: curaga

Posted by curaga on Dec. 31 2007,15:46

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!

Posted by lucky13 on Dec. 31 2007,18:04

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.

Posted by curaga on Dec. 31 2007,20:51

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.

Posted by WDef on Jan. 04 2008,17:13

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.
.

Posted by curaga on Jan. 06 2008,10:31

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.

Posted by WDef on Jan. 09 2008,13:31

Last one I looked at they were using IceWM - after the 215CE I think. Wonder why they switched. Icewm is nice.

Re backup: the Puppy backup methology is quite different to dsl. DSL simply makes an archive, which is fine for our purposes - Puppy is writing changes to a filesystem on a file-backed loop - that filesystem is part of the aufs unified view that the user sees. This makes the "backup" very fast (barring a sync) and you can have a lot of stuff in it if you want to.

User writes to the filesystem are held on a tmpfs filesystem on ramdisk and are copied over to the file-backed loop at intervals if this resides on a flash drive. This is quite clever for reducing write cycles to flash, though you could conceivably lose data if the system freezes or power is lost in between. In practice doesn't seem to be a problem.

To encrypt the file-backed loop, last time I cheked they're using cryptoloop I think, which has known vulnerabilities and is a bad choice.

[ Mind you, dsl is writing its backup in *plaintext* to the backup medium (like it once used to) before overwriting and encrypting since switching from 3des to bcrypt, so in terms of data security that could be considered a retrograde move. ((bcrypt can't work in a pipe the way 3des or gpg can so Robert would have had little choice other than to not use bcrypt). ]

Puppy could get stung one day if they get the wrong kernel/loop driver combination, it will start freezing the system up randomly. They seem to have avoided that so far.

I'm out of touch, they may have swiched to dm-crypt/cryptsetup-LUKS by now, but that still would not avoid potential loop driver freezes on a file-backed loop.

Posted by curaga on Jan. 09 2008,15:38

I didn't look at puppy's encrypting possibilities at all, I didn't have a need for that..

Anyway, there are ways around bcrypt's limitations, three come to my mind:
- either building on the official blowfish implementation, or editing bcrypt
- keeping the plain backup in RAM, not the backup medium (probably not feasible for DSL)
- and the the ideal solution: named pipes. If we make one, it will be accepted into bcrypt as a file, and nothing will be written in plaintext. Even the tar compression speed of the system isn't a problem, bcrypt just sees a slow-to-read device.

You seem to be a better security expert than me - do you see any obvious flaws in named pipes?
If not, maybe this could be implemented in DSL.

Posted by roberts on Jan. 09 2008,15:56

Just a comment. I designed DSL features long before there was unionsfs/aufs. I designed DSL to be nomadic. Therefore no hardware specifics in the backup. I designed and created dot dsl, uci, and tar.gz extensions before dot pup, et. al. I did this several reasons, factor out large static files from the backup, reduce write cycles, read many, write once, provide easy self contained "packages" with easy reboot and they are removed.

I am still supporting what I wrote, now years ago. I too, could have dropped, syslinux, legacy (non-unionfs) and chose to not be nomadic.

Most, if not all kernel 2.6 based distros now offer a unionfs/aufs with liveCD. Instead, I have tried to offer more within my original design goals. Both Austrumi and Puppy have gone on to larger systems and use higher compression to achieve small physical (download) size, but system requirements and runtime size is much higher than DSL. I cannot run those systems on much of my hardware.

Even the new eeePC uses "a frugal" installation. Where the system is frozen and all user changes are done in union space.
I applaud this approach. That concept was what I was doing with DSL frugal install and ramdisk. One can always boot to a known pristine state. One does not suffer from "system rot" or other "oops" corruption.

While the 2.4 kernel is still being maintained, I don't have the luxury of newer unionfs/aufs and other subsystems being supported in 2.4 kernel. There is much debate on 2.6 kernel being more for servers than desktop. But the pressure of lack of support by major subsystems, aufs, ndiswrapper, etc limits the capability moving forward.

Posted by WDef on Jan. 09 2008,19:26

@Curaga:

Quote

named pipes. If we make one, it will be accepted into bcrypt as a file

No it won't unfortunately. As I said, bcrypt can't work in a pipe. (You're probably not aware that I was the one who suggested using named pipes with 3des on dsl back in the olden days to avoid this issue then). A look at the bcrypt code shows why. It gets the input file size at the beginning and passes this down as an argument through a bunch of functions. This makes it quite sure how much memory it's using, and is slightly easier, but is not necessary. A name piped is a 0-byte file, which bcrypt interprets as no file at all. Reading from stdin or a pipe is not difficult to code, so I wish they'd done this and it seems like bad design to me when most other encryption progs can read from stdin. Writing to stdout can be more problematic because garbage out cannot be deleted or rewound on a pipe.

@Roberts: interesting background there on 2.6.xx. I recall Puppy *had* to move to aufs, because the way they stack their filesystem layers was causing lots of problems under unionfs (can't recall the details) - certain files went invisible in certain packages or something - aufs solved this for them dsl's system doesn't have these issues with unionfs.

Posted by curaga on Jan. 10 2008,15:55

Could you possibly add stdin reading to it? It's open source, under the first BSD license.

Posted by WDef on Jan. 10 2008,17:33

I could probably hack up a patch to make it read from stdin, but it would be far better if the bcrypt developers did this.

Perhaps post a feature request for an option to read from stdin (and preferably write to stdout also) on their developer mail list or whatever they have?

Posted by curaga on Jan. 10 2008,18:41

Well, since the last update is from 2002, I doubt there's anyone who would respond

Posted by WDef on Jan. 10 2008,19:16

I didn't realize it was unmaintained. In itself that 's not a great sign for an encryption prog unfortunately.

Not sure about alternatives. The aespipe binary is 60K when stripped ie still bigger than bcrypt. Perhaps if optimized for size would get smaller. des is 39.5K.

I'll think about a patch. I fooled around with the OpenSSL API and wrote a (not production ready) blowfish encryption prog out of it not long ago that read from stdin, so I have the general idea. (It wasn't that small a binary). But I wouldn't inflict anything like that of mine on the general public just yet without getting some expert code review.