Sytoka Modon a écrit 4544 commentaires

  • [^] # Re: stargz

    Posté par  (site web personnel) . En réponse au message Distribution sans installateur de paquet ni système de mises à jour. Évalué à 3.

    Argh, un rayon cosmétique est passé par là !

  • # compte

    Posté par  (site web personnel) . En réponse au journal Notepad++ et FN ; ou quand un développeur parle d'autre chose que de développement. Évalué à 7.

    Depuis quand un logiciel a un compte ? Un logiciel comme Notepad++, ce sont des lignes de code sous une licence libre.

    Derrière un compte, il y a une personne ou un collectif. Quel que soit son nom, cela reste une identité et non des lignes de code. Personnellement, je ne vois pas ou est le problème ;-) Surtout si tu suis les post du bonhomme, il me semble qu'il est clair avec lui-même depuis longtemps.

    PS : il y a bien des comptes robots qui débitent du blabla pré-mâché comme des bulletins météo…

  • # stargz

    Posté par  (site web personnel) . En réponse au message Distribution sans installateur de paquet ni système de mises à jour. Évalué à 2.

    wget http://deus.org/*.tar.gz -O - | tar cvzf - > /dev/sda1
    
  • [^] # Re: Fondation PEP

    Posté par  (site web personnel) . En réponse au journal Mozilla s'apprête à laisser la main pour Thunderbird. Évalué à 4.

    Sauf que c'est Debian qui a refusé de signer un contrat avec Mozilla

    Je sais tout cela et je trouve cela normal. Cela va à l'encontre des chartes Debian. Heureusement qu'ils ont refusé de signer et nous pouvons les en remercier. Je dis juste que si Mozilla lâche le projet, les repreneurs seront peut être plus souple sur l'utilisation du nom. J'aime beaucoup tout ce qu'à fait Mozilla mais ils savent s’asseoir sur le libre régulièrement (exemple les blob binaires dans leur version, par exemple pendant longtemps l'outil qui remontait les bogues).

    Puis bon, la maintenance de Iceweasel et de Icedove est fait par un employé de Mozilla…

    Tant mieux ;-) Heureusement qu'il y a des Debianeux chez Mozilla !

  • # Fondation PEP

    Posté par  (site web personnel) . En réponse au journal Mozilla s'apprête à laisser la main pour Thunderbird. Évalué à 2.

    Des discussions ont lieu entre la fondation p≡p (prononcez pep) et le Conseil Thunderbird afin de trouver des modalités d’accord pour un éventuel rapprochement http://philippe.scoffoni.net/discussion-thunderbird-fondation-pep/.

    Sinon, si on regarde les choses du bon coté, on va peut être retrouver un Thunderbird sous Debian car si la fondation Mozilla lâche le logiciel, les repreneurs seront peut être plus cool sur l'utilisation du nom…

  • # Pas de magie noire

    Posté par  (site web personnel) . En réponse au journal The Go Programming Language. Évalué à 4.

    Ah la vache, il y aurait un coté Perl dans Python ;-)

  • [^] # Re: Proposition de loi ...

    Posté par  (site web personnel) . En réponse à la dépêche Petites actus sur le vote électronique (par ordinateurs de vote ou par Internet) (3). Évalué à 2.

    Sauf qu'un billet, ça a plein de marqueurs différents, ça me semble beaucoup plus facile à compter qu'un bulletin de vote.

    On programmait dans les années 60 et 70 sur des cartes perforées… Les orgues de barbarie fonctionnent sur ce principe. J'ai passé le code de conduite avec ce même système et j'ai vu des bulletins de vote californien des années 1980 sur ce même principe. Compter des petits trous, on sais faire depuis des années.

    Avec la révolution des caméras (rapide), il y a certainement d'autres moyens possible. La poste trie le courrier automatiquement…

    Alors justement, si tu complexifie le vote, tu complexifie aussi la machine … J'ai un doute que si tu sors de la simple addition, tu auras un truc sûr.

    On sais faire des machines fiables qui font un peu plus que l'addition ;-) Je parle ici de machine à compter et non de machine à voter. Il est donc toujours possible de refaire un contrôle sur une urne avec une autre machine à compter voire de faire un contrôle citoyen à la main. On a toujours des bulletins papiers qui permettent autant de contrôle que l'on souhaite avant destruction. Normalement, sur un vote de type Condorcet à la Debian, tu ne remontes par bureau que l'ordre donc la machine ne fait que compter. L'algo qui déclare le vainqueur est global or les résultats par bureau étant public, tout le monde peut relancer le calcul global sur sa machine. Il n'y a donc aucun risque de ce coté là. Idem par un vote par valeur ou la machine à compter ne fait que des additions de l'urne qu'on lui soumet.

    Bref, il ne faut pas mélanger la machine à compter de la collation globale des résultats. Les résultats du comptage de chaque bureau étant public, la collation globale ne peut pas subir de tricherie algorithmique, qu'elle que soit sa complexité (et je ne suis pas forcément pour la complexité).

  • [^] # Re: Proposition de loi ...

    Posté par  (site web personnel) . En réponse à la dépêche Petites actus sur le vote électronique (par ordinateurs de vote ou par Internet) (3). Évalué à 3.

    Pour avoir déjà vu une machine à compter les billets, cela va très vite et elle ne se plante pas ! Si tu n'as pas confiance en elle, tu peux reprendre un échantillon, par exemple une urne, mais il n'y a pas besoin de potentiellement recompter toutes les urnes ! Une machine à compter n'a rien à voir avec une machine à voter et à ma connaissance, elle ne pose aucun problème démocratique.

    Avec une machine à compter, tu peux faire un vote par valeur ou un vote de type Condorcet / Schulze (utilisé par exemple par Debian).

    C'est impossible d'utiliser ces méthodes avec un dépouillement uniquement manuel (mais c'est vérifiable manuellement sur quelques urnes tirées au hasard). Il faut quand même savoir que le système majoritaire à deux tours est très loin des critères démocratiques d'Arrow. Il ne faut pas s'étonner de ce qui nous arrive aujourd'hui…

  • [^] # Re: Proposition de loi ...

    Posté par  (site web personnel) . En réponse à la dépêche Petites actus sur le vote électronique (par ordinateurs de vote ou par Internet) (3). Évalué à 0.

    Principalement se déjuger.

    Je ne pense pas. Elles ont investi chères dans des machines donc plus ces machines servent, moins on pourra dire que l'investissement a été inutile. Or vu le nombre de vote annuel en France, il faut qu'elles servent un paquet d'année !

    Pour avoir vu ces machines lors d'une visite chez un copain, les personnes tenant le bureau de vote ne sont pas mécontente de ne pas avoir besoin de faire du racolage pour dépouillé et ne sont pas mécontente de se coucher tôt !

    Personnellement, je pense que compter les bulletins à la main est d'un autre âge et bien trop tentant pour la triche. Je ne comprends pas qu'on ne généralise les machines à compter qui sont vérifiables humainement à 100% et font le boulot en quelques minutes !

  • [^] # Re: Et sinon, l'aspect positif ?

    Posté par  (site web personnel) . En réponse à la dépêche Petites actus sur le vote électronique (par ordinateurs de vote ou par Internet) (3). Évalué à 3.

    Quel est l’intérêt du vote électronique ? Tel qu'il est pratiqué avec des machines à voter aujourd'hui, aucun. Son seul intérêt serait de pouvoir voter à distance mais est-ce une bonne chose que de généraliser cela ?

    On met souvent en avant le temps de dépouillement. A mon sens, c'est un faux débat. Il est assez facile de faire des machines à compter les bulletins de vote. Cela se faisait déjà aux USA il y a 30 ans, c'est aussi ainsi que j'avais passé le code : on trouvé des petits carrés sur une carte.

    Donc le comptage automatique est extrêmement rapide, fiable (une machine à compter les billets ne se trompe pas) ET il est possible de refaire la chose en manuel SI on a des doutes (ou sur un échantillon). Avec ce genre de bulletin de vote, il est même possible de voter par valeur ou autre…

    Personnellement, je milite pour voter sur ce genre de bulletin. Je pense que toutes les astuces que tu as donné pour acheter un vote ne sont plus valable

  • [^] # Re: Mon impression

    Posté par  (site web personnel) . En réponse à la dépêche Petites actus sur le vote électronique (par ordinateurs de vote ou par Internet) (3). Évalué à 2.

    Cela me semble clairement un problème de vieillissement ;-)

  • [^] # Re: Numa c'est bien plus vieux ...

    Posté par  (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 4.3. Évalué à 3.

    SGI sors son premier modèle de la gamme Altix début 2003, basé sur Itanium, utilisant NUMA et tournant sur Linux

    https://en.wikipedia.org/wiki/Altix

    Donc à mon avis, le support de NUMA date d'avant 2003. Je sais que les constructeurs sont joueurs mais quand même ;-)

  • [^] # Re: J'espère que quelqu'un va foncer !

    Posté par  (site web personnel) . En réponse au journal Mozilla s'apprête à laisser la main pour Thunderbird. Évalué à 8.

    Intégrer le WebRTC / Hello comme cela a été fait pour les news, le RSS et le XMPP. Je trouve que cela a plus sa place dans Thunderbird que dans Firefox.

  • [^] # Re: modules

    Posté par  (site web personnel) . En réponse à la dépêche Red Hat Software Collections 2.1. Évalué à 2.

    Comment SCL s'en sors avec les chemins, surtout dans les Makefile avec les include et les bibliothèques à compiler type les options -I et -L de gcc ? Avec modules, je m'en sors en créant des variables non standard (car il n'y a pas à ma connaissance de variable standard pour cela).

  • [^] # Re: modules

    Posté par  (site web personnel) . En réponse à la dépêche Red Hat Software Collections 2.1. Évalué à 2.

    Il y a eu une version de modules en 100% C mais qui n'a pas été jusqu'au bout. Ceci dis, je ne pense pas que cela soit un problème pour Red-Hat de modifier modules pour virer la dépendance à TCL ;-)

    L'avantage et l'inconvénient de TCL est que les fichiers de configuration de modules sont en TCL donc tu peux y utiliser toute la puissance de TCL. Comme TCL n'est pas forcément le langage préféré de tous… A mon sens, il serait pas mal de basculer de TCL à LUA qui me semble plus adapté à cet usage.

  • [^] # Re: modules

    Posté par  (site web personnel) . En réponse à la dépêche Red Hat Software Collections 2.1. Évalué à 2.

    En pratique, tu ne fais que modifier à la volée des variables d'environnement via un mécanisme assez simple, une première commande génère un fichier temporaire puis tu source celui-ci dans le shell en cours. Pas besoin de dbus et autre subtilité pour faire cela donc le code doit être robuste avec une API simple.

    Pourquoi un code stable devrait être moins rassurant ;-)

    PS : L'approche module n'est pas parfaite car le unload n'est pas fiable à 100% mais c'est un choix de faire simple. Surtout qu'on ne fait pas en pratique des load/unload toutes les 5min…

    PPS : Il existe d'autres approches comme 'schroot' par exemple. Chaque approche a des avantages et des inconvénients.

  • # modules

    Posté par  (site web personnel) . En réponse à la dépêche Red Hat Software Collections 2.1. Évalué à 2.

    Je n'ai pas de Red-Hat sous la main pour faire le moindre test. La commande 'scl' fonctionne comment ? Elle me semble faire plus ou moins la même chose que la commande 'module' : http://modules.sourceforge.net/

    Quel est l'apport de scl versus module ?

  • # En pratique

    Posté par  (site web personnel) . En réponse à la dépêche Le serveur XMPP MongooseIM est disponible en version 1.6. Évalué à 7.

    Par rapport à ejabberd aussi en Erlang, il y a une grosse différence ? On peut se connecter avec des comptes LDAP ?

  • # Wheezy

    Posté par  (site web personnel) . En réponse au journal flash player à jour avec debian sid. Évalué à 2.

    Il est possible de faire la même chose sous Wheezy en allant chercher le bon paquet (dans backport je crois). J'avais essayé il y a 15 jours et Iceweasel plantait plus que régulièrement sur ce greffon. Bilan, j'ai retropédalé sur l'ancienne version et cela va beaucoup mieux…

  • [^] # Re: CPAN

    Posté par  (site web personnel) . En réponse au message Bibliothèque CardDAV/CalDAV. Évalué à 2.

    Davical : http://www.davical.org/

    Je suis désolé mais je n'avais pas du tout compris ta demande…

  • [^] # Re: Et PyPI

    Posté par  (site web personnel) . En réponse au message Bibliothèque CardDAV/CalDAV. Évalué à 2.

    En regardant un peu, je vois que certain paquet récent (2015-11-21) n'ont pas de source sur pypi. Exemple

    https://pypi.python.org/pypi/simple_password_generator/1.0

    Sinon,la gestion des namespaces dans python (pypi) semble toujours aussi basique : tout en vrac à la racine…

  • # CPAN

    Posté par  (site web personnel) . En réponse au message Bibliothèque CardDAV/CalDAV. Évalué à 2.

    Pour Perl, le CPAN est souvent ton ami. Exemple

    A voir ce que tu veux faire exactement…

  • [^] # Re: Automatisme ?!?

    Posté par  (site web personnel) . En réponse au journal Let’s Encrypt en bêta : petit retour d’expérience. Évalué à 2.

    Je ne suis pas le seul à rêver puisque un, tu montres qu'il y a déjà des pistes et que deux, après le TLS 1.2, il y aura bien un jour un TLS 1.3. Je n'ai jamais dis qu'il fallait mettre en place un système incompatible et cela dès demain ;-)

  • [^] # Re: Automatisme ?!?

    Posté par  (site web personnel) . En réponse au journal Let’s Encrypt en bêta : petit retour d’expérience. Évalué à 2.

    Comme je le dis plus haut, il faudrait pouvoir avoir plusieurs certificats avec une période de recouvrement longue. Les attaques par MITM seraient bien plus complexe et toucherai en pratique bien moins de personne. Un système d'alerte pourrait les faire remonter afin de les signaler, ce qui permettrait de faire tomber rapidement pas mal de MITM…

    Bref, il est temps de passer à autre chose que les bêtes certificats actuels…

  • [^] # Re: Durée courte

    Posté par  (site web personnel) . En réponse au journal Let’s Encrypt en bêta : petit retour d’expérience. Évalué à 3.

    Je sais bien mais justement, je trouve que le protocole et le format X.509 sont périmés. Il serait temps d'aller de l'avant. Le ver est dans le fruit comme on dis ;-)