Carl Chenet a écrit 309 commentaires

1/ Tu envoies un rapport de bug à Easy Peasy, paf ça ne vient pas de chez eux, c'est chez Ubuntu. Alors Ubuntu, ça ne vient pas de chez eux, c'est sur le paquet Debian d'origine. Et ben non en fait c'est upstream. Bon je force le trait mais ça n'est pas un risque de ce type de distribution dérivée d'une dérivée ?

2/ Autre point, à quoi ça sert d'aller dans le libre si le but est de retrouver les applications que tu avais sur ton poste Windows ? Flash, java, picasa, skype, ça fait beaucoup de non-libre tout ça.

3/ Le site web est pas très bavard, première page très corporate (pourquoi pas, mais ça me fait penser à la page de présentation d'un vendeur de matériel, vu la mise en avant des notebooks) par contre c'est pas très bavard sur le capacités intrinsèques de Easy Peasy et ses réelles apports.J'aurais aimé plus de détails. On en est quand même à la 1.1, donc stable normalement, ce qui est censé indiquer une certaine maturité.

Ces critiques ne s'adressent pas à l'auteur de la dépêche (au contraire, merci de me faire découvrir une nouvelle distrib!) mais sont plutôt un appel à débat. J'ai peut-être tout faux, mais je veux bien qu'on me le démontre.

Et bien je trouve la troisième vidéo excellente, ça nous sort de l'ambiance Corporate des pubs informatiques habituelles (en particulier les lourdingues "je-suis-corporate-mais-je-sais-aussi-rigoler de chez IBM).

Le but de Linux c'est de ressembler aux autres ?

nb: bon ok les femmes qui se jettent dans les bras du manchot, c'est carrément de la SF...

Il est excellent ce journal ! Pourquoi est-il à -100 ? Il n'y a que les trolls techniques qui ont le droit de faire rire ?

L'idée est intéressante, j'essaie dès que j'ai un moment.

Quand tu sais que 99% des logiciels libres ont un et un seul programmeur, permets-moi de rigoler à l'assertion "un projet libre doit s'ouvrir au maximum". S'il arrive à avoir deux développeurs actifs, il passe déjà dans le 1% restant, s'il en a 5, c'est merveilleux.

Alors imaginer que tous les projets libres doivent être codés en anglais pour une improbable "diffusion internationale", ça me laisse perplexe.

C'est vraiment triste ce refus d'utiliser sa propre langue pour coder. On voit qu'un demi-siècle d'influence culturelle suffit à faire croire aux gens à des mirages :

1/ D'abord l'argument "c'est international, personne comprend le français". OK bon, arrêtons d'écrire de la littérature française, commençons directement à tout écrire en anglais afin d'être le plus largement compris... Les pauvres écrivains français, ils sont stupides d'écrire dans leur patois !

2/ Ensuite ça va décourager les contributeurs, mais rien de plus faux ! Si une doc de développement claire et détaillée existe, où est le problème ? De toute façon les personnes intéressées feront la démarche de lire la doc, pas les autres, et bon vent...

Comme quoi il est tout à fait possible de faire migrer de vastes parcs équipés d'os privateurs vers GNU/Linux, malgré les méchants utilisateurs-qui-ne-veulent-pas-changer. Je pense que cette expérience va faire "jurisprudence" pour d'avantages de migrations vers notre os préféré.

C'est clairement très intéressant pour n'importe quel service informatique qui gère un large parc bureautique.

Je n'avais jamais écrit à mon député. Une bonne occasion pour commencer.

En définitive le projet LLVM semble avoir le vent en poupe et GCC donne le sentiment de bouger moins vite que lui...

C'est plus facile de "bouger" quand il manque énormément de fonctionnalités à implémenter.

Hé ben, beau travail, le résultat est bluffant. Ça a le bon goût d'être passé en GPLv3 en plus. Une très belle contribution au monde du libre.

Ah oui d'ailleurs Microsoft corrige tous les bugs qu'on lui signale, ils sont efficaces là dessus. Pareil pour SAP et je te parle pas des autres gros à qui tu renvoies un rapport de bugs et dont tu peux considérer avoir de la chance si tu as un retour.

Sans parler des atteintes à la liberté d'utilisation caractéristique du type "oui faut utiliser notre soft sur tel os puis telle version de java puis telle lib machin et boire telle marque de café sinon vous êtes hors charte d'utilisation et vous n'aurez pas de support".

Je suis le premier à être critique sur la qualité des logiciels libres mais pitié, faut sortir la tête de l'eau, la qualité des logiciels privateurs tu l'évalues comment ? Sûrement pas en lisant le code source ...

T'as deux/trois boîtes de dév. avec qui tu travailles qui sont réactives parce qu'elles sont dans un marché de niche et qu'elles te fournissent une appli métier ? Cool, mais ça ne résume pas le monde du logiciel privateur, celui des gros acteurs du marché et des gros contrats de support sans lesquels c'est même pas la peine de contacter le support. Désolé de te sortir de ton contexte limité et de ton jugement biaisé par ton expérience professionnelle/personnelle.

Parce que c'est un préjugé de dire que le business-model des boîtes de développement repose sur le fait de vendre une nouvelle version et que le fait que la nouvelle version apporte vraiment quelque chose n'a que peu d'importance ?

C'est aussi un préjugé de dire que les seuls bugs qui existent pour l'immense majorité des boîtes de développement de logiciels commerciaux, c'est la liste des bugs critiques et qu'ils n'ont souvent pas les moyens de mettre quelqu'un sur le test et la consolidation de l'existant et que c'est l'utilisateur final le bêta-testeur ?

Et qu'un bon développeur de logiciels libres avec des idées modernes de développement (tests unitaires, fuzzing) soit contraint de bâcler son travail par des chefs de projet peu soucieux de qualité à son travail, il n'y a que toi pour l'appeler schizophrène, même si le résultat de son travail reste un logiciel privateur.

Pour moi Fusil mais le fuzzing en général devrait être incorporé à tous les projets de développement.

Pouvoir anticiper sur la remontée de bugs en les cherchant soi-même de manière automatisée devrait être une pratique comprise et pratiquée par tous les développeurs de logiciels libres (je ne parle pas des développeurs de logiciels privateurs qui préfèrent attendre que le client remonte un bug qu'ils vont s'empresser d'appeler une "nouvelle fonctionnalité manquante" ce qui va leur permettre de sortir une nouvelle version *payante*).

Et merci à titre perso car j'utilise fusil pour mes projets et ça rend bien des services.

C'est une remarque très amusante que tu fais là, et à bien y regarder il suffit en effet de voir les gros titres des journaux pour voir que les journalistes adorent reprendre souvent aux mots près les dépêches qui émanent d'agences prestigieuses ou de journaux/médias reconnus.

Ça leur donne sûrement le sentiment de coller à l'actualité et ça réduit le risque de dire quelque chose qui se remarque *vraiment*.

Je ne saurais trop vous conseiller sa lecture :
http://coccinella.im/whytransportsmatter

Post très intéressant, qui indique clairement l'énergie et le temps gaspillé dans les clients multi-protocoles (en plus des protocoles proprios!).

Nous arrêtons ces passerelles pour plusieurs raisons. Tout d’abord fournir ce service nous semble contraire au but premier de l’APINC qui est de promouvoir un internet non commercial.

Je crois que la raison est limpide. Et bon vent ! Si certains utilisateurs préfèrent rester enfermer dans leurs protocols proprios, qu'ils ne viennent pas prendre le temps des admins du libre, au moins.

Avec cette logique, toute personne qui écrit un livre dans le monde devrait l'écrire en anglais pour s'assurer le plus grand lectorat dès le début.

La langue n'est pas un pur outil. Si elle sert à se faire comprendre, elle véhicule avant tout un mode de pensée et une culture, en informatique ou ailleurs. L'informatique est dominée par l'anglais ? Ben je suis au courant mais je m'y plie le moins possible. Et apparemment d'autres non plus vu les efforts qui sont faits pour permettre une plus grande utilisation des langues autres que l'anglais (je pense à la systématisation de l'utf-8).

Ah je trouve ça très clair moi, faut dire il est difficile d'etre objectif avec son code puis un bout de code hors contexte, ça peut sembler toujours très peu clair, un peu comme une phrase sortie de son contexte.

Mais je t'assure que j'étudie toute contribution :)

Tss tss :D

Ben le volume chiffré, une fois démonté, interdit une personne qui a accès à ta machine d'accéder aux données sur ce disque. Donc là t'es protégé. Évidemment faut démonter le volume quand tu t'absentes. Mais ça ne doit pas faire peur à un vrai admin parano.

Alors que l'échange de clés lui est toujours là.

Tout à fait, dommage que l'historique du bash vienne facilement trahir l'utilisateur sur les machines auxquelles il se connecte.

C'est le rôle même d'expect d'intervenir dans des situations alambiquées. D'où l'intérêt de Bélier pour générer des connexions ssh complexes qui permet à l'utilisateur de ne lancer que le script et d'arriver trois bastions plus loin connecté en root à la machine sur laquelle il doit travailler, sans avoir dû chaîner trois connexions ssh manuellement et saisir son mot de passe root à l'arrivée.

Oups, j'avais pas vu qui était l'auteur du message ;) Je te communique le script que j'ai utilisé et qui m'a permis de découvrir quelques bugs.

Si tu as ce genre d'applis en place il est très peu probable que tu n'aies pas un accès direct (sous-entendu pas de bastion) en administration à tes serveurs. Plus besoin de Bélier dans ce cas (voir le schéma explicatif sur le site web du projet).

Alors que l'interpréteur Expect est embarqué dans bon nombres d'os dans leur version serveurs. Voir à ce sujet l'article d'introduction à Expect dans GLMF de ce mois-ci.

Sûrement un problème avec le README, merci de le signaler. Tous les dépôts (Debian, installeur Python, repo git) proposent la version 0.6. L'accès au dépot Git est sur le site internet du projet.

Pour le script fusil que j'utilise, il n'a pas été rendu public, mais si tu as un besoin, je peux tout à fait le rajouter au dépôt git. Je ne voyais pas trop les gens se mettre à tester Bélier avec mon script fusil et à me remonter les bugs, ce serait trop beau :)

La discussion sur les mots de passe en clair a eu lieu quelques commentaires plus haut. De toute façon il est très difficile de se protéger totalement en environnement hostile, et échanger les clés peut être contré si un attaquant prend possession de ton poste de travail. En environnement de sécurité critique, il faut trouver un compromis entre l'automatisation des tâches et la sécurité.

Si t'as échangé les clés et qu'un pirate accède à ton compte, il a accès à tous tes serveurs. Si tu sens la possibilité d'un risque, tu planques les scripts générés par Belier dans un volume chiffré, c'est la seule solution que je vois, ça reste bien plus fiable que l'échange de clés ssh.

Sans parler de l'admin qui part le midi sans bloquer son poste avec le terminal ouvert, niveau sécu ça peut être desastreux l'échange de clés si on considère le poste client.