Pour rappel, le protocole SSH est en gros un telnet/ftp chiffré avec des fonctionalités d'authentification forte basée sur les clefs public/privé. Cette implémentation se base pour les fonctions cryptographiques sur l'implémentation "open source" du protocole SSL/TLS OpenSSL.
De plus, comme gage de qualité de l'ensemble, ce sont les mêmes gens un peu "fous de sécurité" du projet OpenBSD qui s'y collent.
Alors si vous voulez supprimer une fois pour toutes ces bonnes vieilles r-commandes et ce protocole non sécurisé qu'est ftp (NdM : le non-anonyme en tout cas)... une seul chose à faire : installer la dernière version d'OpenSSH et patcher régulièrement vos machines avec la dernière version (et le dernière version de OpenSSL) pour éviter les surprises.
Cette version (en fait la version 3.6 du 31 mars) ne corrige pas beaucoup de choses. Mais elle corrige les éventuelles failles dues à une attaque contre les clefs RSA decouverte recement ( "timing attack against RSA keys" dixit la release note). Pour plus d'infos sur les corrections, se référer à la « release note ».
Aller plus loin
- Le site officiel du projet OpenSSH (7 clics)
- La « release note » de la version 3.6.1 (3 clics)
- Le site de OpenSSL (2 clics)
- Le texte de la "timing attack" contre les clefs RSA (1 clic)
# Qualité ?
Posté par AlV . Évalué à 10.
La sécurité sûrement (au moins jusqu'au prochain trou de sécurité ;o), mais la qualité, laissez moi rire...
Ah, ah, ah !
Ca y est, j'ai ri.
Bon, sérieusement, un survol du code source montre immédiatement que ces gorets ont tout codé à base de variables globales alors qu'il eut été facile de passer un contexte alloué dans le programme principal, ce qui leur aurait permis de faire de la majorité du code une (des) bibliothèque(s) et de permettre ainsi d'écrire des clients différents de ceux qu'ils fournissent ou d'embarquer du ssh dans une appli sans problème.
Exemple : la gestion des paquets (packets.c) dans lequel les fonctions ne prennent pas d'argument...
Reprendre leur code dans un environnement multi-thread c'est à se tirer une balle dans la tête (ou ailleurs selon les goûts).
Si ça c'est de la qualité, nous n'avons pas la même définition de la qualité >:o7
[^] # Re: Qualité ?
Posté par Nap . Évalué à 1.
Est-ce que les logiciels libres ont souvent ce genre de problèmes ?
Et pourquoi ? J'ai déjà lu des choses du genre : "le code de tel logiciel est imbuvable, pour empécher un fork"
Bel esprit...
Ca m'étonnerait que les développeurs du monde libre soient plus mauvais que les autres... alors pourquoi certains logiciels sont-ils si mal codés ?
[^] # Re: Qualité ?
Posté par Philippe F (site web personnel) . Évalué à 5.
Tu as l'air de penser que les logiciels fermes sont bien codes. Au contraire, c'est bien pire. En entreprise, souvent, la seule chose qui compte, c'est que ca marche a une date donnee. Les audits de code sont tres tres tres rares, donc on trouve souvent des usines a gaz bricolees de partout, qui marchent a une date donnee mais sont totalement impossiblea a maintenir ou faire evoluer.
Pourquoi tu crois que les promoteurs de methogologies de developpement se font autant de thune ? Parce que il y a un besoin, quand les boites s'apercoivent a quel point leur logiciels sont pourris en interne.
Donc les logiciels libres les plus crades sont en general bien mieux codes que la moyenne des logiciels proprietaire. Cela dit, ca n'excuse rien. J'enrage quand je me tape des logiciels au code pourri ou mal organise (genre vim).
[^] # Re: Qualité ?
Posté par Nap . Évalué à 1.
[^] # Re: Qualité ?
Posté par pasBill pasGates . Évalué à 2.
Perso de ce que j'ai vu chez MS, dans le libre et ailleurs dans d'autres softs proprios, je suis pas tres convaincu par ton argumentation.
Oui certaines boites ont tendance a bacler pour sortir a une date X, mais elles ont aussi tendance a ne plus jamais le refaire apres car ca leur retombe tres vite sur la gueule. Tiens, MS par exemple, ca nous est arrive il y a plusieurs annees, et maintenant les priorites ont ete remises dans le bon ordre.
De mon experience il n'y a pas un des deux qui est en general mieux code que l'autre.
[^] # Re: Qualité ?
Posté par Olivier Jeannet . Évalué à 10.
J'avais lu un article très intéressant dans le MISC "spécial sécurité" ( http://tldp.org/linuxfocus/Francais/March2003/article273.shtml(...) ) où l'auteur dit :
<blockquote>
Tout cela a certaines conséquences, en particulier, le code est devenu et tend à être de plus en plus une monstrueuse adaptation constante (je sens le syndrome "sendmail" poindre à l'horizon) et cela n'est pas très sain pour une application de cryptologie qui devrait être extrêmement rigoureuse et claire (j'éviterai ici mon classique couplet sur les produits de cryptologie open-source "que tout le monde peut relire mais que personne n'a jamais relu", et qui alors dans les faits ne procurent qu'une confiance non démontrée et donc totalement artificielle, voire surfaite et surestimée).
[...]
Ces réserves faites, les implémentations concurrentes libres n'étant pas si nombreuses et mieux loties, je crois qu'il est pragmatique de considérer qu'actuellement OpenSSH est la pire des implémentations, à l'exclusion de toutes les autres... ! Un chantier utile à la communauté serait une remise à plat et une reprise du codage à zéro cependant.
</blockquote>
PS: Fabien, le tag blockquote n'a plus l'air de marcher. Templite aurait besoin d'un petit patch...
[^] # Re: Qualité ?
Posté par tfing . Évalué à 5.
est ce que quelqu'un a des remarques a formuler contre au niveau qualité ?
[^] # Re: Qualité ?
Posté par earxtacy . Évalué à 2.
Multiplier les bibliotheques n'augmente pas les risques de compromission ?
je dis ca comme ca :)
[^] # Re: Qualité ?
Posté par AlV . Évalué à 1.
Bah, tout dépend de ce que tu entends par "multiplication" et "augmenter"...
Là, il n'y a pas "multiplication", il y a juste séparation du noyau de fonctionnalités du programme de la partie interface utilisateur (par exemple)
Si tu veux dire que chaque fois qu'on trouvera un trou de sécurité dans une (toutes les) bibliothèque(s) d'un OpenSSH "relooké", il faudra mettre à jour ces bibliothèques, non, ça n'augmente pas par rapport à mettre à jour OpenSSH lui-même...
Le problème est à peine différent et le fond reste le même : la sécurité d'un système n'est pas un état figé, il faut tout le temps se tenir sur ses gardes et être prêt à mettre à jour.
Si tu veux dire qu'éventuellement plusieurs applications seront impactées, oui, certainement, mais ce sera de toutes façons plus facile de mettre à jour des bibliothèques que de chercher dans quels programmes des bouts du OpenSSH monolithiques ont été dupliqués (toujours le problème du link dynamique par rapport au link statique)...
> je dis ca comme ca :)
Pourquoi ne pas le dire comme ça, en effet... ;o)
[^] # Re: Qualité ?
Posté par Philippe F (site web personnel) . Évalué à 8.
[^] # Re: Qualité ?
Posté par Samuel DUBUS . Évalué à 0.
> qualité, laissez moi rire...
Je trouve que la securité est quand même un assez bon critère de qualité pour un logiciel ... surtout si le soft est justement un logiciel de "sécurité". Néanmoins, tous les paramétres d'un logiciel doivent être pris en compte pour porter un jugement de valeur c'est vrai.
Donc si je récapitule :
- sécurité,
- "Open Source",
- facile à installer (même à partir des sources),
- patché régulièrement,
- code "audité" régulièrement ( même principe que OpenBSD ).
C'est déjà pas si mal pour un logiciel qui est développé par des "bénévols" ... En tous cas c'est pas pire que la plupart des logiciels aux sources fermées.
[^] # Re: Qualité ?
Posté par AlV . Évalué à 3.
Utiliser des variables statiques à tour de bras dans son code est une source d'ennuis permanente aussi bien pour les créateurs que pour ceux qui maintiennent après : une fonction "void f (void)" qui fait autre chose que printf "Hello World!\n"; a tendance à me hérisser le poil : je ne sais rien du flux des données dans cette fonction et je suis obligé de me "palucher" la lecture du code source d'une fonction dont je me moque certainement pour vérifier qu'elle n'a pas un p*tain d'effet de bord >:o(
Evidemment, ça vaut aussi pour les tordus qui passent des paramètres mais modifient aussi des variables globales >:oO
Bénévoles, peut-être (et je suis le premier à les remercier de s'être attelés à un problème loin d'être simple), mais codeurs gorets aussi :o)
> En tous cas c'est pas pire que la plupart des logiciels aux sources fermées.
Dans mon expérience de codeur et de mainteneur, j'ai vu de tout dans les codes sources propriétaires, du bon (meilleur qu'OpenSSH et de loin), du moyen, du mauvais et du pire.
De toutes façons, le pire code à lire en première approche est le code que quelqu'un d'autre a écrit. Il faut passer outre cette première approche pour entrer dans la logique du code (quand il y en a une) : c'est un boulot ingrat et délicat.
Par contre, je persiste et je signe : un code qui s'appuie sur l'utilisation de variables globales devient un cauchemar pour quelqu'un à un moment ou un autre !
P.S.
Parfois dans ma carrière professionnelle, on m'a justifié l'utilisation de variables globales par des raisons d'efficacité (accès mémoire plus rapide), mais souvent, le reste du code aurait mérité des optimisations qui compensaient largement la "perte de temps" du passage de paramètres (un pointeur, c'est 4 ou 8 octets, pas 512Ko).
[^] # Re: Qualité ?
Posté par Samuel DUBUS . Évalué à 2.
Tres bien je tempere donc mon avis sur la qualite de OpenSSH. Je suis d'accord sur le fond avec toi sur la qualite du code. Neanmoins, a part l'aspect qqpeu fouillie du code d' OpenSSH, les autres aspects du projet sont de bonne qualite ...
> Par contre, je persiste et je signe : un code qui s'appuie sur l'utilisation de variables globales devient un cauchemar pour quelqu'un à un moment ou un autre !
C'est peut etre pour eviter que les autres ne relisent le code et ne trouvent des failles de securite ... une sorte de "crypto-code" ...
Heu, non la c'est une blague hin !
a+
[^] # Re: Qualité ?
Posté par earxtacy . Évalué à 1.
qu'on est leur reponse :)
# SFTP
Posté par pasPierre pasTramo . Évalué à 6.
Et y a vraiment trés trés peu d'option.
J'espére que la nouvelle version changera tout cela.
[^] # Re: SFTP
Posté par Rado R. . Évalué à 9.
lftp fish://@
[^] # Re: SFTP
Posté par Rado R. . Évalué à -1.
C'est lftp
[^] # Re: SFTP
Posté par patton . Évalué à -1.
[^] # Re: SFTP
Posté par Philippe F (site web personnel) . Évalué à 3.
Voila.
Et sous Gnome ?
Variante rapide: ALT+F2, fish://@host
Cette derniere suppose que ton ssh est configure de partout.
[^] # Re: SFTP
Posté par Philippe F (site web personnel) . Évalué à 1.
Je m'interrogeai juste au sujet de Gnome, pour savoir si une telle fonctionnalite etait disponible.
[troll on]
Cela dit, comme Gnome choisit de devenir un desktop de neuneu (non non, l'utilisateur ne sait pas configurer, retirons toute configuration), je doute que ca y soit ou que ca y arrive.
De l'autre cote, KDE devient un desktop de power user alors que sa cible initiale est l'utilisateur debutant.
Parfois le logiciel libre, c'est vraiment n'importe quoi
[^] # Re: SFTP
Posté par Christophe Fergeau . Évalué à 2.
(une fois que c'est installé, tu peux faire mumuse avec dans Nautilus)
Enchanté de faire ta connaissance pfremy, j'avais juste lu ton troll sur gnome sur advogato y a qques temps et je savais pas que t'étais français :p
[^] # Re: SFTP
Posté par Philippe F (site web personnel) . Évalué à 1.
- ca n'est pas inclus dans gnome (ou bien le site web n'est pas a jour)
- l'URI fish://users@host a l'air plus repandue (c'est un standard ?) que sftp://users@hosts(...) mais n'est pas supportee.
Cela dit, ok, gnome peut le faire aussi. J'espere qu'ils vont l'integrer rapidement avec la syntaxe la plus repandue.
Heureux de voir que mes trolls sont lus :-). D'ailleurs, puisque le sujet de la qualite du code a ete evoquee, je maintiens mon point de vue de l'epoque : quand les mainteneurs d'un soft disent que l'architecture est hyper compliquee, qu'on peut rien reuiliser ou integrer ailleurs et qu'il faut recoder la moitie de truc, je pense que le soft a ete mal ecrit a la base.
[^] # Re: SFTP
Posté par Christophe Fergeau . Évalué à 1.
[^] # Re: SFTP
Posté par nigaiden . Évalué à 3.
Normalement, il devrait être possible de faire un bureau qui peut satisfaire beaucoup de monde, en mettant en évidence les options pour débutants et en proposant de cacher les options pour utilisateurs expérimentés. Nautilus proposait quelque chose comme ca dans une vieille version, mais maintenant qu'il n'y quasiment plus d'options/commandes dans ses menus, cette possibilité de choisir son niveau a disparu. Mais je pense quand même que c'est une bonne chose, qui devrait être intégré au niveau du bureau. Ensuite, lorsque les utilisateurs se sentiraient plus à l'aise avec leurs applications, ils pourraient les passer petit à petit en mode "expérimenté".
Concernant gnome, je pense qu'ils vont devoir faire machine arrière car les utilisateurs expérimentés devront bientôt faire toute leur config en éditant des fichiers de configuration (puisqu'on ne peut plus faire grand chose avec l'interfrace graphique) et en auront vite marre...
Par contre je ne comprends pas ta remarque concernant KDE...
[^] # Re: SFTP
Posté par Christophe Fergeau . Évalué à 0.
Résultat, le mode débutant serait pour ainsi dire inutile, ca ferait du boulot en plus pour les developpeurs, et on se retrouverait avec un truc aussi bordélique que kd.. euh gnome 1
[^] # Re: SFTP
Posté par nigaiden . Évalué à 1.
_ ceux qui ont déjà une bonne expérience (sous Windows par exemple), et à ceux-là s'applique bien ta remarque
_ ceux qui n'ont jamais utilisé d'ordinateur (beaucoup moins nombreux, il est vrai) et pour ceux-là je pense que deux modes seraient utiles
En ce qui concerne l'implémentation, on pourrait imaginer que les développeurs utilisent une option en plus, genre :
MenutItem = gnome_menu_item_new( "Menu item", ..., NEWBIES );
Et après c'est aux librairies gnome de se débrouiller.
Enfin, je parle, je parle, mais c'est pas moi qui vais coder ça ;-)
[^] # Re: SFTP
Posté par Christophe Fergeau . Évalué à 2.
Et à mes yeux, c'est quand meme mieux d'avoir simple qui marche correctement pour tout le monde du premier coup....
[^] # Re: SFTP
Posté par Philippe F (site web personnel) . Évalué à 5.
L'approche debutant / confirme pour le logiciel est possible. Cependant, avec ca, tu te dis que les utilisateurs debutants le resteront eternellement et que peut-etre ils vont passer a cote d'une fontionnalite interessante cote confirme.
Une autre probleme est que ca rend le developpement plus complexe. Telle fonctionnalite, elle est pour les debutants ou pas ? Parfois il y a des fonctionnalites complexes qui fournissent des fonctionnalites simples et c'est pas facile de marrier ca de facon coherente. Cela dit, je serai assez pour ce genre de chose dans certains logiciels de KDE. Konqueror et KMail ont beaucoup trop de menus a mon avis.
L'approche de Gnome, menee par Havoc et Owen est assez radicale aujourd'hui: on supprime tout ce qui se configure et estimant que les defauts doivent etre bons.
Ils ont raison sur le fait que les reglages par defaut doivent etre bons. Il y a aussi plein d'options de configuration qui ont ete introduites pour pallier a une faiblesse de l'interface. Danc ce cas aussi, il faut supprimer le reglage et corriger l'interface.
Cependant, il reste des options qu'il est legitime de vouloir configurer et dans leur croisade contre la configuration, Havec et Owen en ont supprime pas mal. Il ne reste plus alors qu'a lancer ton gconf, mais c'est en contradiction avec le but de faire un bureau convivial.
L'approche de KDE (representee par Aaron Seigo) face au meme probleme est plutot d'essayer de fournir les meilleures interfaces possible, tout en conservant les options de configurations qui sont necessaire compte tenu de la diversite des habitudes des utilisateurs (simple-clique et double-clique ?). Il y a beaucoup de boulot et pas beaucoup de developpeurs. Pourtant, c'est pas tres dur. Les connaissances requises en code sont minimales. Voire null, le plus important, c'est la diplomatie pour expliquer a un auteur que il faut qu'il change son appli comme ca et comme ca.
Ma remarque concernant KDE vient du fait qu'aujourd'hui, KDE a plein de fonctionnalite qui sont bien plus utiles pour des utilsisateurs tres avances que pour des debutants. Si tu lances KMail, par exemple, tu as 4 facons de repondre a un message. Tu as trois facons differentes de faire un forward. En tant qu'utlisateur avance, j'apprecie enormement ces options. Mais je trouve le menu tres charge.
Tu peux utiliser plein de ioslave avances comme fish://, ftp://,(...) http://,(...) man:, info:. Les trois premiers sont utilisables partout, notamment dans les dialogues de sauvegardes. Cependant, peu d'utilisateurs savent qu'ils peuvent faire du ftp ou du ssh directement dans leur dialogue de sauvegarde.
C'est en ce sens que je trouve que KDE devient de plus en plus tourne hacker.
[^] # Re: SFTP
Posté par Christophe Fergeau . Évalué à 1.
Et puis bon, kde ils fument un peu la moquette des fois, genre l'ioslave sql:// ou alors les options de config pour choisir la police et la couleur des éléments de l'historique.
Ok, je suis carrément pas objectif parce que j'aime pas kde :) (je trouve la plupart des screenshots laids, et konqueror a l'air d'avoir un peu trop de boutons dans tous les sens à mon gout)
[^] # Re: SFTP
Posté par matiasf . Évalué à 5.
Pour les utilisations complexes, il faut soit passer par la ligne de commande ou utilisé un autre outil que celui par défaut.
Regardons word qui propose des tonnes d'options. 99 % des gens ne les modifiés pas. Sous windows, ce qui est modifié est le fond d'écran, l'économiseur d'écran et autres futilités de ce type. D'ailleur les utilisateurs de Windows ne sont pratiquement jamais demandeur de plus de "personnalisation". Mettre plein d'option ne veux pas dire que tu vas contenter beaucoup de monde, mais "peut-être" un peu plus de monde. D'autre allant vers un système plus simple. Pour moi les applis par défaut doivent être simples et tant pis pour les 2 % de "power user". D'ailleur le "power user" utilise la ligne de commande :-)
[^] # Re: SFTP
Posté par Philippe F (site web personnel) . Évalué à 2.
[^] # Re: SFTP
Posté par Christophe Fergeau . Évalué à 1.
Et faut arreter avec "gconf c'est la base de registre, c'est windows, c'est nul"
J'ai pas kde d'installé chez moi, mais je suppose que les fichiers de conf doivent se trouver dans .kde et qu'ils doivent etre vaguement organisés comme des fichiers .ini de win31. C'est pas très compliqué de faire un éditeur de config pour ça qui ressemblera a regedit... Tout ça pour dire que avec un peu de mauvaise fois, on peut dire que tout système de config centralisé est un clone de la base de registre...
[^] # Re: SFTP
Posté par matiasf . É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: SFTP
Posté par Philippe F (site web personnel) . Évalué à 3.
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. C'est meme parfois mis en avant comme argument pour supprimer des options de configuration de l'interface utilisateur: "si les utilisateurs veulent vraiment changer ca, ils pourront toujours utiliser gconf".
Je pense que cette attitude precise (s'en remettre a gconf sans fournir une vraie interface graphique) va a contresens du but de projets comme KDE et Gnome, qui est, rappelons le, de fournir des applications coherentes, completes et conviviales.
L'argument qu'un utilisateur avance sera toujours capable d'utiliser gconf pour changer les parametres xy d'une application n'est pas le bon. 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 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.
<<
> - 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. >>
J'espere que tu vois mieux ce que je voulais dire au regard de ce commentaire: un parametre que tres peu d'utilisateurs sont susceptibles de changer, tel que la vitesse du double-clique souris doit-il pouvoir etre configurer graphiquement ? Ma reponse est oui, mais il faut faire tres attention a l'ergonomie presentee pour ce choix. A priori une telle configuration doit etre cachee dans un panneau de parametres avances et ne doit pas ennuyer l'utilisateur qui cherche juste a faire marcher la molette de sa souris par exemple.
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.
> Remarque qu'il y a plein de paramètre dans /proc/sys. Tu réclames une interface graphique pour les éditer ?
J'apprecierai une interface graphique pour les editer, capable de me fournir de l'aide sur ce a quoi correspond chaque parametre, au moins a titre didactique. Un peu comme pour la configuration du noyau. Je ne reclame rien mais oui, j'apprecierai.
> Tu les édites quotidiennement ? Ou tu fais comme tout le monde et fais confiance au paramètrage par défaut ?
Il y a trois aspect et il ne faut pas en occulter un par un autre:
1. il faut de bon parametres par defaut
2. certaines options ont besoin d'etre modifiables
3. la modification doit etre conviviale et si possible assistee
Pour repondre a ta question, je fais confiance aux defauts (1) et il m'est arrive une fois dans ma vie de les editer (2). Pourtant, (3) me paraitrait souhaitable aussi. Tu vas me dire qu'on cree des assistes ? Vraiment, apprecierai tu de configurer ton noyau si on te balancait juste le .config sans toute la documentation ? Te consideres-tu comme un assiste parce que tu as lu une fois l'aide sur telle option tordue ?
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.
<<
> - 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.
>>
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". Ca ressemble a un aveu d'impuissance. Au contraire, il faut rechercher l'ergonomie qui permet d'integrer ce besoin sans perturber les autres usages, plus courants. C'est le challenge et c'est le genre d'avancees que KDE ou Gnome proposent.
De fait, kprinter, ainsi que le futur equivalent pour gnome gerent cette problematique tres bien. Tu as un dialogue pour les configurations courantes, et si tu cliques sur avance, la tu peux te lacher avec les configurations tordues. Pas besoin de cacher ca honteusement dans gconf.
> C'est comme pour la vitesse de gravage. Orgonomiquement ça n'apporte rien.
C'est une fonctionnalite importante (de ce que j'en sais, je n'ai jamais grave) puisque a certaines vitesses, certains graveurs fonctionnent mal. Donc il est important que la vitesse de gravage qui va etre utilisee soit au moins affichee, de facon a ce que l'utilisateur averti puisse verifier que tout semble ok.
> C'est comme les options "activer bidule pour éviter le bug de truc". Il faut corriger truc et non ajouter une option.
Tout a fait. Il doit y avoir au moins 50% des options de configurations qui ne sont la que pour pallier a une interface problematique. Les developpeurs sont assez obtus parfois sur leur choix et refusent d'envisager que leur vision n'est pas la plus commune. Parfois, ils font un geste, ils t'ajoutent une option.
> Si c'est pour un petit nombre d'utilisateur, cette option doit être viré de
> l'interface graphique par défaut.
C'est la que nos points de vue divergent.
> L'environnement par défaut doit être simple et ne pas demander de consulter 20 tableaux de configuration.
Tout a fait. Et c'est relativement le cas pour KDE. La premiere fois que tu l'utilises, il lance kpersonaliser, qui te permet de configurer quelques parametres importants et apres tout marche. C'est la politique de "on doit avoir de bonnes options par defaut".
> 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...
Vraiment ? Es-tu sur ? L'experience montre au contraire que les gens qui sont depasses par les options de configuration ne vont meme pas les voir.
Ceux qui vont voir les options de configurations sont justement ceux qui sont capables de les utiliser et apprecient de pouvoir regler des parametres auxquels seuls eux sont sensibles (position de la barre des taches, vitesse de la souris, etc).
Evidemment, apres, il faut faire attention a l'ergonomie. Si tu balances le XF86Config a quelqu'un qui veut juste ajouter un racourci clavier, il va etre depasse. Mais si tu fournis une interface pour certaines sections et options de XF86Config qui lui permettent de rajouter facilement des actions sur ses boutons en plus de son clavier, il appreciera.
Mais je suis contre renoncer a l'ergonomie sous pretexte qu'on peut toujours editer son XF86Config a la main.
> Pour les quelques utilisateurs pour qui l'option est indispensable, ils passent par gconftool/gconf-editor ou vim/kconf, etc...
Je crois que je me suis exprime assez clairement: je ne suis pas d'accord avec cette approche. C'est comme si on pensait qu'on ne peut faire que des outils graphique pour neuneu. Non, meme un utilisateur tres avance peut apprecier un bon outil graphique. Mais il faut que l'outil graphique soit bon, il faut de l'ambition des le depart.
[^] # Re: SFTP
Posté par Christophe Fergeau . Évalué à 0.
Et il est dommage qu'aaron (je ne connais pas du tout ce monsieur, donc je sais pas du tout ce que je dis :) ait renoncé à faire une interface simple, et considère que la seule possibilité quand les développeurs ne savent pas quoi mettre par défaut est de caser une option de config bien cachée dans le coin sous le tapis ou personne ne la voit.
Pour le débat sur la taillle du cache du graveur de CD, je tiens à vous rappeler à tous les deux que de nos jours, soit le graveur va vite et de toute facon il supporte le burnproof ou assimilé et donc on s'en fout complètement qu'il y ait des buffer overrun en cours de gravure, soit il est lent, et quoi que l'on fasse, le disque dur devrait pouvoir suivre. Et si on a une vieille machine avec un graveur lent et que l'on tente de compiler trois noyaux en matant un dvd, je pense que la personne qui fait ça mérite de foirer son cd :)
[^] # Re: SFTP
Posté par Toufou (site web personnel) . Évalué à 1.
D'un autre côté, la personne qui fais l'apprenti sorcier avec des trucs qu'elle ne maîtrise pas du tout mérite de foirer son install, non ?
[^] # Re: SFTP
Posté par Christophe Fergeau . Évalué à 1.
J'ai suffisamment donné en "réparation" de windows avec mes parents ou mes soeurs qui modifient des trucs sans trop savoir ce que ça fait, et ensuite "je comprends pas, j'ai rien touché"
[^] # Re: SFTP
Posté par Toufou (site web personnel) . Évalué à 1.
- Soit c'est windows qui se dégrade tout seul et ils ont effectivement rien touché => mauvais système, changer système.
- Soit ils ont touché et dans ce cas ils faut leur dire de ne pas toucher ce qu'ils ne comprennent pas.
L'utilisation d'un ordi est a la portée de tout le monde, certes, mais certainement pas sa configuration ou sa maintenance (c'est un peu comme si j'allais faire l'apprenti sorcier dans le moteur de ma voiture).
Donc :
- soit tu protèges les options de configurations critiques et ne les laisses disponibles que pour l'administrateur. C'est ce que font beaucoup de systèmes, même Windows 9x via poledit (je crois)
- soit tu expliques aux utilisateurs qu'il ne faut pas y toucher (moi non plus je ne crois pas à cette solution).
Dans tous les cas (et pour revenir au sujet initial), ça ne remet pas en cause l'accès à _toutes_ les options de configuration d'un soft via une IHM conviviale (graphique ou texte), il faut juste en protéger l'accès.
[^] # Re: SFTP
Posté par Christophe Fergeau . Évalué à 1.
[^] # Re: SFTP
Posté par matiasf . É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 nigaiden . Évalué à 1.
C'est vrai que c'est dommage, car ces ioslaves sont une bonne idée. Certains me semblent vraiment adaptés aux débutants/ceux-qui-veulent-pas-s'emm.. : je pense en particulier à audiocd:// qui permet de faire facilement des ogg. Seulement cet ioslave n'est pas très accessible à ces personnes. Dommage...
[^] # Re: SFTP
Posté par matiasf . Évalué à 8.
Présent !
C'est pour quoi faire un environnement graphique sous unix ? C'est pour faire simple et pas pour se prendre la tête. Pour le compliqué, je me tourne vers une ligne de commande.
Par exemple il y a des programmes graphique de gravage de cd qui sont pleins d'options. Pour utiliser ces programmes il faut faire un "man mkisofs", un "man cdrecord", lire 3 Howto, etc... Dans ces cas, je préfère la ligne de commande. Afin les programmes graphiques blindés d'options qui font tout et un peu plus sont généralement beaucoup plus bugués que la version ligne de commande.
J'utilise Gnome mais je préfère une xterm à un truc faussement conviale.
[^] # Re: SFTP
Posté par Olivier Jeannet . Évalué à 2.
Excuse-moi, mais ça fait plusieurs messages que tu parles de gravage, je te signale que tu inventes un mot, on parle de gravure tout simplement.
[^] # Re: SFTP
Posté par patton . Évalué à 1.
A part ca si vous aviez aussi une idee pour un client graphique sous win ce serait parfait.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.