Merci pour ce résumé sur le vote électronique, ça clarifie bien les choses :)
Pour la conclusion de Stéphane Glondu, après avoir lu sa présentation, je trouve sa formule plutôt optimiste face à la réalité. Malgré une théorie du cryptage franchement avancée, un anonymat absolument inexplicable au votant moyen, bref en y mettant franchement du sien pour développer un système de vote électronique anonyme et sécurisé, tout cela est balayé en une phrase: on doit supposer que la machine est fiable.
Il n'y a pas l'ombre d'une solution pour ce problème. Plutôt que la formule utilisée par Stéphane Glondu, j'aurais donc conclu (AMHA) que le vote électronique comporte encore des problèmes majeurs non résolus qui devraient être bloquants aujourd'hui.
Mais pas si bloquants que ça, pour nos dirigeants actuels, manifestement…
La cours de cassation vient de donc prendre une décision en contradiction avec sa propre décision d'il y a 2 ans ? Les deux cas sont-ils donc différents ?
Une question se pose: qui a la responsabilité de "faire suivre" tout ce qui est lié à l'activation et au fonctionnement du logiciel ?
Prenons un exemple: Une version boîte de Windows, qui demande une activation qui sera (imaginons, je ne me souviens plus si c'est encore le cas) liée au hardware de la machine. Dans le cas d'une revente de cette licence, il faudrait réinitialiser cette activation: qui va supporter ce coût ? Est-ce à l'éditeur, dont la protection ne devrait pas entraver l'utilisation légale de son produit ? Est-ce au revendeur, sensé vendre un produit fonctionnel ?
Et comment se souvenir d'une passphrase par site ? Car certains sites stockent le mot de passe en dur… et parfois le perdent…
Bref, choisir des mots génère sûrement une meilleure entropie, mais trouver un automatisme site-->passphrase reste utile.
Il a juste pris le premier fichier .c qui apparaît dans ton lien. Mais au delà de ce détail, ton journal fera évidemment bondir n'importe quel développeur un peu consciencieux: aider à programmer sans écrire de commentaire est une aberration.
Un exemple tout simple ? J'ai regardé, dans l'ordre demo-04.c puis demo-03.c. J'ai globalement compris ce que faisait le second, grace…. aux commentaires :)
Ne pas se méprendre: proposer une abstraction pour l'accès au hardware en programmation est tout à fait appréciable. C'est surtout ces petits mots "compréhensible sans commentaire", qui rappellent inévitablement de mauvais souvenirs.
Moi j'ai cliqué sur "inutile", pas sur "déplaît". C'est distrayant, point. Ne pas confondre "Pertinent/inutile" avec "J'aime/J'aime pas" ou "Je suis d'accord/Je suis pas d'accord", même si la vague Facebook nous a tous un peu influencés…
Lorsque j'ai rédigé ce message, il y avait 10 commentaires. Je n'ai pas la possibilité de modifier mon commentaire initial, ni le contenu du journal. J'étais censé faire quoi ?
Effectivement, je suis allé un peu vite en besogne: gnome-control-center a simplement migré son code sur cet API: http://system-tools-backends.freedesktop.org/dbus-spec.html qui n'est actuellement implémenté que par un seul daemon: systemd.
On peut donc supposer qu'Ubuntu a implémenté un second daemon répondant à cet API DBus, ou bien qu'ils ont annulé le patch correspondant à ce bug: https://bugzilla.gnome.org/show_bug.cgi?id=658352
Je connais trop peu systemd pour le juger. Je m'inquiète seulement sur le fait qu'il implique une dépendance beaucoup plus forte entre les applications et le système d'init lui-même. Donc un système moins flexible.
Ce qui devait arriver arriva: systemd n'est plus "un système d'init comme un autre". Avec cette dépendance, Gnome devient spécifique à systemd, et donc à Linux. L'étau se resserre: on s'éloigne encore d'un pas des principes d'Unix.
La cause ? Aucune abstraction de systemd. Le bénéfice ? Une intégration plus poussée avec le noyau Linux. Les conséquences ? Un système monolithique, des inter-dépendances fortes.
systemd devient, de plus en plus, un composant difficile à remplacer…
Le remède est simple: imposer une interopérabilité. Bien sûr il faudrait définir les contours de cette contrainte (pour les sites web), mais il y a sûrement un compromis intelligent et acceptable.
Ce problème n'a jamais été réglé pour les messageries instantanées: les ponts entre MSN, Facebook et GTalk sont rares, même si Jabber améliore les choses. La question est moins présente aujourd'hui simplement parce que les posts sur G+ et Facebook ont remplacé en partie la messagerie instantanée.
On comprend cependant la réticence de Facebook à être interopérable: un concurrent pourrait alors facilement émerger. Pour ceux qui n'utilisent que les fonctions de base (liste de contacts, mur), la valeur ajoutée de FB est très faible. G+, qui fait partie d'un écosystème Google plus large, est peut-être moins inquiété par cette question.
Finalement, serait-ce intelligent d'imposer l'interopérabilité des données personnelles compilées sur les "gros" sites de réseaux sociaux ? Qu'en pensez-vous ?
Finalement c'est bien ça le plus important: libérer les données déjà saisies. Il faudrait donc demander à l'auteur (oui ! il faut le contacter !) soit:
* publier tout le code source, ou mieux, le mettre sous licence libre
* publier les specs de la base de données
Et il est probable que les specs de la base soient plus ou moins le logiciel lui-même, si l'architecture n'a pas été proprement découpée.
Personnellement, vu l'état de la situation actuelle, je vois mal quels arguments l'auteur pourrait avancer contre la diffusion du code source. Espérons qu'il ne l'ait pas perdu ! ;)
Il est bien triste que ce genre de nouvelle soit aussi rare. Dans les structures publiques, préférer le libre et libérer ses outils devrait être la norme. Bien sûr, on ne peut libérer du code dont on ne possède pas les droits, mais lorsque c'est développé en interne je ne vois pas où est le problème.
Les services publics et administrations sont payés directement par les citoyens. De même que les documents publics sont… publics, les logiciels "publics" devraient êtres aussi mis à disposition des citoyens.
Ou alors, les services publics n'ont-ils la main-mise sur quasiment aucun de leurs outils ? Dans ce cas, n'existe-t-il pas de logiciel libre capable de les remplacer efficacement ? Question naïve, j'imagine.
Non, là en l'occurence l'ami t'a prêté à 3%, puis il a vu que tu aurais du mal à rembourser tes futurs emprunts alors il a mis le taux des futurs emprunts à 18%. Toi, tu proposes de ne pas rembourser les prêts à 3%.
Visiblement ils ont pris les archives, fait "Imprimer en PDF", et pouf, 9€. C'est clairement insuffisant: soit ils baissent le prix pour refléter l'absence d'effort de mise en page pour le format numérique (ainsi que l'absence de support physique), soient ils font un réel travail de réédition, en prenant en compte les spécificités et les avantages du numérique.
Bref, une bonne idée mais visiblement mise en œuvre par un néophyte du numérique…
J'ai cherché "greenpeace", "moore", "julliard". Je ne crois pas un seul instant que ces personnes n'ont pas de lien avec le nucléaire. Ou alors ils tirent tous leurs renseignements dans Google News ?
Bref, un outil de dénonciation, au but flou, aux méthodes opaques. Quand je vois ça, je crains plus cette organisation que le nucléaire.
Pas de compromis entre les deux tours. La nuance est importante: au premier tour, tu votes pour un candidat et son programme. Si le programme change juste après, à quoi bon voter pour lui ?
Je suis d'accord avec toi. Il y a au moins trois façons de voir les choses:
C'est GTK la base, et donc ce genre de comportement devrait être spécifié au niveau GTK: montrer d'abord les dossier, montrer les fichiers cachés par défaut, single click… Dans ce cas, il faut tout mettre coté GTK, et faire en sorte que Nautilus ne fasse qu'utiliser ces préférences.
Le GtkFileChooser n'est qu'un outil, qui devrait s'adapter à l'environnement par le biais d'une API ou d'une config adaptée. Dans ce cas, on met la configuration dans Gnome (pas seulement Nautilus), et on a du coup un environnement de bureau cohérent au niveau Gtk.
Le GtkFileChooser a son propre comportement, un peu comme le fait qu'une appli Qt dans Gnome va appliquer son propre thème. Gnome devrait donc implémenter son propre GnomeFileChooser, qui aurait le comportement qui va bien. Comme au point 2., ceci dit, il mettre la configuration au niveau de Nautilus n'est pas idéal, et il faut la mettre au niveau Gnome.
C'est un peu lorsque Nautilus gérait le fond d'écran: c'était une préférence de Nautilus. WTF? C'était brouillon, mais au moins ça marchait… et ça peut être peaufiné plus tard, de toutes façons.
N'importe laquelle de ces solutions améliorerait la situation actuelle…
[^] # Re: mise en page
Posté par Christophe . En réponse à la dépêche Sortie du noyau Linux 3.5. Évalué à 3.
Je confirme… en gros on a un gros bloc HTML indigeste, au lieu de la belle news à la patrick_g. Frustration !
# Conclusion de Stéphane Glondu
Posté par Christophe . En réponse à la dépêche Petites actus sur le vote électronique (par ordinateurs de vote ou par Internet). Évalué à 6.
Merci pour ce résumé sur le vote électronique, ça clarifie bien les choses :)
Pour la conclusion de Stéphane Glondu, après avoir lu sa présentation, je trouve sa formule plutôt optimiste face à la réalité. Malgré une théorie du cryptage franchement avancée, un anonymat absolument inexplicable au votant moyen, bref en y mettant franchement du sien pour développer un système de vote électronique anonyme et sécurisé, tout cela est balayé en une phrase: on doit supposer que la machine est fiable.
Il n'y a pas l'ombre d'une solution pour ce problème. Plutôt que la formule utilisée par Stéphane Glondu, j'aurais donc conclu (AMHA) que le vote électronique comporte encore des problèmes majeurs non résolus qui devraient être bloquants aujourd'hui.
Mais pas si bloquants que ça, pour nos dirigeants actuels, manifestement…
# La cours a-t-elle Google ?
Posté par Christophe . En réponse au journal La vente liée est autorisée en France. Évalué à 4. Dernière modification le 13 juillet 2012 à 11:23.
Une recherche de 30 secondes me donne:
https://linuxfr.org/news/vers-la-fin-de-la-vente-li%C3%A9e-de-windows-la-cour-de-cassation-v
La cours de cassation vient de donc prendre une décision en contradiction avec sa propre décision d'il y a 2 ans ? Les deux cas sont-ils donc différents ?
# Responsabilité
Posté par Christophe . En réponse à la dépêche Licences privatives abusives : un éditeur ne peut pas s'opposer à la revente d'une licence. Évalué à 4.
Une question se pose: qui a la responsabilité de "faire suivre" tout ce qui est lié à l'activation et au fonctionnement du logiciel ?
Prenons un exemple: Une version boîte de Windows, qui demande une activation qui sera (imaginons, je ne me souviens plus si c'est encore le cas) liée au hardware de la machine. Dans le cas d'une revente de cette licence, il faudrait réinitialiser cette activation: qui va supporter ce coût ? Est-ce à l'éditeur, dont la protection ne devrait pas entraver l'utilisation légale de son produit ? Est-ce au revendeur, sensé vendre un produit fonctionnel ?
[^] # Re: Just sayin...
Posté par Christophe . En réponse au journal Gé(né)rer ses mots de passe. Évalué à 2.
Et comment se souvenir d'une passphrase par site ? Car certains sites stockent le mot de passe en dur… et parfois le perdent…
Bref, choisir des mots génère sûrement une meilleure entropie, mais trouver un automatisme site-->passphrase reste utile.
[^] # Re: code code fait la poule
Posté par Christophe . En réponse au journal HWA : accéder au matériel autrement. Évalué à 4.
Il a juste pris le premier fichier .c qui apparaît dans ton lien. Mais au delà de ce détail, ton journal fera évidemment bondir n'importe quel développeur un peu consciencieux: aider à programmer sans écrire de commentaire est une aberration.
Un exemple tout simple ? J'ai regardé, dans l'ordre demo-04.c puis demo-03.c. J'ai globalement compris ce que faisait le second, grace…. aux commentaires :)
Ne pas se méprendre: proposer une abstraction pour l'accès au hardware en programmation est tout à fait appréciable. C'est surtout ces petits mots "compréhensible sans commentaire", qui rappellent inévitablement de mauvais souvenirs.
[^] # Re: −42 ?
Posté par Christophe . En réponse au journal L'histoire du mot « Linux » ou étude scientifique du dit mot. Évalué à 1.
Moi j'ai cliqué sur "inutile", pas sur "déplaît". C'est distrayant, point. Ne pas confondre "Pertinent/inutile" avec "J'aime/J'aime pas" ou "Je suis d'accord/Je suis pas d'accord", même si la vague Facebook nous a tous un peu influencés…
[^] # Re: Merci
Posté par Christophe . En réponse au journal RFC 6647: Email Greylisting: An Applicability Statement for SMTP. Évalué à 2.
Ok, Merci !
[^] # Re: Merci
Posté par Christophe . En réponse au journal RFC 6647: Email Greylisting: An Applicability Statement for SMTP. Évalué à 4.
Vulgarisation, je n'irai pas jusque là: après avoir lu le journal, je ne sais toujours pas ce qu'est le Greylisting…
[^] # Re: Présentation de wmcoincoin
Posté par Christophe . En réponse au journal RPM de wmcoincoin 2.5.1f dispo . Évalué à 6.
Le gros bouton rouge.
[^] # Re: avant de s'énerver
Posté par Christophe . En réponse au journal Gnome3 et systemd, c'est la fin des haricots!. Évalué à 6.
Lorsque j'ai rédigé ce message, il y avait 10 commentaires. Je n'ai pas la possibilité de modifier mon commentaire initial, ni le contenu du journal. J'étais censé faire quoi ?
[^] # Re: avant de s'énerver
Posté par Christophe . En réponse au journal Gnome3 et systemd, c'est la fin des haricots!. Évalué à 10.
Effectivement, je suis allé un peu vite en besogne: gnome-control-center a simplement migré son code sur cet API: http://system-tools-backends.freedesktop.org/dbus-spec.html qui n'est actuellement implémenté que par un seul daemon: systemd.
On peut donc supposer qu'Ubuntu a implémenté un second daemon répondant à cet API DBus, ou bien qu'ils ont annulé le patch correspondant à ce bug: https://bugzilla.gnome.org/show_bug.cgi?id=658352
Bref, fausse alerte. Désolé pour le bruit.
[^] # Re: Irrémédiable
Posté par Christophe . En réponse au journal Gnome3 et systemd, c'est la fin des haricots!. Évalué à 10.
Je connais trop peu systemd pour le juger. Je m'inquiète seulement sur le fait qu'il implique une dépendance beaucoup plus forte entre les applications et le système d'init lui-même. Donc un système moins flexible.
[^] # Re: Irrémédiable
Posté par Christophe . En réponse au journal Gnome3 et systemd, c'est la fin des haricots!. Évalué à 10.
Certes. Combien de temps avant que KDE requière systemd, directement ou non ?
# Irrémédiable
Posté par Christophe . En réponse au journal Gnome3 et systemd, c'est la fin des haricots!. Évalué à 10.
Ce qui devait arriver arriva: systemd n'est plus "un système d'init comme un autre". Avec cette dépendance, Gnome devient spécifique à systemd, et donc à Linux. L'étau se resserre: on s'éloigne encore d'un pas des principes d'Unix.
La cause ? Aucune abstraction de systemd. Le bénéfice ? Une intégration plus poussée avec le noyau Linux. Les conséquences ? Un système monolithique, des inter-dépendances fortes.
systemd devient, de plus en plus, un composant difficile à remplacer…
# Interopérabilité
Posté par Christophe . En réponse au journal Sergey Brin dénonce les «cages dorées» de Facebook et Apple. Évalué à 6.
Le remède est simple: imposer une interopérabilité. Bien sûr il faudrait définir les contours de cette contrainte (pour les sites web), mais il y a sûrement un compromis intelligent et acceptable.
Ce problème n'a jamais été réglé pour les messageries instantanées: les ponts entre MSN, Facebook et GTalk sont rares, même si Jabber améliore les choses. La question est moins présente aujourd'hui simplement parce que les posts sur G+ et Facebook ont remplacé en partie la messagerie instantanée.
On comprend cependant la réticence de Facebook à être interopérable: un concurrent pourrait alors facilement émerger. Pour ceux qui n'utilisent que les fonctions de base (liste de contacts, mur), la valeur ajoutée de FB est très faible. G+, qui fait partie d'un écosystème Google plus large, est peut-être moins inquiété par cette question.
Finalement, serait-ce intelligent d'imposer l'interopérabilité des données personnelles compilées sur les "gros" sites de réseaux sociaux ? Qu'en pensez-vous ?
[^] # Re: from scratch
Posté par Christophe . En réponse au journal Problème de suivi d’un logiciel privateur. Évalué à 2.
Finalement c'est bien ça le plus important: libérer les données déjà saisies. Il faudrait donc demander à l'auteur (oui ! il faut le contacter !) soit:
* publier tout le code source, ou mieux, le mettre sous licence libre
* publier les specs de la base de données
Et il est probable que les specs de la base soient plus ou moins le logiciel lui-même, si l'architecture n'a pas été proprement découpée.
Personnellement, vu l'état de la situation actuelle, je vois mal quels arguments l'auteur pourrait avancer contre la diffusion du code source. Espérons qu'il ne l'ait pas perdu ! ;)
[^] # Re: relativisons...
Posté par Christophe . En réponse au journal Le crash du Sukhoi en Indonésie. Évalué à 2.
J'ai l'impression qu'elles étaient ridicules, mais dans l'autre sens…
# Encore un effort...
Posté par Christophe . En réponse à la dépêche Le Parlement européen va libérer son gestionnaire d'amendements. Évalué à 10.
Il est bien triste que ce genre de nouvelle soit aussi rare. Dans les structures publiques, préférer le libre et libérer ses outils devrait être la norme. Bien sûr, on ne peut libérer du code dont on ne possède pas les droits, mais lorsque c'est développé en interne je ne vois pas où est le problème.
Les services publics et administrations sont payés directement par les citoyens. De même que les documents publics sont… publics, les logiciels "publics" devraient êtres aussi mis à disposition des citoyens.
Ou alors, les services publics n'ont-ils la main-mise sur quasiment aucun de leurs outils ? Dans ce cas, n'existe-t-il pas de logiciel libre capable de les remplacer efficacement ? Question naïve, j'imagine.
[^] # Re: Pour ceux qui ne comprennent pas le grec
Posté par Christophe . En réponse au journal Résultat des élections. Évalué à 4.
Non, là en l'occurence l'ami t'a prêté à 3%, puis il a vu que tu aurais du mal à rembourser tes futurs emprunts alors il a mis le taux des futurs emprunts à 18%. Toi, tu proposes de ne pas rembourser les prêts à 3%.
[^] # Re: Nous y voilà…
Posté par Christophe . En réponse à la dépêche Firefox 12 et Thunderbird 12 sont sortis ; Mobile est mis à jour. Évalué à 3.
Mais c'est quoi une version majeure ? Pourquoi ne pas remplacer le numéro de version par une date ?….
# Edition numérique
Posté par Christophe . En réponse au journal [Linux Magazine] Les numéros d'OpenSilicium disponible en PDF. Évalué à 4.
Visiblement ils ont pris les archives, fait "Imprimer en PDF", et pouf, 9€. C'est clairement insuffisant: soit ils baissent le prix pour refléter l'absence d'effort de mise en page pour le format numérique (ainsi que l'absence de support physique), soient ils font un réel travail de réédition, en prenant en compte les spécificités et les avantages du numérique.
Bref, une bonne idée mais visiblement mise en œuvre par un néophyte du numérique…
# Greenpeace ?
Posté par Christophe . En réponse au journal Facenuke. Évalué à 5.
J'ai cherché "greenpeace", "moore", "julliard". Je ne crois pas un seul instant que ces personnes n'ont pas de lien avec le nucléaire. Ou alors ils tirent tous leurs renseignements dans Google News ?
Bref, un outil de dénonciation, au but flou, aux méthodes opaques. Quand je vois ça, je crains plus cette organisation que le nucléaire.
[^] # Re: ()
Posté par Christophe . En réponse au journal [présidentielles] 1 million d'électeurs. Évalué à 0.
Pas de compromis entre les deux tours. La nuance est importante: au premier tour, tu votes pour un candidat et son programme. Si le programme change juste après, à quoi bon voter pour lui ?
[^] # Re: Le problème n'est-il pas pris à l'envers ?
Posté par Christophe . En réponse au journal Gnome 3 : cachez ce bug que je ne saurais voir. Évalué à 6. Dernière modification le 30 mars 2012 à 11:40.
Je suis d'accord avec toi. Il y a au moins trois façons de voir les choses:
C'est GTK la base, et donc ce genre de comportement devrait être spécifié au niveau GTK: montrer d'abord les dossier, montrer les fichiers cachés par défaut, single click… Dans ce cas, il faut tout mettre coté GTK, et faire en sorte que Nautilus ne fasse qu'utiliser ces préférences.
Le GtkFileChooser n'est qu'un outil, qui devrait s'adapter à l'environnement par le biais d'une API ou d'une config adaptée. Dans ce cas, on met la configuration dans Gnome (pas seulement Nautilus), et on a du coup un environnement de bureau cohérent au niveau Gtk.
Le GtkFileChooser a son propre comportement, un peu comme le fait qu'une appli Qt dans Gnome va appliquer son propre thème. Gnome devrait donc implémenter son propre GnomeFileChooser, qui aurait le comportement qui va bien. Comme au point 2., ceci dit, il mettre la configuration au niveau de Nautilus n'est pas idéal, et il faut la mettre au niveau Gnome.
C'est un peu lorsque Nautilus gérait le fond d'écran: c'était une préférence de Nautilus. WTF? C'était brouillon, mais au moins ça marchait… et ça peut être peaufiné plus tard, de toutes façons.
N'importe laquelle de ces solutions améliorerait la situation actuelle…