Some thoughts on puppy's state and future
Posted: Wed 01 Feb 2012, 10:57
I'm a relative newcomer to Puppy and linux but I hope I can express some thoughts, even as an outsider.
Should be noticed that some of the issues addressed here are also appearing in several other threads in this forum. I just try to put them all together in a "global" approach.
Current State
Puppy is a bursting community of capable, creative and (mostly) friendly people that is producing the (apparently) most successful "small distro" , that brings it at the heels of "big distros".
Currently Puppy-5.x builds has 6 in development (Wary, Racy, Saluki, Lupu, Slacko and Fatdog) and countless other derivatives to fit every possible need. This has the obvious advantages but also some disadvantages I believe.
The major one is "consumption" of good developers in rediscovering the wheel and thus the limited advancement of puppy-core, which is supported only by one person Barry, that also takes care of 2 official puppy builds (and some experimental).
The obvious question is, can we keep all these while being more efficient and advance puppy further?
If you think not, stop reading here.
Puppy goals
Puppy is a distribution established for its support of older hardware, its compactness, efficiency and portability.
Lately we see more and more puppy running in machines with 2+ cores and 4GB+ RAM while ISOs can fill up a CD and have UIs with every imaginable bell and whistle (obviously Saluki is not one of them).
There is nothing wrong with these builds and is good to have. However, they may try to "pull" Puppy that way. May be they are right. May be the P3/P4-class, 256/512MB RAM machines are the minority of the puppy-istalled base and will disappear the next year or two. But also new "low spec" hardware is appearing in the market. Namely, netbooks and ARM machines.
A decision must be made to what extend puppy is going to focus in newer, high power hardware and if so what will be its competitive advantage over Ubuntu or Fedora, other than few milliseconds in program loading or Puppy-on-a-Stick that almost every major distro has now-days.Is it going to shift to netbooks and ARM? Is it going to stick with the older hardware as a primary goal? All of the above? Other?
Tool Chain
One major problem of the current multi-faceted approach is "dispersion" of puppy developers. Currently puppy does not have the person-power and the organized structure required to be "everything to everyone". At the same time its limited resources are hampered by the lack of a common tool-chain.
Every distro for each major version has as a minimum a common kernel, binutils, gcc, libc and xserver. This allow for consistent packaging and easier upgrading. In Puppy all the aforementioned builds are different in one component or another. Thus the same packages must be re-compiled, similar bugs must be re-squashed, repos must be re-build.
But what about old hardware and multi-binary compatibility? Two of the current puppy goals.
I think that like wary/racy, every Puppy-N.x could have a main and a retro version (with their respective tool chains).
Regarding binary compatibility, to the extend that the tool chains are different, they should not have the puppy major version in their name or even describe themselves as "based on", because simply they are not. Could be Puppy Slacko for example but not Puppy 5x Slacko, or could be Puppy 6 if Barry or whoever decides, decides that this will be the tool chain the next version will use.
Woof
Woof, the puppy builder, is actually what puppy development is today. Is responsible for the flurry of puppies and the recent puppy success, I would think. However, may have some weaknesses that could be improved. E.g have less hard coded items, use source files instead of binaries etc.
BK is the sole developer of woof. The developer community contributions may address one or another bug/feature but do not affect woof structure and inner workings to any extend. May be woof could be reworked, addressing some issues and coming in line with other matters mentioned here. May be could open up to more contributions by other developers. May be it could have a "stable" and a "development" branch as other build system have. May be it could be split in subsections and have different maintainers for each one with Barry at the helm (like kernel.org). May be ... I'm sure that will not be a lack of ideas in this front.
Package management and repos
One major problem with puppy and derivatives is packet management and repos. ibiblio has 15 repos and smokey01 another 6 or 7 while the forum has countless pets. At the same time PPM does not know how to handle these and quite often installing a package generate more problems than it solves. This is not user friendly and gives the impression of a sub-par distro.
Puppy needs audited, signed pets and PPM needs to check dependencies and version compatibility in advance. Could allow "unofficial" packages to be installed (as many other package managers) but maybe after a series of scary warnings.
Besides the user friendliness this should also release some of the developers' efforts to debug and/or recompile packages.
Of course such a change, besides new coding, needs some decisions on the pet format and requirements and some people to actually do pet QA and repo maintenance.
Puppy summit
All these bring up the issue of decision.
This is strictly up to Barry Kauler. He is the owner of Puppy. He is the one that must decide how and by whom the puppy label can be attached to a build.
My suggestion is that this should be done by a group of developers and users hand-picked by Barry or voted by the community. This group can channel a bit the scattered efforts, decide on principles and development approaches and assure continuation if/when Burry retires.
I believe however that this decision can not be made in a forum or in a chat-room or by any other electronic communication. I think is time for a puppy summit
(Some travel cost could be covered by donations from the multiple puppy beneficiaries).
In this summit/meeting/conference BK and whoever else is available will meet face to face and discuss in person what should be done, and most important how it should be done, for any of the aforementioned issues deem worthy.
This "strategy" meeting could be augmented by developer presentations of new infrastructure items and a code-sprint to address some puppy issues or lay the foundation for some additions/changes to core puppy (e.g. gtk3 support that ttuuxxx started on 2.14X)
So let's get all the (big) dogs together!
My (looong) 2c.
Should be noticed that some of the issues addressed here are also appearing in several other threads in this forum. I just try to put them all together in a "global" approach.
Current State
Puppy is a bursting community of capable, creative and (mostly) friendly people that is producing the (apparently) most successful "small distro" , that brings it at the heels of "big distros".
Currently Puppy-5.x builds has 6 in development (Wary, Racy, Saluki, Lupu, Slacko and Fatdog) and countless other derivatives to fit every possible need. This has the obvious advantages but also some disadvantages I believe.
The major one is "consumption" of good developers in rediscovering the wheel and thus the limited advancement of puppy-core, which is supported only by one person Barry, that also takes care of 2 official puppy builds (and some experimental).
The obvious question is, can we keep all these while being more efficient and advance puppy further?
If you think not, stop reading here.
Puppy goals
Puppy is a distribution established for its support of older hardware, its compactness, efficiency and portability.
Lately we see more and more puppy running in machines with 2+ cores and 4GB+ RAM while ISOs can fill up a CD and have UIs with every imaginable bell and whistle (obviously Saluki is not one of them).
There is nothing wrong with these builds and is good to have. However, they may try to "pull" Puppy that way. May be they are right. May be the P3/P4-class, 256/512MB RAM machines are the minority of the puppy-istalled base and will disappear the next year or two. But also new "low spec" hardware is appearing in the market. Namely, netbooks and ARM machines.
A decision must be made to what extend puppy is going to focus in newer, high power hardware and if so what will be its competitive advantage over Ubuntu or Fedora, other than few milliseconds in program loading or Puppy-on-a-Stick that almost every major distro has now-days.Is it going to shift to netbooks and ARM? Is it going to stick with the older hardware as a primary goal? All of the above? Other?
Tool Chain
One major problem of the current multi-faceted approach is "dispersion" of puppy developers. Currently puppy does not have the person-power and the organized structure required to be "everything to everyone". At the same time its limited resources are hampered by the lack of a common tool-chain.
Every distro for each major version has as a minimum a common kernel, binutils, gcc, libc and xserver. This allow for consistent packaging and easier upgrading. In Puppy all the aforementioned builds are different in one component or another. Thus the same packages must be re-compiled, similar bugs must be re-squashed, repos must be re-build.
But what about old hardware and multi-binary compatibility? Two of the current puppy goals.
I think that like wary/racy, every Puppy-N.x could have a main and a retro version (with their respective tool chains).
Regarding binary compatibility, to the extend that the tool chains are different, they should not have the puppy major version in their name or even describe themselves as "based on", because simply they are not. Could be Puppy Slacko for example but not Puppy 5x Slacko, or could be Puppy 6 if Barry or whoever decides, decides that this will be the tool chain the next version will use.
Woof
Woof, the puppy builder, is actually what puppy development is today. Is responsible for the flurry of puppies and the recent puppy success, I would think. However, may have some weaknesses that could be improved. E.g have less hard coded items, use source files instead of binaries etc.
BK is the sole developer of woof. The developer community contributions may address one or another bug/feature but do not affect woof structure and inner workings to any extend. May be woof could be reworked, addressing some issues and coming in line with other matters mentioned here. May be could open up to more contributions by other developers. May be it could have a "stable" and a "development" branch as other build system have. May be it could be split in subsections and have different maintainers for each one with Barry at the helm (like kernel.org). May be ... I'm sure that will not be a lack of ideas in this front.
Package management and repos
One major problem with puppy and derivatives is packet management and repos. ibiblio has 15 repos and smokey01 another 6 or 7 while the forum has countless pets. At the same time PPM does not know how to handle these and quite often installing a package generate more problems than it solves. This is not user friendly and gives the impression of a sub-par distro.
Puppy needs audited, signed pets and PPM needs to check dependencies and version compatibility in advance. Could allow "unofficial" packages to be installed (as many other package managers) but maybe after a series of scary warnings.
Besides the user friendliness this should also release some of the developers' efforts to debug and/or recompile packages.
Of course such a change, besides new coding, needs some decisions on the pet format and requirements and some people to actually do pet QA and repo maintenance.
Puppy summit
All these bring up the issue of decision.
This is strictly up to Barry Kauler. He is the owner of Puppy. He is the one that must decide how and by whom the puppy label can be attached to a build.
My suggestion is that this should be done by a group of developers and users hand-picked by Barry or voted by the community. This group can channel a bit the scattered efforts, decide on principles and development approaches and assure continuation if/when Burry retires.
I believe however that this decision can not be made in a forum or in a chat-room or by any other electronic communication. I think is time for a puppy summit
(Some travel cost could be covered by donations from the multiple puppy beneficiaries).
In this summit/meeting/conference BK and whoever else is available will meet face to face and discuss in person what should be done, and most important how it should be done, for any of the aforementioned issues deem worthy.
This "strategy" meeting could be augmented by developer presentations of new infrastructure items and a code-sprint to address some puppy issues or lay the foundation for some additions/changes to core puppy (e.g. gtk3 support that ttuuxxx started on 2.14X)
So let's get all the (big) dogs together!
My (looong) 2c.