Puppy Linux Discussion Forum

mikeslr wrote: Tue May 07, 2024 11:14 pm

CD, DVD, USB-Stick

Maybe it's time to reorder or even drop this list, most Puppy users that boot from removable media probably use a flash drive. Many don't have an optical drive, and some have one but never use it.

mikeslr wrote: Tue May 07, 2024 11:14 pm

These require little or no RAM when not in use.

This is inaccurate, an application that sits in a 5 MB SFS that got copied to RAM at boot time causes extra 5 MB of RAM usage even when the application is not running. Different tools count "used" memory differently (without page cache and other reclaimable memory, only RSS, by total mapped pages, ...) so some will agree with this statement and some won't. IMO better remove it.

The RAM consumption of an external AppImage or portable having a menu entry is that of the text file in /usr/share/applications/, a pixmap, and maybe a symlink., Little.

The minimum requirement for most Puppys is now 2 Gb = 2048 Mb
5 Mb / 2048 = .2% = little.

Several years ago I tested the ram consumption of LibreOffice, loaded but not in use. IIRC, it was 37. Today, maybe, 75. 75/2048 = 3.7%, well really not very much and it would be in RAM-Cache. Remember how effectively Puppys handle RAM.

But you're right: it would be more accurate to say that an Unloaded SFS consumes no RAM. Was trying to paint a generally accurate picture using few words. Don't know how much space DistroWatch allows; so did not distinguish between those portables.

With the general description of Puppy being a separate page from that of BookwormPup64, will make the distinction.

I'd leave in mention of CD & DVD. Only a couple of words. And while most users no longer have need for them, the Beginner's Section still gets questions about their use; and a couple 'old hands' still swear by their use as a security measure.

mikeslr wrote: Wed May 08, 2024 2:23 pm

Unloaded SFS

mikeslr wrote: Wed May 08, 2024 2:23 pm

5 Mb / 2048 = .2% = little.

Yes, a *mounted* SFS doesn't add much to RAM consumption, if this SFS sits on disk. But if the SFS is copied to RAM by initrd and it's 4 GB on disk, then it's going to eat 4 GB of RAM (the size of the SFS) even if the applications inside the SFS are unused. This memory can't be freed without rebooting and configuring pfix=nocopy or removing this SFS from the queue.

I understand that you don't aim for 100% accuracy, but I think it's a bit weird to announce that copying of SFSs to RAM (one of the major features of Puppy, something users see during Puppy's slow boot) doesn't consume RAM. Some think Puppy is a 'toy distro' built by amateurs, and weird claims in a release announcement are a great reason not to use a distro.

mikeslr wrote: Wed May 08, 2024 2:23 pm

Remember how effectively Puppys handle RAM.

Same way as other distros, nothing special here.

mikeslr wrote: Wed May 08, 2024 2:23 pm

I'd leave in mention of CD & DVD. Only a couple of words.

So maybe move these words? Start with flash drives, mention other media later.

@dimkr You're right. I wasn't taking into consideration what I've often referred to as 'alphabet' SFSes, e.g. ydrv.sfs; only 'application' SFSes, e.g. LibreOffice.sfs. Or distinguishing those from the mounting of a SaveFile, e.g, puppy_version_#-save.sfs. And, of course, the puppy_version_#.sfs --the core/base containing the file-and-window managers, and the dev's choice of applications-- is, itself, only an SFS.

Examining what other Distros have done, what I referred to as the 'the advert' is of the nature of a 'mission statement'. Providing a 'mission statement' which is succinct, will be understandable to the general public and accurate about a family of operating systems as diverse and flexible as Puppys is proving to be elusive. I spent much of yesterday mulling that over; approaching it from different angles. Even before I read your last post, your previous critique may have jogged one of my few remaining brain cells.

Correct me if I'm wrong. I think Puppy's modularity and the variety of ways by which a base puppy can be enhanced such as (1) by installing applications into one module (the SaveFile/Folder), (2) addition of modules –alphabet or application-- or (3) modification of those modules depends on that Puppy's use of either AUFS or Overlays. When AUFS is employed, whether a module is copied into RAM or merely mounted, what modules are copied into RAM at boot-up, the number of additional modules which can be employed and whether they can be loaded and unloaded on-the-fly depends of the configuration/coding of initrd. I assume that is also true when Overlays are used. But you know what they say about assumptions.

At any rate, my current thinking is that the mission statement has to make note of Puppys extensive use of either AUFS or Overlays and provide a few examples (without getting into the technicalities of AUFS and Overlays, which newbys won't care about and the experienced will either know or can discover). Those examples can note the effects on RAM usage.

Suggestions for a technically accurate statement of Puppy's use of AUFS or Overlays would be appreciated.

How does employment of a SaveFolder and/or AppImage –these are only mounted-- fit in?

The save folder directory is mounted and added as the top layer of the file system stack. It is treated like a read-write drive. Appimages are executed programs that are self contained. They are packaged along with all the needed components needed to run.

From Wiki:

AppImage (formerly known as klik and PortableLinuxApps) is an open-source format for distributing portable software on Linux. It aims to allow the installation of binary software independently of specific Linux distributions, a concept often referred to as upstream packaging. As a result, one AppImage can be installed and run across Ubuntu, Arch Linux, and Red Hat Enterprise Linux without needing to use different files. It aims to be a format that is self-contained, rootless, and independent of the underlying Linux distribution.

Thanks for the quick reply. Have some 'real world' stuff to do. Will pick this up when I get back. In the meantime, would appreciate from anyone the suggestions for a technically accurate statement of Puppy's use of AUFS or Overlays.

Getting too deep in the weeds.

Again the statement on the Puppy Linux section needs to be general type info.

Not the technical how it does it.

What it can do not how it does it.

distrowatch present statement wrote:

Puppy Linux is yet another Linux distribution. What's different here is that Puppy is extraordinarily small, yet quite full-featured. Puppy boots into a ramdisk and, unlike live CD distributions that have to keep pulling stuff off the CD, it loads into RAM. This means that all applications start in the blink of an eye and respond to user input instantly. Puppy Linux has the ability to boot off a flash card or any USB memory device, CDROM, Zip disk or LS/120/240 Superdisk, floppy disks, internal hard drive. It can even use a multisession formatted CD-RW/DVD-RW to save everything back to the CD/DVD with no hard drive required at all.

Maybe all that is needed is to update type of storage device it can be installed on to boot the computer.

Puppy Linux has the ability to boot off a flash card or any USB memory device, CDROM, Zip disk or LS/120/240 Superdisk, floppy disks,

Change this to:

Puppy Linux has the ability to install on and boot off any device a computer can boot from. CD/DVD, USB flash drive, Hard drive(internal or external), SD card, or SSD drive (internal or external.

Maybe add something like this:
Can be a live install or a special type called frugal, that is all of Puppy OS inside a folder. This folder can be placed any location, even inside another operating system install.
Any changes or additions are stored in a save file or folder.

The specific info statement, about a specific Puppy version, can get into technical info about it, but still not too weedy!

SFSs consume RAM not because they're added to the aufs/overlay stack, but because initrd copies the SFS from disk to a tmpfs in RAM (and then mounts the copy). It's not squashfs, aufs or overlay that do this copying, but initird (unless you specify pfix=nocopy). If mounted directly from disk without this copying, the extra mounted SFS consumes a negligible amount of memory.

In a laptop with 2 GB of RAM, you don't have much RAM available for use if SFSs are copied to RAM, especially with a full-featured modern Puppy. If you have swap, you're probably using it 100% of the time.

I think it's time to disable this copying by default, for 3 reasons:
1. Puppy is getting bigger, hence this copying consumes more and more RAM in computers that can't be upgraded
2. With a SSD, the performance gain from this copying is negligible and it's a waste of RAM
3. This RAM is probably better spent by the browser and other modern applications

dimkr wrote: Thu May 09, 2024 4:33 pm

...I think it's time to disable this copying by default, for 3 reasons:
1. Puppy is getting bigger, hence this copying consumes more and more RAM in computers that can't be upgraded
2. With a SSD, the performance gain from this copying is negligible and it's a waste of RAM
3. This RAM is probably better spent by the browser and other modern applications

I am in agreement of the points.

Yet, I think this understanding should accompany those points

1. Some SFSs, Appimages as well, are subsystems that run often in the use of the system.
   Distro publishers, in and out of the forum, ARE posting suggestions to users a recommended platform for their offerings when presented to the community. This I feel is helpful to potential uses.

2. SSDs are fast, but we dont have any measurements of the performance difference between of reading programs for execution from SSD via PCI-bus/USB-port versus reading via the Linux I/O subsystem when the programs are in RAM.

3. It would be nice if we had measurements of RAM subsystems use differences when all OS programs are run from system disk versus when the necessary subsystems are resident in RAM for applications to use. To date, I know of no such capacity tests done in the forum community. Seems obvious, but without data, well ???

Just a few thoughts

Clarity wrote: Fri May 10, 2024 4:40 am

It would be nice if we had measurements

Here you go, try this:

cat << EOF > /tmp/1.c
int main() {
	for (unsigned long have = 0; ; have += 4*1024*1024) {
		void *a = malloc(4*1024*1024);
		memset(a, 0, 4*1024*1024);
		printf("allocated %zu\n", have);
	}
	return 0;
}
EOF
gcc /tmp/1.c -o /tmp/1
swapoff -a
/tmp/1

It's a simple program that allocates memory in 4 MB chunks and prints the number of bytes it was able to allocate. It clears the allocated memory because memory allocations are "free" until you use (write to) the allocated memory.

I ran it on a machine with 2 GB of RAM with Vanilla Dpup 10.0.52. This Puppy consumes around 200 MB of RAM on this machine on first boot, before I open any applications. I have several GBs of swap, so the program can allocate way more memory than available RAM, therefore I ran it with swap disabled.

The total size of *.sfs is 851 MB, so I'd expect RAM available for use by applications to increase by about 851 MB if copying of SFSs to RAM is disabled (not the default). If SFSs are copied to RAM, they must consume RAM, right?

With pfix=copy or without any pfix= (default is to copy), it stops at 901775360 (this program is able to allocate only 0.9 GB of RAM). This is very close to 2 GB, minus 200 MB (total RAM consumption before I started this program) minus 851 MB (total size of SFSs).
With pfix=nocopy, it stops at 1790967808 (this program is able to allocate 1.79 GB of RAM). This is very close to 2 GB minus 200 MB, hence copying SFSs to RAM increases total RAM consumption by their size.

I think it would be enough to say that Puppy uses a layered file system, without going into details like which one, and definitely without claims about Puppy's RAM consumption.

We also need to make changes here: https://www.tecmint.com/linux-distribut ... computers/

tosim wrote: Fri May 10, 2024 3:54 pm

We also need to make changes here: https://www.tecmint.com/linux-distribut ... computers/

That opinion article was posted in 2014! If the site hasn't updated it, that's on them, not us. Last "reply" was in 2021...

Wiz57 wrote: Fri May 10, 2024 5:13 pm

tosim wrote: Fri May 10, 2024 3:54 pm

We also need to make changes here: https://www.tecmint.com/linux-distribut ... computers/

That opinion article was posted in 2014! If the site hasn't updated it, that's on them, not us. Last "reply" was in 2021...

within the article it is mentioned

The latest version of Anti X is version 23.1 and was released in February 2024.

tosim wrote: Fri May 10, 2024 3:54 pm

We also need to make changes here: https://www.tecmint.com/linux-distribut ... computers/

you will never find a review article about Puppy Linux, that will be very good.

No one seems to really understand Puppy Linux.

If they even get close to correct information, that seems to be about all you can ask.

We had one person, actually post on this forum, and asked us to provide information for them to use.

That was the closest to a good review of Puppy Linux, I have ever read.

Keep in mind that a review based on one specific Puppy version, is nothing but a review of that Puppy version.

No two Puppy versions are exactly the same.

I am just happy that people include Puppy Linux in these type reviews of Linux OS's.

dimkr wrote: Thu May 09, 2024 4:33 pm

SFSs consume RAM not because they're added to the aufs/overlay stack, but because initrd copies the SFS from disk to a tmpfs in RAM (and then mounts the copy). It's not squashfs, aufs or overlay that do this copying, but initird (unless you specify pfix=nocopy). If mounted directly from disk without this copying, the extra mounted SFS consumes a negligible amount of memory.

In a laptop with 2 GB of RAM, you don't have much RAM available for use if SFSs are copied to RAM, especially with a full-featured modern Puppy. If you have swap, you're probably using it 100% of the time.

I think it's time to disable this copying by default, for 3 reasons:
1. Puppy is getting bigger, hence this copying consumes more and more RAM in computers that can't be upgraded
2. With a SSD, the performance gain from this copying is negligible and it's a waste of RAM
3. This RAM is probably better spent by the browser and other modern applications

EasyOS makes the decision in the initrd whether to copy sfs's to ram based on this:

FREEK=`grep '^MemFree:' /proc/meminfo | tr -s ' ' | cut -f 2 -d ' '`

Then applies an algorithm, considering media speed (SSD or HDD) also.

@dimkr :-

dimkr wrote: Thu May 09, 2024 4:33 pm

SFSs consume RAM not because they're added to the aufs/overlay stack, but because initrd copies the SFS from disk to a tmpfs in RAM (and then mounts the copy). It's not squashfs, aufs or overlay that do this copying, but initird (unless you specify pfix=nocopy). If mounted directly from disk without this copying, the extra mounted SFS consumes a negligible amount of memory.

In a laptop with 2 GB of RAM, you don't have much RAM available for use if SFSs are copied to RAM, especially with a full-featured modern Puppy. If you have swap, you're probably using it 100% of the time.

I think it's time to disable this copying by default, for 3 reasons:
1. Puppy is getting bigger, hence this copying consumes more and more RAM in computers that can't be upgraded
2. With a SSD, the performance gain from this copying is negligible and it's a waste of RAM
3. This RAM is probably better spent by the browser and other modern applications

'Kayyy..... Alright; I'm officially 'curious' now (and I'm certainly no expert here, believe me).

So; what is in fact the most resource-efficient method for running ANY modern app - be it browser, multimedia, a graphical application, whatever - on a 'constrained' device (low RAM, small storage device, etc, etc.)?

Fully-installed? "Loaded" from SFS? Or sitting outside the save, as is the case with the 'portable' apps?

Like you say, ANYTHING you run on a 'puter will use RAM. That's what the stuff is THERE for, after all....but which is actually the most efficient way to use it?

Mike.

mikewalsh wrote: Sat May 11, 2024 12:14 pm

Like you say, ANYTHING you run on a 'puter will use RAM. That's what the stuff is THERE for, after all....but which is actually the most efficient way to use it?

That depends on how you define efficiency, because you can't have it all.

Want low RAM usage? Keep your applications outside of RAM (not inside a SFS that's copied to RAM, not in /tmp, etc') and not in compressed format (so they don't need to be decompressed into a separate region in RAM). The tradeoff is disk space, startup time of applications (because reading from disk is slower than reading from RAM) and possibly slowness at runtime (for example, when an application loads a plugin, an icon or something else from disk).

Want low CPU usage? Don't compress (don't put them inside a SFS) or encrypt (put inside an encrypted directory/file system/partition/volume) your applications and the files they write to, and avoid use of swap (limit RAM consumption, lower swappiness, and avoid use of compressed swap like zram). This comes the cost of disk space and probably RAM (because page cache contains bigger, uncompressed files, and less pages in swap means more pages in RAM), overall system stability and even high risk of data loss (no swap means applications can crash when you're low on RAM).

Want low disk space? Compress everything, preferably within one file (so identical chunks in many files are deduplicated), at the cost of CPU and RAM.

(In my dpup builds, when I have to choose, I trade bigger size for lower RAM usage and lower CPU usage. Space efficiency is the least important kind of 'efficiency' because storage is cheap and upgradable, while CPUs are rarely upgradable or worthwhile to upgrade, and most computers have non-upgradable RAM or a hard limit they reach after one upgrade. And most storage comes in multiples of GB or TB, so if you have enough space for a 300 MB Puppy, you probably have enough space for a 1 GB Puppy, even if this a 2010 netbook.)

BarryK wrote: Sat May 11, 2024 8:04 am

EasyOS makes the decision in the initrd whether to copy sfs's to ram based on this:

Code: Select all

FREEK=`grep '^MemFree:' /proc/meminfo | tr -s ' ' | cut -f 2 -d ' '`

Then applies an algorithm, considering media speed (SSD or HDD) also.

Puppy has a similar formula and it prioritizes SFSs if RAM is too low (see https://github.com/puppylinux-woof-CE/woof-CE/pull/3783).

Future dpup builds of mine (see https://github.com/vanilla-dpup/woof-CE ... onsumption) add even more 'efficiency' improvements:
1. This copying is disabled by default if booting from a SSD (very little observable difference when booting from my 9 years old, relatively slow SATA SSD) - the downside is that you can't unplug the flash drive you're live booting from
2. There's no copying really - instead, the SFSs are locked into page cache
3. This locking happens in the background with low priority, while the boot process continues (much faster boot) and if the boot media is super slow it continues while you're already in your graphical desktop and doing your stuff
4. If running low on RAM, the processes that hold the SFSs cached in RAM volunteer to release this memory, it's a win-win situation: SFSs stay in RAM if you have enough RAM, otherwise this RAM is freed automatically and it's not 'reserved'

@dimkr @BarryK
My approach was very different. I just set the minimum ram requirements in order to copy SFS to RAM. It will not copy to RAM if the RAM installed on target PC was below minimum ram requirement

the downside is that you can't unplug the flash drive you're live booting from

That is a feature that some people want to have.

@dimkr :-

Thanks for the 'explainer'. Much appreciated.

My two devices fall at pretty much opposite ends of the scale. The main desktop rig has a relatively powerful CPU, buckets of RAM (32 GB DDR4) and so much storage it may seem ridiculous to some (5 TB+). In that respect, for a Puppy user, I'm pretty atypical.......although over the last decade, I have noticed many of our regulars are also utilising much more capable hardware than they were a decade ago. Natural enough, I guess; tech develops over time, and in real terms prices DO drop, and a lot of gear finds its way onto the secondhand/refurb markets.

(Meaning that many of us are running far more up-to-date gear (for US, as Puppy users) even though it may still be considered 'dated' when compared to brand-new, 'cutting-edge' tech.... *shrug*)

I could run any distro I wanted on this thing.......but I like 'our Pup' too much to do that!

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The old Dell Latitude - itself pretty old, but SUCH an improvement over the even older Inspiron that finally popped its clogs the year before last - here you've got a Core2Duo, w/4GB DDR2 and a 'middle-of-the-road' 128GB LiteOn SSD (which some fool shoehorned Win 10 onto before I got hold of it from the seller on eBay!)

It's no powerhouse, though Dell always built these things like a brick outhouse.....and for its time, it was still pretty full-featured (like a wireless 'catcher' that lets you scan for wireless networks even when powered-down, an 'automatic' screen brightness sensor - which amazingly works under Linux).....stuff like that. She dual boots with Xenialpup64 and Fossapup64, with which I'm satisfied. It does what I want when I keep Mama company of an evening.

Mike.

bigpup wrote: Sat May 11, 2024 1:05 pm

the downside is that you can't unplug the flash drive you're live booting from

That is a feature that some people want to have.

Probably, but I wonder how many Puppy users actually unplug the flash drive they're booting from. They must be using Puppy without persistency, or put a save file/folder on an internal drive (so it's not 100% clear why they boot from a flash drive in first place).

In my opinion, allowing computers with 1 GB or 2 GB of RAM to run a modern Puppy comfortably (i.e. without reserving 700 MB of RAM by copying SFSs to RAM) is more important than supporting the (niche?) use case of unplugging the flash drive. In many computers, a modern (but big) Puppy can run much better than an old one, if booted pfix=nocopy, so the bigger size on disk doesn't translate into higher RAM consumption. Changing the default from "copy" to "no copy" or at least improving the formula that decides what to copy, when and how, can extend the usable service life (= ability to comfortably run a Puppy that's compatible with modern browsers?) of many old computers.

mikewalsh wrote: Sat May 11, 2024 1:56 pm

in real terms prices DO drop, and a lot of gear finds its way onto the secondhand/refurb markets.

True, but what I'm saying is, storage is super cheap, to the point size on disk is a very bad deciding factor. If you're deciding between a 300 MB Puppy with various limitations and a modern, good Puppy that suits your needs but requires 1 GB of space, don't buy a 512 MB flash drive (if you can find one these days). Even a 1 GB flash drive is enough, and the price difference between 1 GB, 2 GB, 4 GB and 8 GB is tiny.

And if you have slow hard drive that makes everything sluggish, you can get a small and cheap Chinese SSD. It won't be a quality NVMe drive, but many times faster than a spinning drive.

Puppy grows in size over time, and it's inevitable considering today's software development practices. But people blindly assume that Puppy is 'efficient' just because it's small on disk, when a modern Puppy can be much more RAM-hungry than a minimal Debian installation only because of things like this SFS copying thing. More often than not, it's so lightweight only because people measure resource consumption the wrong way

hi all

i do believe that modularity can play a role here

people are attracted to small iso size
as well as low ram and cpu use

that is why they are attracted to puppy

if you built a distro that had only a browser
and a few basic apps terminal text editor filemanager etc

but could be added to as desired with modules

the browser could be loaded into ram
and could be made as efficient as possible

and the original iso could be kept small
to be attractive to those who do not like bloatware

i think as everything gets bigger
puppy will have to look at this

otherwise just use linux mint

wanderer

wanderer wrote: Sat May 11, 2024 3:49 pm

i do believe that modularity can play a role here

Modularity is not guaranteed to reduce size, splitting one compressed archive to multiple archives can increase size. If you have files A and B, both similar to each other, A is compressed in x.tar.gz and B is compressed in y.tar.gz, the total size of x.tar.gz and y.tar.gz is bigger than the size of a z.tar.gz that contains both A and B compressed together. Most executables have identical regions, so compressing multiple executables together rather than individually or in small groups (= no modularity) allows even bigger size reduction thanks to deduplication.

In addition to increased size, modularity can increase CPU and RAM consumption. The thing that reads x.tar.gz and y.tar.gz has to decompress the regions that appear in both A and B twice.

A short and vague statement, without commitment to small size or low resource consumption, would work best.

hi dimkr

thanks for the explanation/analysis

im not really talking about how big everything will end up
add ons can be bundled into very large modules to reduce redundancies and cpu use

inevitably if you want more stuff things are going to get bigger

im talking about the initial impression of the iso

if everything is included right off the bat
the iso will eventually get so big
there wont be any distinction between puppy and the bigger distros

we already do this with browsers and dev files
the iso has the light browser but you can get a full firefox.sfs
if you want to compile something load the devx.sfs

also im assuming some people wont really want a lot of the other stuff
maybe just a browser
a minimal iso will run faster and be more manageable for more limited machines

as i said we already do it
just something to look at long term
the iso seems to be getting bigger and bigger

wanderer

wanderer wrote: Sat May 11, 2024 3:49 pm

otherwise just use linux mint

Not really.

wattOS 13 (1.4GB) is the true 'vanilla' Bookworm64 IMO.
I wanted to adopt it actually. Too bad it ain't Puppy.
(Familiarity breeds loyalty).

A few months ago I "played" with wattOS for a while; I preferred Peppermint.

I've waved goodbye to FossaPup64 9.5.
I just said "Hello" to Dim's 'vanilla' Vanilla Dpup 10.
Honestly, I felt embarrassed to see myself as an 'IT
enthusiast' when, in fact, the "I" up there is a little
outdated, like an 'Outdated Information Technology guy'.
Probably just me, myself, and I.

hi all

this is just a technical question

is a file symlinked to root

more efficient

than a file mounted to root with a layered filesystem

wanderer

wanderer wrote: Sat May 11, 2024 7:18 pm

im talking about the initial impression of the iso

Most Puppy releases use xz compression for SFSs, which has the highest compression ratio (and worst decompression speeds) out of all currently available options. Everything worth compressing in the Puppy ISO is already compressed.

wanderer wrote: Sat May 11, 2024 7:18 pm

the iso will eventually get so big
there wont be any distinction between puppy and the bigger distros

People should learn that small size doesn't guarantee low resource consumption, sometimes even the opposite. Puppy's focus should be low RAM and CPU consumption, not low disk space usage - most old computers have enough storage to for big modern software, but they're too slow to run it or don't have enough RAM to run it comfortably (without constant swapping or crashes).

My Eee PC came with a 250 GB hard drive, it can fit BookwormPup64 although it's twice as big as S15Pup. It can even fit my own dpup builds, which are the biggest among all options I tried (almost 900 MB). Guess which Puppy has lowest CPU and RAM consumption.

wanderer wrote: Sat May 11, 2024 7:18 pm

a minimal iso will run faster and be more manageable for more limited machines

My dpup builds have a small, 314MB-sized 'retro' flavor. It's way more CPU intensive, due to xz compression, lack of VA API drivers and other differences. It's small but slow. Again, assuming that small size guarantees better performance or higher CPU/RAM efficiency, is a fallacy.

wanderer wrote: Sat May 11, 2024 7:18 pm

the iso seems to be getting bigger and bigger

There's not much we can do about this. Browsers are getting bigger, the range of firmware a distro needs to provide to ensure broad hardware support is expanding, more and more applications depend on GPU acceleration (Vulkan drivers, VA API drivers) ... there will be consequences when you remove things. For example, most Puppy releases don't support Bluetooth audio, GPU-accelerated video decoding and emoji, IMO very big price to pay for smaller ISO size.

I think it's a bad strategy to advertise Puppy as a "small" distro, I believe that most users are willing to "pay" some disk space for basic features other OSs have, like Bluetooth support, and prefer something that "just works". BookwormPup64 is popular for good reasons.

Hello @wanderer and other members.

I caution at the use of words like "low ram" and "bloatware". These often are essentially meaningless and often their usage is in a negative light. I dont think we want negative light, overall.

Forum distros, in todays world, seemingly intend to be as useful to a large population of user rather than to be so small as to force use, force evaluation, force reviews, and force maintenance upon the user's OOTB experience.

Puppy continues to be a small deliverable and is many cases it the deliverable that catches new user's eyes as they venture here to evaluate the USEFULNESS of the distros on this forum.

The basic framework of products in this forum distros desktops hasn't really changed in the past decade or more. There's been new versions of products with greater features as well as replacements of some older products with similar or better features for various reason and mostly for improved behavior. All of this comes at a price in size, but the size does not necessary mean diminished operation behavior.

As @dimkr and @mikewalsh have alluded to many times in the past, BROWSERS continue to improve and morph over time for security as well as other features to support reasonable web delivers. As such, browser sizes are major users of system RAM for all of us Internet users.

Lastly, as I have continue to share, many/most of the PAST PUPs, continue to boot and operate on the old PC desktops they were designed around back in their day.

AND, many on the forum continue to misunderstand with a belief that a deliverable size translates to enormous RAM use when on the desktop. And some confuse this deliverable size as not having the intelligence to be efficient in operation(s). This has NEVER been true, yet many dont seem to know this.

Just some observations I've seen over the past days across the forum...not just here on this thread.