au serveur S qui peut être weloveourdictator.org ou deathtothedictator.org
Si les deux sont obligés d’utiliser le même certificat et donc doivent appartenir à la même personne, ça limite vraiment les possibilités de cacher un site derrière un autre (je vois mal les torturés monter un site avec leurs bourreaux pour garantir que ni les uns ni les autres ne savent qui regarde quoi, surtout que le détenteur du certificat peut tout déchiffrer, c'est ballot).
À part l’exemple de Wikipedia qui n’est qu’une vitrine vers une console de contrôle du monde, tu as des exemples où la confusion entre plusieurs noms possible peut apporter quelque-chose concrètement ?
Bon, dès ce soir, je commence à me générer des certificats clients pour Wikipedia, ce sera peut-être long par force brute, mais si ce que tu dis est vrai, le jeu en vaut la chandelle… ☺
Oui, j'avais oublié ça parce-que ça implique du coup que tous les noms partagent le même certificat. Je répondais en réaction à tu peux seulement connaître l'ip du serveur avec lequel la personne communique (et le port), or avec HTTPS, on connaît le certificat en plus (mais effectivement pas directement le nom).
Donc ne pas voir transiter le nom n'apporte pas de confidentialité supplémentaire, on sait quand-même chez qui tu consultes les infos (le même détenteur du certificat), alors qu'avec la seule IP, sur des serveurs mutualisés ça serait très différent. Seulement dans ce cas, HTTPS offrirait plus de confidentialité que le nom qui circule en clair, ce n'est pas le cas, donc sans minimiser l'intérêt d'HTTPS, il n'apporte rien de ce côté là (même si ma réponse trop rapide était fausse).
En pratique, ça ne change pas grand-chose, parce-que du coup le serveur doit répondre en HTTPS avant de savoir avec quel nom il est consulté, donc en HTTPS : 1 IP = 1 nom.
En fait, j'ai court-circuité une explication dans le journal. De la même manière que GTK quand aucune méthode d'entrée n'est spécifiée, IBus n'utilise pas XIM mais sa propre méthode d'entrée quand le mode de saisie par mots n'est pas activé. Du coup, IBus souffre des mêmes limitations et ne prend pas en compte la configuration des entrées X.org. Pas de « $HOME/.XCompose » avec IBus, et ses tables de compositions ne sont pas synchronisées avec X.org, d'où l'intérêt du greffon IBus XKBC (lien dans le journal) qui devrait résoudre ce problème.
Du coup, par défaut, j'ai le choix entre le confort de mes combinaisons de touches via la composition de X, ou la possibilité de saisir des caractères mathématiques par mots LaTeX. Comme je n'utilise que des langues à alphabets courts et pas de chinois ou de japonais, je préfère bénéficier par défaut de mes réglages de composition que de la saisie par mots. Évidemment, avant que je découvre ces problèmes j'utilisais IBus en permanence (et c'est ce que doivent faire tous les utilisateurs de GTK qui n'ont jamais vu les limites du mode de saisie par défaut).
Non, « Contrôle + Espace » ça sert juste à basculer le mode de saisie dans le cas où tu utilises déjà une méthode d'entrée comme IBus. Heureusement qu'en l’utilisant tu peux toujours taper des caractères normaux et que tu as bien deux modes de saisie. Maintenant, tu verras que tu peux aussi choisir avec le menu des champs de saisie une autre méthode d'entrée, auquel cas « Contrôle + Espace » n'aura plus d'effet mais les autres points abordés fonctionneront.
Pour activer XIM manuellement par exemple, il faut choisir dans le menu la méthode d'entrée « Méthode de saisie X » pour GTK en français ou XIM dans Qt en anglais (désolé, je n'ai pas sous la main d'appli Qt francisée où il est possible de changer la méthode d'entrée).
Le jour ou une distro viendra avec 40000 logiciels (pas paquets, logiciels) à jour, on pourra commencer (seulement commencer) à dire que le système de dépôt rempli son rôle
Ah parce que, selon toi, le rôle d'un système de dépots, le but ultime, c'est forcément d'avoir plein de logiciels ?
Pour abonder dans ce sens, combien de fois ai-je utilisé aptitude pour trouver le nom d'un logiciel à conseiller à mes collègues sous Windows ! À chaque fois, malgré les quelques faux-positifs qui ne sont pas portés sous Windows, le logiciel que je trouve est mieux adapté à leur besoin que le gratuiciel qu'ils ont mis un temps fou à repérer sur les sites de téléchargement (ou le truc craqué que leur a filé un autre collègue).
Au final c'est bien, ça a même convaincu certains de quitter Windows complètement. Les autres se contentent des quelques logiciels libres que je leur ai conseillé ainsi puisque (et c'est tant mieux) cette méthode de recherche ne renvoie que des logiciels libres.
Et surtout, contrairement à ce que dit Zenitram, il n'y a aucune incohérence entre suivre les versions sur un site dédié et utiliser un gestionnaire de paquets. En effet, les versions ne sont pas forcément les mêmes (et j'ai déjà expliqué pourquoi ça ne me gêne pas plus que ça), et le public n'est pas tout à fait le même. Là où le gestionnaire de paquets est censé être utilisé par tous les utilisateurs, seuls ceux qui veulent chercher un peu plus loin, les développeurs et les curieux utilisent Freshmeat.
Par exemple, personnellement, je regarde beaucoup Distrowatch alors que l'essentiel des annonces concerne des versions bêta, c'est que j'ai envie de tester les nouveautés, éventuellement de remonter des bugs, mais ce n'est pas pour autant que veux tout tout de suite dans ma Debian. C'est valable avec d'autres logiciels, même en tant que non développeur, il m'arrive de compiler certaines applis depuis les dépôts Git (ou SVN, c'est pas moi qui choisis), et ça ne m'empêche pas d'utiliser au quotidien la version distribuée par Debian qui est souvent plus stable et plus intégrée au reste de la distro.
Tu as l'air de connaitre un minimum de choses sur la question (ce que laissent supposer tes interventions). Pourquoi ne pas initier une réflexion/comparatif sur ces différents systèmes de package: recenser, détailler, comparer... pour qu'il soit possible ensuite de spécifier/réaliser l'évolution vers un meta-package.
De toute façon, je ne crois pas que ce serait la bonne solution. La fabrication de paquet n'est pas toujours aisée, et elle gagnerait à être simplifiée pour beaucoup de distros, cependant je trouve ça très bien si les développeurs ne font leurs paquets eux-même. L'intérêt des paquetages, ce n'est pas leur format, mais le travail d'intégration à la distribution que font les mainteneurs (sauf pour Ubuntu ☺).
La course au numéro de version, c'est un peu le truc qui ne sert à rien. Je ne me plains pas chque fois que je vois une fonctionnalité ajoutée dans le SVN d'un projet et qu'elle n'est pas encore dans ma distro. Déjà, je dois attendre que la sortie d'une version par les développeurs, et ensuite les mainteneurs fabriquent le paquet et apportent toute leur connaissance des rouages de la distro. je considère que ça fait partie du cycle de développement. Après, pour les testeurs ou lors d'une fonctionnalité vraiment intéressante, j'apprécie que les développeurs me dépannent en sortant des verisons précompilées (et plutôt pas sous la forme de paquetages) des « nightly builds », mais c'est normal si ce n'est pas dans la distro.
Quand est-ce que'ont remet en question le principe des dépôts avec un format propre à chaque distro dans son coin et que donc le "collectif" n'arrive pas à suivre? Je sais, tabou tout ça... Ne surtout pas parler de ce qui ne marche pas...
Ce n'est pas tabou, c'est juste que ça marche très bien pour l'utilisateur et que ça évite la multiplication des tiers de confiance lors de la distribution d'un programme. Maintenant, les développeurs qui font eux-même leur paquet, c'est un truc que je n'ai jamais vraiment compris, en tant qu'utilisateur ça m'a toujours compliqué les choses :
- je dois installer le paquet en tant que super-utilisateur, alors que je pourrais tester le programme en tant qu'utilisateur simple ;
- il manque toujours plein de distributions ;
- les devs se plaignent de devoir faire ce boulot que je ne leur demande pas ;
- si ça marche sous Windows, c'est parce-qu'en cas de soucis les dévs n'hésitent pas à fourguer avec le programme tout un paquet de choses qui seraient des dépendances sous Linux. Eh ben moi ça m'irait bien un programme pré-compilé dans un répertoire avec des bibliothèques liées statiquement ou un wrapper qui définit un LD_LIBRARY_PATH comme le proposent beaucoup d'éditeurs de logiciels proprios sous Linux. C'est simple pour l'utilisateur comme sous Windows, et au moins, ça laisse la fabrication des paquets à ceux qui font ça bien.
Je ne sais pas s'il existe encore des gens pour ne pas saisir la référence, voilà de quoi comprendre : http://www.arobase.org/spam/monty-python.htm (avec texte original et traduction pour les anglophobes).
les images sur des pages web ça a d'autres usages que une photo OU des éléments de décoration [...] comme dans des pages dites interactives
Une image rend interactif ? Même dans une page interactive, une image reste une image. Peut-t-elle être autre chose qu'un contenu (auquel cas le alt est nécessaire et justifié) ou de la présentation (qui devrait partir en CSS) ?
indispensable à la page. mais inutile pour un non-voyant.
Oui, donc rien à voir avec l'accessibilité du coup s'il existe des trucs indispensables mais que ça ne concerne pas les non-voyants et qu'ils ont pas à le savoir (après tout c'est pas ta faute s'ils y voient rien, hein).
c'est ballot, c'est explicitement prévu et conseillé par la norme
Oui, c'est même ce à quoi je répondais. Avec le contexte d'un tel conseil, ça veut dire en gros, « ne le faîtes pas, après si vous voulez être valide avec le schéma normalisé sans comprendre pourquoi, la solution est de mettre un truc vide ». Normalement si t'as bien fait ton boulot en amont (séparation de la CSS) ça n'arrive pas.
forcer la main à de nombreux pisseurs de code qui ne s'en servaient pas du tout.
Ceux qui ne s'en servaient pas en mettent maintenant un vide… Personnellement je m'en fous, ce n'est pas plus accessible dans un cas que dans l'autre (donc pas pire). Par contre je trouve intelligent que la norme considère qu'une image dispose nécessairement d'un texte alternatif. Après si en tant qu'auteur TU considères que les aveugles, les navigateurs consoles, les moteurs de recherche et autres ne méritent pas d'accéder à l'information, eh ben tu décris rien dans le alt.
Si moi je considère que les gens qui utilisent des navigateurs respectueux des standards n'ont pas à lire tout ce que j'écris, alors je mets du texte dans des commentaires XML en exploitant des bugs de parsing d'IE. J'ai des documents valides, lisibles que sous IE… Ben c'est pas ce que prévoit la norme, ça te choque ?
Le point où je suis en désaccord avec moi-même dans ma réponse précédente, c'est la comparaison avec le poids des images. C'est vrai que ça peut ne pas être négligeable comme le soulignait Zenitram. Maintenant, dans la mesure où ça s'adresse aux images CONTENUES dans la page, c'est normal qu'elles soient accessibles à tous, et donc cette surcharge me paraît tout à fait justifiée.
Pour brièveté peut-être, mais en pratique ça arrange bien ton propos aussi. Le alt="" est un contournement de norme, c'est juste que quitte à ne pas respecter les recommandations du W3C quand on met des puces en tant qu'images dans le corps de texte, le W3C rappelle que ce n'est pas une raison pour oublier la norme et propose donc un moindre mal : tu fais n'importe quoi, mais tu l'assumes dans le document en écrivant explicitement que c'est n'importe quoi que tu voulais faire (alt="" signifie en gros que ton truc ne sert à rien).
Et puis 6 caractères ASCII, alors que tu charges une image pour faire une puce, je ne vois pas le bloat, c'est quoi 6 octets par rapport à ton image ?
Posté par jyes .
En réponse au journal Oui, Mariage.
Évalué à 2.
Si, l'État reconnaît au moins le catholicisme, la protestantisme et autres dérivés du christianisme, ainsi que le judaïsme et la religion musulmane. Je ne connais pas la liste exacte, il y en a peut-être d'autres, mais toutes croyances ne sont pas mises sur le même plan. Les sectes par exemple sont interdites, c'est-à-dire que tu peux croire en ce que tu veux, mais récolter une obole pour faire vivre ton église du Grand Ornithorynque Asthmatique risque de t'attirer des ennuis.
Les Églises bénéficient ce cette reconnaissance mais du coup, elles n'ont pas le droit de faire n'importe-quoi (en théorie).
Éhéh, effectivement je me suis emporté. Je me suis emporté parce-que j'ai voulu répondre à tes deux messages en même temps, et qu'OpenSearch n'apporte rien (ni n'enlève d'ailleurs) à l'intérêt contestable d'une barre de recherche séparée.
Donc en vrai et après vérification, Arora gère parfaitement OpenSearch mais pas Midori et Seamonkey. Midori dispose par contre d'un moyen très facile de définir de nouveaux moteurs de recherche ce qui compense au moins partiellement ce manque. Quant à Seamonkey, je ne sais vraiment pas d'où me venait cette impression, en fait c'est même assez compliqué de lui ajouter des moteurs de recherche et ça mériterait d'être amélioré (c'est un format simple à comprendre, mais pas OpenSearch, et inaccessible depuis les menus du navigateur).
Donc j'ai écrit beaucoup de bêtises, pardon aux familles tout ça, mais vous ne m'enlèverez pas de l'idée qu'une barre commune présente plein d'avantages. Et grâce à Tanguy Ortolo, j'ajoute même : « et vive OpenSearch ! ».
TOUS [1] les navigateurs que j'ai essayé le proposent !
Arora, Seamonkey, Midori [2] gèrent très bien le format OpenSearch et permettent tous de changer le moteur de recherche par défaut et à la volée pour des cas ponctuels. Ça n'explique en rien le besoin d'une deuxième barre. Seamonkey justement s'en sort sans (en fait il triche, il a un panneau de recherche complet mais qui n'est pas forcément visible en permanence, et un moteur de recherche AU CHOIX dans la barre d'adresse).
[1] J'ai menti, j'utilise aussi links2 qui ne le propose pas, mais l'idée générale reste la même.
[2] Midori permet même de créer facilement un moteur de recherche à partir de rien, ce qui est très bien. Pour Arora, j'avais dû regarder comment marche OpenSearch pour lui donner à manger, mais en gros Firefox n'est pas le seul navigateur pratique d'utilisation. J'essaye régulièrement Firefox mais je n'arrive pas encore à gérer les droits des sites que je visite (chargement des images, scripts, etc) avec une granularité aussi fine qu'avec Seamonkey.
La barre de recherche est intégrée à la barre d'adresse. C'est même une fonctionnalité qui me rend difficile de quitter Iceape/Seamonkey. Tu tapes un mot pour voir dans ton historique si ça te remonte quelque-chose, si rien ne te satisafit, un coup de flêche vers le haut et pouf! la recherche peut-être directement lancée dans ton moteur de recherche par défaut. Et pour une barre de recherche distincte avec d'autres atouts, il y a un panneau avec un onglet "rechercher" très complet.
Je ne comprend pas pourquoi les autres navigateurs séparent la barre de recherche et d'adresse, ce sont deux fonctions séparées mais la manière dont c'est fait dans Seamonkey sépare bien les deux, sauf que quand on cherche un truc et qu'on s'aperçoit la "recherche intelligente" dans l'historique ne done rien, ça évite de devoir le copier puis le coller dans une autre barre : on ne se sert jamais des deux en même temps !
L'utilisation que j'en voit sur quasiment toutes les installations Gnome actuelles par exemple, c'est le déverrouillage du trousseau par défaut à l'ouverture de la session. C'est directement un plugin PAM qui démarre gnome-keyring quand tu te connectes (du coup, ça marche aussi bien avec Gdm, Kdm, Xdm, etc).
Autre usage, dans un cas moins Michu mais toujours desktop, c'est le déchiffrement du $HOME au login. Ou alors utiliser des utilisateurs ne diposant pas de mot de passe (donc dans l'impossibilité de s'identifier pour quelque service que soit via su, ssh, etc) mais autorisés à se connecter depuis l'écran et le clavier physiques de la machine (utile pour un compte Guest sans authentification sur une machine qui peut toutefois proposer des accès comme SSH pour être dépannée à distance).
La seule limite à l'usage de PAM est ton imagination :-) et pour t'en donner une idée :
# aptitude search '?name(^libpam-.*)' | wc -l
63
Je trouve cette initiative vraiment intéressante, mais effectivement je pense que le choix de l'hébergeur peut avoir une incidence énorme sur la confidentialité que vous pouvez proposer. En effet, sans entrer dans l'illégalité, la réponse intelligente aux requêtes judiciaires et policières demande un certain temps que ne prennent pas les hébergeurs grand-public à bas coût.
Depuis que No-Log a rendu impossible la création de nouveaux comptes sur leur serveur, l'association a continué à vivre et cherche à essaimer son fonctionnement vers d'autres serveurs indépendants afin de décentraliser les échanges de courriers électroniques. En effet, arrivés à plus 70 000 comptes, No-Log ne faisait plus seulement face à des problèmes techniques, mais aussi philosophiques : que se passerait-il en cas de compromission du serveur, ou de saisie ? No-Log a toujours respecté la loi et répondu aux requêtes judiciaires en bonne et due forme, mais a toujours respecté au maximum la confidentialité et l'indépendance de ses utilisateurs, ce que sa trop grande taille remettait en question. En arrêtant la création de comptes, l'association espérait bien voir apparaître de nouvelles initiatives pour prendre le relai et s'est proposée de les accompagner tant sur le plan de l'aide technique au besoin que sur les facilités d'hébergement etc.
Tout ça pour dire que je trouve Sud-Ouest.org très intéressant et qu'il prend une très bonne direction malgré son hébergeur. Peut-être qu'en prenant contact avec des gens de Globenet, vous pourriez même régler ce dernier point sans douleur et dans un délai raisonnable (pour vous).
En tout cas, bonne continuation, excellente initiative ! Depuis le retrait de No-Log, je ne savais plus quel fournisseur de courriel conseiller, le vôtre me paraît actuellement le meilleur (après la solution perso chez soi sur sa ligne Internet mais cette solution ne convient pas encore à tout le monde/tous les usages).
Bon, sinon, la vraie principale différence avec No-Log, c'est que No-Log était/est un fournisseur d'accès à Internet (bas débit).
Personnellement, je n'utilise ni KDE ni vraiment Gnome, mais justement ce qui me retient le plus d'utiliser KDE c'est cette impression de retour sous Windows. OK, il paraît (et j'ai essayé, ça semble vrai dans une certaine mesure) que c'est super configurable par rapport à Gnome etc, mais ce que je vois moi de mon point de vue utilisateur c'est que les technos sont très interdépendantes, alors qu'il est (surtout était mais ça reste vrai pour encore une majeure partie) facile d'utiliser certaines briques de Gnome sans utiliser tout Gnome. Je trouve Gnome plus modulaire, avec notamment une distinction forte entre les applications rendant des services et les applications pour les utiliser. Du coup mon bureau est rempli de technos Gnome qui ne se voient pas mais qui fonctionnent très bien comme ça, et je n'ai même pas de Gnome panel, ni même l'ensemble de libs Gnome-Desktop d'installé.
Là où je suis parfaitement d'accord avec toi, c'est sur l'aspect chiant de Gconf. C'est documenté, mais même en ayant un peu l'habitude de travailler avec il reste très difficile d'anticiper l'organisation d'un morceau de configuration que l'on décrouvre, et lire la doc avant chaque nouveau réglage n'est clairement pas ergonomique. Cela dit, avec des dépendances faibles au bureau Gnome lui-même, les clefs Gconf à bidouiller à la main sont extrêmement rares (mais cet atout ne concerne pas les "vrais" utilisateurs de Gnome).
[^] # Re: Drogue ?
Posté par jyes . En réponse au journal Le figaro : gentoo [a une] redoutable pointe de vitesse. Évalué à 10.
[^] # Re: Intérêt d'HTTPS ?
Posté par jyes . En réponse au journal HTTPS Everywhere. Évalué à 2.
Si les deux sont obligés d’utiliser le même certificat et donc doivent appartenir à la même personne, ça limite vraiment les possibilités de cacher un site derrière un autre (je vois mal les torturés monter un site avec leurs bourreaux pour garantir que ni les uns ni les autres ne savent qui regarde quoi, surtout que le détenteur du certificat peut tout déchiffrer, c'est ballot).
À part l’exemple de Wikipedia qui n’est qu’une vitrine vers une console de contrôle du monde, tu as des exemples où la confusion entre plusieurs noms possible peut apporter quelque-chose concrètement ?
Bon, dès ce soir, je commence à me générer des certificats clients pour Wikipedia, ce sera peut-être long par force brute, mais si ce que tu dis est vrai, le jeu en vaut la chandelle… ☺
[^] # Re: Intérêt d'HTTPS ?
Posté par jyes . En réponse au journal HTTPS Everywhere. Évalué à 2.
Donc ne pas voir transiter le nom n'apporte pas de confidentialité supplémentaire, on sait quand-même chez qui tu consultes les infos (le même détenteur du certificat), alors qu'avec la seule IP, sur des serveurs mutualisés ça serait très différent. Seulement dans ce cas, HTTPS offrirait plus de confidentialité que le nom qui circule en clair, ce n'est pas le cas, donc sans minimiser l'intérêt d'HTTPS, il n'apporte rien de ce côté là (même si ma réponse trop rapide était fausse).
[^] # Re: Intérêt d'HTTPS ?
Posté par jyes . En réponse au journal HTTPS Everywhere. Évalué à 2.
En pratique, ça ne change pas grand-chose, parce-que du coup le serveur doit répondre en HTTPS avant de savoir avec quel nom il est consulté, donc en HTTPS : 1 IP = 1 nom.
[^] # Re: L'UTF-8 sa krash du fe
Posté par jyes . En réponse au journal Méthodes d’entrée pour les applications graphiques, de XIM à GTK en passant par IBus et UIM. Évalué à 0.
[^] # Re: SCIM vs IBus
Posté par jyes . En réponse au journal Méthodes d’entrée pour les applications graphiques, de XIM à GTK en passant par IBus et UIM. Évalué à 3.
Du coup, par défaut, j'ai le choix entre le confort de mes combinaisons de touches via la composition de X, ou la possibilité de saisir des caractères mathématiques par mots LaTeX. Comme je n'utilise que des langues à alphabets courts et pas de chinois ou de japonais, je préfère bénéficier par défaut de mes réglages de composition que de la saisie par mots. Évidemment, avant que je découvre ces problèmes j'utilisais IBus en permanence (et c'est ce que doivent faire tous les utilisateurs de GTK qui n'ont jamais vu les limites du mode de saisie par défaut).
[^] # Re: SCIM vs IBus
Posté par jyes . En réponse au journal Méthodes d’entrée pour les applications graphiques, de XIM à GTK en passant par IBus et UIM. Évalué à 4.
Pour activer XIM manuellement par exemple, il faut choisir dans le menu la méthode d'entrée « Méthode de saisie X » pour GTK en français ou XIM dans Qt en anglais (désolé, je n'ai pas sous la main d'appli Qt francisée où il est possible de changer la méthode d'entrée).
[^] # Re: commentaire inutile
Posté par jyes . En réponse au journal Ah le français !. Évalué à 3.
https://help.ubuntu.com/community/GtkComposeTable
[^] # Re: LaTeX, c'est bien !
Posté par jyes . En réponse à la dépêche Sortie de LyX 1.6.6 et LyX 2.0-α4. Évalué à 3.
[^] # Re: Jobs tout puissant
Posté par jyes . En réponse au journal Vulnérabilité du greffon Flash : 64 bits piégés. Évalué à 6.
[^] # Re: fin annoncée...
Posté par jyes . En réponse au journal La fin de Freshmeat.net. Évalué à 3.
Pour abonder dans ce sens, combien de fois ai-je utilisé aptitude pour trouver le nom d'un logiciel à conseiller à mes collègues sous Windows ! À chaque fois, malgré les quelques faux-positifs qui ne sont pas portés sous Windows, le logiciel que je trouve est mieux adapté à leur besoin que le gratuiciel qu'ils ont mis un temps fou à repérer sur les sites de téléchargement (ou le truc craqué que leur a filé un autre collègue).
Au final c'est bien, ça a même convaincu certains de quitter Windows complètement. Les autres se contentent des quelques logiciels libres que je leur ai conseillé ainsi puisque (et c'est tant mieux) cette méthode de recherche ne renvoie que des logiciels libres.
[^] # Re: fin annoncée...
Posté par jyes . En réponse au journal La fin de Freshmeat.net. Évalué à 8.
Et surtout, contrairement à ce que dit Zenitram, il n'y a aucune incohérence entre suivre les versions sur un site dédié et utiliser un gestionnaire de paquets. En effet, les versions ne sont pas forcément les mêmes (et j'ai déjà expliqué pourquoi ça ne me gêne pas plus que ça), et le public n'est pas tout à fait le même. Là où le gestionnaire de paquets est censé être utilisé par tous les utilisateurs, seuls ceux qui veulent chercher un peu plus loin, les développeurs et les curieux utilisent Freshmeat.
Par exemple, personnellement, je regarde beaucoup Distrowatch alors que l'essentiel des annonces concerne des versions bêta, c'est que j'ai envie de tester les nouveautés, éventuellement de remonter des bugs, mais ce n'est pas pour autant que veux tout tout de suite dans ma Debian. C'est valable avec d'autres logiciels, même en tant que non développeur, il m'arrive de compiler certaines applis depuis les dépôts Git (ou SVN, c'est pas moi qui choisis), et ça ne m'empêche pas d'utiliser au quotidien la version distribuée par Debian qui est souvent plus stable et plus intégrée au reste de la distro.
[^] # Re: Explication?
Posté par jyes . En réponse au journal Petit coup de gueule contre les distributions grand public. Évalué à 5.
Tu as l'air de connaitre un minimum de choses sur la question (ce que laissent supposer tes interventions). Pourquoi ne pas initier une réflexion/comparatif sur ces différents systèmes de package: recenser, détailler, comparer... pour qu'il soit possible ensuite de spécifier/réaliser l'évolution vers un meta-package.
De toute façon, je ne crois pas que ce serait la bonne solution. La fabrication de paquet n'est pas toujours aisée, et elle gagnerait à être simplifiée pour beaucoup de distros, cependant je trouve ça très bien si les développeurs ne font leurs paquets eux-même. L'intérêt des paquetages, ce n'est pas leur format, mais le travail d'intégration à la distribution que font les mainteneurs (sauf pour Ubuntu ☺).
La course au numéro de version, c'est un peu le truc qui ne sert à rien. Je ne me plains pas chque fois que je vois une fonctionnalité ajoutée dans le SVN d'un projet et qu'elle n'est pas encore dans ma distro. Déjà, je dois attendre que la sortie d'une version par les développeurs, et ensuite les mainteneurs fabriquent le paquet et apportent toute leur connaissance des rouages de la distro. je considère que ça fait partie du cycle de développement. Après, pour les testeurs ou lors d'une fonctionnalité vraiment intéressante, j'apprécie que les développeurs me dépannent en sortant des verisons précompilées (et plutôt pas sous la forme de paquetages) des « nightly builds », mais c'est normal si ce n'est pas dans la distro.
[^] # Re: Explication?
Posté par jyes . En réponse au journal Petit coup de gueule contre les distributions grand public. Évalué à 1.
Ce n'est pas tabou, c'est juste que ça marche très bien pour l'utilisateur et que ça évite la multiplication des tiers de confiance lors de la distribution d'un programme. Maintenant, les développeurs qui font eux-même leur paquet, c'est un truc que je n'ai jamais vraiment compris, en tant qu'utilisateur ça m'a toujours compliqué les choses :
- je dois installer le paquet en tant que super-utilisateur, alors que je pourrais tester le programme en tant qu'utilisateur simple ;
- il manque toujours plein de distributions ;
- les devs se plaignent de devoir faire ce boulot que je ne leur demande pas ;
- si ça marche sous Windows, c'est parce-qu'en cas de soucis les dévs n'hésitent pas à fourguer avec le programme tout un paquet de choses qui seraient des dépendances sous Linux. Eh ben moi ça m'irait bien un programme pré-compilé dans un répertoire avec des bibliothèques liées statiquement ou un wrapper qui définit un LD_LIBRARY_PATH comme le proposent beaucoup d'éditeurs de logiciels proprios sous Linux. C'est simple pour l'utilisateur comme sous Windows, et au moins, ça laisse la fabrication des paquets à ceux qui font ça bien.
[^] # Re: Présent!
Posté par jyes . En réponse au journal Ce bug ne sera pas corrigé car nous ne pouvons pas le reproduire. Évalué à 2.
http://www.arobase.org/spam/monty-python.htm (avec texte original et traduction pour les anglophobes).
[^] # Re: pour la forme,
Posté par jyes . En réponse au journal Appel à l'accessibilité GNU. Évalué à 2.
Une image rend interactif ? Même dans une page interactive, une image reste une image. Peut-t-elle être autre chose qu'un contenu (auquel cas le alt est nécessaire et justifié) ou de la présentation (qui devrait partir en CSS) ?
indispensable à la page. mais inutile pour un non-voyant.
Oui, donc rien à voir avec l'accessibilité du coup s'il existe des trucs indispensables mais que ça ne concerne pas les non-voyants et qu'ils ont pas à le savoir (après tout c'est pas ta faute s'ils y voient rien, hein).
c'est ballot, c'est explicitement prévu et conseillé par la norme
Oui, c'est même ce à quoi je répondais. Avec le contexte d'un tel conseil, ça veut dire en gros, « ne le faîtes pas, après si vous voulez être valide avec le schéma normalisé sans comprendre pourquoi, la solution est de mettre un truc vide ». Normalement si t'as bien fait ton boulot en amont (séparation de la CSS) ça n'arrive pas.
forcer la main à de nombreux pisseurs de code qui ne s'en servaient pas du tout.
Ceux qui ne s'en servaient pas en mettent maintenant un vide… Personnellement je m'en fous, ce n'est pas plus accessible dans un cas que dans l'autre (donc pas pire). Par contre je trouve intelligent que la norme considère qu'une image dispose nécessairement d'un texte alternatif. Après si en tant qu'auteur TU considères que les aveugles, les navigateurs consoles, les moteurs de recherche et autres ne méritent pas d'accéder à l'information, eh ben tu décris rien dans le alt.
Si moi je considère que les gens qui utilisent des navigateurs respectueux des standards n'ont pas à lire tout ce que j'écris, alors je mets du texte dans des commentaires XML en exploitant des bugs de parsing d'IE. J'ai des documents valides, lisibles que sous IE… Ben c'est pas ce que prévoit la norme, ça te choque ?
Le point où je suis en désaccord avec moi-même dans ma réponse précédente, c'est la comparaison avec le poids des images. C'est vrai que ça peut ne pas être négligeable comme le soulignait Zenitram. Maintenant, dans la mesure où ça s'adresse aux images CONTENUES dans la page, c'est normal qu'elles soient accessibles à tous, et donc cette surcharge me paraît tout à fait justifiée.
[^] # Re: pour la forme,
Posté par jyes . En réponse au journal Appel à l'accessibilité GNU. Évalué à 1.
Et puis 6 caractères ASCII, alors que tu charges une image pour faire une puce, je ne vois pas le bloat, c'est quoi 6 octets par rapport à ton image ?
[^] # Re: Bonne initiative
Posté par jyes . En réponse au journal Oui, Mariage. Évalué à 2.
Les Églises bénéficient ce cette reconnaissance mais du coup, elles n'ont pas le droit de faire n'importe-quoi (en théorie).
[^] # Re: Bien uzbl
Posté par jyes . En réponse à la dépêche En vrac, les autres navigateurs. Évalué à 3.
Donc en vrai et après vérification, Arora gère parfaitement OpenSearch mais pas Midori et Seamonkey. Midori dispose par contre d'un moyen très facile de définir de nouveaux moteurs de recherche ce qui compense au moins partiellement ce manque. Quant à Seamonkey, je ne sais vraiment pas d'où me venait cette impression, en fait c'est même assez compliqué de lui ajouter des moteurs de recherche et ça mériterait d'être amélioré (c'est un format simple à comprendre, mais pas OpenSearch, et inaccessible depuis les menus du navigateur).
Donc j'ai écrit beaucoup de bêtises, pardon aux familles tout ça, mais vous ne m'enlèverez pas de l'idée qu'une barre commune présente plein d'avantages. Et grâce à Tanguy Ortolo, j'ajoute même : « et vive OpenSearch ! ».
[^] # Re: Bien uzbl
Posté par jyes . En réponse à la dépêche En vrac, les autres navigateurs. Évalué à 3.
Arora, Seamonkey, Midori [2] gèrent très bien le format OpenSearch et permettent tous de changer le moteur de recherche par défaut et à la volée pour des cas ponctuels. Ça n'explique en rien le besoin d'une deuxième barre. Seamonkey justement s'en sort sans (en fait il triche, il a un panneau de recherche complet mais qui n'est pas forcément visible en permanence, et un moteur de recherche AU CHOIX dans la barre d'adresse).
[1] J'ai menti, j'utilise aussi links2 qui ne le propose pas, mais l'idée générale reste la même.
[2] Midori permet même de créer facilement un moteur de recherche à partir de rien, ce qui est très bien. Pour Arora, j'avais dû regarder comment marche OpenSearch pour lui donner à manger, mais en gros Firefox n'est pas le seul navigateur pratique d'utilisation. J'essaye régulièrement Firefox mais je n'arrive pas encore à gérer les droits des sites que je visite (chargement des images, scripts, etc) avec une granularité aussi fine qu'avec Seamonkey.
[^] # Re: Bien uzbl
Posté par jyes . En réponse à la dépêche En vrac, les autres navigateurs. Évalué à 2.
Je ne comprend pas pourquoi les autres navigateurs séparent la barre de recherche et d'adresse, ce sont deux fonctions séparées mais la manière dont c'est fait dans Seamonkey sépare bien les deux, sauf que quand on cherche un truc et qu'on s'aperçoit la "recherche intelligente" dans l'historique ne done rien, ça évite de devoir le copier puis le coller dans une autre barre : on ne se sert jamais des deux en même temps !
[^] # Re: PAM ?
Posté par jyes . En réponse à la dépêche Sortie de Slackware 13.1. Évalué à 2.
Autre usage, dans un cas moins Michu mais toujours desktop, c'est le déchiffrement du $HOME au login. Ou alors utiliser des utilisateurs ne diposant pas de mot de passe (donc dans l'impossibilité de s'identifier pour quelque service que soit via su, ssh, etc) mais autorisés à se connecter depuis l'écran et le clavier physiques de la machine (utile pour un compte Guest sans authentification sur une machine qui peut toutefois proposer des accès comme SSH pour être dépannée à distance).
La seule limite à l'usage de PAM est ton imagination :-) et pour t'en donner une idée :
# aptitude search '?name(^libpam-.*)' | wc -l
63
[^] # Re: Différence avec no-log
Posté par jyes . En réponse à la dépêche Sud-Ouest.org : Un hébergeur libre de courriels et soucieux de votre liberté. Évalué à 7.
Depuis que No-Log a rendu impossible la création de nouveaux comptes sur leur serveur, l'association a continué à vivre et cherche à essaimer son fonctionnement vers d'autres serveurs indépendants afin de décentraliser les échanges de courriers électroniques. En effet, arrivés à plus 70 000 comptes, No-Log ne faisait plus seulement face à des problèmes techniques, mais aussi philosophiques : que se passerait-il en cas de compromission du serveur, ou de saisie ? No-Log a toujours respecté la loi et répondu aux requêtes judiciaires en bonne et due forme, mais a toujours respecté au maximum la confidentialité et l'indépendance de ses utilisateurs, ce que sa trop grande taille remettait en question. En arrêtant la création de comptes, l'association espérait bien voir apparaître de nouvelles initiatives pour prendre le relai et s'est proposée de les accompagner tant sur le plan de l'aide technique au besoin que sur les facilités d'hébergement etc.
Tout ça pour dire que je trouve Sud-Ouest.org très intéressant et qu'il prend une très bonne direction malgré son hébergeur. Peut-être qu'en prenant contact avec des gens de Globenet, vous pourriez même régler ce dernier point sans douleur et dans un délai raisonnable (pour vous).
En tout cas, bonne continuation, excellente initiative ! Depuis le retrait de No-Log, je ne savais plus quel fournisseur de courriel conseiller, le vôtre me paraît actuellement le meilleur (après la solution perso chez soi sur sa ligne Internet mais cette solution ne convient pas encore à tout le monde/tous les usages).
Bon, sinon, la vraie principale différence avec No-Log, c'est que No-Log était/est un fournisseur d'accès à Internet (bas débit).
[^] # Re: Mauvais métaphore
Posté par jyes . En réponse au journal De l'abération de la notion même d'antivirus. Évalué à 2.
Oh si, dans la balance des comptes des éditeurs d'antivirus, l'apport est largement positif …
[^] # Re: Adieu Mandriva
Posté par jyes . En réponse au journal Mandriva et Linagora. Évalué à 1.
Là où je suis parfaitement d'accord avec toi, c'est sur l'aspect chiant de Gconf. C'est documenté, mais même en ayant un peu l'habitude de travailler avec il reste très difficile d'anticiper l'organisation d'un morceau de configuration que l'on décrouvre, et lire la doc avant chaque nouveau réglage n'est clairement pas ergonomique. Cela dit, avec des dépendances faibles au bureau Gnome lui-même, les clefs Gconf à bidouiller à la main sont extrêmement rares (mais cet atout ne concerne pas les "vrais" utilisateurs de Gnome).