tactique de rapidité

Post Reply
Message
Author
oui

tactique de rapidité

#1 Post by oui »

bonjour

je parlais de rapidité à adef dans le fil parallèle. il y a des choix à respecter et l'essentiel est

a/ le nombre de lecteurs disponibles
b/ la capacité du RAM

en effet, c'est le calvaire quand puppy bloque le CD et ne le rend pas, parce qu'il en a constamment besoin lui-même, parce que le PC n'a pas trop de RAM, car, alors, ton lecteur/graveur est bloqué pour de bon...

par contre, si tu as beaucoup de RAM, tu peux faire exécuter très vite des bibliothèques considérables de programmes utiles...

... mais ceux au prix d'une réelle lenteur au démarrage.

nous avons 2 PC principaux.
- mon laptop MEDION qui a 256 Moctets de RAM seulement
- le PC mini DELL SX270 de ma femme qui lui, a 512 Moctets de RAM

tous les 2 n'ont qu'un seul lecteur/graveur de CD / DVD

sous puppy, mon laptop fait du bruit: les souffleries de refroidissement fonctionnent en permanence (pas du tout sous windows), donc je ne le lance que qu'en j'en ai besoin. en outre, j'ai remarqué que si je regrave ma version de puppy, c'est vers 118 .. 122 Moctets que puppy ne veut plus me restituer le CD: je n'ai plus assez de RAM pour que puppy tourne intégralement dans le RAM. vu que la mémoire VIDEO en consomme pas mal sans doute. par contre, il charge ces 118 Moctets en quelque chose comme 2 minutes

sous puppy sur le DELL de ma femme, on n'entend rien (passée la bruyante phase de démarrage). l'ordi est en marche toute la journée de 8 h 00 à 23 h, est connu pour parait-il consommer peu de courant, et on ne monte puppy qu'une fois par jour et n'arrête jamais. et là on monte une vraie tapée de beaux programmes d'un coup, 280 Moctets. grâce au 512 Moctets de RAM, tout tourne en RAM (toute la journée!) et puppy restitue encore le CD, donc le lecteur est libre toute la journée pour autre chose. par contre charger ces 280 Moctets demande presque 6 minutes! on ne le ferait pas tous les quarts d'heure!

l'avantage des programmes sur disque "remastered" sont qu'ils sont directement dans le RAM de but en blanc, avec l'incomparable vitesse d'exécution, inégalée même par les meilleures des autres distributions de linux ou de windows!

mais si on encombre inutilement sa version "remastered", à un moment, le ram devient insuffisant, et donc puppy travaille avec lent lecteur de CD (au lieu du rapide disque dur), et ne rend plus le CD...

on a alors une trotinette :idea:

il faut trouver l'équilibre entre ce que l'on met dans la version remastered et ce que l'on mémorise dans le fichier de puppy sur le disque dur (qui est considérablement plus rapide que le CD!)

j'ai remarqué que Open Office est très rapide même en restant sur le disque dur. heureusement, car c'est un redoutable gros morceau!

si on veut donc un Open Office en RAM, on devrait opter de préférence pour l'une des 4 versions allégées contenant Open Office de but en blanc. le tout fait autour des 100 .. 120 Moctets et même sur mon laptop limité, le CD est restitué, c.a.d. que tout tourne en RAM, donc Open Office aussi. mais ces versions allégées ont Xvesa et non pas Xorg, comme nous francophones devrions préférer.

bon, il y a donc des choix à faire...

salut

Pelo

7 ans plus tard... 2014

#2 Post by Pelo »

L'histoire va montrer que beaucoup vont vouloir charger ce petit étalon pendant que d'autres chercheront à alléger leur percheron (Debian)

Médor

#3 Post by Médor »

Bonjour,

Il est totalement faux de dire qu'avec 256Mo de ram Open Office soit chargé en ram :!:

À lui seul Le sfs de d'Open Office (ou Libre Office...) allégé fait au alentour de 150Mo soit décompressé/monté trois fois plus : ~450Mo :!:
Idem en chargeant Puppy en ram, suivant la version, le sfs principal fait de 120 à 160 Mo :!:
Et avec des sfs compressés en xz c'est plus de quatre fois la taille après décompression...

Donc Puppy + Open Office ça fait minimum 1 Go décompressé en ram sans compter qu'il faut naturellement encore suffisamment de ram pour faire tourner le système et pouvoir lancer les applications :!:

C'est pour cela qu'avec 256Mo de ram l'on entend parler depuis longtemps de la barrière des 100 Mo pour l'image iso (sfs principal compressé en gz) :!:
Au delà forcement il est impossible de libérer le lecteur CD/DVD, donc se tourner sur une installation frugale ou complète mais bien sûr ce sera alors le support usb/dd qui ne pourra pas non plus être retiré :lol:

Cordialement,
Médor.

oui

#4 Post by oui »

ah oui? tu veux que je te monte un ISO de Puppy en ligne qui ne fait que 99 MB OO inclus :lol: ?
naturellement pas le plus moderne mais un vieux Puppy, selon le motto, «petit deviendra grand» mais il a le mérite d'être là et de fonctionner! car un vieux OO vaut bien un Gnome-Office dit moderne mais toujours sous développé par rapport à Star Office 5.1 (la dernière version de la sté StarOffice initiale et qui fut mise, avec la précédente 5.0, sous Public Domain. OO débutant était à peu près équivalent, sauf que le navigateur et bureau intégrés y ont été, de toute évidence définitivement, supprimés!). Et aujourd'hui encore je préfèrerais toujours ces vieux Puppy 1.8 et 2.0 avec OO intégré s'ils pouvaient traiter l'USB, notamment les claviers etc., correctement (celà ne fut le cas qu'à partir de Puppy 2.10. et, surtout, 2.12, sur lequel se basent plusieurs légendaires remasteurisations).

regarde la date du message!

Pelo s'em....... à 100 sous de l'heure à la retraite et est en train de déterrer des de vraies antiquités: le 19.2.2007, c'était 4 ans après le démarrage de Puppy et de ce forum... aujourd'hui, nous sommes 10 ans après ce démarrage, 6 ans plus tard, bien tassés, que ce message...

ding - ding - ding, réveillez vous les gars :wink:

Médor

#5 Post by Médor »

Bonjour Oui,

Effectivement j'ai bien vu la date mais après avoir répondu ;)
Ce qui ne remet pas ma réponse en cause car pour pouvoir travailler tout en ram il faut que les fichiers et le système tiennent dans la ram :!:
Si tu prends l'exemple de l'iso de Slitaz 3 ordinaire elle pèse 30 Mo, la version lowram fait 120 Mo !

Dans mes vieilleries j'ai toujours Star Office 5.1 qui d'ailleurs à l'origine était produit par la société allemande StarDivision avant son rachat par Sun ;)


Malheureusement Pelo a la capacité de mettre le souk sur le forum à défaut d'être apte à suivre des cours d'informatique :lol:

Cordialement,
Médor.

oui

#6 Post by oui »

bonjour Médor

bonne réponse. merci!

j'en reviens au premier message que Pelo a donc déterré! il y a une explication: j'ai toujours donné énormément de place à ma SWAP, et dès qu'il y une SWAP, Linux s'en accapare toujours.

comment Linux gère la SWAP, ce n'est sans doute un secret pour personne, puisque Linux est Open Source, mais c'est quand même resté un secret pour moi. je suppose seulement que c'est l'explication: dans mes 2 Go de SWAP que je donnais déjà à l'époque, on peut même loger un Debian graphique actuel, et pas seulement le live d'Emil... est-ce que Puppy, ou son Linux (Slackware à l'époque) l'a fait, je l'ignore! Mais comme Puppy restituait le CD et que j'avais besoin du lecteur pour d'autres choses (en 2007, je pense que je n'avais peut-être encore jamais possédé de clef USB), d'une part, et que d'autre part tout marchait, je ne me suis jamais posé la question.

le squashing à très haut taux de compression est d'ailleurs plus récent, même si c'est pas tout neuf! pour SliTaz, c'est absolument essentiel: sinon on se serait rendu compte que SliTaz aussi a terriblement engraissé (changé d'équipement, presque plus rien dedans, et mis des programmes légers-légers, de manière extrêmement habile d'ailleurs, la gestion de l'installeur et le gestionnaire de paquets la version adaptée de Midori, c'est tout bonnement génial, avec l'avantage en plus, que Midori fonctionne vraiment, car les gars de SliTaz on creuvé l'abcès et fait de Midori un navi sans concession...
...dans SliTaz, alors que dans d'autres distros, on a souvent des ratées avec.

dans ses receptes sur le forum de Puppy, Dougal préconisait longtemps (je ne sais d'ailleurs pas s'il a changé - je me limite simplement à ne pas prétendre qu'il le préconise à la date actuelle) le squashing basse compression, et SliTaz 1 et 2, c'était encore mieux, c'était à très basse compression (j'obtenais des facteurs de décompression de juste un peu plus de 1,5!). ceux qui ont encore le manuel initial de Christophe, d'ailleurs, peuvent le lire clairement dans SliTaz from Scratch (la recepte initiale, car elle aussi a changé.

les développeurs n'aiment d'ailleurs le recours à la très haute compression qu'en tout dernier recours, car cela les fait poireauter devant leur écrans très longtemps en plus pour des clopinettes, et, à la décompression, cela aussi mange considérablement du temps (mais quand le fichier n'est pas sur un support rapide, j'appelle support rapide un disque dur 7200 rpm, cela peut être modéré légèrement par le gain de temps de lecture du contenu de l'ISO en RAM). ce sont des considérations difficiles et à apprécier et à généraliser dans le monde de Puppy, dont les adeptes disposent d'une variété considérable de hardware les plus diverses... l'un se fiche de gains minimes alors que pour l'autre, toujours rivé pas les circonstances à une trottinette, ils peuvent être quand même très intéressants. j'ai eu des phase par ex. de PC d'occas n'ayant au départ que 10 GB de disque dur à 5400 upm avant de trouver un disque de rechange... il y en a qui ont gardé cela, car ils n'ont jamais acheté de l'occas, le PC neuf leur a coûté, à l'époque, la peau des fesses, et ils ont considéré que c'était comme le mariage, un contrat pour le reste de la vie...

Médor

#7 Post by Médor »

Re,

Bien sûr avec une swap ça aide ! Mais en fait Puppy ne décompresse pas tout en ram si elle n'est pas suffisante.
J'ai actuellement avec Slacko-5.7.0 en frugale et 256 Mo de ram dont 12 Mo partagés :

Code: Select all

# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        38G   28G  9,4G  75% /initrd/mnt/dev_save
/dev/loop1      124M   66M   59M  53% /initrd/pup_rw
/dev/loop0      157M  157M     0 100% /initrd/pup_ro2
/dev/loop4      140M  140M     0 100% /initrd/pup_ro4
unionfs         124M   66M   59M  53% /
tmpfs           310M 1012K  309M   1% /tmp
shmfs            36M     0   36M   0% /dev/shm
#
L'occupation en mémoire est de : 153/239 Mo
Mon fichier de swap affiche : 498/500 Mo, soit 2 Mo d'occupés actuellement.
Et j'ai Opera, Sakura et Leafpad qui tournent en plus de X, Openbox, Lxpanel, Gkrellm :!:

Pour en revenir à Slitaz v3.0, le cd loram fait 132 Mo contre 32 Mo pour l'iso classique...
Voir sur cette page le détail, il est bien indiqué :
SliTaz-Doc wrote:La taille de RAM minimum pour le noyau SliTaz LiveCD est de 160 MO (128 Mo pour SliTaz 1.0). De nombreuses applications graphiques ne fonctionnent pas avec cette faible quantité de mémoire, il est donc recommandé d'utiliser l'option de démarrage en mode texte : screen = text.
(Il n'y a pas de date indiqué, je suppose que c'est pour la v 2.0...).
Même en v 3.0 il y a Firefox par défaut, pour Midori il a certes pris de l’embonpoint mais c'est surtout le poids du webkit actuel qui est maintenant plus gros que Firefox ;)

Bon, je retourne à ma traduction d'un plugin Météo pour Lxpanel, il est en bonne voie j'ai recréé/complété le mo fr de lxpanel...

Cordialement,
Médor.
Attachments
Capture_2014-03-20_174501.jpg
(58.18 KiB) Downloaded 159 times

Post Reply