Size Matters - Puppy needs standardization on this.

What features/apps/bugfixes needed in a future Puppy
Message
Author
gcmartin

Size Matters - Puppy needs standardization on this.

#1 Post by gcmartin »

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.
Last edited by gcmartin on Fri 06 Jan 2012, 00:32, edited 3 times in total.

gcmartin

#2 Post by gcmartin »

I thought i would offer this for insights:

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.
Last edited by gcmartin on Fri 06 Jan 2012, 00:33, edited 1 time in total.

User avatar
playdayz
Posts: 3799
Joined: Fri 25 Apr 2008, 18:57

#3 Post by playdayz »

IMHO there is one "objective standard" for Puppy size and that is 128MB. If a Puppy is smaller than 128MB then it will load into RAM on a computer with 256MB RAM.

Stripe
Posts: 658
Joined: Wed 23 Jun 2010, 05:18
Location: In a field. England

#4 Post by Stripe »

Hi all

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.

Cheers

Don

gcmartin

#5 Post by gcmartin »

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.

User avatar
arcanis
Posts: 84
Joined: Sun 30 Oct 2011, 22:17
Location: Columbus, Ohio

#6 Post by arcanis »

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.

Sorry if I'm just restating the obvious. Sometimes I talk too much.

linuxcbon
Posts: 1312
Joined: Thu 09 Aug 2007, 22:54

#7 Post by linuxcbon »

I can do it too.

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.

best regards

User avatar
8-bit
Posts: 3406
Joined: Wed 04 Apr 2007, 03:37
Location: Oregon

#8 Post by 8-bit »

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.

How much would again be saved by a Z.....SFS file.

jabu2
Posts: 46
Joined: Tue 08 Apr 2008, 03:19
Location: Australia

Standards, Rules, Conventions, Regulations and overkill

#9 Post by jabu2 »

gcmartin

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)

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#10 Post by technosaurus »

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/? ... 207f47395a
as of this commit we can use busybox lspci instead of elspci
http://git.busybox.net/busybox/commit/? ... ab9f02dc4d
as of this commit we can use busybox timeout instead of waitmax
http://git.busybox.net/busybox/commit/? ... c210e17775
as of this commit we can use busybox rev instead of rev
http://git.busybox.net/busybox/commit/? ... af3d05d4c3
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?)
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

nooby
Posts: 10369
Joined: Sun 29 Jun 2008, 19:05
Location: SwedenEurope

#11 Post by nooby »

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

nooby
Posts: 10369
Joined: Sun 29 Jun 2008, 19:05
Location: SwedenEurope

#12 Post by nooby »

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

User avatar
James C
Posts: 6618
Joined: Thu 26 Mar 2009, 05:12
Location: Kentucky

#13 Post by James C »

playdayz wrote:IMHO there is one "objective standard" for Puppy size and that is 128MB. If a Puppy is smaller than 128MB then it will load into RAM on a computer with 256MB RAM.
Playdayz summed it up pretty well. :)

Anyone is free to build a puplet as big as they please though.

User avatar
maxerro
Posts: 53
Joined: Sun 10 Oct 2010, 16:11

#14 Post by maxerro »

Cuts from the telenovela:
gcmartin wrote:...
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?"

User avatar
sickgut
Posts: 1156
Joined: Tue 23 Mar 2010, 19:11
Location: Tasmania, Australia in the mountains.
Contact:

#15 Post by sickgut »

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.

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#16 Post by technosaurus »

sickgut wrote: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.
[sarcasm]
And predators in the wild are not affected by other predators competing over limited resources.
[/sarcasm]
if you are going try to bust myths, please provide data and not FUD

full install - ever heard of seek/read/write times? it takes longer for programs to start up
frugal install - if SFS in RAM is large it can force swap when RAM usage gets high ... and if no swap file or partition exists it will fail
live cd - do I even have to say it?
Puppy runs in many forms - you have to consider them all

try to prove that compression in RAM actually makes it slower than reading from a hard disk - better get yourself a really old cpu and a really fast hard disk

Being a small distro doesn't directly make puppy use less RAM, carefully selecting packages that are both small _and_ based on minimal dependencies that use less resources does.

The number of programs running is not directly related to RAM usage
I can load 1000 programs into RAM and use less resources than 10 other programs - dependencies matter. Loading a 10kb fltk program, a 10kb Fox toolkit program a 10kb QT3 program a 10kb SDL game and a 10kb kde4 program can use more resources than 1000 instances of a 10kb gtk+ program

Using 128MB as some arbitrary line is ridiculous though, start with a base system and carefully select, add and tweak the programs that provide your desired user experience. If you need 140Mb of RAM for your main app + 32Mb for system processes and want it to run in pfix=ram on a box with 256Mb, then your limit would be 84Mb. Don't just pick a number and pray that it works, based on some random thumb rule with no basis. Which reminds me, pet packages need an extra field(s) for resource usage in the pet.specs file.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

gcmartin

#17 Post by gcmartin »

Thanks to all who have taken a moment to add comments. It shows what I was getting at.
keep in mind that this shows a dialogue about SIZE. Taking all accounts, to date, we get a perspective of why I started this.

There are lots of perspectives being present here. Now we begin to see when someone says "SIZE" what comes to mind.

Further, when a distro producer creates their distro, some/many distro owners have taken a moment to give a perspective on the size of the ISO. Some others go further, and take a moment to share what RAM they recommend the PC to have.

I just trying to present a picture that when any distro is presented, it would be useful when it is presented to tell us what they intend it be; from a size-wise perspective. And, it would be very effective if it followed something consistent. This way, everyone knows to look for it and everyone knows what it means.

This is why I shared, earlier, that a simple table presented with each distro, would go a long way in presenting some good useful information for the testers, and users of the distros.

I present a table, again, just to ask, what would be wrong with a table that would be our reference to size.

I ask:
  • Does a simple table inhibit the creativity of the distro owners or PET/SFS developers?
  • Can a simple table hurt anyone's effort in using what this community produces?
  • Would a simple table allow an awareness of what the product is going to be using?
I saw one reference that implies that standards stifle development??? This is not true and never was true. From an "idea", standards provide a framework...and an understanding.

So using an arbitrary example for what several have mentioned, review this table below, and offer ideas. I'm trying to reference quality measurement, quality data and simple reference to the multiple, yet differing ideas of what size is. With a table, it no longer is this "gooey" thing, its has a framework for understanding. And, it would have good reasoning that associates with it.

As one other member has pointed out, size has NOTHING to do with quality of one product versus another. NOTHING!!! So because one may be larger or smaller does not mean one is better than the other. (This to me is a comparison of one human size to another human's size. Each of them bring a contribution....which to me is the important part. I can build/set their office space to accommodate their size.).

There are lots of reasons why something as common as a table would be useful? At best, it would offer extreme clarity.
Attachments
Size table for review.png
This is a Sample idea. Needs community to contribute. It an example of 1 distro showing his table. And a 2nd distro is showing its table.
(47.42 KiB) Downloaded 1020 times

User avatar
sickgut
Posts: 1156
Joined: Tue 23 Mar 2010, 19:11
Location: Tasmania, Australia in the mountains.
Contact:

#18 Post by sickgut »

technosaurus wrote:
sickgut wrote: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.
[sarcasm]
And predators in the wild are not affected by other predators competing over limited resources.
[/sarcasm]
if you are going try to bust myths, please provide data and not FUD

full install - ever heard of seek/read/write times? it takes longer for programs to start up
frugal install - if SFS in RAM is large it can force swap when RAM usage gets high ... and if no swap file or partition exists it will fail
live cd - do I even have to say it?
Puppy runs in many forms - you have to consider them all

try to prove that compression in RAM actually makes it slower than reading from a hard disk - better get yourself a really old cpu and a really fast hard disk

Being a small distro doesn't directly make puppy use less RAM, carefully selecting packages that are both small _and_ based on minimal dependencies that use less resources does.

The number of programs running is not directly related to RAM usage
I can load 1000 programs into RAM and use less resources than 10 other programs - dependencies matter. Loading a 10kb fltk program, a 10kb Fox toolkit program a 10kb QT3 program a 10kb SDL game and a 10kb kde4 program can use more resources than 1000 instances of a 10kb gtk+ program

Using 128MB as some arbitrary line is ridiculous though, start with a base system and carefully select, add and tweak the programs that provide your desired user experience. If you need 140Mb of RAM for your main app + 32Mb for system processes and want it to run in pfix=ram on a box with 256Mb, then your limit would be 84Mb. Don't just pick a number and pray that it works, based on some random thumb rule with no basis. Which reminds me, pet packages need an extra field(s) for resource usage in the pet.specs file.
i refered to everything BUT copy to ram. There is no comparison between running in ram or not, just running from disk. if you ready my post more carefully you will see this.

you also speak in a very general manner, while asking that i supply specs. Do you see how pointless it is when you start on that circle... if you are trying to debunk my myth then, how about providing evidence about what you posted regarding your 1000 instances in RAM, instead of just providing FUD?

all im getting at is it doesnt matter how physically large puppy is on a disk.. it has nothing to do with ram usage or other speed related performance issues. A normal unmodified bloated debian live setup with a 3gb live DVD will actually boot and run with no swap with 64mb of ram. Puppy needs 128mb to run live cdrom yet its only a 100mb or so .iso ... size here has no effect on ram usage in puppy or any other linux.

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#19 Post by technosaurus »

sickgut wrote:all im getting at is it doesnt matter how physically large puppy is on a disk.. it has nothing to do with ram usage or other speed related performance issues. A normal unmodified bloated debian live setup with a 3gb live DVD will actually boot and run with no swap with 64mb of ram. Puppy needs 128mb to run live cdrom yet its only a 100mb or so .iso ... size here has no effect on ram usage in puppy or any other linux.
yes it does, you are trying to oversimplify it. The table really needs to have different requirements for each pupmode... the requirements for each varies and some _do_ depend on size. Sure if puppy wasn't puppy then you'd be 100% correct, but fortunately it is.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

Master_wrong
Posts: 452
Joined: Thu 20 Mar 2008, 01:48

#20 Post by Master_wrong »

@gcmartin
As one other member has pointed out, size has NOTHING to do with quality of one product versus another. NOTHING!!! So because one may be larger or smaller does not mean one is better than the other. (This to me is a comparison of one human size to another human's size. Each of them bring a contribution....which to me is the important part. I can build/set their office space to accommodate their size.).
the iso is not the problem, the problem is wether you use savefile or not ?
if you use save file... then ram is no problem, if you dont then you need more ram to copy iso into ram.

A normal unmodified bloated debian live setup with a 3gb live DVD will actually boot and run with no swap with 64mb of ram. Puppy needs 128mb to run live cdrom yet its only a 100mb or so .iso
i say... good luck using that dvd drive for that debian, because you cant just eject the dvd...
puppy need the ram so can use the dvd drive.
Cluster-Pup v.2-Puppy Beowulf Cluster
[url]http://www.murga-linux.com/puppy/viewtopic.php?p=499199#499199[/url]

Post Reply