IT IS NOT!
I am NOT dismissing the many items of functionality. This comment is to ask for some assistance on a definition that I think would help everyone. I am a user, and it cannot come from me. I ask this because the functionality discussion is going to be derailed by a SIZE discussion that I envision is on the horizon. In a world where it is now becoming commonplace to have a 1GB+ PC, the systems that are being generated by the functionality which can be included from WOOF and others, must also take into account that the world is moving also. And, on one hand, it is as there has been a consistent movement to address modern 32bit PCs as well as newer platforms.
Here's the problem: We have
- System Designer(s) targets for generation of a specific type of Puppy. This includes package selection technology for distro users to apply in the generation of a specific Puppy.
- System Distro Owners who use the system crafted by the System Designer(s) to generate a Puppy,
- Application developers who take source, packages, or scripts to make functional packages to address either a Linux subsystems, a system applications, or user applications to give a robustness of functionality.
- Users, who have various needs that come into play as they select and use a particular Distro Owner's Puppy.
Problem restated "NOT ONE OF THESE GROUPS HAS STATED WHAT THEY MEAN BY SIZE and WHY THEY HAVE ADOPTED THE PARTICULAR DEFINITION THEY USE!
This is what confounds the constant discussion and references to size that everyone of us uses. We all have a particular "perception" of the constant we refer to as "SIZE", but no real definition or goal.
Let's assume, there is reasonable accuracy in what I have share thus far. "No one know what that is" and yet, I bet, everyone who reads this has already thought to themselves that THEY KNOW. In a way...YES, they do.....at least a piece of it.
Male or female: SIZE matters. In my world, size=capacity. Which leads you to ask "what's capacity?" in the world I come from (and even today the rule is the same), mathematically, it addresses how many of these can I get into that. Specifically, is that BIG Enough. Further, how long will that last at present usage and growth. Will that address foreseeable changes and demand. In systems operation, the most important item in the SIZE equation is "PATH-LENGTH"! And, to date, not one Puppy person has EVER discussed path-length as a topic or in description or in design objective or in measurement of anything including Puppy OS subsystems or application. And, not to take issue with anyone, because you shrunk the physical size does NOT mean you have made any major improvement in either systems operation or user needs. There is NOTHING formal here. This for a 21st century OS as we begin to really compete should have us maturing in our understandings of what the hardware vendors are providing us so that we exploit it to give the users an ever expanding multimedia OS to match the direction the world is heading. We need to begin to turn our attention to adding this needed functionality for a robust user experience instead of the 'chest pounding' that many do using SIZE as the means. This does NOT mean to abandon SIZE objectives, but it does mean that we should standardize our size objectives with a definition that covers what and why a specific objective needs to be in place.
Here's an example of a known subsystem here is the Linux community. If one system is disk sized at 25MB and for a given transaction require a 400K path-length to complete while similar subsystem that does the same work is disk sized at 60MB and provides the same 400K path-length to complete a given transaction. Which is better? (The answer depends on who you are) Someone(s) of you will take the smaller and declare is "gospel". But, let's peer a little deeper. I know that a single transaction takes 400K in the one, but, the one does NOT have to ability to compete with the other because the other not only handles that one transaction, but scales to 1000s more of these, while at the same time performing other needs for that system user at the same time without degrading the overall transaction path-lengths or the time-slice response times. Now, which one is better? (This was not a question by the way for I'm sure, knowing this, our intelligence tells us to take the scaling app over the non-scaling one unless we had disk-space problems. And for this example, there isn't one of us with a 35MB disk space problem.) Taking an additional look, assume, if measurements are correct, the 25MB app takes 30MB of RAM while the 60MB app takes 28MB of RAM. Here's hoping by now that we begin to see how SIZE really needs some constant definition when used in Puppyland to reference what we mean when we throw these terms about.
Let's help each other by defining what we mean by size somewhere which can be standardized for understanding. If you are a distro owner, state "Proudly" the size you feel is important to the community who will be investigating your distro for consumption. Several distro owners have done so in the past (you know who you are). And with applications, I would be happy just to know what functionality is provided. The specific MB size is UN-important to me. The system performance of the application requirement is of utmost importance to me. For, the RAM usage in ALL of my Puppy dealings is relatively small in comparison to the size of RAM it is using.
If we proudly show the system needs in terms of its sizes and if we proudly show the application needs running within the system, we would have a much more. real and consistent, awareness in our audience than the misleading items we see today. If we could LOOK at what we really are trying to do. Are we trying to address a personal preference or are we addressing a packaging that operates comfortably on the platforms which you intend them to perform on.
Puppyland has a diverse combination of skills and personalities that exist in this community. They bring to the table a wealth of useful insights and talents. It would be great if we could standardize some objectives so that everyone is on the same page for the direction we move toward. And, for new directions. we should, too, standardize its objective, mission, and most of all, ITS NEED!.
This distro does NOT posses any "internal" tools that is consistently applies to demonstrate performance at either the OS level, the subsystem levels, or the application levels. Excepting for a few or our members, there is an indifference to addressing this. Thus, our community continues to banter about the term without consist definition or objective measurement. We just say "Look, .... size is reduce..."??? without ever explaining why or how its benefited anything real. There are other examples I cam bring to bear, but, examples do NOT address the need for consistency in use of a powerful term as SIZE has become.
This is merely my sharing my observation on this topic. I in no way have asked nor am asking for any abandonment of any distro owner or application provider's efforts. I am asking for a consistency in defining what we mean by SIZE whenever we throw the word around.
And, if there is some way to apply a tool to assist us in size measurements, we should do it I have used Hardinfo as one of the tools which provides some insights to my system's behavior in comparison. But, because I use it, does NOT mean that it is widely viewed as a valid too within this communityl. This is because it is NOT specifically asked for. Nor is any tools, generallly asked for, by our distro owners.
Help by offering something that could improve the level of understanding needed within the community on this. Offer anything you think could help all of us.