Puppy's big problem with woof and woof CE

[rufwoof]

I've just formed a initrd/vmlinuz pair using EasyOS 1.0.8 (4.14.91 x86_64 kernel). Around 10MB combined (4986KB initrd.xz, 5185KB vmlinuz) where that boots to cli and has mc installed (handy for file management and text editing) ... and net connects. Enough to tftp or wget or whatever from wherever ... perhaps to grab a remote main sfs, and then continue on with init to mount/switch-root that locally downloaded main sfs.

For the formation I stripped out all unused modules/drivers that otherwise would have had it up at 120MB or so. i.e. just left the sky2 module/driver as required for my eth0 hardwired connection.

'Bloat', if you want to call it that, is more a case of modules/drivers expansion to encompass a wider range of hardware.

[8Geee]

Not a coder, but I will opine this... WoofCE is a platform by which one can 'drop in' a kernel amongst other things. If one looks at older puppies, this is a great tool to keep older hardware insulated from the likes of Spectre/Meltdown and derivitives. As example I will point out sailor enceladus' Slacko5.7.1-WoofCE (kernel 3.18.135). What is considered a solid distro by 01micko is refreshed for the modern day problems mentioned above.

Its not a problem, or a bug... its a feature.

JMHO
8Geee

[p310don]

I was going to add a smartarse response suggesting to go away and use KolibriOS if you want a small OS.

The last time I used it, it was around 2mb a few years ago. It booted to a desktop in 1 or 2 seconds, and basically did nothing.

It is now 26mb, and I haven't had a successful VM boot yet. Apparently it does work much better now, but my experience is yet to see that.

So no matter what OS you look at, size growth is inevitable if you want to continue to add features and support to it.

Unfortunately, Puppy is largely not a "primary producer" of programs, so to have the mainline programs in puppy, we have to put up with size creep from outside sources.

[dancytron]

I've just formed a initrd/vmlinuz pair using EasyOS 1.0.8 (4.14.91 x86_64 kernel). Around 10MB combined (4986KB initrd.xz, 5185KB vmlinuz) where that boots to cli and has mc installed (handy for file management and text editing) ... and net connects. Enough to tftp or wget or whatever from wherever ... perhaps to grab a remote main sfs, and then continue on with init to mount/switch-root that locally downloaded main sfs.

For the formation I stripped out all unused modules/drivers that otherwise would have had it up at 120MB or so. i.e. just left the sky2 module/driver as required for my eth0 hardwired connection.

'Bloat', if you want to call it that, is more a case of modules/drivers expansion to encompass a wider range of hardware.

I imagine it would be possible to write a script that would strip out all the unused modules and drivers and then remaster the Puppy so that it would only run on one particular piece of hardware and be around 100MB smaller. But from a user point of view, what would be the practical benefit of that kind of crippled version?

[p310don]

I imagine it would be possible to write a script that would strip out all the unused modules and drivers and then remaster the Puppy so that it would only run on one particular piece of hardware and be around 100MB smaller. But from a user point of view, what would be the practical benefit of that kind of crippled version?

You could compile a kernel to be specific for your hardware, which will work, and possibly work better. But you'd lose portability (one of Puppy's many strengths). And you could strip out programs, libs and drivers you don't need to save space.

A good article is here:

https://unix.stackexchange.com/question ... nux-kernel

Right now, storage space is ridiculously cheap, with terabytes of storage for around a hundred dollars. And that is on super fast storage media. On modern hardware, Puppy with it's newfound bloat is still super quick, and takes up a miniscule percentage of the media.

If you have older hardware that can't keep up, then older Pups might be more suited.

[rufwoof]

That 10MB was high xz compression, that wouldn't actually boot (support not built into the kernel). 12MB using gzip combined initrd.gz/vmlinuz size). I've just compiled/added lynx to that however, so swollen to 14MB. mc file manager with its text editor alongside lynx web browser works well. Nice also to be able to manually craft a .html file using a relatively friendly mc editor and view it in lynx. As a test I downloaded as a bionicpup iso, 350MB in 40 seconds.

[s243a]

That 10MB was high xz compression, that wouldn't actually boot (support not built into the kernel). 12MB using gzip combined initrd.gz/vmlinuz size). I've just compiled/added lynx to that however, so swollen to 14MB. mc file manager with its text editor alongside lynx web browser works well. Nice also to be able to manually craft a .html file using a relatively friendly mc editor and view it in lynx. As a test I downloaded as a bionicpup iso, 350MB in 40 seconds.

Are you sure it was the kernal that lacked support for xz compression rather than the initrd. I say this because I was playing with stemsee script to build a kernal and the initrd seemed to load as well as the xz compressed kernel, but the other sfs that was generated with the kernal (containing firmware or kernal modules) wouldn't load because xz compression wasn't supported for sfs files.

[rufwoof]

Are you sure it was the kernal that lacked support for xz compression rather than the initrd. I say this because I was playing with stemsee script to build a kernal and the initrd seemed to load as well as the xz compressed kernel, but the other sfs that was generated with the kernal (containing firmware or kernal modules) wouldn't load because xz compression wasn't supported for sfs files.

Could well be (I just assumed without actually looking). In practice I'm just leaving the initrd as-is (non compressed, 22MB). I only quickly xz'd and gz'd it to get some filesize figures and noticed that the xz version didn't actually boot.

[musher0]

Hello all.

Another avenue to keep Puppy small would be to use as many on-line apps /
services as possible, instead of having them on-board. E.g. petihar's Triton 6.0.
(He was not the first, BTW, to take a Puppy down this path.)

Not that I totally agree with this approach, with all due respect to petihar's
competent work. However, some on-line apps are now as mature as on-board
apps, and in some cases, better. E.g. SpellCheckPlus, which, IMO, is much
more sophisticated and user-centered than HunSpell or aspell.

The give-and-take of this approach is that the user needs a powerful browser.
Will the space gained by not having (e.g.) abiword and gnumeric locally be
canceled out by needing firefox or vivaldi to be able to connect to (e.g.) the
SOHO on-line suite? Food for thought, isn't it?

BFN.

[oui]

years ago, the creators of tiny linux distributions did only take care don't to install an avoidable mixture of heavy box packages like QT for only one use (we are GNOME Office users excepted for Gnome web, and have no realistic other choice in small iso's), divers versions of webkits for divers app's (a lot of app's, not only browsers, require today a specific webkit version, often all different, as graphic base) at the same time, or, now, qtwebengine, or KDE or other runtimes heavy stuff and dependencies over that! the increase of size is really dramatic if you don't care of that! if you renounce, the user stay free to add more as heavy he wants through ppm if he really needs that and remaster his heavy special version (*1 ! a lot of puppy stuff is not really used by all, don't forget that... and the trend is to develop not really necessary enthusiasm for new heavy stuff so special that common user have only small profit of it! each window manager different from JWM brings sacrifices of size (better would be SFS to bind, or not, over JWM) !

(*1 next profit is that you generally have no real overview which dependencies you can remove. if all app's would be use the same graphic base, if you remove ONE app, you can admit that the other continue to need all dependencies and can friendly forget to uninstall the dependencies of that app...

[dancytron]

years ago, the creators of tiny linux distributions did only take care don't to install an avoidable mixture of heavy box packages like QT for only one use (we are GNOME Office users excepted for Gnome web, and have no realistic other choice in small iso's), divers versions of webkits for divers app's (a lot of app's, not only browsers, require today a specific webkit version, often all different, as graphic base) at the same time, or, now, qtwebengine, or KDE or other runtimes heavy stuff and dependencies over that! the increase of size is really dramatic if you don't care of that! if you renounce, the user stay free to add more as heavy he wants through ppm if he really needs that and remaster his heavy special version (*1 ! a lot of puppy stuff is not really used by all, don't forget that... and the trend is to develop not really necessary enthusiasm for new heavy stuff so special that common user have only small profit of it! each window manager different from JWM brings sacrifices of size (better would be SFS to bind, or not, over JWM) !

(*1 next profit is that you generally have no real overview which dependencies you can remove. if all app's would be use the same graphic base, if you remove ONE app, you can admit that the other continue to need all dependencies and can friendly forget to uninstall the dependencies of that app...

Other than the browser, abiword and gnumeric, the graphics card drivers, wireless card drivers, and llvm, what would you propose to remove from Puppy?

Taking that list of things you propose to remove, would they even total more than 10 megabytes?

[s243a]

years ago, the creators of tiny linux distributions did only take care don't to install an avoidable mixture of heavy box packages like QT for only one use (we are GNOME Office users excepted for Gnome web, and have no realistic other choice in small iso's), divers versions of webkits for divers app's (a lot of app's, not only browsers, require today a specific webkit version, often all different, as graphic base) at the same time, or, now, qtwebengine, or KDE or other runtimes heavy stuff and dependencies over that! the increase of size is really dramatic if you don't care of that! if you renounce, the user stay free to add more as heavy he wants through ppm if he really needs that and remaster his heavy special version (*1 ! a lot of puppy stuff is not really used by all, don't forget that... and the trend is to develop not really necessary enthusiasm for new heavy stuff so special that common user have only small profit of it! each window manager different from JWM brings sacrifices of size (better would be SFS to bind, or not, over JWM) !

(*1 next profit is that you generally have no real overview which dependencies you can remove. if all app's would be use the same graphic base, if you remove ONE app, you can admit that the other continue to need all dependencies and can friendly forget to uninstall the dependencies of that app...

Other than the browser, abiword and gnumeric, the graphics card drivers, wireless card drivers, and llvm, what would you propose to remove from Puppy?

Taking that list of things you propose to remove, would they even total more than 10 megabytes?

I don't know. Maybe some of the stuff that oui listed could be moved to the adrive.

[oui]

Other than the browser, abiword and gnumeric, the graphics card drivers, wireless card drivers, and llvm, what would you propose to remove from Puppy?

Taking that list of things you propose to remove, would they even total more than 10 megabytes?

that is not really the question! 666philb and jamesbond did explain how the size can grow if you compare with very old versions

but there is a difference between very old and relatively recent versions!

BK did try and did have success (in making) and die show us how he can shrink the usual stuff of Puppy under 100 Mb. but he didn't have success in showing us

excepted with Slacko 5.3 perhaps (also about 100 Mb, a little more, but it was a real Puppy, not an experimental Racy / Wary).

if you take ONE app on board with only one webkit as dependency on board, you have automatic 50..60 Mb more ballast . have you 3, and all a different webkit or somewhat equivalent then you have 3 x 50 .. 60 Mb ballast. one real big space-eater seems be for ex. VLC...

the problem is also not if

- you spare an application and publish without this kind of application

but if

- you select a sufficient application better with small number of supplementary dependencies...

it would be nonsens for ex. to sacrifice didiwiki, an old companion of puppyist, and win only a few bites...

but the difference between Slacko 5.3 and new versions is certainly not only a matter of growing all the sources...

[musher0]

@s243a
Euh... isn't the adrv a part of Puppy !?

@oui
One thing I think we can do is use ffplay / avplay to the fullest, with various scripts
for audio and video. That way we do not need to have any big media app on board,
such as mpv, mplayer or vlc. Those are typically 20 to 40 Mg in size. We could still
offer them as sfs options instead of having them on board.

Also, please note, about the webkit: it requires the llvm library. If you flush the llvm
library, forget the webkit and any browser based on it.

IIRC, 01micko was able to achieve a 100 Mb Puppy with his slacko-5.3.3 because
just about that time the author of squashfs incorporated the xz compression in it,
and 01micko seized the occasion. So that 100 Mb is somewhat artificial.

@all
I think trying for a 100Mg Puppy has become unrealistic. Although offering a skin-
and-bones Puppy may demonstrate a dev's competence, I believe that users want
some "flesh and muscle" in their Pup. They want to be able to do a number of
things daily with it, and that requires a Puppy that has been intelligently populated.

Is Puppy in a diet contest with any other distro? IMO, the "Hey, look, my distro is
more anorexic than yours" line of thought is childish. It is also dangerous in that
users may stop being interested in us if they perceive that PuppyLinux devs are
obsessed with small size, and it is our only concern.

I say, let's try our best to come up with a concise distro, but if users require this or
that app, let's give it to them. We devs are also users, aren't we?

Feeling constricted is no fun for anyone. If users do not find an app they need in
Puppy OOTB, they'll go elsewhere and adopt a distro that offers it.

I hope the above contributes to the discussion. BFN.

[tallboy]

I have great troubles finding a replacement for my Lucid 5.2.8.7 (no, please, I am NOT asking for alternatives here!). My feeling is that one of the things that all recent Puppys have in common, is that the original idea from BK was lost somewhere along the way. Puppy was designed to run from a CD or DVD, later from a memory stick, and not installed to a HDD. Just stuff the CD into a Windoze PC and boot it! The choice when running from a CD, was either as a live multisession or as a frugal install. The late Pupys are still not recommended to be installed to a HDD, but many of them are designed to run in frugal mode only. The option to save to a multisession CD is gone, lost somewhere in woofland, because the same woofCE solution is used for all of them. I have a lot of old PCs that still work flawlessly, exept for the OS. I dislike the idea of scrapping them. Puppy made it possible to run them, but that option is slowly disappearing. Remastering late Puppys to keep the size down - for use on old and low memory PCs - is made difficult by the steadily increasing size of the necessary programs and their deps and updates. If I need some "flesh and muscle" from my PC, I boot my 4 Gb Debian. I takes some time to boot, and I cannot use many programs at the same time, but they are bristling with muscles. That is not what a Puppy is made for.
And regarding size: My ancient Macs used the office pack Claris Works, which was 690Kb installed...

[ITSMERSH]

@Tallboy

There's still Plop Bootmanager to boot old Computers from CD and then to choose another boot option from the Plop Menu. That way e.g. one can boot from USB flash drive on very old computers.

And for the RAM one can boot pfix=nocopy. The .sfs is not copied to ram that way.

[musher0]

Hello TallBoy.

Twelve-year old i686's have room for up to 2 Gb's of RAM. MSI even advertised that
one of their motherboards could harbor 3 Gb's of RAM provided the three RAM sticks
were of the same make.

Can you not combine 2-3 RAM sticks on your main computer? That way, you could
perhaps adopt a more recent Puppy? (Just an idea.)

@all:
I understand wanting to have a Puppy that is concise, that tries not to include two apps
that do generally the same thing. But I do not understand oui's and some other
people's obsession with anorexic Puppies.

This discussion up to now has not suggested anything that a serious Puppy dev is
not doing already. E.g., the new DPupBuster does NOT have: abiword, gnumeric,
claws-mail, hex-chat. What else could be chopped off? mpv?

In another thread, oui is suggesting CLI apps to bring down still more the size of the Pups.
I like using urxvt, Midnight Commander, less. But only CLI apps? Hmm. There are
reasons why OpenOffice is a GUI app: ease and speed of use come to mind.

For the rest, I can't see what emotion people are venting by insisting that their Puppies be
anorexic. Something along the lines of "I'm fat, so my Linux has to be slim?" Who
knows?

A very pretty, 5'7" tall, fashion model looks in the mirror and is completely convinced that
she is fat at 110 lbs. Similarly some Puppy users look at their nice-looking, high-
performance, Linux distro and think: "OMG, it's iso is 290 Mb", forgetting that this Puppy
offers the same facilities as a distro that is 2.5 times its size.

Anorexia is a mental illness, you know! You think that PuppyLinux is big? It's all in
your head!

BFN.

[oui]

Hi

Anorexic and technique, hum, what a relation...

An OS is not an artwork, it's my opinion, each app in a good designed system has a function and if the function is fully available and works the system is ok.

Puppy is special case:

The name "Puppy" is a well defined program and announces what will be awaiting, A baby of one lovely pet. And I am about certain, that working with a distro builder let grow the risk of fatidic fatness. Woof / WoofCE can help ...

... or become a shadow which you will never more jump over!

musher designs the most newer iso, the new DPupBuster. and explains that it «does NOT have: abiword, gnumeric,
claws-mail, hex-chat.»

ok, it also has Midori, also he speaks from SliTaz under an other name as SliTaz also has mTpaint, MHwaveEdit and some goodies in it?

oh yes ...

but ... huh ... stop stop stop

oh no, the size is completely different, like day and night

[rufwoof]

What is in a puppy main sfs is what the developers decided to include/exclude. That main sfs can be remastered so users can revise what's in or out of the main sfs. The developers choice could be very lean - so users might have to install many things, very fat - so the user might not have to install anything else, or somewhere between.

Typically vmlinuz boots and init inside the initrd runs, which typically switch-roots to the main sfs. If however you replace switch-root with a chroot (and not umount things inside the inird) then from the desktop you can break out of the 'main system' back to a initrd's cli. From there you could umount the entire main system from memory and perhaps boot another entirely different main sfs. The only thing that matters is that the choice of main sfs's loaded match the choice of kernel (vmlinuz) booted.

Puppy's, without the kernel/modules and added programs (Libre etc.), tend to be very small. The core puppy utilities are lean, and mostly scripts. You can't really count libre office or whatever as being puppy, as they're just additional installed, or not, default choices that the developers made, that the user could add to or remove if they so chose (via remastering). Similarly the kernel/modules side is a choice, lean and less hardware supported, or fat and more all encompassing, or somewhere between.

[dancytron]

What is in a puppy main sfs is what the developers decided to include/exclude. That main sfs can be remastered so users can revise what's in or out of the main sfs. The developers choice could be very lean - so users might have to install many things, very fat - so the user might not have to install anything else, or somewhere between.

Typically vmlinuz boots and init inside the initrd runs, which typically switch-roots to the main sfs. If however you replace switch-root with a chroot (and not umount things inside the inird) then from the desktop you can break out of the 'main system' back to a initrd's cli. From there you could umount the entire main system from memory and perhaps boot another entirely different main sfs. The only thing that matters is that the choice of main sfs's loaded match the choice of kernel (vmlinuz) booted.

Puppy's, without the kernel/modules and added programs (Libre etc.), tend to be very small. The core puppy utilities are lean, and mostly scripts. You can't really count libre office or whatever as being puppy, as they're just additional installed, or not, default choices that the developers made, that the user could add to or remove if they so chose (via remastering). Similarly the kernel/modules side is a choice, lean and less hardware supported, or fat and more all encompassing, or somewhere between.

But there isn't much to remove if you want to follow Barry's model of a very small distro that does pretty much anything with a gui app [without relying on applications in the cloud] and runs on almost all hardware.

While there is some duplication, like you said, with the exception of the browsers and office apps and maybe the video players, it is all very tiny apps and scripts.

There just isn't anything of substantial size to remove that doesn't produce a crippled version of puppy.

Just as a data point, if you take the 32 bit debian stretch 7.5 Puppy, uninstall Palemoon, Abiword, Gnumeric, and Deadbeef, install links2 and remaster with a zdrv you get a main sfs file that is 243 megabytes and a zdrv that is 31 megabytes.

If you then delete all the graphics drivers from /usr/lib/dri except the intel i915 driver and resquash with xz, you get a main sfs file that is 215 megabytes.

Take that and look at it with gdmap, what else could you get rid of and still have a useful distro? Cups and sane? The wireless drivers? All the video players?

It doesn't take woof. I suggest oui use the remaster process and produce a prototype of what he is talking about. It is supposed to be a doacracy after all.