Selon l'article de OSNews ( http://osnews.com/story.php?news_id=7324(...) ) notre OS préféré est devenu trop gros, trop lourd, trop lent.
Il bouffe de la mémoire à tire-larigot et, sur ce plan uniquement, n'a plus aucun avantage par rapport à Windows.
Avant de vous lancer dans des trolls d'anthologie prenez la peine de lire l'article qui est intéressant : l'auteur ne parle que des grandes distributions généralistes pour le grand public (sa critique exclut donc une slack ou une Gentoo ou une Debian qui sont difficiles d'accès mais peuvent êtres "tunés" pour réduire l'empreinte mémoire).
A noter aussi une petite faute de goût vers la fin (le missile anti-havoc) qui gâche un peu l'article et qui va provoquer des flame-wars stériles alors que l'on devrait parler sérieusement du problème évoqué.
Journal Linux est il gros et gras ?
10
juin
2004
# Linu* est il gros et gras ?
Posté par Nÿco (site web personnel) . Évalué à 10.
Linus ou Linux ?
# mais...
Posté par deftones_chris . Évalué à 7.
Concernant les "grandes" distributions, on ne peut pas demander du tout graphique reposant sur X et KDE (ou Gnome) et que cela tienne sur 1Mo. Faut être réaliste :)
Il y a peut être également un problème de mentalités des programmeurs actuels. Vu que beaucoup travaillant sur des machines contenant des centaines de mégas de RAM et certains n'ayant pas connus les ordis de 64Ko voire 1Ko (je reconnais que c'est un extrême) , ils ont tendance à faire de allocations mémoire bien large sans vraiment se poser de questions.
[^] # Re: mais...
Posté par o°Oo°Oo°o°O°Oo°Oo°Oo°Oo°o°O°O o° . Évalué à 5.
Tu as des logiciels pour Fenêtre qui te permettent de virer tous les trucs système qui ne te servent pas.
Par exemple : 98Lite ou XPLite, etc.
J'avais réussi à faire tenir un Fenêtre 95 dans 12 Mo sur mon disque dur (en virant presque tout, il faut avouer), et l'empreinte mémoire était proportionnellement plus petite.
[^] # Re: mais...
Posté par deftones_chris . Évalué à 2.
A moins que les xxLite permettent de le faire.
[^] # Re: mais...
Posté par un_brice (site web personnel) . Évalué à 4.
Le reste non... faut pas rêver (surtout qu'une fois en mode texte -> plus vraiment possiblité de faire grand chose -> autant être sous GNU/Linux).
# C'est pas trop tôt
Posté par Mr YouP . Évalué à 10.
Sinon, l'article dit beaucoup de vérité et un problème que je rencontre souvent lors de migration, c'est leeeeennt (OOo sur un celeron 500/128Mo 40seconde de démarrage, même sous xfce).
Je pense qu'il y a principalement deux causes :
- Xfree (qui est vachement pas rapide et pas réactif)
- les grosses applis genre OOo et moz qui n'ont pas eu comme objectif premier d'être rapide, qui sont devenues incontournable dans la migration (du fait de leur existance sous win) et qui sont terriblement lourdes à faire tourner sur des "petites" machines.
Sachant que ce qui me fait le plus râler c'est qu'elles sont plus rapide sous windows (le comble).
[^] # Re: C'est pas trop tôt
Posté par kolter (site web personnel, Mastodon) . Évalué à 6.
Mais ce sont deux systèmes d'exploitation dont la conception diffère...
Une distrib Linux s'articule sur plusieurs couches logicielles (du noyau à l'editeur de texte en passant par le système d'affichage de fenêtres) qui sont multi-plateformes et sont souvent indépendantes de la couche inférieure et de leur couche supérieure... j'en veux pour preuve X qui tourne sur plusieurs type de noyau et qui fait fonctionner plusieurs types de gestionnaire fenêtres....
Windows, de mon point de vue est plutot un seul logiciel où vu de l'extérieur, tout est un seul bloc (une boite noire) dans laquelle on peut faire tout les branchements et raccourcis qu'on veut... (mais est ce le cas.... ?)
Je pense que la perte de rapidité (s'il y'a perte, des benchs ... ????), vient de l'intéraction entre les couches... et plus y'a de couches, plus le phénomène s'accentue....
M.
[^] # Re: C'est pas trop tôt
Posté par Anonyme . Évalué à 4.
tout est un seul bloc (une boite noire) dans laquelle on peut faire tout les branchements et raccourcis qu'on veut...
IBM a essayé dans les année 80 => système totalement impossible à maintenir : l'absence de couche entraine un propagation de bug lors de correction (un truc marche pas bien on le corrige, mais plein de truc appelant ne marche plus avec la correction)
Mais il y a certes moins de couche matérielles.
Globalement je ne pense pas que ce soit le nombre de couche qui pose problème, mais la rapidité entre les couches. Sous X tout est protable (quasiment), sous win rien.
L'intégration est alors plus facile : on peut optimiser à font puisse que de toute manière puisque la couche inférieure on la connait c'est toujours la même.
[^] # Re: C'est pas trop tôt
Posté par Boa Treize (site web personnel) . Évalué à 7.
Des chiffres, des preuves ? Moi je dis que XFree86 est vachement rapide et réactif, mais qu'il est chargé comme un baudet par les experts de la transparence qui ne maîtrisent pas l'architecture X ou qui se perdent en abstractions coûteuses.
Y a-t-il un équivalent MsWindows de x11perf ?
[^] # Re: C'est pas trop tôt
Posté par Mr YouP . Évalué à 4.
Et quand je fais un top, j'ai toujours un process X tout en haut de la liste qui grossi, qui grossi....
d'ailleurs, je suis bluffé quand je vois geexbox booter sous le frame buffer (par contre j'y connais pas grand chose et ne saurais dire pourquoi il ne faut pas comparer X et framebuffer)
[^] # Re: C'est pas trop tôt
Posté par Guillaume Knispel . Évalué à 4.
X c'est un énorme truc bourrin, qui dispose certe de qualités, mais qui sont de moins utiles aujourd'hui surtout fasse aux défauts qu'elles procurent (d'autant que windows & co est en train (dans une certaine mesure) de rattraper son manque de modularite graphique, sans pour autant que les trucs locaux en souffrent). X permet par exemple de déporter l'affichage avec une modularite extrème (une appli peut par exemple gerer l'interface utilisateur d'un soft, et une autre tournant sur une autre machine avec un autre archi peut très bien s'occuper de l'affichage d'un contenu quelquonque (mettons une image du ciel) dans l'IU de l'autre).
Malheureusement X est de trop bas niveau en ce qui concerne les primitives qui transitent par réseau, X est de trop haut niveau pour gerer des trucs videos ou 3D en local sans extension, et les extensions rajoutent une lourdeur supplementaire à X. En gros il faudrait faire une espèce de quadrature du cercle pour rendre tout ca parfait.
[^] # Re: C'est pas trop tôt
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Alan Cox a démontrer plein de fois que les bibliothèques type Qt et GTK fonctionne de tel façon que plein d'optimisations de X interne ne peuvent pas fonctionner. Dans certain cas, tinyX de kate packard qui n'a aucune accélération 2D, semble plus réactif à cause de ça.
"La première sécurité est la liberté"
[^] # Re: C'est pas trop tôt
Posté par Moonz . Évalué à 2.
# Psssssssssss
Posté par 007 . Évalué à 6.
Pareil avec n'importe quoi d'autre.
Ici une FC2 avec gnome 2.6, mozilla, evolution qui tournent qui tourne en même temps :
$ free
total used free shared buffers cached
Mem: 518292 512004 6288 0 19128 332756
-/+ buffers/cache: 160120 358172
Swap: 583104 146708 436396
J'ai aussi postgresql, apache, named qui tournent.
Après boot et login sous Gnome je n'ai même pas 128 Mo d'utilisé (cache compris).
> even if not as much as Fedora, for example Arch Linux or Slackware run Gnome on 128 MB
FC2 avec gnome 2.6 peut s'utiliser avec 128 MB. Aucun problème. Gnome n'est qu'une "partie" du problème.
Prend une Slack optimisée à fond et lance :
- Gnome
- Mozilla
- Evolution
- Openoffice
le tout en même temps et regarde la place que ça prend. Ajoutes aussi une page web qui utilise java et une autre qui utilise flash (pour le fun :-)). Ben ça va prendre beaucoup de place mémoire. Il n'y a pas de mistère. Et je ne parle pas de glouton comme gdb ou eclipse.
Avant la presse "de merde" était la presse "professionnelle"; maintenant c'est aussi la presse Linux. Fait chié alors...
Faites un comparatif, Gnome/XFCE ou OpenOffice/Koffice sur une PII à 233 Mhz avec 128Mo et dites lequel est le plus adapté.
Mais les comparatifs fumeux entre distributions me saoule comme jamais.
> GNOME-Terminal uses around 70% of the CPU just to draw the text
GNOME-Terminal est utf8 et passe par pango. Si le monsieur connait un terminal qui peut afficher les noms de fichier en Arabe ou chinois et qui marche très vite, alors qu'il nous fasse signe.
Faire "cat /usr/share/doc/pango-1.4.0/HELLO.utf8" dans Gnome-terminal puis dans rxvt ou xterm pour voir la différence.
> these two offending apps were both written by the same guy (Havoc Pennington)
Et si le monsieur c'est mieux coder que Havoc, qu'il n'hésite pas et nous montre son talent.
[^] # Re: Psssssssssss
Posté par Benoît Déchamps (site web personnel) . Évalué à 2.
[^] # Re: Psssssssssss
Posté par 007 . Évalué à 0.
Mais ce qui est en swap est par essence moins utilisé.
Je viens de faire un "swapoff -a" :
$ free
total used free shared buffers cached
Mem: 518292 514172 4120 0 17292 303072
-/+ buffers/cache: 193808 324484
Swap: 0 0 0
Faut toujours se méfier de ce qu'indique le swap. Et non, ce n'est pas un bug. C'est absolument normal.
[^] # Re: Psssssssssss
Posté par Troy McClure (site web personnel) . Évalué à 1.
ouais enfin si il pouvait afficher les caractères ascii sans se trainer comme une grosse bouse ça serait pas mal aussi:
http://linuxfr.org/~schyzomarijks/12617.html#410615(...)
la capacité a afficher du klingon n'excuse pas d'être 20 fois plus lent que les autres
[^] # Re: Psssssssssss
Posté par 007 . Évalué à -1.
Et bien fais le !
Personne fait mieux dans ce domaine que gnome-terminal (normal, c'est le seul). Donc à moins que tu sois un hacker de haute volée, ta critique ne tiens pas.
Puis t'es libre d'installer rxvt ou xterm ou...
btw : un utilisateur de gnome-terminal sais installer un autre émulateur.
[^] # Re: Psssssssssss
Posté par Troy McClure (site web personnel) . Évalué à 5.
et il n'y a pas besoin d'être un hacker pour imaginer comment le rendre moins lourdingue: au lieu d'afficher laborieusement tous les caractères quand il reçoit 10MB de texte d'un coup, il pourrait sauter les premiers 9.9MB qui vont scroller et seront immédiatement masqués (enfin ça c'est avec un xterm, parce qu'avec gnome terminal on a le temps de les voir passer..) et n'afficher que les derniers caractères reçus. D'ailleurs, vu l'allure du scroll dans konsole, j'ai l'impression que c'est comme ça qu'il procéde.
[^] # Re: Psssssssssss
Posté par 007 . Évalué à 1.
Ben alors de quoi tu te plainds ?
> mais ça ne m'enleve pas le droit de dire que ça en est une, de bouse.
Sans le moindre argument...
> D'ailleurs, vu l'allure du scroll dans konsole, j'ai l'impression que c'est comme ça qu'il procéde.
Et koncole gère utf8 ?
Non.
D'autres dans des pays "klingon" pour toi, trouverons que konsole est une bousse car il n'affiche pas des caractères communs pour eux. Et "eux" il ne sont pas minoritaire. Rien que la chine c'est déjà plus d'un milliard de personne. Mais certains projets préfèrent ignorer les "klingons" pour une optimisation dont 98 % des gens se foutent complètement.
[^] # Re: Psssssssssss
Posté par Troy McClure (site web personnel) . Évalué à 2.
http://www.google.fr/search?&q=gnome-terminal+slow(...)
hinhinhin
[^] # Re: Psssssssssss
Posté par 007 . Évalué à 0.
Alors compare gnome-terminal avec un "vrai" équivalent avant de dire que c'est une bouse.
Quand konsole supportera l'affichage d'utf8, tu nous feras des jolis benchs et peut-être que tu nous démontreras que gnome-terminal est une "bouse".
[^] # Re: Psssssssssss
Posté par Troy McClure (site web personnel) . Évalué à 4.
non parce que quand je fais un petit ls dans xterm j'ai mon résultat de suite, donc sa relative lenteur ne gène. Quand gnome-bouse met cinq secondes à faire la même chose, s'accapare 80% de cpu quand je fais tourner un soft qui affiche 5 lignes/seconde, alors oui je trouve ça génant, et ma première réaction à chaud est de m'exclamer "oh mon dieu! mais ce gnome terminal est vraiment une grosse bouse bloated, la v.2.0 était poussive, la 2.2 était lente et la 2.6 n'a rien amélioré si c'est comme ça je reprends mon xterm"
qu'il soit lent pour afficher de l'arabe ou du chinois je peux l'admettre mais ça n'est pas une raison valable pour l'empêcher d'afficher correctement et avec un minimum de célérité les 127 caractères les plus courants.
[^] # Re: Psssssssssss
Posté par 007 . Évalué à -2.
Si tu le dis....
Ben utilises xterm (qui afficher correctement 2^32/2^8 (soit 1/16777216) caractère de utf8) et basta.
[^] # Re: Psssssssssss
Posté par calandoa . Évalué à 4.
Juste que ça commençait à me les briser menues...
[^] # Re: Psssssssssss
Posté par Guillaume Knispel . Évalué à 2.
> Et koncole gère utf8 ?
je sais bien que pour traiter correctement de l'utf8 il faut eviter de lire 1 octet sur trois dans le flux, mais rien n'oblige de tous les afficher, donc je vois mal ce que vient faire l'argument d'utf8 lorsqu'on te décris une méthode simple pour éviter de laguer monstrueusement !
> Mais certains projets préfèrent ignorer les "klingons" pour une optimisation dont 98 % des gens se foutent complètement.
Une fois encore, tu crois qu'une opti détruit des fonctionnalité là où elle est seulement extrèmement logique (et extrèmement commune au point d'être connue par quiquonque ait fait un peu de prog d'affichage en mode texte)
[^] # Re: Psssssssssss
Posté par 007 . Évalué à -1.
Pourquoi personne ne réussi ce qui te parait si simple. Même grep en a pris un coup avec utf8 et même avec des fichiers qui n'utilisent que de l'ASCII.
[^] # Re: Psssssssssss
Posté par j (site web personnel) . Évalué à 2.
Terminal --> Codage de caractère --> [liste] - [ajouter ou supprimer]
Avec le système d'onglets tu peux avoir des terminaux avec des codages différents (UTF8 & Europe de l'Ouest par ex.)
Tu utilises quoi comme émulateur de terminal ?
[^] # Re: Psssssssssss
Posté par Troy McClure (site web personnel) . Évalué à 2.
A mon avis la solution idéale serait une interface graphique un minimum conviviale à screen.
[^] # Re: Psssssssssss
Posté par j (site web personnel) . Évalué à 4.
[^] # Re: Psssssssssss
Posté par totof2000 . Évalué à 1.
Normal, ce sont les mêmes journalistes qui rédigent les articles ...
PS - Tu pourrais être un peu moins ag(g?)ressif dans tes commentaires. Ca sert à rien de s'enerver, c'est mauvais pour la santé ...
[^] # Re: Psssssssssss
Posté par Julien Portalier . Évalué à 6.
> un terminal qui peut afficher les noms de fichier en Arabe ou chinois
> et qui marche très vite, alors qu'il nous fasse signe.
Réponse : « uxterm » ou « xterm -u8 »
Léger, très rapide et bougrement efficace dès qu'il s'agit de travailler en unicode. Je n'ai aucun problème pour afficher tous mes fichiers dans n'importe quelle langue (français, japonais, etc.). Par contre, je reconnais que ce n'est pas eye candy, il lui manque une petite option de transparence et des tabs. Mais ça seul gnome-terminal le permet (la plupart des term gèrent la semi-transparence, mais aucun ne gère l'unicode correctement). Mais j'ai abandonné celui-ci : il était d'une lourdeur exécrable dans Gnome 2.4, j'ai pas trop essayé en Gnome 2.6 il a l'air un poil plus rapide (mais je parle pas de l'empreinte mémoire).
[^] # Re: Psssssssssss
Posté par 007 . Évalué à 0.
$ time ls -l /dev
[...]
real 8m38.363s
user 0m0.228s
sys 0m0.181s
Oui, plus de 8 minutes !
avec gnome-terminal :
$ time ls -l /dev
[...]
real 0m22.279s
user 0m0.195s
sys 0m0.079s
avec find pour éviter les couleurs
uxterm :
$ time find /dev
[...]
real 0m10.839s
user 0m0.009s
sys 0m0.042s
gnome-terminal :
$ time find /dev
[...]
real 0m7.939s
user 0m0.012s
sys 0m0.067s
Et je me demande si uxterm supporte l'anti-aliasing.
[^] # Re: Psssssssssss
Posté par ckyl . Évalué à 3.
mkdir dir && cd dir
for i in `seq 10000` ; do touch $i ; done
for i in `seq 10000 20000` ; do mkdir $i; done
(quelques chmod pour changer les couleurs => 4 couleurs repartie uniformement)
uxterm
ls --color=auto -l 0,40s user 0,12s system 3% cpu 15,568 total
gnome-terminal
ls --color=auto -l 0,42s user 0,12s system 0% cpu 1:40,70 total
Ahma c'est surtout ton uxterm qui a un gros problème par ce qu j'ai justement arrete d'utiliser GT tellement il est insuportable de lenteur en fullscreen. Pourtant j'adore ses fonctionalités et sa config mais le fait qu'il puisse affiche des caractères que je n'afficherais jamais ne compense pas le fait qu'il soit leeeeeeeeeeeeeeeeeeent.
Note qu'ici il y a quand même 20 000 entrées dans le répertoire je dois etre tres loin de ton /dev... Et le ratio semble confirmer par tout les post que j'ai vu.
[^] # Re: Psssssssssss
Posté par 007 . Évalué à 0.
$ ll /dev/ | wc -l
7531
$ find /dev/ | wc -l
18763
Voilà pour "mon" /dev.
Essais mon exemple et donnes tes valeurs.
Sinon j'ai pour ton exemple :
$ time gnome-terminal -e "ls --color=auto -l"
real 0m27.636s
user 0m6.654s
sys 0m0.659s
$ time uxterm -e "ls --color=auto -l"
real 0m16.112s
user 0m2.558s
sys 0m0.306s
Mais
$ time uxterm -e "ls --color=auto -l /dev"
real 0m49.418s
user 0m1.238s
sys 0m0.248s
$ time gnome-terminal -e "ls --color=auto -l /dev"
real 0m6.242s
user 0m2.107s
sys 0m0.152s
Et :
$ time uxterm -e "find /dev"
real 0m4.683s
user 0m1.328s
sys 0m0.147s
$ time gnome-terminal -e "find /dev"
real 0m2.951s
user 0m1.363s
sys 0m0.107s
C'est bonnet blanc et blanc bonnet.
> Ahma c'est surtout ton uxterm qui a un gros problème
$ gnome-terminal --version
Gnome gnome-terminal 2.6.0
Ou alors tu as un gros problème avec ton GT.
J'ai tout utilisé avec la configuration par défaut. Et xterm est favorisé car il utilise une police de caratère plus petite et pas d'anti-aliasing.
[^] # Re: Psssssssssss
Posté par ckyl . Évalué à 3.
Mon gnome-term c'est un 2.6.0 compilé pour l'occassion sur ma basse de test.
Après a vrai dire je m'en fou que sur un exemple X ou Y soit le plus rapide. A l'utilisation gnome-terminal à des lenteurs et beaucoup de personnes l'ont constaté et sont repasssées a contre coeur sur de l'xterm. Comme souvent quand on compare des programmes interactifs on s'en fou royal de savoir qui est le plus rapide ce qui est interessant c'est qui semble le plus rapide ! Bref celui contre lequel on ne peste pas a attendre quand on bouge son curseur dans un Vim en fullscreen c'est ce qui m'a fait arreter GT. Si tu passes ton temps a attendre que ton term reagisse il est temps d'en changer quelque soit son nom.
Si le support d'X ou Y plombe les perfs il n'y aurait pas moyen de désactiver le support pour retrouver de la patate lorsque la fonctionalité est inutile ? (j'y connais rien dans ce domaine). Moi j'aime bien GT simplement il m'a tellement enervé que je l'ai viré :-/
[^] # Re: Psssssssssss
Posté par 007 . Évalué à 0.
Les utilisateurs arabes, etc doivent être très content. Les autres sont libres d'installer xterm ou équivalent. Et s'ils sont très satisfaits d'xterm, ce n'est pas une raison pour descendre en flamme GT. Moi même sur du matériel un peu vieu, je resort un "vieu" rxvt.
Le seul truc qui me gonffle dans GT, c'est lors de la compilation d'application. Dans ce cas j'ouvre un nouveau tab et je mets le focus dessus. Et voilà :-)
[^] # On ose dire du mal de xterm?
Posté par calandoa . Évalué à 3.
Et hop :xterm -en UTF-8 -fn '-*-fixed-medium-r-normal--12-*-*-*-*-*-iso10646-1'
Par contre, si quelqu'un connait un autre terminal capable d'accepter ou non le line wrap, qu'il me fasse signe... j'ai essayé rxvt/aterm/eterm/konsole/gnome-terminal et je n'ai jamais pu trouver comment faire ça alors qu'il s'agit pourtant d'une fonctionnalité de base! mais bon c'est tellement plus fashion de faire des trucs semi-transparents ou anti-aliasés...
# "Linux"
Posté par Colin Leroy (site web personnel) . Évalué à 3.
Le truc, c'est qu'il est vrai que mon iBook met pas mal de temps à démarrer entièrement, jusqu'au xdm. Le PC de ma copine (un Duron 1.3) aussi prend son temps, pourtant pas c'est un ordi rapide.
Linux n'est pas lent, il passe la main à init en 5 secondes. init ensuite lance tout un tas de trucs dont je n'ai pas un réel besoin, mais que je préfère avoir (ssh, apache) et ça prend du temps.
Mais une fois loggué, mes applis arrivent très vite, jamais ça ne swappe, jamais ça ne rame. Pour moi c'est ça l'important, pas le temps de démarrage supérieur à celui du Windows de mon boulot. (Parce qu'un portable sous Linux, ça ne se redémarre pas).
[^] # Re: "Linux"
Posté par deftones_chris . Évalué à 2.
Tu pourrais en effet le faire... On ne parle pas de démarrage mais d'utilisation de plus en plus important de ressources comme la mémoire qui aura une forcemment une répercussion sur l'utilisation.
Tu dis que cela ne swappe pas... mais pour combien de mémoire ? car avec 128Mo, j'ai dû mal à croire que tu tournes avec un Kde + Mozilla + Ooo + un lecteur de mp3 sans que cela swappe.
[^] # Re: "Linux"
Posté par Colin Leroy (site web personnel) . Évalué à 4.
(oui, sylpheed-claws leake pas mal. pas trouvé d'où ça vient).
Après reboot ça donne ça: http://www.colino.net/top2.txt(...)
(comme je suis pas devant je peux pas me reconnecter facilement, donc y'a pas d'applis).
Il faut pas oublier de prendre en compte le cache là dedans...
[^] # Re: "Linux"
Posté par Volnai . Évalué à -1.
Bon Ok, les iBook ont une tres bonne autonomie, mais faut quand même pas pousser...
# C Xfree86 4.0.x qui bouffe la dose de RAM
Posté par syj . Évalué à -1.
Que KDE ou Gnome utilise 100 Mo, çà ma parrait normal vu le nombre d'image qui sont utilisé pour décorer l'interface.
çà m'a toujours parru étonnant que X bouffe autant de mémoire.
En comparaisont. Un Windows NT4 chargé sans rien de lancé bouf 60 Mo de Ram. Mais là, il y a entre autre en plus un explorateur de fichier, un windows manager, et une barre de tâche de lancé.
[^] # Re: C Xfree86 4.0.x qui bouffe la dose de RAM
Posté par Colin Leroy (site web personnel) . Évalué à 8.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
8582 root 15 0 75048 29m 52m S 0.0 4.7 13:44.41 X
75Mo de ram, dont 52m SHARED = mémoire utilisée par des libs partagées avec les applis qui en ont besoin.
[^] # Re: C Xfree86 4.0.x qui bouffe la dose de RAM
Posté par un_brice (site web personnel) . Évalué à 4.
# Ritournelle
Posté par ploop (site web personnel) . Évalué à 7.
Quand te dé-grand-gros-gras-linux-eras-tu ?
Je dé-grand-gros-gras-linux-erai
Quand tous les grands-gros-gras-linux
Se dé-grand-gros-gras-linux-eront.
Ô d'autres gamins la-bas -->[]
# 256 Mo recommended
Posté par Ayrton . Évalué à 1.
C'est faut ou pas ?
Debian ou Slackware vont peut-être indiquer 128 Mo "recommended" en graphique mais on sait tous que c'est faut. Aucune distribution n'est satisfesante avec 128 Mo en usage bureautique. A moins d'utiliser twm, dilo, balsa, lyx etc. La différence n'est pas dans la distribution mais dans les programmes qu'on utilisent.
[^] # Re: 256 Mo recommended
Posté par Gniarf . Évalué à 2.
# et que KDE
Posté par Geo Vah . Évalué à 1.
- Traitement de Texte (KOffice)
- Navigateur (Konqueror)
- Messagerie Instantanée (Kopete)
- ...
90% des applications nécessaires non ?
Maintenant si j'utilise mozilla : j'ai un toolkit graphique en plus de chargé, openoffice je charge encore un toolkit graphique, et pis tant que j'y suis... galeon encore un tookit graphique :
le fait d'avoir plusieurs toolkit graphiques en mémoire oblige donc à charger plusieurs libraries, GTK, KDE/QT, ... !!!
Ce soir je vais tester la mémoire utilisées en ne chargeant que KDE...
[^] # Re: et que KDE
Posté par Joris Dedieu (site web personnel) . Évalué à 6.
Je pense que si on éliminait les redondances on gagnerai beaucoup en perf. Ça doit être à mon avis le prochain boulot des distros.
Y a le problème des toolkits mais aussi celui des composants et de la modularité (je les appelle comme ça. Peut-être un informaticien éclairé pourra-t-il me donner le terme exact).
Je lance OO et alors que mon système sait déjà faire tout ça très bien, je me retape les fonctions suivantes (sans parler du toolkit) :
gérer des zip
afficher des images
parser du xml
exporter en pdf
gérer des fichiersgérer l'impession
...
pour peu que j'ai konqueror lancé en parallèle ça fait pas mal de code en double.
Le modèle du bazars trouve ici sa limite. Il et sur qu'avoir du choix c'est super, mais il faut se donner les moyens de ce choix. Ça veux dire que ce qui existe un fois n'a aucune raison d'exister deux fois.
Je dis peut-être des conneries ----> dans ce cas n'hesitez pas à me le dire. J'essaye juste d'exprimer un sentiment que j'ai dans l'utilisation courrente de linux
Je me demande également si mono n'est pas une reponse possible à ce probleme ?
[^] # Re: et que KDE
Posté par 007 . Évalué à 0.
Sûrement.
> dans ce cas n'hesitez pas à me le dire.
C'est fait :-)
> Y a le problème des toolkits
??? Quel problème ? Tu veux une "dictature" qui impose gtk+ ou qt ?
Tu veux qu'on virer la partie "thèmisable" des toolkits qui bouffe de la mémoire ?
> mais aussi celui des composants et de la modularité
Sans modularité il n'y a pas réutilisation. Il faut de la modularité. Point final.
> Je me demande également si mono n'est pas une reponse possible à ce probleme ?
En quoi ?
[^] # Re: et que KDE
Posté par Joris Dedieu (site web personnel) . Évalué à 3.
Je me dis juste qui s'il y à pas une seule distro sortie d'usine qui propose des boites de dialogue enregistrer sous, imprimer ...etc , commune à l'ensemble des applications c'est qu'il y a un problème quelque part.
Je me dis juste que la modularité de gnome n'est pas celle de kde qui n'est pas celle de Openoffice, qui n'est pas celle de mozilla.
On ne retrouve pas la cohérence des commandes GNU dans les interface graphique. Pourquoi ce système si clair et intelligent deviens dès qu'il faut cliquer quelque part un peu bordellique. Impliquant trente technologies distincte pour des choses similaires ?
Alors je me dit qu'il manque un outil. Et que cet outil c'est peut-être mono.
[^] # Re: et que KDE
Posté par 007 . Évalué à 3.
Mais c'est du logiciel libre. Et oui. Il n'y a pas une haute instance qui dit : seulement qt ou seulement gtk.
Si tu veux un système contraignant avec seulement un toolkit, alors vas voir du côté des systèmes proprio. On ne peut pas avoir le beurre et l'argent du beurre.
> Alors je me dit qu'il manque un outil. Et que cet outil c'est peut-être mono.
Si tu obliges tout le monde à utiliser mono. Mais tu n'y arriveras pas....
[^] # Re: et que KDE
Posté par Joris Dedieu (site web personnel) . Évalué à 3.
2. L'interoperabilité reste un objectif important pour garantir la diversité (si gtk et qt étaient incompatibles l'un des deux n'aurait survécu)
3. librairies et toolkit sont la vision d'une certaine informatique informaticienne. L'important pour l'utilisateur c'est de pouvoir agencer harmonieusement des briques logicielles sans avoir à sacrifier la diversité ou la performance
4. Je ne pense pas que tout le monde veuille utiliser mono. Je pense que mono peut-être une nouveauté bienvenue dans la manière de concevoir des applications.
On pourrait par exemple imaginer qu'une application s'adapte aux briques logicielles qu'elles rencontrent. Mono parcequ'il est résolument multi-plateforme propose l'esquisse d'une api de haut niveau capable à terme de s'adapter à la diversité des composants système.
Mono sera-t-il le slimfast de systeme GNU ;)
[^] # Il nous faut des composants !
Posté par Olivier Grisel (site web personnel) . Évalué à 4.
Je suis assez d'accord. Il existe pourtant une solution partielle à ce problème qui permet de conserver (patiellement) le modèle du bazar : l'utilisation de composants intéropérables.
Des initiatives comme D-BUS de freedesktop.org et les composants XPCOM de Mozilla sont crucialles pour résoudre ce problème de libs redondantes. Il est vraiment urgent que les développeurs des projets desktops majeurs (KDE, GNOME, Mozilla et OOo) se mettent d'accord pour utiliser une infrastructures de composants communes pour tout ce qui concerne les libs de bas niveau (eg. xml, réseau, zip, traitement d'images, de son et de videos, ...). Et tout cela de manière indépendante du langage de programmation utilisé.
C'est un boulot de coordination et de standardisation énorme mais il semble que l'initiative Freedesktop et le rapprochement GNOME/Mozilla représente un premier pas dans cette direction.
# J'en ai marre de mettre des titres
Posté par Infernal Quack (site web personnel) . Évalué à 4.
N'importe quelle distrib est tunable. Faut savoir virer les services qui servent à rien et utiliser les outils qui sont adaptés à sa configuration.
Sous XP c'est pareil et sous n'importe quelle OS.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: J'en ai marre de mettre des titres
Posté par patrick_g (site web personnel) . Évalué à 2.
Je t'invite à relire ma phrase.
Quand j'écris que "sa critique exclut donc une slack"...etc cela ne fait pas référence au fait de pouvoir être "tuné" mais au fait d'être grand public.
[^] # Re: J'en ai marre de mettre des titres
Posté par 007 . Évalué à 0.
[^] # Re: J'en ai marre de mettre des titres
Posté par patrick_g (site web personnel) . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.