I have always been aware of some things about the Puppy system that is "batted" around continuously within the forum. There is this constant awareness of SIZE without any "real" meaningful definition in place. It is at the very heart of many discussions I've seen over the years. The meaningful definition should be consistent, accurate and universal; IN PUPPYLAND.

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.

All of these people bring something personal to the table in terms of taste, needs, and desires.

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._________________Get ACTIVE Create Circles; Do those good things which benefit people's needs!
We are all related ... Its time to show that we know this!
3 Different Puppy Search Engineor use DogPileLast edited by gcmartin on Thu 05 Jan 2012, 20:32; edited 3 times in total

I fully recognize that increasing functionality comes along with increasing costs. Everyone should recognize and everyone should appreciate what this community is providing us. So, maybe something as simple as SIZE statements accompanying distros could be a help until such time as the powers to be brings us a better standard description of size.

For any distro it could be helpful/useful, to both them and us, to provide their own:

expected distro size

expected RAM needed to boot the system without SWAP

expected RAM needed to boot the system with SWAP

observed initial RAM in use after initial boot

expected RAM to support smooth system operations using the defaults provided by the distro developer(s)

Hope this gets creative juices flowing._________________Get ACTIVE Create Circles; Do those good things which benefit people's needs!
We are all related ... Its time to show that we know this!
3 Different Puppy Search Engineor use DogPileLast edited by gcmartin on Thu 05 Jan 2012, 20:33; edited 1 time in total

GCmartin how long is a piece of string ? puppies are now being specialized for different hardware (wary, pae and 64bit) are made to use other distro's software (dpup, lucid, slacko) some of the the cutting edge puplets are way above what would be a "normal" size for a official release (and some are way under), yet they are needed so that ideas, theories and bugs can be worked out.

do you make a distinction between 32 and 64 bit? or different kernel types? take the recent release of slacko both iso's, main and pae were identical (bar the kernel) (both woof built) but the pae iso was about 13mb smaller due to different file compression on the main sfs, was one of them the wrong size?

IMHO It is best left to the developer to use their judgement on size, as no matter how a project is explained only the developer will be able to truly see what they want to create, and with the quality of puppies being produced long may it stay that way.

Thanks @Playdayz. As you know I am aware of efforts you provided to give an awareness of your Distro's needs. I agree with what you've done. But, the distro owners and the application developers do NOT all do this nor do they share a "common" method of doing this.

We could expand and try building something common thru this thread and how that either thru the Generation process or the announcement process, there comes a common method so that the widespread system use it more nearly understood. This would give a better understanding and appreciation for all; generation, owners, developers and users alike.

@Stripe, thanks for your comments. For clarity (those who saw your comments), I agree that the those producing distros or packages for us should, where possible (there are instances that come to mind where this may not be initially possible), be sharing that information with us.

Thus, to make it easier and more consistent, we could provide some common approaches to this information need that would make everyone's job easier and well understood.

Puppy is maturing.

Hope this helps._________________Get ACTIVE Create Circles; Do those good things which benefit people's needs!
We are all related ... Its time to show that we know this!
3 Different Puppy Search Engineor use DogPile

Not a bad idea, actually. I know I always thought that Zenwalk and later Bodhi and the previous incarnation of #! were small at several hundred MB, so Puppy at ~100MB was really small compared to anything other than Slitaz or Slax. (I never really got along with TinyCore.)

But I ramble...I really hate using a DVD for only about 1GB in burning a distro. It seems like such a waste in away.

So, my first reaction was, "Why do we really need to draw up some rule about size? That's all we need is more rules, laws and some community telling me my new puplet is 'non-standard.' This cuts across the grain of the open source spirit!" In other words I was kind of thinking of the length of string, too.

BUT Playdayz comes to the rescue with a meaningful standard, so thanks for the question gcmartin and the answer playdayz.

And now we have a reason to care about a standard of size. Sometimes, that is. There will always be deviations, some more than others, so the purpose of the pup or puplet must be taken into consideration.

Nothing can possibly be conceived in the world, or even out of it, which can be called good, without qualification, except a good will. Intelligence, wit, judgement, and the other talents of the mind, however they may be named, or courage, resolution, perseverance, as qualities of temperament, are undoubtedly good and desirable in many respects; but these gifts of nature may also become extremely bad and mischievous if the will which is to make use of them, and which, therefore, constitutes what is called character, is not good. It is the same with the gifts of fortune. Power, riches, honour, even health, and the general well-being and contentment with one's condition which is called happiness, inspire pride, and often presumption, if there is not a good will to correct the influence of these on the mind, and with this also to rectify the whole principle of acting and adapt it to its end. The sight of a being who is not adorned with a single feature of a pure and good will, enjoying unbroken prosperity, can never give pleasure to an impartial rational spectator. Thus a good will appears to constitute the indispensable condition even of being worthy of happiness. There are even some qualities which are of service to this good will itself and may facilitate its action, yet which have no intrinsic unconditional value, but always presuppose a good will, and this qualifies the esteem that we justly have for them and does not permit us to regard them as absolutely good.

Moderation in the affections and passions, self-control, and calm deliberation are not only good in many respects, but even seem to constitute part of the intrinsic worth of the person; but they are far from deserving to be called good without qualification, although they have been so unconditionally praised by the ancients. For without the principles of a good will, they may become extremely bad, and the coolness of a villain not only makes him far more dangerous, but also directly makes him more abominable in our eyes than he would have been without it. A good will is good not because of what it performs or effects, not by its aptness for the attainment of some proposed end, but simply by virtue of the volition; that is, it is good in itself, and considered by itself is to be esteemed much higher than all that can be brought about by it in favour of any inclination, nay even of the sum total of all inclinations.

Even if it should happen that, owing to special disfavour of fortune, or the niggardly provision of a step-motherly nature, this will should wholly lack power to accomplish its purpose, if with its greatest efforts it should yet achieve nothing, and there should remain only the good will (not, to be sure, a mere wish, but the summoning of all means in our power), then, like a jewel, it would still shine by its own light, as a thing which has its whole value in itself. Its usefulness or fruitfulness can neither add nor take away anything from this value. It would be, as it were, only the setting to enable us to handle it the more conveniently in common commerce, or to attract to it the attention of those who are not yet connoisseurs, but not to recommend it to true connoisseurs, or to determine its value. There is, however, something so strange in this idea of the absolute value of the mere will, in which no account is taken of its utility, that notwithstanding the thorough assent of even common reason to the idea, yet a suspicion must arise that it may perhaps really be the product of mere high-flown fancy, and that we may have misunderstood the purpose of nature in assigning reason as the governor of our will. Therefore we will examine this idea from this point of view. In the physical constitution of an organized being, that is, a being adapted suitably to the purposes of life, we assume it as a fundamental principle that no organ for any purpose will be found but what is also the fittest and best adapted for that purpose. Now in a being which has reason and a will, if the proper object of nature were its conservation, its welfare, in a word, its happiness, then nature would have hit upon a very bad arrangement in selecting the reason of the creature to carry out this purpose. For all the actions which the creature has to perform with a view to this purpose, and the whole rule of its conduct, would be far more surely prescribed to it by instinct, and that end would have been attained thereby much more certainly than it ever can be by reason.

I also hear how Puppy is very small in size regarding the ISO for download in comparison to other distros.
It is pointed out that Puppy basically contains the equivalent applications that the other distro offers and a lot more as to how one can install, and run Puppy.
But in the other distro, you have additional code required to not run as root.
You also normally have the compiler built in.

If we take a basic Puppy ISO and add the kernel source, and the compiling software and libraries, it grows by quite a bit.

Is leaving it out a good thing?
To me, having it as external packages helps Puppy to support PCs with less ram.

One thing that I wonder about is the memory and system requirements as well as setup.

I still have an old Red Hat version of Linux that required 64 megs of ram to get you to a desktop with the basic applications one would need.

So is the support for all the new hardware as well as the old a factor in Puppy's footprint.

How much less of a footprint would it take if Puppy went back to an additional drivers SFS that only loaded the required drivers.

Are all the drivers that are included loaded into memory, not activated, in the main SFS file?

In other words, are only the drivers I require for my specific PC installed?

In the old days of adding hardware, the install disk was required to access and install additional drivers as needed.
Now we add hardware and expect it to work without having to access an install disk for the drivers.

I read your post most carefully, and your pleas.
All good stuff, and I do sympathise.
But the history of Puppy tells me that Playdayz has got it in few words, viz:
There are only two rules:
1. Puppy (at this stage) aims for 128 mb for reasons stated by Playdayz
2. Puppy needs no other rules

Please believe me when I say this is no criticism.

Chairman Mao said "let a hundred flowers bloom" Or was it Confucious?
I forget who said "one only needs one prize pumpkin"
ATVB (all the very best)

re size of "base" puppy:
puppy _can_ be as small as 5 mb by doing the following:
clean up the initrd
build in kernel modules that are in the initrd where possible
(goingnuts did this with a lot of modules in pupngo)
use a xz compressed kernel with the initramfs included
(for development versions just use an xz compressed initrd)
don't gzip files in a xz compressed filesystem
(modules, keymaps, fonts...)
use a multicall binary for the base X apps (Xvesa, jwm, rxvt,...)
(see recent discussion in the pupngo thread)
linkmount the sfs on top of the initramfs _or_ a mounted save file as rootfs
(I wrote a similar linker in jwm_tools)
use a single function header for scripts (see my bashbox thread)
all the rest is stuff that gets tweaked by pupleteers anyways, why not make it easier - puplets could range anywhere from 5mb- to 5gb+ ... in other words why aim for the target, when you can hit the bullseye

cleaning up init (it has grown slow and bloated):
as of this commit we can use busybox blkid instead of guessfstype/disktype
http://git.busybox.net/busybox/commit/?id=90615a0c5c326fa3cf78fc719f7b16207f47395a
as of this commit we can use busybox lspci instead of elspci
http://git.busybox.net/busybox/commit/?id=982bc7176d04d9d3e2b40c4ddba24eab9f02dc4d
as of this commit we can use busybox timeout instead of waitmax
http://git.busybox.net/busybox/commit/?id=a9acbe6caddc59e7e25f4e469322e5c210e17775
as of this commit we can use busybox rev instead of rev
http://git.busybox.net/busybox/commit/?id=fc6f6e933c20e6016d19339ac472f6af3d05d4c3
not to mention find/xargs/cp/modutils...
find blocks can be replaced with functions that more efficiently (read faster) recurse a directory to perform various actions
xargs is only used in finding drives - I do it with only ash in jwm_tools
cp -u is not needed - just let cp fail if file exists
grep is used gratuitously and could be replace with case ... or while read VAR; do case ...
lsmod ~= cat /proc/modules (much faster b/c it is a nofork applet)
modinfo - just look in the modules.dep - that is what it does anyways
modprobe - busybox modprobe works fairly well now - past issues with subdirs
(this part is secret - dont tell anyone - you can flatten the modules into the same dir, bypass that problem and drastically shrink the modules.dep and the time to create it)
losetup - not needed by busybox mount - it auto handles loops
I could go on, but you can see the extent of it - too much for me to tackle in an afternoon (the extent of my attention span - it would be easier to start from scratch)

re size of devx:
symlink many of the duplicates (see git*, gcc...)
remove static libraries if there is a shared version (it only causes problems anyways)
also there are a lot of infrequently needed (for most users) tools that could be replaced with an alternative bit of code - for example most people only want to checkout a repository - I think amigo/bigbass? posted some bits a while back that did this for several version controls (thread?)_________________Web Programming - Pet Packaging 100 & 101

Edit oops I realize now that my post can be seen in bad light.
I don't want to dampen your enthusiasm at all. Continue
but realize that without that inner motivation nothing happens old text follows
I can see much merit in all the contributions in this thread.
But we have to remember the most important one.

Inner motivation can not be community decided upon.
A Dev only do what the inner motivation allow them to.

As users we can have wishes and set up standards or
wish lists or preferences or faved ways how a distro
should behave but if the Dev lack the inner motivation
then there will be no change at all.

Even to write about it can damper diminish or shut off that
inner motivation. It has to come spontaneously from within.

A kind of emergent process that is a mystery to most of us _________________I use Google Search on Puppy Forum
not an ideal solution though

technosaurus I love what you and GoingNuts do with PupNgo which is truly small.

But for some of us noobs the learning curve get too steep

And it was based on puppy412? or was it 420? Anyway a kernel that
lacked the drivers that would allow certain things for newer computers
like my netbook. So it booted but then one would have to compile the driver or something.

So it seems it is too difficult to apply same idea on the modern versions.

I mean it would be great to have a PupnGo based on Lupu 528 or
preferably using pemasu retake on Jemimah drivers and RFKILL and
suc hfor puppeee so it also work on such small computers.

That would bring small and functional together._________________I use Google Search on Puppy Forum
not an ideal solution though

...
The meaningful definition should be consistent, accurate and universal; IN PUPPYLAND.
...
Male of female: SIZE matters. In my world, size=capacity.
...
The specific MB size is UN-important to me.
...
I am asking for a consistency in defining what we mean by SIZE whenever we throw the word around.
...

Now I want you to write an assignment: "Could I be satisfied with a small but highly efficient capacitor?"

having had experience with creating other linux distros, there seems to be a some mythology surrounding the disk size of an OS and its speed.

Small disk size is only of benefit to speed at boot time, IF the OS is being copied to RAM. Obviously the smaller the size the quicker it gets copied. But this is the only case. And even when you do this, a non copy to ram boot will boot faster.

Note that Puppy is not a 100mb OS, a full install will be 400mb or so on your HDD. The compression that makes Puppy 100mb when running frugal from your hdd or usb stick actually makes it slower. This is a case where shrinking something actually reduces performance.. and why? its the wow factor of a 100mb iso. Also if puppy wasnt compressed, it would be faster and still be small enough to fit on a live-cdrom.

also many people believe that being a small distro in disk size means it will use less ram, this is also not true. The ram usage is just how many programs are loaded into ram at any given time. Also it doesnt matter if you have 1TB worth of files on your partition or 80mb, it takes the same amount of time to mount the partition. A 1TB puppy would be just as fast as a 100mb puppy. Excluding copy to ram at boot.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum