Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Tue 26 Mar 2019, 12:07
All times are UTC - 4
 Forum index » Taking the Puppy out for a walk » Suggestions
Puppy's big problem with woof and woof CE
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 5 of 10 [144 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 Next
Author Message
oui

Joined: 20 May 2005
Posts: 3332
Location: near Woof (Germany) :-) - 3 PC's: DELL SX280 750 MB Pentium4, Acer emachines 2 GB AMD64. DELL XPS15

PostPosted: Tue 26 Feb 2019, 05:30    Post subject:  

Hi mistfire

mistfire wrote:
Hello

I just want to share my opinion.

Here are some factors that makes the puppy bloat.

1. Web Browser
2. Multimedia Player
3. Office suites
4. DRI files
5. Kernel modules
6. Firmware drivers
7. UEFI boot files
8. SFS Compression

TazPuppy is around 100Mb yet with wide hardware support. The small main SFS file size was achieved by using xz compression with 1Mb block size.

Slitaz was 40-50Mb but lack of hardware support by default. You need to download some kernel modules in order to work with computer to computer this will reduce portability.

I made a discussion on X-Slacko Slim on how to reduce the filesize the Puppy.

In order to make Puppy small:
1. Use a lightweight browser but HTML5 and ajax compliant and it can play HTML5 video, audio, and stream
2. A lightweight player that can play commonly used formats such as mpg, mp4, wmv, wma, mp3, avi, wav, aac, mkv, ogg, ogv, oga
3. Use maximum SFS compression settings when creating the main puppy sfs file. (xz compression with 1Mb block size)
4. Remove uneccessary docs and source code headers (those are belong in devx sfs modules)
5. Office suites is optional

For new, unique, and breakthrough features for puppy. Take a look at X-Slacko Slim (the base files which I improved and modified is already provided on the thread).


Yes, you are right, above factors are determinant for a small distribution!

But, actually, it is not really the matter:

musher0 wrote:

E.g., including the devx, josejp2424's latest DPup, DPupBuster, is ~ 375 Mb.
Without the devx: 273 Mb.


musher0 wrote:

E.g., the new DPupBuster does NOT have: abiword, gnumeric,
claws-mail, hex-chat. What else could be chopped off? mpv?


This product of WoofCE is also only a one-bone where the big pre installed bone is the browser and it's libraries of course, but the browser is the very light browser Midori!

Nothing else excepted the usual tools and the very light weight little app's like mTpaint etc. (also being in the base of SliTaz, you can look in our Tazpup where you are the main actor!)

To build a small distro, a very important question is that of the choice of libraries (often very big dependencies): all GTK OR all QT (*1 ! And a distro builder is generally not trained to do that...

Other packages have to become extra packages...

(*1 probably the QT version will become 50 .. 60 Mb biger than the GTK version
Back to top
View user's profile Send private message 
musher0

Joined: 04 Jan 2009
Posts: 13777
Location: Gatineau (Qc), Canada

PostPosted: Tue 26 Feb 2019, 06:03    Post subject:  

oui.

For the record, Midori being a "very light" browser is an illusion. It requires LLVM and the
libgtkwebkit (99Mb's combined). Believe me if you will, but it is true.

Go double-check. Your hopes up in smoke, eh?

_________________
musher0
~~~~~~~~~~
Je suis né pour aimer et non pas pour haïr. (Sophocle) /
I was born to love and not to hate. (Sophocles)
Back to top
View user's profile Send private message 
oui

Joined: 20 May 2005
Posts: 3332
Location: near Woof (Germany) :-) - 3 PC's: DELL SX280 750 MB Pentium4, Acer emachines 2 GB AMD64. DELL XPS15

PostPosted: Tue 26 Feb 2019, 17:16    Post subject:  

musher0 wrote:
oui.

For the record, Midori being a "very light" browser is an illusion. It requires LLVM and the
libgtkwebkit (99Mb's combined). Believe me if you will, but it is true.

Go double-check. Your hopes up in smoke, eh?


is that your first official critic against the choices taken in the last new dpup and installing midori 7 (and without solution to see youtube)?

I did look in my try in Upup64: Seamonkey has exactly 100 Mb UNPACKED, no external files (but no dictionaries, only links to hunspell, where they are really needing for text processing etc.), no limits concerning HTML5 or youtube etc, and offers the classic HTML4 editor with spell check, and the full email client, being, on top, needing in Midori to be really equivalent Wink .

bad deal really as Midori 4 do the same (all the SliTaz distro is, of course squashed, only 50 Mb light, with Midori in it), and, if the developers are fit, THAT midori 4 can handel HTML5 and youtube, you have seen my print screen (today a lot of Puppy's have not the same luck...)

are you becoming an opponent to your new lovely distro buster?
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 1216
Location: not Bulgaria

PostPosted: Wed 27 Feb 2019, 18:21    Post subject:  

Come on guys. Even pretty old computers come with a few GB of storage space. The amount of space (40MB or 400MB) a distribution occupies on that is really irrelevant (and more and more so nowadays). What remains relevant in how much RAM the distributions uses, where such RAM remains quite limited on older but still useful computers (say 1 or 2 GB RAM machines). And the other important issue is browser speed (page rendering and so on).

So, important tests are:

1. How fast does the browser render web pages.

2. How much RAM does the browser occupy before loading any pages.

But most important of all really:

3. How many tabs containing high-load pages (such as gmail pages) can a browser open before it crashing owing to physical RAM running out (note that this is likely more a problem of heavy web pages than the browsers themselves - if webpage eats memory I guess there is not a lot the browser can do about it ).

There is probably one very good reason for a small distribution to be particularly nice: it can all be loaded in limited RAM with still enough RAM left to do useful work. And even old systems work fast when programs_and_OS are already in RAM (new systems can have very fast external SSD drives anyway, so not so important to load into RAM anyway). Slitaz is great for that (it uses lots of RAM actually but that's cos all of it is, by default anyway, loaded into RAM even on quite low RAM systems). On systems with more RAM, bigger distros (like Pup or the Dogs) can also be competely loaded into RAM and still usable (though browser heavy web pages do quickly use up a lot of RAM per tab opened).

So, for me, the point/use of Slitaz and any tiny assembled distro is that it will run very fast on low RAM limited systems when a bigger distro would need slow access to external drives all the time (including often a lot of swap space usage - i.e. swapping pages in and out between RAM and external storage).

So, nice if WOOF-CE also included as tiny a Puppy as possible - I don't think that can be achieved with Pups build from straight Debian or Ubuntu repositories though - too many dependencies (including big libs) - too big compiles - too many included docs. For small systems, Slitaz currently unmatched, but persistence/save capability of Slitaz is very limited. Tazpup addresses that lack by using Puppy boot/save mechanisms, but at increase of size cost. I imagine Tazpup could be slimmed down since some Slitaz functionality not needed since has Pup alternatives. But since it uses components from current pup maybe some libs or other pup-borrowed components are bigger than they need to be? - I don't know. I can't see that Tazpup iso size needs to end up twice the size of its underlying Slitaz tho, well, except I guess Tazpup is currently providing Xorg? and full, not busybox, bash shell?

wiak

Last edited by wiak on Wed 27 Feb 2019, 19:30; edited 1 time in total
Back to top
View user's profile Send private message 
oui

Joined: 20 May 2005
Posts: 3332
Location: near Woof (Germany) :-) - 3 PC's: DELL SX280 750 MB Pentium4, Acer emachines 2 GB AMD64. DELL XPS15

PostPosted: Wed 27 Feb 2019, 19:18    Post subject:  

all precedent reasonings of wiak are true.

but a detail has a highly importance: how much web indirections can create the opening from only one unique web page (news paper etc. frequently a terrible number you see if the browser is build in with a strong close of that and you or the webmaster or the author crew of the browser demand your approvals for each indirection. this correspond often with the usual pre settings for Konqueror, but of course, puppyists don't really often meet konqueror in the praxis)... this depends also dramatically from use or not from somewhat like an adblockler and how strong you did have to set it on to permit to see all your prefered pages without restrictions as the redirections are, it so, the payment that the page owner require from you to supply the service financed by publicity...

what is the result?

the hidden ~/.cache subdir in your "home" grows and grows and grows!

today I did enter the web at 19 h 30. the laptop was shutdown. I did start live full in RAM with bionicpup64 version 7.9.8. and as I never use some save file or dir, no /root/.cache present at starting point (I did check it!)

following printscreen has the date today 23.37. And we did have lunch an hour between this time! The at starting point (of the browsing activity) created .cache did grow until

126 MB!

I did look into the subdir: the big content was a second hidden subdir named "mozilla" (not /root/.mozilla but /root/.cache/mozilla !)

I did look into an available full installation (as I did rapport often from SliTaz in the last hours, a full install from SliTaz: The full install did need, all included 3,3 Gb, but the /user/tux/.cache/mozilla alone

1 Gb ! (so that the real net size of the full installation was under 2,3 Gb!)

This is in my eyes a MAJOR LIMITATION for PC's working in RAM-mode only!

The function using ~.cache is highly problematic!

Is that function needing? What does it concrete FOR the user?

(Note: they are more subdir in ~.cache of the full install. for ex. fontconfig, menus, midori, mozilla, openbox, webkitgtk and readme saying ~/.cache/ - User cache directory XDG variable: XDG_CACHE_HOME. But the content of all other is low. Of course, I am not really an user of midori, In the other case, it would perhaps be different!)
cacheProblem.jpg
 Description   
 Filesize   28.9 KB
 Viewed   299 Time(s)

cacheProblem.jpg

Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 1216
Location: not Bulgaria

PostPosted: Wed 27 Feb 2019, 19:40    Post subject:  

I'm not on Linux just now, oui, but I suspect, when system is RAM-only, that cache size will shrink and grow automatically depending on how much physical RAM system actually needs. In general cache usage tends not to be problematic for that kind of reason. In practical terms, I mean that Slitaz will not crash or slow down because of that cache growing too big.

I could well be wrong.

wiak
Back to top
View user's profile Send private message 
oui

Joined: 20 May 2005
Posts: 3332
Location: near Woof (Germany) :-) - 3 PC's: DELL SX280 750 MB Pentium4, Acer emachines 2 GB AMD64. DELL XPS15

PostPosted: Wed 27 Feb 2019, 19:57    Post subject:  

Hi wiak

I answer better here this part of your answer to me in the other thead:

wiak wrote:

Regarding distribution 'size', I still feel the use of Xorg in Puppy (and only Xvesa in Slitaz) is one major reason for difference between Pups and Slitaz - and probably cut-down lib set in Slitaz - I don't know. What Slitaz provides in such a small iso is certainly amazing (similar to what tiny core can do, albeit with a lot of tinkering required in tiny core to achieve user-quality provided by Slitaz). But more generally, I also tend to feel that distribution size isn't so important (even my 2GB 2008 machine works perfectly fine with larger distributions) - 100MB, 200MB, 500MB, doesn't make a lot of difference on most machines (and once you install larger apps/Xorg etc, size soon becomes similar...): what is important is RAM used when running apps (in terms of machine slowing down, swap being uses, or system crashing). Doesn't seem to matter what size of distribution you use in that regard - problem is the browser experience and moreso the heavy coded web pages, which suck RAM for every tab used.

wiak


SliTaz handles right! The full installation of all modules for xorg (or for all printers) etc. is nonsens! The installation grows (not so much as in the past, in the past it was terribly more as Xvesa was yet separate and all modules were more heavy) but, big or not, it is nonsens because on one terminal you will meet only a need for one module that most of the linuxians know before they start their installation (I, for ex., need "intel"). Same thing for CUPS and it's filters. You generally have not so different printers in use. My Brother-HL-2035-hl1250.ppd is on my HD. No need to install all the gutenprint cram...

where is would be important, in the field of the user languages because so much points have to be taken in consideration, the big Puppy did years along nothing and today it continue to be so, that in no one "help" from JWM menu you will find the url needing to localize your system (and only sometime at an other logic place like icon on the desk for installations complements), where SliTaz "the light" ALWAYS did propose immediately (before the installation) a choice between the 3 Swiss languages DE-FR-IT, as created first in Swiss, and, over that, EN...

to critic SliTaz because it continues to offer only a few modules for Xorg is ridiculous. It starts with the Xorg module also named Xvesa but not the old Xvesa...

If you know (my own situation!) that this will be problematic by first start (with INTEL, nobody in LINUX likes INTEL!), you add in the grub menu / .cfg at the end of the line for the kernel the command

screen=text

and you start even in pure text mode where you can immediately reinstall xorg using

tazx

(the packages list loading happens automatic...) ans select reorganize xorg!

i find it is an adequate solution not to overload the ISO and the squashed system going into the RAM, it is more important, as the most users really never will use a lot of xorg modules!

.orthography

Last edited by oui on Thu 28 Feb 2019, 09:29; edited 5 times in total
Back to top
View user's profile Send private message 
oui

Joined: 20 May 2005
Posts: 3332
Location: near Woof (Germany) :-) - 3 PC's: DELL SX280 750 MB Pentium4, Acer emachines 2 GB AMD64. DELL XPS15

PostPosted: Wed 27 Feb 2019, 19:58    Post subject:  

Hi wiak

wiak wrote:
I'm not on Linux just now, oui, but I suspect, when system is RAM-only, that cache size will shrink and grow automatically depending on how much physical RAM system actually needs. In general cache usage tends not to be problematic for that kind of reason. In practical terms, I mean that Slitaz will not crash or slow down because of that cache growing too big.

I could well be wrong.

wiak


thank you for that statement!
Back to top
View user's profile Send private message 
tallboy


Joined: 21 Sep 2010
Posts: 1220
Location: Oslo, Norway

PostPosted: Sun 03 Mar 2019, 17:51    Post subject:  

ITSMERSH wrote:
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.

As I wrote, I have some old PCs which can read a CD, a few only have early USB. I have not had money to buy new equipment, and I see no reason to throw away a working computer.

wiak wrote:
Slitaz is great for that (it uses lots of RAM actually but that's cos all of it is, by default anyway, loaded into RAM even on quite low RAM systems).

Intereresting fact? No, not really, because that is how all my live Puppys always have run. As a matter of fact, as I wrote in an earlier post, that is how Puppy was designed to run; a single user, as root, from RAM.

And I don't need any storage space at all to run Puppy, but the advantage of having a small HDD, is that you can have a healthy swap partition on it, which allows you to run large apps with little RAM.

But then again, I must correct myself. Earlier Puppys didn't need any storage space, because you could save your session to the multisession CD that contained the .iso, BUT THAT OPTION WAS DELETED SOME TIME AGO IN THE WOOF CEs! Mad

_________________
True freedom is a live Puppy on a multisession CD/DVD.
Back to top
View user's profile Send private message 
ITSMERSH

Joined: 02 May 2018
Posts: 911

PostPosted: Sun 03 Mar 2019, 18:32    Post subject:  

Quote:
But then again, I must correct myself. Earlier Puppys didn't need any storage space, because you could save your session to the multisession CD that contained the .iso, BUT THAT OPTION WAS DELETED SOME TIME AGO IN THE WOOF CEs!

Probably this removal is just a bug or accident.

Yesterday I made a remaster of BionicPup64 7.9.6 (which I already remastered before) to try to apply some fixes from 8.0 to 7.9.6.

Accidentially I deleted /etc/rc.d/PUPSTATE and replaced it with an almost empty version from read only mounted BionicPup64 8.0. The remaster script then complained about running in PUPMODE=2, so unable to remaster.

Since the original PUPSTATE wasn't recoverable I just changed that PUPMODE=2 to PUPMODE=5 and did a remaster successful.

Though, at next boot a message appeared on the screen which said I'm NOT booting from a multi-session cd. After hit enter it booted fine, though. So, the ability to boot a multi-session cd/dvd seems to be still implemented, which makes me think it's just a bug that you can't save anymore to a multi-session cd.

My I suggest to get in contact with the woofCD stewards (I don't like this term...).

_________________
RSH

Beware of the Dog ähem nic007! Wink
Back to top
View user's profile Send private message 
musher0

Joined: 04 Jan 2009
Posts: 13777
Location: Gatineau (Qc), Canada

PostPosted: Sun 03 Mar 2019, 19:03    Post subject:  

Hello, minimalists!

nanolinux is all of 14Mb big!
(~ 1/3 the size of SliTaz)

BFN.

_________________
musher0
~~~~~~~~~~
Je suis né pour aimer et non pas pour haïr. (Sophocle) /
I was born to love and not to hate. (Sophocles)
Back to top
View user's profile Send private message 
ITSMERSH

Joined: 02 May 2018
Posts: 911

PostPosted: Sun 03 Mar 2019, 19:06    Post subject:  

musher0 wrote:
Hello, minimalists!

nanolinux is all of 14Mb big!
(~ 1/3 the size of SliTaz)

BFN.


Could be enough to get to the moon and back!

But I don't want to enter the moon. Got something better to do. And for that something better I definitely need more than 14MB of System/Software.

_________________
RSH

Beware of the Dog ähem nic007! Wink
Back to top
View user's profile Send private message 
musher0

Joined: 04 Jan 2009
Posts: 13777
Location: Gatineau (Qc), Canada

PostPosted: Sun 03 Mar 2019, 22:04    Post subject:  

Hi, "ITSMERSH".

If you want to go to the moon, please feel free! Laughing

Well, I just ran nanolinux, and it's quite nice. And worth it, if only for the excellent PIM
called "The Daily Journal".

Funny anecdote: it is so small that when PBurn burned it to DVD, it froze -- well, maybe just
"hanged". To make sure, the copy was ok, I made another burn with
Code:
cdrskin -v dev=/dev/sr0 blank=as_needed -eject padsize=300k $1
And it too sort of did not know what to do after the first sector was burnt.
But the burn booted to desktop ok.

BFN.

_________________
musher0
~~~~~~~~~~
Je suis né pour aimer et non pas pour haïr. (Sophocle) /
I was born to love and not to hate. (Sophocles)
Back to top
View user's profile Send private message 
rufwoof

Joined: 24 Feb 2014
Posts: 2925

PostPosted: Sun 03 Mar 2019, 22:56    Post subject:  

Thanks for the nanolinux pointer musher0.

I frugal'd it. Copied the cde folder inside the iso to the root hdd as folder name tce, copied the initrd (corepure64.gz) and kernel (vmlinuz64) files into /nano and I setup a grub4dos menu.lst entry for 60x480 resolution ...

title nano
root (hd0,0)
kernel /nano/vmlinuz64 loglevel=3 cde vga=0x321 showapps multivt quiet
initrd /nano/corepure64.gz

Booted, used the image viewer, loaded dillo and logged into puppy linux forum, took a screenshot ..etc. OSS playing OK (radio player and mp3's, but starts at max volume (ouch!). Also right headphone normal, left - low volume.
screenshot1.png
 Description   
 Filesize   43.89 KB
 Viewed   109 Time(s)

screenshot1.png


_________________
( ͡° ͜ʖ ͡°) :wq
Back to top
View user's profile Send private message 
musher0

Joined: 04 Jan 2009
Posts: 13777
Location: Gatineau (Qc), Canada

PostPosted: Mon 04 Mar 2019, 02:30    Post subject:  

Hi rufwoof.

T'is nothing at all, don't mention it.

But here's a piece of trivia, if I may.

Nanolinux' hummingbird logo jogged my memory a bit. That's why I noticed it. There
used to be a non-Linux (?) distro called Kolibri (10 years ago?). Same concept,
everything very small. To that Kolibri distro, our BarryK contributed some Assembly
code, IIRC. Maybe some of his material is still in this Nanolinux-1.3?

It think it unlikely there would be two Assembly code programmers named Barry Kauler
with the same penchant for tinyness. Wink

BFN.

_________________
musher0
~~~~~~~~~~
Je suis né pour aimer et non pas pour haïr. (Sophocle) /
I was born to love and not to hate. (Sophocles)
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 5 of 10 [144 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Taking the Puppy out for a walk » Suggestions
Jump to:  

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


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1671s ][ Queries: 12 (0.0181s) ][ GZIP on ]