J'ai relu attentivement l'article. J'ai lu vos commentaires.
Ya encore un boulette dans l'article :
> RedHat 9.0 : codename Shrieke
C'est shrike.
On est plus à ça...
C'est un test baclé.
L'autre truc désagréable, c'est que frlinux ne manque pas une occasion pour rappeler qu'il a eu des problèmes avec la 8.0 .
frlinux m'a solicité pour connaitre les différences entre RH8.0 et 9. Les seuls trucs retenus sont négatif.
Je rappelle une parties du mail (ce sont mes propos et non ceux de frlinux) que je lui ai envoyé :
* Passage à rpm v4.2 :
- création de paquets debuginfo (symbol et source) pour debug. Excellent. Ces paquets ne sont pas fournis avec la RH9.
- contrôle plus fin lors de la construction de paquet. Par exemple, tu construits toto-1.0.i386.rpm. Les fichiers du paquet sont piochés de /var/tmp/toto-root lors de la construction. Si un ficher dans "buildroot" n'est pas référencé, la construction du paquet échoue. Ça évite d'oublier des fichiers.
- plus de deadlock avec rpm -Uvh. Enfin! c'était une peste sous RH8.0.
* Le mode dma pour cdrom est activé par défaut. Sur la RH8.0 le dma est
interdit pour les lecteurs cdrom/dvd. Pour contourner ce problème il
fallait ajouter une options pour ide-cd dans /etc/modules.conf ou en
paramètre noyau.
* subversion est livré. Malheureusement c'est une version de test seulement. Par exemple il n'y a pas le nécessaire pour faire un serveur subversion. la version livré intègre neon, http-apr, etc... tout le nécessaire dans un paquet et non splité en plusieurs paquets comme c'est fait par les mainteneurs de subversion : http://summersoft.fay.ar.us/pub/linux/redhat/RPMS/i386/subversion-l(...)
* Les coredumps sont par défaut suffixé du pid du programme qui a planté (pratique pour éviter qu'un core dump soit écrasé). C'est configurable via /etc/sysctl.conf (introduit dans RH7.3 je crois) qui est lu au boot. idéal pour un :
dev.rtc.max-user-freq = 1024
J'suis d'une naïveté parfois...
Je crois que ce soir je vais me coucher avec en ayant mal au cul.
> Le probleme etant que des devs n'utilisent pas (ou ne devraient pas utiliser) des distribs betas. Mais c vrai que pour wine depuis la sortie de la beta de RH ils travaillaient dessus.
C'est plustôt bon ça. Ça montre qu'il faut fournir ntpl "out of the box" pour que les devs se penche sérieusement sur le problème. C'est pas sans soucis évidement, mais un y a un côté positif. Dans 6 mois la grosse majorité des applis fonctionneront avec ntpl et toute les distributeurs pourront sortir une distribe avec ntpl sans essuier les "critiques" que subit redhat actuellement.
Il faut que les distributeurs "osent". Mandrake utilise acpi et je m'en félicite même si je n'utilise pas une mandrake. Car c'est du libre et que les autres distribes en profiterons. redhat sort ntpl et ntpl est dans cooker maintenant et sera présent dans la prochaine mandrake. Que du bonheur! Ce type d'initiative fait avancer le logiciel libre. Et si la redhat 9 ne vous plait pas, c'est pas grave. Si elle ne fait pas marcher vos programme favoris, c'est pas grave, utilisé autre chose.
Ce qui est "choquant", c'est quand ceux ceux qui n'utilisent pas une redhat 9 se plaignent du chois fait par redhat de mettre ntpl. Or ils profiterons à moyen terme (6 mois, c'est court) du boulot, de l'"impact" de la sortie de cette distribe (ce qui est totalement normal).
> Oki mais la version 2.4 n'est pas exactement la meme.
ntpl est surtout côté glibc. Et la glibc 2.3 marche très bien avec 2.4 et 2.5 sur mon système. Merci.
> mais si on pouvait simplement suspendre les taches a volonte (ce que ne permet tjs pas les NTPL)
Humm. Tu as un lien ?
> Elles peuvent vraiment pas car la norme posix pour les threads est trop limitee
Tu es sûre ? Linux a eu du mal pour avoir une implémentation 100 % Posix.
> après 2s de recherche sur google...
Je suis une grosse faignasse parfois...
> le fait est que si ça pète le fonctionnement de nombreux programmes, c'est un peu dommage.
On ne le dira jamais assez :
- linux-thread est présent dans la rh9
Par contre, ce n'est pas le système de threading par défaut. Voir la release note :
http://ftp.crihan.fr/mirrors/ftp.redhat.com/redhat/linux/9/en/os/i386/RELEASE-NOTES-fr.html
Le choix de faire de ntpl le système de threading par défaut est discutable.
> Je pense, peut etre à tort, que ce genre de trucs devrait etre beaucoup plus testé
ntpl n'a pas vraiment de défaut actuellement (il en reste évidement). Le problème c'est que des applis n'ont pas un usage standard des thread. Il y a plein d'appli qui utilise ntpl sans recompilation et d'autre qui marche dès le début avec une recompilation.
> Pour finir, je pense que tu dois reconnaitre que le "produit" RH Linux d'aujourd'hui n'est comparativement plus le même que ce qu'il était à l'époque des version 6.x et 7.x. Il est évident que RH s'en sert beaucoup plus comme d'un laboratoire pour ses versions pro (et payantes)
Je le reconnais et ce que tu dis est très vrai ! D'ailleur je l'ai déjà dit :-) :
http://linuxfr.org/comments/187048,1.html
Je commence par :
- "La distribution RedHat Linux n'est plus ce qu'elle était. Avant c'etait une solution professionnelle disponible pour 0 avec un support de 3 ans. Maintenant c'est une distribution pour la communauté ou un usage personnel (web/bureautique/developpement/etc)."
> Il est évident aussi qu'un tel changement de politique peut ne pas plaire à tout le monde
Il ne me plait pas. Je veux dire de faire de RHL une distribe qui ne peut être utilisée en production ne me plait pas. Mais ce qui compte c'est que redhat fasse toujour du logiciel libre.
Tiens, ils ont sorti un truc développé sous GPL (très proche de la gpl, c'est l'équivalent de la gpl mais rédigé par ibm) :
http://www.redhat.com/software/rhea/
> maintenant le fait de l'integrer sans trop tester (et c'est le cas vu la maturite du portage) et sans chercher a "prevenir/aider" des projets importants du LL qui en subiront les consequencs...
La première beta de la rh9 avait ntpl. Et l'annonce signalait aussi ntpl :
http://linuxfr.org/2002/12/24/10790.html
Pour la "maturité", ça fait depuis 6 mois au minimum que ntpl est dans 2.5 et le cvs de glibc. Le problème de wine, jre, realplay, etc... est qu'ils font un usage non posix des threads. C'est pas un reproche ! la nouvelle implémentation est plus exigente. Le problème, est que ntpl ne peut être modifier pour supporter les astuces "tordus" de linux-thread. Il faut que les applis s'adaptent pour faire une code 100 % posix.
C'est comme pour gcc 2.95 -> gcc 3.
C'est chiant, c'est vrai, mais c'est un mal nécessaire.
> depuis les applis que j'utilise le plus souvent sous nux sont mortes :((((((((((
Tu as testé avec LD_ASSUME_KERNEL=2.4.1 qui est justement là pour ne pas utiliser ntpl mais linux-thread ?
> que personne ne savait trop comment ca marche les NTPL (merci RH).
http://people.redhat.com/drepper/
Petit rappel. NTPL est posix et linux-thread est posix aussi. Les problèmes que "révèlent" NTPL, sont les usages non posix de linux-thread. C'est comme pour les montées en version de gcc.
Pour "downgrader" un paquet il faut utiliser "rpm --oldpackage".
En cas de problème, il faut penser à fouiller http://bugzilla.redhat.com/ . Ça n'enlève rien au fait que Redhat a fait une connerie (je dis ça ceux qui vont dire que je fais du publi-reportage) mais ça peut aider.
Essaies :
ftp://people.redhat.com/jakub/glibc/errata/8.0/
C'est une version qui devrait corriger le problème.
> aux critiques d'un obscur site de troisième zone
Je pense que son test est fait honnêtement et n'est pas motivé par une envie de "casser" du redhat. Il y a quelques imprécisions/manques. Et j'en suis partiellement fautif. Par exemple ce problème dma/highpoint dans la nouvelle interface IDE, c'est moi qui lui est souffré à l'oreille car il m'a demandé des infos sur les différences entre rh8.0 et 9. Je me suis peut-être mal exprimé ou je ne sais quoi mais il a fait une erreur.
Et alors, qui n'en fait pas ?
frlinux connait mieux mandrake que redhat et il est normal qu'il y ait plus d'erreur pour un test redhat que mandrake. La faute serait de ne pas chercher à s'améliorer dans les tests de redhat.
> un obscur site de troisième zone
frlinux publie son avis. La news est accèpté sur linuxfr. No problemo. Tout les avis sont bons. Ce que je n'aime pas, c'est la mauvaise foi. frlinux n'a pas, selon moi, fait preuve de mauvaise foi.
> surtout de ta part et dans les yeux d'houplaboum (qui a beaucoup d'affection pour toi, semble-t-il ;-))
J'aime bien ce type de relation passionnelle^W irrationnelle.
> C'est surtout que tu t'adresse à l'auteur personellement.
C'est juste. J'ai hésité. Au début je voulais faire un réponse privé et une public. Quand j'ai vu qu'il n'y avait que ça de "privé", je n'ai fait qu'une réponse public.
Notes aussi que c'est une réponse public sur un article public. Rien à voir avec une tarte aux amandes que tu boufferas chez toi. Bon appétit.
> Pas de pot, c GPL http://burrittway.org/linux/docs/bclinux10.html
J'ai dit Si, en gras dans le texte. Merci pour l'information.
> c'est dommage, avant il y avait un panneau de config RH ET les entrées dans le menu....
J'ai pas compris.
> Je suis donc très curieux de savoir ce qui se passe à présent qu'ils intègrent des choses telles que la NPTL.
J'utilise RH9 depuis 1 semaines sans problème. Et les rares programmes qui posent problème avec NPTL, par exemple realplay, je les lance avec "env LD_ASSUME_KERNEL=2.2.5" et ça roule.
Ben mandrake a aussi sorti un truc pas très testé comme redhat le fait avec ntpl.
> La fixation sur la comparaison RedHat / Mandrake, c'est maladif ou tu te forces?
Ce qui me gonffre, c'est que lorsque RedHat sort un truc, systèmatiquement ya les critiques qui fusent :
- pas fiable
- pas compatible
- etc...
Mandrake innove aussi (et c'est très bien) et n'a jamais de critique. Et moi ça commence à me brouter sérieusement.
J'ai rien contre Mandrake. C'est cette différence de traitement qui est trollesque, puante qui me les casse.
La prochaine Mandrake (avec linux 2.4) aura surement NTPL et je suis sûr qu'il n'y aura pas la moindre critique.
NTPL EST le nouveau standard pour les thread. RedHat pousse, aide son adoption et c'est très bien.
> chercher a imposer la NTPL par rapport aux NGPT (sponsorise plutot par IBM)
C'est se foutre de la gueule des devs Linux ce type de propos. Les devs Linux on choisi NTPL pour Linux 2.6. Ils sont grands et pas facilement impressionnables.
RedHat en sortant RH9 avec NTPL, va aider sont adoption et le fiabiliser. C'est tout benéfice pour Linux 2.6. Faut aussi remarquer qu'Alan Cox a développé le nouveau code IDE (initialement pour 2.6) avec le 2.4 et que tout le monde l'utilise et personne ne se plaind.
> 1) C'est la NGPT qui sera dans le 2.6 (ou le 3.0), donc incompatiblité entre la RH9 et les versions futures
C'est la même implémentation. (C'est 2.6 officiellement).
> 2) La NGPT sur un 2.4 fait quand même office de grosse verrue par rapport au support des threads actuels
Pourquoi ?
> qui est ce qu'il est, mais qui fonctionne
La nouvelle implémentation ne marche pas ?
> 3) Etant un patch sur le 2.4, bonjour les incompatibilités.
Oui et non. C'est comme fournir apache 2. Il y a des incompatibilité. Mais il y a toujour l'ancienne version. Voir : http://linuxfr.org/comments/193003,1.html(...)
> Maintenant, l'intégration de ce genre de chose chez les entreprises qui veulent être à la pointe (et qui ont donc des compétences internes très souvent), se fait par l'application des dits patches directement par la société, avec toute une batterie de tests à la cléf pour vérifier que ça fonctionne bien.
Ben c'est RedHat qui a fait ce boulot. Doit-on se plaindre ?
> L'intégration d'une telle fonctionnalité dans une distribution basée sur une 2.4, sachant les problèmes que ça risque d'engendrer, est pour moi 1) une erreur 2) très risqué
Tu peux me sortir la même phrase pour Mandrake qui vient de sortir acpi ?
> En tout cas, je trouve ça osé de la part de RH d'inclure quelquechose de si peu testé dans une distribution officielle.
de la release note :
==========================================
Si une application ne fonctionne pas correctement avec NPTL, elle peut être exécutée à l'aide de l'ancienne implémentation de LinuxThreads, en réglant la variable d'environnement suivante:
LD_ASSUME_KERNEL=<kernel-version>
Les versions suivantes sont disponibles:
- 2.4.1 Linuxthreads avec piles flottantes
- 2.2.5 Linuxthreads sans piles flottantes
Le support NPTL pour toutes les applications liées dynamiquement peut êtredésactivé à l'aide de l'option boot-time suivante:
C'est un 2.4.21-pre3 . Pour Mandrake tu as aussi fait cette erreur (c'est un 2.4.21-pre4 et non un pre5).
> l'enregistrement des machines sur lesquelles se trouve la RedHat (fournissant au RHN la liste de vos RPMs ...
Fournir la liste des RPM est optionnel.
De plus : http://www.redhat.com/software/rhn/legal/(...)
- "Uses of Data from Red Hat Network
Under confidentiality agreements, Red Hat may match user information with third-party data. Also, Red Hat discloses aggregated user statistics in order to describe our services to current and prospective partners, advertisers, and other third parties. Please note though that none of your personal information will ever be sold or shared with outside parties."
> Je dois dire que je ne suis pas un grand fan de BlueCurve.
de : http://frlinux.net/?section=distributions&article=89(...)
- "en fait surtout le thème Blue Curve qui est assez réussit"
- "de plus le thème Blue Curve est très sympathique."
Contrairement à RH8.0 et gnome 2 il est possible de changer de thème avec une interface graphique. Je n'ai pas vérifié avec Kde.
> Ma carte réseau (une broadcom 4400 intégrée sur mon Asus a7v8x) nécessite des pilotes qui sont sur le CD des pilotes de ma carte mère.
Si les drivers sont proprios, c'est normal. RedHat a fait le choix de ne fournir aucun driver proprio (drivers dont il ne peuvent modifier les sources).
> Plutôt qu'une approche de panneau de configuration tout en un, RedHat a opté pour des raccourcis permettant de faire une tâche chacun. Vous pouvez les voir en ligne de commande directement en tapant : redhat + tab + tab (oui deux fois))
C'est redhat-config- le prefix. Mais ça ne change pas grand chose.
Sinon tout ces outils sont regroupés dans le menu "Outils système".
> J'ai installé manuellement les modules de ma carte réseau mais ils n'apparassaient pas dans la liste (je m'y attendais quelques peu)
C'est normal. C'est kudzu qui prend en compte les nouveaux modules. Il faut soit lancer kudzu de nouveau (service kudzu start) ou rebooter.
> A signaler que des problèmes sont en vue pour les possesseurs de RAID (soft raid) et le déplacement des disques car Anaconda (l'installateur de RH) ne fait pas bien sont travail.
Ce n'est pas anaconda qui fait mal son boulot. De plus il ne déplace pas les disque. C'est qu'il exige que les partitions utilisées pour le périphérique raid correspondent à ce qui est marqué dans les infos raid. Il est plus exigent que la détection automatique par le noyau. Si tu déplaces (physiquement) un disque avant d'utiliser anaconda et que tu ne mets pas à jour ces infos, ça coince. Si tu crées le périphérique raid (logiciel) avec anaconda, il n'y a pas de problème.
> Un petit chmod 666 plus tard (soyons brutal), tout marche dans le meilleur des mondes.
Il faut utiliser /etc/security/console.perms
> En parlant des modules, devices et autres joies du kernel. J'ai rencontré un problème sur le loopback (possibilité de monter une iso du disque dur vers un répertoire du disque dur). Il ne m'a pas été possible de les démonter par la suite. On m'a également signalé le problème sur d'autres machines.
Si c'est par rapport au mail que je t'ai envoyé, j'ai fait un correctif que je te rappèle :
> > > * Côté noyau, je trouve la RH8.0 réellement rock solide. J'ai eu
> > > quelques problèmes avec la RH9 :
> > > - interface loopback (/dev/loop0) que je ne peut plus virer
> > > - Impossible de démonter un système de fichier alors qu'il n'est plus
> > > utilisé.
> > >
>
> Je "jouais" avec kickstart et j'ai monté des partitions cramfs (système
> de fichier compressé). Malheureusement, les partitions cramfs ne sont
> pas visibles avec df. Les problèmes ci-dessus, n'existent pas.
Pour moi, il n'y a pas de problème. Ou alors un problème avec df uniquement. La commande mount me donne les bonnes info.
> La RedHat 9.0 utilise un nouveau code pour l'IDE, désactivant d'un coup la possibilité de toucher aux DMA si les lecteurs CD/DVD sont sur une carte Highpoint (problème vu aussi dans le kernel 2.5).
Il utilise le nouveau code développé par Alan Cox et disponible dans Linux vanilla depuis 2.4.19. Par contre pour la RH 8.0 RedHat n'a pas utilisé ce nouveau code même si le noyau était un 2.4.19-rc1-ac1. Pour la RH9, RedHat utilise ce nouveau code comme mandrake et les autres.
> J'ai l'impression que vous avez pris mes arguments comme beaucoup plus agressifs que ce que je veux dire. J'essaie juste d'exprimer une problematique, pas de flamer ou de troller (meme si j'ai du mal a resister a la tentation sur des remarques corollaires).
Y a pas de problème. Par contre , j'ai pas aimé le "base de registre".
> Pour gconf, ce n'est pas le programme en soi que je critique, c'est que a l'heure actuelle, certaines options de certaines applications ne sont accessibles que par gconf.
Si tu ne veux pas troller, évite "ne sont accessibles que par gconf" :-) . Mais dis "ne sont pas accessible à un novice" ou "n'est pas intégré à l'interface de l'appli". C'est pas gconf le problème. Si l'option est uniquement modifiable avec un éditeur de texte, le problème reste entier.
> Je pense que cette attitude precise (s'en remettre a gconf sans fournir une vraie interface graphique)
C'est s'en remettre à gconf (ou autre) pour les cas particuliers. Ça donne de la souplesse sans alourdir l'interface de l'application. gconf-editor n'est pas là pour remplacer le menu "paramètre""préférence" de galeon. Ça n'a jamais été l'objectif. C'est fournir une moyen de configuration pour quelques options avancées qui n'interressent que 2 % des utilisateurs sans "polluer" les autres utilisateurs. Gecko fourni des tonnes d'options et galeon ne permet d'en modifier que 10 % maximum. Qui ça gène ? croix tu que galeon doit fournir une interface graphique pour toutes les options de gecko (donné l'url about:config pour voir la liste complète).
> va a contresens du but de projets comme KDE et Gnome, qui est, rappelons le, de fournir des applications coherentes, completes et conviviales.
C'est ça que je comprends pas. Que les outils en ligne de commande soient là pour satisfaire tous les besoins de tout les utilisateurs, je comprend.
Fais un "man mkisofs" et dit moi si le fait de couvrir toutes les options de mkisofs est compatible avec une interface conviviale et accessible à tout le monde.
Selon moi, on ne peut satisfaire tout le monde avec une appli. Il faut une appli simple pour 98 % des utilisateurs et des applis plus poussées pour ceux qui en ont besoin. Je répète, j'ai rien contre de fait de proposer plusieurs appli ! Nautilus n'est pas là pour remplacer bash ou gentoo ! gtoaster n'est pas là pour remplacer le couple killer mkisofs/cdrecord. Ce que j'aime pas, c'est que tu insinues que Gnome est contre les applis pour utilisateurs avancés. Ce n'est pas le cas. Gnome prone des applis simple pour les applis par défaut. De plus, l'émergeance de freedesktop var permettre le developpement d'autres bureaux, panel, etc... qui sont compatible mais différent. Il y aura le bureau gnome pour les "neuneux" (présent !) le bureau kde pour les "power user", etc... Certains préfèrent gnome d'autres kde. Le fait que les bureaux Kde et Gnome soient différents est positif. Si gnome doit faire comme Kde avec plein d'option, des applis par défaut pour "power user", quel est l'intérêt pour l'utilisateur final d'avoir le choix entre Gnome et Kde ? Une appli ou un bureau ou un wm ne peut pas satisfaire tout le monde.
Tu peux dire que tu préfère Kde car il a plein d'options que tu ne retrouves pas dans Gnome. Mais il me semble que tu ne peux pas reprocher à Gnome d'avoir fait le choix de la simplicité. C'est ce choix que tu ne devrais pas critiquer.
Tu peux dire :
- "dommage, il n'y a pas l'option bidule dans tel appli."
Mais tu ne devrais pas dire :
- "gnome c'est naze car ils ont fait le chois d'être simple, dépouillé pour les applis par défaut"
Moi j'utilise principalement bash et les outils en ligne de commande (faut dire que je suis "vieux" et j'ai grandi avec la ligne de commande) et je ne suis pas demandeur d'appli aussi touffue que la ligne de commande. Si j'utilise le programme de gravage par défaut, c'est pas pour me prendre la tête avec plein d'options que je ne peut comprendre qu'en lisant un Howto de 50 pages. Attention, je dis pour l'appli par défaut !
> A priori, il est tout a fait possible d'integrer dans une application des fonctionnalites accessibles aux debutants et des fonctionnalites accessibles aux experts, sans pour autant rendre l'application inutilisable ou effrayante. C'est l'objectif que defend Aaron regulierement sur kde-usability.
C'est le choix de Kde et il est respectable et bénéfique pour les utilisateurs qui aiment ce concepte.
> C'est un peu triste de voir que Havoc et Owen semblent avoir renonce sur ce plan-la et preferent la voie de la facilite en supprimant beaucoup d'options de configuration ou en les cachant dans gconf.
Pour info, il y a plus de dev Sun ou Ximian dans Gnome que de dev RedHat. D'ailleur Redhat n'est pas représenté dans la fondation gnome actuellement.
> preferent la voie de la facilite en supprimant beaucoup d'options
Ben c'est pas "facile". Il faut cherché le bon compremis. C'est peut-être plus dure que de prendre le principe "on implémentent tous les options et c'est à l'utilisateur de se démerder". Le programme doit gérer la pluspart des situations sans s'en remettre à l'expertise de l'utilisateur. Prends l'applet "liste de fenêtre", ils ont ramé pour avoir une taille dynamique de l'applet. Maintenant il y a "taille minimum" et "taille maximum" (dont les valeur par défaut sont 50 et 4096). Pour Gnome 2.4, l'applet n'aura plus de paramètre taille. Considère l'exemple que j'ai donné de virer l'option indiquant le périphérique à utiliser pour graver un cd. C'est pas simple.
> Avec la direction que prend Gnome, on a l'impression que ce genre de parametre de configuration va etre cache completement de l'application parce qu'on le considere comme trop avance, et que l'utilisateur doit rester un neuneu.
Tu trolles. Pourquoi dire "neuneu".
> Pour des projets pour KDE ou Gnome ou le but est de fournir une interface conviviale, je trouve ca dommage de renoncer justement a fournir une interface conviviale sous pretexte que seuls les utilisateurs avances peuvent s'en passer et utiliser un truc non convivial.
C'est pour les applis fourni pas défaut. Avoir un menu "démarré" avec 200 programmes dont 150 ne seront jamais utilisé par 98 % des utilisateurs n'est pas bon. Mais rien empêche l'utilisateur d'ajout son applis "avancée".
> Si le besoin apparait techniquemnt, il faut le prendre en compte. Il n'y a pas de "ergonomiquement, on n'a pas a le faire"
T'as pas compris. Par exemple : Techniquement on ne sait pas déterminer la vitesse de gravage donc on ajoute une option. Donc j'ai bien dit que des options étaient ajoutées pour des raisons techniques. Pour l'ergonomie, il serait bon de savoir déterminé automatiquement la vitesse de gravage. Malheureusement, pour des raisons techniques, on ne sait pas le faire. Et donc on ajout une option qui n'est pas "conviviale" mais techniquement nécessaire.
> Pas besoin de cacher ca honteusement dans gconf.
Tu trolles. D'ailleur le mettre dans gconf, c'est le rendre visible de façon standard.
> Tu prends un mauvais exemple puisque tu choisis de te positionner tes arguments sur l'ergonomie d'une application
Considère que le bureau, le file manager, etc... sont des applis.
> et non sur les parametres de configuration
Car les paramètres de configuration d'un graveur ne sont pas des paramètres de configuration ? Bizarre...
> - creation d'une image: cette foncionnalite est indispensable si tu veux graver des CD en serie, genre des Knoppix pour les distribuer a la linux expo.
Je parle de 98 % des utilisations. Je ne parle pas de programme fait pour des cas particuliers.
Je parle de faire une image avant de graver. Je ne parle pas de graver une image. Evidement qu'un programme de gravage doit pouvoir gravé une image. Je parle de l'étape intermédiaire de faire une image avant de graver.
> - la taille du cache peut s'averer importante. Pour un systeme comme gentoo ou tu es susceptible d'avoir des compilations pendant ton gravage, c'est important. On peut aussi imaginer que l'utilisateur regarde un divx ou un DVD en attendant la fin de son gravage.
J'ai dit 32 mo. Cette valeur est ok dans la majorité des cas. Avec ce niveau de cache, tu peux copier des gros fichiers entre disques dures, visualiser un dvd, lancer trois compilations, et le tout en parallèle. Et même sous gentoo ça doit marcher.
> De toute facon, le tu ne fais que souligner l'importance des choix par defaut intelligents (et tout le monde est d'accord), pas la problematique des options de configurations.
Je parle du besoin d'ajouter ou non une option qu'elle soit de configuration ou fonctionnelle.
> - faut-il pouvoir ajuster les fontes dans l'historique des sites visites
Aucun intérêt. Tout doit être visible. Pourquoi pas ajouter les fontes pour le menu, les bulles, etc, etc. Je préfère la notion de thème (même si généralement j'utilise le thème par défaut car j'aime pas me prendre la tête).
> - faut-il pouvoir choisir son window manager ?
Tu changes de sujet. Je parle d'applications par défaut. Je suis pour la diversité. Avoir de la diversité dans le choix du wm est un truc. Dire que le window manager par défaut doit avoir 200 options est un autre truc. Et puis Gnome permet de changer de window manager. Et si Kde respecte freedesktop, on va pouvoir utiliser le window manageur de Kde sous Gnome. C'est de la diversité. j'ai rien contre.
> - faut-il se taper une base de registre pour toucher a des parametres subtils comme la vitesse de double-clique souris ou la resistance sur les bords quand on change de bureau en passant par les bords ?
Troll puant. J'espère que tu es satisfait avec tes fichiers .ini ala win 3.11 et que tu n'as pas besoin de fixer 50 variables d'environnements. Un partout, balle au centre.
Remarque qu'il y a plein de paramètre dans /proc/sys. Tu réclames une interface graphique pour les éditer ? Tu les édites quotidiennement ? Ou tu fais comme tout le monde et fais confiance au paramètrage par défaut ?
> - faut-il pouvoir ajuster des parametres completement abscond sur les imprimantes ?
Non. Ça c'est un problème technique et non un problème d'ergonomie. Ergonomiquement on n'a pas à le faire. Techniquement c'est peut-être nécessaire. C'est comme pour la vitesse de gravage. Orgonomiquement ça n'apporte rien. Imagines s'il faut faire la même chose avec les disques dures ...
Si on savait déterminer de façon fiable la vitesse de gravage, cette option devrait être virée. C'est comme les options "activer bidule pour éviter le bug de truc". Il faut corriger truc et non ajouter une option.
> - l'option correspond a une ergonomie tres pauvre. Il faut corriger le pb d'ergonomie, fournir des parametres par defauts intelligents et remettre l'option dans un coin.
Faut déjà vérifier si l'option est utile pour une majorité et pas pour une minorité.
> - l'option semble completement debile et il vaut mieux faire un choix clair: ex : ordre ok/cancel dans les dialogues.
C'est un problème de norme. freedesktop avec Gnome et Kde (+ qq autres) y travail. Pour ma part, que le bouton "ok" soit à gauche ou à droite, je m'en fout du moment qu'il est toujours du même côté.
> - l'option n'est utile que pour un tres petit nombre d'utilisateurs, mais pour eux, elle est indispensable (parametres d'imprimantes, parametres de la vitesse de la souris, ...). On reproche a Gnome d'avoir supprime des options qui rentraient dans cette categorie-la alors qu'une approche intelligente (les mettre dans un dialogue "configuration avancee", refaire un peu l'ergonomie de l'application) permet de satisfaire a la fois les utilisateurs de base et les utilisateurs avances.
Si c'est pour un petit nombre d'utilisateur, cette option doit être viré de l'interface graphique par défaut. L'environnement par défaut doit être simple et ne pas demander de consulter 20 tableaux de configuration. Même si c'est dans un coin "options avancées", le gens vont regarder et trouver ça compliqué, ça va engendrer des tonnes de discutions stériles, le diagnostique en cas de problème est moins facile, la maintenance de l'appli plus lourde, etc... Attention, je ne dis pas de virer l'option. Je dis qu'elle de doit pas être visible dans les applis par défaut. Pour les quelques utilisateurs pour qui l'option est indispensable, ils passent par gconftool/gconf-editor ou vim/kconf, etc...
> La reponse est loin d'etre evidente comme je le disais.
Effectivement et les erreurs sont possibles et Gnome a surement viré une option qu'ils ont ajouté après. Par contre, ce que je n'apprécie pas c'est le principe "simpliste" de dire que plus il y a d'option (même dans un coin) plus on satisfait d'utilisateurs. C'est faut. Lorsque les gens font <éditer><configuration>, ce n'est généralement pas pour tomber sur 40 options dont 2 lui sont utiles, car on a voulu contenter tout le monde. Et je le répète, c'est pour les applications par défaut. J'ai absolument rien contre une autre applis avec 300 options si elle n'est pas par défaut.
> que ce soit iod ou s qui sont descendant de QIODevice, ne supporte pas de void* dans les fonctions writeBlock ou readBlock,
Le language C avec la libc conserve toujours un certain charme :-) ...
fais un man write, open, read, malloc, realloc, free et tu auras un réponse évidente à ton problème. Faut pas faire de l'objet pour faire de l'objet.
Vois aussi que readBlock attent un (char *) et non un (char **). Donc la fonction ne fait pas de malloc ! Danger !
Si la fonction attend un (char *), elle a tord. Désolé. C'est de la programmation des années 70. Face à ça, faire un cast de (void *) à (char *) n'est pas dramatique. Il n'y a pas de conversion, c'est pour virer un warning du compilo.
voilà le proto de read() qui est posix :
ssize_t read(int fd, void *buf, size_t count);
(void *) pour les data. (size_t) pour la taille.
Tu peux te permètres un cast.
#include <stdio.h>
struct {
void * data ;
size_t size ; // pas int. C'est pas un nombre c'est une taille !
} img ;
img.size= iod.size();
if ((img.data=malloc(img.size)) == NULL) {
perror(NULL) ;
exit(EXIT_FAILURE)
}
iod.readBlock((char *)img.data,img.size);
QTextStream ts(s);
QString imgstr=QString("Content-type: image/%1\n\r").arg(imgformat)+QString("Content-length: %1\n\r").arg(img.size)+QString("Accept-Ranges: bytes\n\n");
ts<<imgstr;
ts.unsetDevice();
s->writeBlock((char *)img.data, img.size);
iod.close();
s->close();
free(img.data);
}
[^] # Re: Test de la RedHat 9
Posté par matiasf . En réponse à la dépêche Test de la RedHat 9. Évalué à 2.
Ya encore un boulette dans l'article :
> RedHat 9.0 : codename Shrieke
C'est shrike.
On est plus à ça...
C'est un test baclé.
L'autre truc désagréable, c'est que frlinux ne manque pas une occasion pour rappeler qu'il a eu des problèmes avec la 8.0 .
frlinux m'a solicité pour connaitre les différences entre RH8.0 et 9. Les seuls trucs retenus sont négatif.
Je rappelle une parties du mail (ce sont mes propos et non ceux de frlinux) que je lui ai envoyé :
* Passage à rpm v4.2 :
- création de paquets debuginfo (symbol et source) pour debug. Excellent. Ces paquets ne sont pas fournis avec la RH9.
- contrôle plus fin lors de la construction de paquet. Par exemple, tu construits toto-1.0.i386.rpm. Les fichiers du paquet sont piochés de /var/tmp/toto-root lors de la construction. Si un ficher dans "buildroot" n'est pas référencé, la construction du paquet échoue. Ça évite d'oublier des fichiers.
- plus de deadlock avec rpm -Uvh. Enfin! c'était une peste sous RH8.0.
* Le mode dma pour cdrom est activé par défaut. Sur la RH8.0 le dma est
interdit pour les lecteurs cdrom/dvd. Pour contourner ce problème il
fallait ajouter une options pour ide-cd dans /etc/modules.conf ou en
paramètre noyau.
* subversion est livré. Malheureusement c'est une version de test seulement. Par exemple il n'y a pas le nécessaire pour faire un serveur subversion. la version livré intègre neon, http-apr, etc... tout le nécessaire dans un paquet et non splité en plusieurs paquets comme c'est fait par les mainteneurs de subversion :
http://summersoft.fay.ar.us/pub/linux/redhat/RPMS/i386/subversion-l(...)
* Les coredumps sont par défaut suffixé du pid du programme qui a planté (pratique pour éviter qu'un core dump soit écrasé). C'est configurable via /etc/sysctl.conf (introduit dans RH7.3 je crois) qui est lu au boot. idéal pour un :
dev.rtc.max-user-freq = 1024
J'suis d'une naïveté parfois...
Je crois que ce soir je vais me coucher avec en ayant mal au cul.
[^] # Re: Gestion des accents avec une partition FAT32...
Posté par matiasf . En réponse à la dépêche Test de la RedHat 9. Évalué à 3.
dev/hda1 /mnt/windows vfat uid=500,gid=500,umask=002,iocharset=utf8 1 1
devrait marcher.
> Red Hat ne propose pas la détection automatique des partitions Windows.
À l'installation, ça le fait.
> il s'évertue à ne pas comprendre les caractères accentués qui finissent par s'afficher avec des "?" et l'impossibilité de les ouvrir.
Dans ces cas là, utilises l'option -b de ls pour avoir le nom.
[^] # Re: Test de la RedHat 9
Posté par matiasf . En réponse à la dépêche Test de la RedHat 9. Évalué à 1.
[^] # Re: Test de la RedHat 9
Posté par matiasf . En réponse à la dépêche Test de la RedHat 9. Évalué à 6.
[^] # Re: Test de la RedHat 9
Posté par matiasf . En réponse à la dépêche Test de la RedHat 9. Évalué à -1.
[^] # Re: Moi je pense que la prochaine MAJ de ma RedHat 8.0 ce sera une Debian ...
Posté par matiasf . En réponse à la dépêche Test de la RedHat 9. Évalué à 4.
[^] # Re: Moi je pense que la prochaine MAJ de ma RedHat 8.0 ce sera une Debian ...
Posté par matiasf . En réponse à la dépêche Test de la RedHat 9. Évalué à 6.
[^] # Re: Test de la RedHat 9
Posté par matiasf . En réponse à la dépêche Test de la RedHat 9. Évalué à 1.
[^] # Re: Test de la RedHat 9
Posté par matiasf . En réponse à la dépêche Test de la RedHat 9. Évalué à 1.
[^] # Re: Test de la RedHat 9
Posté par matiasf . En réponse à la dépêche Test de la RedHat 9. Évalué à 2.
[^] # Re: Test de la RedHat 9
Posté par matiasf . En réponse à la dépêche Test de la RedHat 9. Évalué à -3.
[^] # Re: Test de la RedHat 9
Posté par matiasf . En réponse à la dépêche Test de la RedHat 9. Évalué à 0.
[^] # Re: Test de la RedHat 9
Posté par matiasf . En réponse à la dépêche Test de la RedHat 9. Évalué à -2.
Merci pour tout feedback.
[^] # Re: Test de la RedHat 9
Posté par matiasf . En réponse à la dépêche Test de la RedHat 9. Évalué à 6.
Oui :
http://ftp.crihan.fr/mirrors/ftp.redhat.com/redhat/linux/9/en/doc/R(...)
[^] # Re: Test de la RedHat 9
Posté par matiasf . En réponse à la dépêche Test de la RedHat 9. Évalué à -1.
[^] # Re: Un bon article - OK
Posté par matiasf . En réponse à la dépêche Test de la RedHat 9. Évalué à -1.
[^] # Re: Test de la RedHat 9
Posté par matiasf . En réponse à la dépêche Test de la RedHat 9. Évalué à -4.
Ben mandrake a aussi sorti un truc pas très testé comme redhat le fait avec ntpl.
> La fixation sur la comparaison RedHat / Mandrake, c'est maladif ou tu te forces?
Ce qui me gonffre, c'est que lorsque RedHat sort un truc, systèmatiquement ya les critiques qui fusent :
- pas fiable
- pas compatible
- etc...
Mandrake innove aussi (et c'est très bien) et n'a jamais de critique. Et moi ça commence à me brouter sérieusement.
J'ai rien contre Mandrake. C'est cette différence de traitement qui est trollesque, puante qui me les casse.
La prochaine Mandrake (avec linux 2.4) aura surement NTPL et je suis sûr qu'il n'y aura pas la moindre critique.
NTPL EST le nouveau standard pour les thread. RedHat pousse, aide son adoption et c'est très bien.
[^] # Re: Test de la RedHat 9
Posté par matiasf . En réponse à la dépêche Test de la RedHat 9. Évalué à -10.
C'est se foutre de la gueule des devs Linux ce type de propos. Les devs Linux on choisi NTPL pour Linux 2.6. Ils sont grands et pas facilement impressionnables.
RedHat en sortant RH9 avec NTPL, va aider sont adoption et le fiabiliser. C'est tout benéfice pour Linux 2.6. Faut aussi remarquer qu'Alan Cox a développé le nouveau code IDE (initialement pour 2.6) avec le 2.4 et que tout le monde l'utilise et personne ne se plaind.
[^] # Re: Un bon article - OK
Posté par matiasf . En réponse à la dépêche Test de la RedHat 9. Évalué à 1.
La RedHat Linux a les même conditions de distribution, modification, etc que Mandrake. Le support est de 1 an comme Mandrake.
> C'est pour les sociétés. particuliers s'abstenir.
La RedHat Linux est pour la "communauté". Ne pas confondre avec la RedHat Enterprise.
[^] # Re: Test de la RedHat 9
Posté par matiasf . En réponse à la dépêche Test de la RedHat 9. Évalué à -7.
C'est la même implémentation. (C'est 2.6 officiellement).
> 2) La NGPT sur un 2.4 fait quand même office de grosse verrue par rapport au support des threads actuels
Pourquoi ?
> qui est ce qu'il est, mais qui fonctionne
La nouvelle implémentation ne marche pas ?
> 3) Etant un patch sur le 2.4, bonjour les incompatibilités.
Oui et non. C'est comme fournir apache 2. Il y a des incompatibilité. Mais il y a toujour l'ancienne version. Voir :
http://linuxfr.org/comments/193003,1.html(...)
> Maintenant, l'intégration de ce genre de chose chez les entreprises qui veulent être à la pointe (et qui ont donc des compétences internes très souvent), se fait par l'application des dits patches directement par la société, avec toute une batterie de tests à la cléf pour vérifier que ça fonctionne bien.
Ben c'est RedHat qui a fait ce boulot. Doit-on se plaindre ?
> L'intégration d'une telle fonctionnalité dans une distribution basée sur une 2.4, sachant les problèmes que ça risque d'engendrer, est pour moi 1) une erreur 2) très risqué
Tu peux me sortir la même phrase pour Mandrake qui vient de sortir acpi ?
[^] # Re: Test de la RedHat 9
Posté par matiasf . En réponse à la dépêche Test de la RedHat 9. Évalué à -2.
de la release note :
==========================================
Si une application ne fonctionne pas correctement avec NPTL, elle peut être exécutée à l'aide de l'ancienne implémentation de LinuxThreads, en réglant la variable d'environnement suivante:
LD_ASSUME_KERNEL=<kernel-version>
Les versions suivantes sont disponibles:
- 2.4.1 Linuxthreads avec piles flottantes
- 2.2.5 Linuxthreads sans piles flottantes
Le support NPTL pour toutes les applications liées dynamiquement peut êtredésactivé à l'aide de l'option boot-time suivante:
nosysinfo
==========================================
# Re: Test de la RedHat 9
Posté par matiasf . En réponse à la dépêche Test de la RedHat 9. Évalué à 10.
C'est un 2.4.21-pre3 . Pour Mandrake tu as aussi fait cette erreur (c'est un 2.4.21-pre4 et non un pre5).
> l'enregistrement des machines sur lesquelles se trouve la RedHat (fournissant au RHN la liste de vos RPMs ...
Fournir la liste des RPM est optionnel.
De plus :
http://www.redhat.com/software/rhn/legal/(...)
- "Uses of Data from Red Hat Network
Under confidentiality agreements, Red Hat may match user information with third-party data. Also, Red Hat discloses aggregated user statistics in order to describe our services to current and prospective partners, advertisers, and other third parties. Please note though that none of your personal information will ever be sold or shared with outside parties."
> afin de pouvoir vous avertir des alertes sur votre distribution.
Pour info, il y a la mailing list :
https://listman.redhat.com/mailman/listinfo/redhat-watch-list(...)
C'est accessible à tout le monde comme les updates.
> Je dois dire que je ne suis pas un grand fan de BlueCurve.
de : http://frlinux.net/?section=distributions&article=89(...)
- "en fait surtout le thème Blue Curve qui est assez réussit"
- "de plus le thème Blue Curve est très sympathique."
Contrairement à RH8.0 et gnome 2 il est possible de changer de thème avec une interface graphique. Je n'ai pas vérifié avec Kde.
> Ma carte réseau (une broadcom 4400 intégrée sur mon Asus a7v8x) nécessite des pilotes qui sont sur le CD des pilotes de ma carte mère.
Si les drivers sont proprios, c'est normal. RedHat a fait le choix de ne fournir aucun driver proprio (drivers dont il ne peuvent modifier les sources).
> Plutôt qu'une approche de panneau de configuration tout en un, RedHat a opté pour des raccourcis permettant de faire une tâche chacun. Vous pouvez les voir en ligne de commande directement en tapant : redhat + tab + tab (oui deux fois))
C'est redhat-config- le prefix. Mais ça ne change pas grand chose.
Sinon tout ces outils sont regroupés dans le menu "Outils système".
> J'ai installé manuellement les modules de ma carte réseau mais ils n'apparassaient pas dans la liste (je m'y attendais quelques peu)
C'est normal. C'est kudzu qui prend en compte les nouveaux modules. Il faut soit lancer kudzu de nouveau (service kudzu start) ou rebooter.
> A signaler que des problèmes sont en vue pour les possesseurs de RAID (soft raid) et le déplacement des disques car Anaconda (l'installateur de RH) ne fait pas bien sont travail.
Ce n'est pas anaconda qui fait mal son boulot. De plus il ne déplace pas les disque. C'est qu'il exige que les partitions utilisées pour le périphérique raid correspondent à ce qui est marqué dans les infos raid. Il est plus exigent que la détection automatique par le noyau. Si tu déplaces (physiquement) un disque avant d'utiliser anaconda et que tu ne mets pas à jour ces infos, ça coince. Si tu crées le périphérique raid (logiciel) avec anaconda, il n'y a pas de problème.
> Un petit chmod 666 plus tard (soyons brutal), tout marche dans le meilleur des mondes.
Il faut utiliser /etc/security/console.perms
> En parlant des modules, devices et autres joies du kernel. J'ai rencontré un problème sur le loopback (possibilité de monter une iso du disque dur vers un répertoire du disque dur). Il ne m'a pas été possible de les démonter par la suite. On m'a également signalé le problème sur d'autres machines.
Si c'est par rapport au mail que je t'ai envoyé, j'ai fait un correctif que je te rappèle :
> > > * Côté noyau, je trouve la RH8.0 réellement rock solide. J'ai eu
> > > quelques problèmes avec la RH9 :
> > > - interface loopback (/dev/loop0) que je ne peut plus virer
> > > - Impossible de démonter un système de fichier alors qu'il n'est plus
> > > utilisé.
> > >
>
> Je "jouais" avec kickstart et j'ai monté des partitions cramfs (système
> de fichier compressé). Malheureusement, les partitions cramfs ne sont
> pas visibles avec df. Les problèmes ci-dessus, n'existent pas.
Pour moi, il n'y a pas de problème. Ou alors un problème avec df uniquement. La commande mount me donne les bonnes info.
> La RedHat 9.0 utilise un nouveau code pour l'IDE, désactivant d'un coup la possibilité de toucher aux DMA si les lecteurs CD/DVD sont sur une carte Highpoint (problème vu aussi dans le kernel 2.5).
Il utilise le nouveau code développé par Alan Cox et disponible dans Linux vanilla depuis 2.4.19. Par contre pour la RH 8.0 RedHat n'a pas utilisé ce nouveau code même si le noyau était un 2.4.19-rc1-ac1. Pour la RH9, RedHat utilise ce nouveau code comme mandrake et les autres.
Le problème Highpoint :
http://bugzilla.kernel.org/show_bug.cgi?id=109(...)
- "The lack of atapi on the highpoint 36x/37x is intentional right now. It may change at some point in the future"
Ce n'est pas un problème spécifique à RedHat.
> Je vous invite enfin à consulter les Release notes (en Français)
Je t'avais fourni la release notes il y a quelque jour car avant elle n'était pas dispo (puis que la distribe n'était pas dispo en download). Maintenant la release note est dispo partout. Par exemple :
http://ftp.crihan.fr/mirrors/ftp.redhat.com/redhat/linux/9/en/os/i3(...)
Pour le download voir ici :
http://www.redhat.com/download/mirror.html(...)
L'annonce propose aussi du rsync :
http://lwn.net/Articles/28062/(...)
notons aussi l'imposante doc :
http://ftp.crihan.fr/mirrors/ftp.redhat.com/redhat/linux/9/en/iso/d(...)
Lisible par exemple ici :
http://ftp.crihan.fr/mirrors/ftp.redhat.com/redhat/linux/9/en/doc/(...)
[^] # Re: SFTP
Posté par matiasf . En réponse à la dépêche Nouvelle version de OpenSSH. Évalué à 6.
Y a pas de problème. Par contre , j'ai pas aimé le "base de registre".
> Pour gconf, ce n'est pas le programme en soi que je critique, c'est que a l'heure actuelle, certaines options de certaines applications ne sont accessibles que par gconf.
Si tu ne veux pas troller, évite "ne sont accessibles que par gconf" :-) . Mais dis "ne sont pas accessible à un novice" ou "n'est pas intégré à l'interface de l'appli". C'est pas gconf le problème. Si l'option est uniquement modifiable avec un éditeur de texte, le problème reste entier.
> Je pense que cette attitude precise (s'en remettre a gconf sans fournir une vraie interface graphique)
C'est s'en remettre à gconf (ou autre) pour les cas particuliers. Ça donne de la souplesse sans alourdir l'interface de l'application. gconf-editor n'est pas là pour remplacer le menu "paramètre""préférence" de galeon. Ça n'a jamais été l'objectif. C'est fournir une moyen de configuration pour quelques options avancées qui n'interressent que 2 % des utilisateurs sans "polluer" les autres utilisateurs. Gecko fourni des tonnes d'options et galeon ne permet d'en modifier que 10 % maximum. Qui ça gène ? croix tu que galeon doit fournir une interface graphique pour toutes les options de gecko (donné l'url about:config pour voir la liste complète).
> va a contresens du but de projets comme KDE et Gnome, qui est, rappelons le, de fournir des applications coherentes, completes et conviviales.
C'est ça que je comprends pas. Que les outils en ligne de commande soient là pour satisfaire tous les besoins de tout les utilisateurs, je comprend.
Fais un "man mkisofs" et dit moi si le fait de couvrir toutes les options de mkisofs est compatible avec une interface conviviale et accessible à tout le monde.
Selon moi, on ne peut satisfaire tout le monde avec une appli. Il faut une appli simple pour 98 % des utilisateurs et des applis plus poussées pour ceux qui en ont besoin. Je répète, j'ai rien contre de fait de proposer plusieurs appli ! Nautilus n'est pas là pour remplacer bash ou gentoo ! gtoaster n'est pas là pour remplacer le couple killer mkisofs/cdrecord. Ce que j'aime pas, c'est que tu insinues que Gnome est contre les applis pour utilisateurs avancés. Ce n'est pas le cas. Gnome prone des applis simple pour les applis par défaut. De plus, l'émergeance de freedesktop var permettre le developpement d'autres bureaux, panel, etc... qui sont compatible mais différent. Il y aura le bureau gnome pour les "neuneux" (présent !) le bureau kde pour les "power user", etc... Certains préfèrent gnome d'autres kde. Le fait que les bureaux Kde et Gnome soient différents est positif. Si gnome doit faire comme Kde avec plein d'option, des applis par défaut pour "power user", quel est l'intérêt pour l'utilisateur final d'avoir le choix entre Gnome et Kde ? Une appli ou un bureau ou un wm ne peut pas satisfaire tout le monde.
Tu peux dire que tu préfère Kde car il a plein d'options que tu ne retrouves pas dans Gnome. Mais il me semble que tu ne peux pas reprocher à Gnome d'avoir fait le choix de la simplicité. C'est ce choix que tu ne devrais pas critiquer.
Tu peux dire :
- "dommage, il n'y a pas l'option bidule dans tel appli."
Mais tu ne devrais pas dire :
- "gnome c'est naze car ils ont fait le chois d'être simple, dépouillé pour les applis par défaut"
Moi j'utilise principalement bash et les outils en ligne de commande (faut dire que je suis "vieux" et j'ai grandi avec la ligne de commande) et je ne suis pas demandeur d'appli aussi touffue que la ligne de commande. Si j'utilise le programme de gravage par défaut, c'est pas pour me prendre la tête avec plein d'options que je ne peut comprendre qu'en lisant un Howto de 50 pages. Attention, je dis pour l'appli par défaut !
> A priori, il est tout a fait possible d'integrer dans une application des fonctionnalites accessibles aux debutants et des fonctionnalites accessibles aux experts, sans pour autant rendre l'application inutilisable ou effrayante. C'est l'objectif que defend Aaron regulierement sur kde-usability.
C'est le choix de Kde et il est respectable et bénéfique pour les utilisateurs qui aiment ce concepte.
> C'est un peu triste de voir que Havoc et Owen semblent avoir renonce sur ce plan-la et preferent la voie de la facilite en supprimant beaucoup d'options de configuration ou en les cachant dans gconf.
Pour info, il y a plus de dev Sun ou Ximian dans Gnome que de dev RedHat. D'ailleur Redhat n'est pas représenté dans la fondation gnome actuellement.
> preferent la voie de la facilite en supprimant beaucoup d'options
Ben c'est pas "facile". Il faut cherché le bon compremis. C'est peut-être plus dure que de prendre le principe "on implémentent tous les options et c'est à l'utilisateur de se démerder". Le programme doit gérer la pluspart des situations sans s'en remettre à l'expertise de l'utilisateur. Prends l'applet "liste de fenêtre", ils ont ramé pour avoir une taille dynamique de l'applet. Maintenant il y a "taille minimum" et "taille maximum" (dont les valeur par défaut sont 50 et 4096). Pour Gnome 2.4, l'applet n'aura plus de paramètre taille. Considère l'exemple que j'ai donné de virer l'option indiquant le périphérique à utiliser pour graver un cd. C'est pas simple.
> Avec la direction que prend Gnome, on a l'impression que ce genre de parametre de configuration va etre cache completement de l'application parce qu'on le considere comme trop avance, et que l'utilisateur doit rester un neuneu.
Tu trolles. Pourquoi dire "neuneu".
> Pour des projets pour KDE ou Gnome ou le but est de fournir une interface conviviale, je trouve ca dommage de renoncer justement a fournir une interface conviviale sous pretexte que seuls les utilisateurs avances peuvent s'en passer et utiliser un truc non convivial.
C'est pour les applis fourni pas défaut. Avoir un menu "démarré" avec 200 programmes dont 150 ne seront jamais utilisé par 98 % des utilisateurs n'est pas bon. Mais rien empêche l'utilisateur d'ajout son applis "avancée".
> Si le besoin apparait techniquemnt, il faut le prendre en compte. Il n'y a pas de "ergonomiquement, on n'a pas a le faire"
T'as pas compris. Par exemple : Techniquement on ne sait pas déterminer la vitesse de gravage donc on ajoute une option. Donc j'ai bien dit que des options étaient ajoutées pour des raisons techniques. Pour l'ergonomie, il serait bon de savoir déterminé automatiquement la vitesse de gravage. Malheureusement, pour des raisons techniques, on ne sait pas le faire. Et donc on ajout une option qui n'est pas "conviviale" mais techniquement nécessaire.
> Pas besoin de cacher ca honteusement dans gconf.
Tu trolles. D'ailleur le mettre dans gconf, c'est le rendre visible de façon standard.
[^] # Re: SFTP
Posté par matiasf . En réponse à la dépêche Nouvelle version de OpenSSH. Évalué à 5.
Considère que le bureau, le file manager, etc... sont des applis.
> et non sur les parametres de configuration
Car les paramètres de configuration d'un graveur ne sont pas des paramètres de configuration ? Bizarre...
> - creation d'une image: cette foncionnalite est indispensable si tu veux graver des CD en serie, genre des Knoppix pour les distribuer a la linux expo.
Je parle de 98 % des utilisations. Je ne parle pas de programme fait pour des cas particuliers.
Je parle de faire une image avant de graver. Je ne parle pas de graver une image. Evidement qu'un programme de gravage doit pouvoir gravé une image. Je parle de l'étape intermédiaire de faire une image avant de graver.
> - la taille du cache peut s'averer importante. Pour un systeme comme gentoo ou tu es susceptible d'avoir des compilations pendant ton gravage, c'est important. On peut aussi imaginer que l'utilisateur regarde un divx ou un DVD en attendant la fin de son gravage.
J'ai dit 32 mo. Cette valeur est ok dans la majorité des cas. Avec ce niveau de cache, tu peux copier des gros fichiers entre disques dures, visualiser un dvd, lancer trois compilations, et le tout en parallèle. Et même sous gentoo ça doit marcher.
> De toute facon, le tu ne fais que souligner l'importance des choix par defaut intelligents (et tout le monde est d'accord), pas la problematique des options de configurations.
Je parle du besoin d'ajouter ou non une option qu'elle soit de configuration ou fonctionnelle.
> - faut-il pouvoir ajuster les fontes dans l'historique des sites visites
Aucun intérêt. Tout doit être visible. Pourquoi pas ajouter les fontes pour le menu, les bulles, etc, etc. Je préfère la notion de thème (même si généralement j'utilise le thème par défaut car j'aime pas me prendre la tête).
> - faut-il pouvoir choisir son window manager ?
Tu changes de sujet. Je parle d'applications par défaut. Je suis pour la diversité. Avoir de la diversité dans le choix du wm est un truc. Dire que le window manager par défaut doit avoir 200 options est un autre truc. Et puis Gnome permet de changer de window manager. Et si Kde respecte freedesktop, on va pouvoir utiliser le window manageur de Kde sous Gnome. C'est de la diversité. j'ai rien contre.
> - faut-il se taper une base de registre pour toucher a des parametres subtils comme la vitesse de double-clique souris ou la resistance sur les bords quand on change de bureau en passant par les bords ?
Troll puant. J'espère que tu es satisfait avec tes fichiers .ini ala win 3.11 et que tu n'as pas besoin de fixer 50 variables d'environnements. Un partout, balle au centre.
Remarque qu'il y a plein de paramètre dans /proc/sys. Tu réclames une interface graphique pour les éditer ? Tu les édites quotidiennement ? Ou tu fais comme tout le monde et fais confiance au paramètrage par défaut ?
Lis la doc gconf avant de redire une "connerie" :
http://www.gnome.org/learn/admin-guide/2.2/gconf-0.html(...)
> - faut-il pouvoir ajuster des parametres completement abscond sur les imprimantes ?
Non. Ça c'est un problème technique et non un problème d'ergonomie. Ergonomiquement on n'a pas à le faire. Techniquement c'est peut-être nécessaire. C'est comme pour la vitesse de gravage. Orgonomiquement ça n'apporte rien. Imagines s'il faut faire la même chose avec les disques dures ...
Si on savait déterminer de façon fiable la vitesse de gravage, cette option devrait être virée. C'est comme les options "activer bidule pour éviter le bug de truc". Il faut corriger truc et non ajouter une option.
> - l'option correspond a une ergonomie tres pauvre. Il faut corriger le pb d'ergonomie, fournir des parametres par defauts intelligents et remettre l'option dans un coin.
Faut déjà vérifier si l'option est utile pour une majorité et pas pour une minorité.
> - l'option semble completement debile et il vaut mieux faire un choix clair: ex : ordre ok/cancel dans les dialogues.
C'est un problème de norme. freedesktop avec Gnome et Kde (+ qq autres) y travail. Pour ma part, que le bouton "ok" soit à gauche ou à droite, je m'en fout du moment qu'il est toujours du même côté.
> - l'option n'est utile que pour un tres petit nombre d'utilisateurs, mais pour eux, elle est indispensable (parametres d'imprimantes, parametres de la vitesse de la souris, ...). On reproche a Gnome d'avoir supprime des options qui rentraient dans cette categorie-la alors qu'une approche intelligente (les mettre dans un dialogue "configuration avancee", refaire un peu l'ergonomie de l'application) permet de satisfaire a la fois les utilisateurs de base et les utilisateurs avances.
Si c'est pour un petit nombre d'utilisateur, cette option doit être viré de l'interface graphique par défaut. L'environnement par défaut doit être simple et ne pas demander de consulter 20 tableaux de configuration. Même si c'est dans un coin "options avancées", le gens vont regarder et trouver ça compliqué, ça va engendrer des tonnes de discutions stériles, le diagnostique en cas de problème est moins facile, la maintenance de l'appli plus lourde, etc... Attention, je ne dis pas de virer l'option. Je dis qu'elle de doit pas être visible dans les applis par défaut. Pour les quelques utilisateurs pour qui l'option est indispensable, ils passent par gconftool/gconf-editor ou vim/kconf, etc...
> La reponse est loin d'etre evidente comme je le disais.
Effectivement et les erreurs sont possibles et Gnome a surement viré une option qu'ils ont ajouté après. Par contre, ce que je n'apprécie pas c'est le principe "simpliste" de dire que plus il y a d'option (même dans un coin) plus on satisfait d'utilisateurs. C'est faut. Lorsque les gens font <éditer><configuration>, ce n'est généralement pas pour tomber sur 40 options dont 2 lui sont utiles, car on a voulu contenter tout le monde. Et je le répète, c'est pour les applications par défaut. J'ai absolument rien contre une autre applis avec 300 options si elle n'est pas par défaut.
[^] # Re: petite question sur les transfert dans le protocole http
Posté par matiasf . En réponse au journal petite question sur les transfert dans le protocole http. Évalué à 7.