Home
dimakrasner.com
Dima Krasner's Homepage
Feb 11 2012
Why Fork Puppy
By dima
I'm currently working on my own distribution, Subito GNU/Linux, which is a strong competitor to Puppy Linux meant to unify its qualities with those SLAX had and put heaps of the Arch Linux and Slackware KISS goodness on top. The idea is to be the first distribution that appeals to advanced users those appreciate the speed and size of "live" distributions but also like the simplicity of Arch.
Here's an assorted list of random rants and complaints about Puppy Linux and its infrastructure, most notably Woof:
1 Puppy Linux's code (especially the code that originates in Woof) is of poor quality; the only solution to this problem is a complete rewrite.
You're mostly correct, here ...
2 Woof is extremely hard to develop for, because it contains thousands of commented-out lines of legacy code and lacks proper documentation. Any part of a distribution-building infrastructure should consists of 100%, purely good code, otherwise its output will inherit its horrible quality.
Agreed.
3 Puppy Linux has a hard dependency on many ancient, deprecated packages (such as nenscript or installwatch) that cannot be built with today's compilers. A good example for this is gtkdialog: nobody's going to port it to GTK+ 3. Puppy was not designed with the possibility of future porting or "sister" distributions in mind: it cannot be ported to another architecture easily, period.
Yes, those hard dependencies on ancient, deprecated packages _should_ be weeded out. Be a bit careful with what could be compiled in a certain environment, or another, though. Gtkdialog -> gtk+ 3, don't know, but, who knows ...
4 According to Barry, Woof 2's blessing to the world was architecture-independence, but this is a lie! The reason its first generation lacked this feature is the fact It uses a chroot call to perform certain operations, but the new version just saves the target architecture and the one it was built on in a file and performs these final operations at boot time, contributing to Puppy's horrible boot speed. This isn't the right way to implement portability.
Cannot comment, am an all x86 bloke ...
5 Woof is slow; it performs all string operations using pipes, downloads files one-by-one from a single mirror and does the big no-no of shell scripting, which is recursion (e.g endless chains of fork() and exec()).
Agreed, woof is slow. However, roar-ng's speed could be improved upon, though it's signicantly faster than woof(2) ...
6 Puppy Linux boots slowly, because it has to search all partitions for its files and dynamically loads specific drivers to determine each partition's type. Also, its kernel package is split between the initramfs (the initial file system used to locate the main one) and the main file system itself, which causes mess and makes Woof less generic.
As you'd know, woof-built puppies searches all partitions, unless a partition is specified at boot-time. Splitting of kernel package between initramfs and the main file system causes _mess_ in what way?
7 With every change to Woof, Puppy Linux becomes more and more ignorant of standards. Although the usefulness of some is debatable, compliance makes development easier, since everybody else follows them.
? - /opt/* ???
8 Altough newer versions of Puppy Linux ship with a more exotic choice of window managers, much of its infrastructure still relies on the traditional JWM and ROX-Filer, which are non-standard in many ways. Woof's desktop integration of the two and the partial support for standards are implemented in dirty ways and make it hard to use Puppy as a development platform.
Yes? And how is cwm more standard?
9 The PET package format used by Puppy's packages is quite messy and hard to work with. Moreover, it uses the traditional gzip compression, which provides a low compression rate in today's standards.
Lower compression rate than xz, agreed. Messy? What's so messy with a bog-standard gz-package with a tucked-on md5sum, including a package-specs-file?
10 Puppy Linux's organizational structure is bad for continuity. Its development team consists of a small group of dedicated volunteers and Barry Kauler, who holds all intellectual property and takes care of all big decisions. Because of this, many fans develop their own, low-quality derivatives that lack creativity or special features, which frustrate novice users because of limited support.
The ease of re-mastering a puppy, or of woofing up your own (in spite of above stated awkwardness of woof(2)) has been a long-time development-choice of BK, as I gather. How roar-ng will ease the frustration of novice users is, yet, still yo be seen ...
11 Old (7.3 and below) versions of the X.Org X server had very limited support for automatic hardware detection (provided by the deprecated HAL daemon) and required a configuration file. Many tools were developed to accomplish this, most notably SaX2 and Puppy's xorgwizard. However, newer versions rely on udev, which is indeed reliable and therefore, hardware detection is good; these tools are no longer needed, but Woof still contains xorgwizard, to provide compatibility with those old versions (most notably, version 7.3, as found in Puppy Linux 4.3.1 and Wary Puppy). The hardware support of Woof-built distributions with later versions is much worse and they suffer from a longer boot sequence, for no reason.
Automatic hardware detection is not always that good ...
12 A distribution built using Woof is limited to the use of packages from Puppy Linux and packages from an optional, other distribution.
As it stands, as of 2012-02-11, using roar-ng is limited to another distribution, with the optional add-mixture of a _certain x86_64 sample distro_ .....
And, for legacy 32-bit:ers ???
13 It is extremely hard to add support for new distributions in Woof, because support for existing ones is provided as conditions in existing scripts.
Yes, agreed. But, on the other hand, how easy is it to add local packages and local package-lists to roar-ng-002, like a roar-ng tester just queried?
To conclude - I think it's time for someone to fork Puppy Linux and compete with it, head-to-head. It's a good product which deserves a better future and more care. The only way to provide this is a revolution and not the ugly evolution, which made me write this.
Innovation, professionalism and rebelliousness: this is my motto. And yours?
There is no doubt, at all, that you're extremely innovative, cunning, canny, and .... But, rebelliousness can, sometimes mistakenly, be interpreted as youngish cockiness, and vice versa ....