007 a écrit 2187 commentaires

> est ce que c'est prévu pour de prochaine version ?

Non. Mais es-ce bien génant que d'insérer des CD sous les 6 mois pour faire une mises à jour ?
Parfois la mise à jour avec yum ou apt marche mais c'est un heureux hazard.

J'ai dit : "une distribution soit-disant compliquée".

> This doesn't affect NetBSD Stable.

Ni windows. Super !

Surtout ne répondez pas et continuer de moinser.
Bande de ploucs.

Pour information personnelle. Pourquoi les gens votent "inutile" à mon commentaire précédent ?
L'éventualité d'un bug dans une version test (qui est une beta) vous a pas effleuré ?

J'y connais rien ou presque en NFS mais la FC2T2 est sortie 6 semaines avant la finale.
La finale est dispo depuis un mois :
http://www.redhat.com/archives/fedora-announce-list/2004-May/msg000(...)

NB : on ne peut updaté de FC2T2 à FC2 finale. Inutile de "gueuler", ça n'a jamais été prévu. Les test releases sont des test releases (étonnant. Non ?).

T'es (maintenant) sous Mandrake et t'es content.
Je suis sous Fedora et je suis content.

Il y a un autre point commun. On se sent pas obligé d'utiliser une distribution soit-disant compliquée pour prouver qu'on est grand.

> mais est révélateur de l'état d'esprit présent dans beaucoup d'entreprises.

Dans les entreprises, ils en n'on rien à foutre d'avoir le driver NVidia qui roxe en 3D ou d'avoir un noyau basé sur un 2.4.21 qui date d'un an.
En entreprise on n'achete pas le matos dernier cri pour se la péter comme des oufs.
L'article n'est absolument pas représentatif de ce qui se passe en entreprise.

> -> Manque de visibilité sur toutes ces histoires de licences, de droits (SCO contribue à cette cacophonie)

Il n'y a aucun manque de visibilité !
Ce qui "favorise" le logiciel proprio, c'est son opacité (comment controler si t'as pas les sources...).
Encore un FUD qui vient d'un membre de la communauté...

> puis avoir des moyens ne signifie pas qu'on souhaite jeter l'argent par les fenetres.

Car payer pour du logiciel proprio c'est bien et payer pour du logiciel libre c'est "jeter l'argent par les fenetres" ?

> Il me semble pas que .rpm puisse faire ca.

rpm peut le faire. En fait .dep ou .rpm ne font pas ça. Mais ils ont des "triggers" pour le faire. .deb utilise cette fonctionnalité pour une configuration interactive (avec debconf je crois) et les .rpm qui sont crée ne le font pas. Mais techniquement rien n'empêche de faire la même chose avec .rpm. Tout en sachant que ce n'est pas .deb ou .rpm qui le fait mais debconf (il me semble).

Merci pour l'info.

> il te demande la chaine, l'heure de debut / fin etc.. et genere une tache "at" et ca roule :)

J'ai mes petits scripts et ça donne par exemple :
$ at 21:30
at> record_FRANCE2 "Le bonheur est dans le pré" 1:40:00

et voilà :-)

> J'enregistre en xvid ma tele avec une charge de 40% du proc sur Athlon XP 2200+.

Je peut descendre à 40 % même avec mon petit xp 1600+. L'avantage avec mplayer c'est "-vop hqdn3d=3:3:8,scale=384:288". Je fais l'acquisition en 768x576 et mplayer fais la réduction d'image en moyennent. Puis j'ai encore un filtre "hqdn3d" qui vire les petites imperfections.

J'ai une autre petit question qui me trouble.
J'ai une voie "virtuelle" dmix dans alsa (visible avec "arecord -L" par exemple). C'est "livré de base" et j'ai rien modifié pour l'avoir.

lorsque je fais plusieurs "mplayer -ao alsa1x:dmix *.mp3" ça marche nickel.
Par contre si je fais ça sur un fichier video avec mplayer, la video est légèrement saccadée.

Une idée/conseil ?

> apparement légal.

C'est légal. D'ailleur RedHat l'a reconnu dans une interview et ils savaient parfaitement que celà allait arriver.

Il y a aussi whitebox linux :
http://www.whiteboxlinux.org/(...)

Mais bon, faut garder en tête ce que l'on fait.
Ces distributeurs n'ont en rien participé à RHEL...

Si RHEL est trop cher, prend une Fedora ou une Debian ou autre chose. Mais une copie d'RHEL...
Je sais, on va me dire qu'Oracle tourne sous RHEL. Mais si on a les moyens pour ce payer Oracle on a les moyens de se payer une RHEL (puis ça participe au logiciel libre).

J'utilisais rxvt et xterm avant. Donc je ne nie pas la lenteur de GT. Mais j'aime pas quand GT se fait critiqué de bloat, de bouse, etc. Il fait des choses que les autres ne font pas.
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à :-)

> A propos des licences, est-ce qu'on est obligé d'acheter une licence pour chaque serveur

Oui. Ou alors tu supprimes tous tes contracts de maintenance avec RedHat.

> typequement sur ce serveur que me servirai de "proxy" pour mes updates, je me fiche un peu du support .... idem pour un serveur qui servira de serveur kickstart , etc ....

Utilise qu'un serveur pour tout ça. C'est pas cher (RHEL ES) :
http://www.redhat.com/apps/commerce/cart.html?store_cart:add_item_c(...)
349 $
Voir utilises RHEL WS qui a squid (179 $).
Mais en place un proxy squid puis configure up2date des postes sous RHEL pour utiliser le proxy squid.

Puis si c'est toujours trop cher, ton proxy squid, tu le mets sous Fedora ou Debian ou Gentoo ou...

Bref, ça ne manque pas choix. Contact RedHat directement.

Et bien fait le !
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.

> 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...

$ 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.

avec uxterm en plein écran :
$ 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.

> 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.

Si tu le dis....

Ben utilises xterm (qui afficher correctement 2^32/2^8 (soit 1/16777216) caractère de utf8) et basta.

Et xterm est lent par rapport à une console virtuelle (il y a un rapport de 10 minimum). C'est un argument pour dire xterm est une bouse ? Non.

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".

Donc si on n'est pas "grand public" on n'est pas critiquable sur ce point ?

C'est le "fond" de ta pensée que je critique. Techniquement tu as raison. Moins de toolkit, moins de librairies à charger. C'est simple.

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....

> ah mais rassure-toi, je n'utilise pas cette grosse bouse

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.

> Je dis peut-être des conneries

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 ?

> la capacité a afficher du klingon n'excuse pas d'être 20 fois plus lent que les autres

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.