Je ne connaissais pas ce blog de l'auteur de upstart. Après avoir lu l'article que tu cites sur son départ de Canonical, écrit il y a un an, je suis allé à la racine pour me faire une idée de ce qu'il écrit en ce moment. Et c'est là qu'est l'ironie du sort, car son dernier billet (fin octobre 2012) c'est Goodbye Ubuntu.
Je n'ai pas aimé le journal De l'inéluctable progrès de l'informatique, ou pas, c'est une râlerie comme des dizaines d'autres qui n'a rien de nouveau et qui ne sert à rien. Je trouve dommage que ce journal ait un score de 44 alors qu'un journal qui apporte une information et amène à une discussion intéressante comme Le store d'Ubuntu et les logiciels proprios se trouve à 13. À croire que les journaux où il n'y a rien à dire attirent les gens qui ne disent rien, mais pertinentent plus que la moyenne.
J'ai passé un bon moment en voyant ce James Bond (sans m'attendre non plus à un grand film, ce n'est pas mon genre de toute façon). J'ai surtout apprécié les images que j'ai trouvé très belles (en particulier le passage à Shanghai) et le changement d'idée permis par une scène de poursuite. Il y a quelques bonnes trouvailles et quelques choses improbables ou incohérentes, mais j'ai surtout été interpellé par certains aspects du film.
Les personnages féminins sont décevants
Le personnage est macho et couche avec tout ce qui bouge, c'est une évidence sur laquelle il n'y a à mon avis pas grand chose à dire : certains trouvent ça normal et faisant partie du personnage, moi je ne suis pas fan mais en effet c'est attendu quand on va voir un James Bond.
Par contre indépendamment des coucheries, j'ai été frappé par le fait que tous les personnages féminins sont décevants ou au moins ambivalents :
M pourrait être la "femme forte" de l'épisode, mais à partir du milieu du film est prend le statut au contraire de personnage vulnérable à protéger; ça fait partie du scénario, mais je ne comprends pas pourquoi sa vulnérabilité est accentuée ("je n'ai jamais su tirer", ça serait à mon avis autant plus marrant qu'elle sache vraiment tirer)
l'agent qui aide James Bond au début de l'épisode se débrouille délicieusement bien sur le terrain, mais finit secrétaire. Cette partie du scénario est vraiment ambiguë à mon avis, oscillant entre "promotion vers un poste à responsabilités" (la façon dont j'avais envie de comprendre) et "t'es une ratée qui sait pas tirer, donc tu t'auto-censures en choisissant la vie de bureau". Dans les deux cas c'est décevant et personnellement je me serais bien passé du côté "référence arrière finale" pour une vraie agent de terrain qui s'éclate dans son rôle et qui retourne au boulot.
le non-personnage à qui James Bond fait l'amour une demi-seconde avant d'aller se bourrer la gueule dans un bar sur une plage turque. Est-ce la personne qui a sauvé James Bond d'une mort attendue ? Comment s'appelle-t-elle ?
la copine du méchant, qui commence dans un rôle actif et égal à James Bond (on ne la voit rien faire vraiment, mais dans le début de leur dialogue commun il et elle sont sur un pied d'égalité en démasquant les armes de l'autre) mais bascule rapidement dans un rôle de femme terrifiée que James Bond manipule pour son but propre et est vaguement déçu de voir tuer rapidement (même s'il pouvait difficilement avoir prévu autre chose)
Le personnage de James Bond est remis en question dans cet épisode, son statut de surhomme mis à mal par la vieillesse ou la fatigue. Si on se permet cette (agréable) remise en question du personnage, je pense qu'il est aussi temps de penser à des personnages féminins qui pètent, qu'ils soient gentils ou méchants, meurent à la fin ou non. Pourquoi pas une complice qui s'en sort mieux que lui pour une fois, ou une grande méchante, pour le prochain film ?
Le MI6 est son propre ennemi
Il y a un pseudo-discours politique dans le film, oscillant entre "maintenant les ennemis sont les terroristes et on est désemparés" et "le gouvernement nous casse vraiment les pieds", auquel à mon avis il ne faut pas attacher trop d'importance car je ne pense pas que ce soit le but du film. Un point intéressant qui n'est en fait pas du tout traité dans le film est que la menace dont il est question ici a été entièrement créée par le MI6: c'est un ex-agent qui attaque la maison mère. Donc autant le film montre le MI6 comme ayant un rôle véritable et utile à jouer dans l'ombre de la vie publique, autant la cause même de la violence et de l'insécurité dans ce film est provoquée par cette mécanique même, ce qui la remet en question au moins aussi sérieusement à mon avis que la demande de transparence et démocratie évoquée dans le film.
La vision de l'informatique est intéressante
Les gens des milieux techniques qui commentent James Bond ont fait des remarques en passant sur le traitement grotesque de l'informatique, et en particulier la sécurité, dans le film. Il y a une remarque effectivement qui m'a fait bien rire du style (je paraphrase) "le mail est protégé par un algorithme asymétrique… donc il se duplique en copies actives sur plein de serveurs dans le monde", et la scène où ils déchiffrent des données protégées est évidemment irréaliste. Ceci dit il y a plusieurs points qui m'ont semblé intéressants dans le traitement de l'informatique dans le film :
Le pirate attaque le MI6 en ayant prévu qu'ils brancheraient son ordinateur à leur réseau pour l'analyser; c'est stupide vous me direz, quand on a une machine à priori hostile, de la brancher à un réseau sensible. Mais dans la vraie vie ce genre de problèmes (machines sensible branchée au réseau) arrive régulièrement, et cette stupidité peut vite être commise par des gens qui devraient savoir les problèmes que ça pose ("mais ça arrive aux autres, pas à moi").
Le beurre du grand méchant est l'attaque de systèmes informatiques vulnérables. Tous les méfaits qu'il cite ont été accomplis avec l'informatique. On oscille entre du FUD sur la cyber-guerre et le terrorisme informatique et une mention réaliste d'un monde sur-connecté qui présente de nouvelles vulnérabilités. "Changer le résultat d'un vote électronique en Ouganda, en faveur du plus offrant ? Facile.". À méditer.
Dans un contexte moins technique "ouech gros pro de la crypto", internet est bien présent dans ce film. C'est là que le pirate formule son attaque personnelle contre M. Quand il commence à divulger les noms de la liste d'agents infiltrés, ce n'est pas en les envoyant aux grands journaux, mais en postant des vidéos Youtube. L'informatique telle qu'elle est perçue par le grand public est bien présente dans ce film, et même un point clé du scénario, et ça je trouve que c'est très intéressant.
Tout à fait d'accord. J'irai même plus loin en disant qu'un chercheur a la responsabilité d'assurer la diffusion la plus large de ses résultats, et qu'un chercheur qui respecterait des règles illégitimes de son employeur ou éditeur ne permettant pas cette diffusion fait un mauvais travail, et qu'on peut le lui reprocher.
Je dirais qu'un outil décentralisé est fédéré à partir du moment où la réunion de deux nœuds peut se comporter en gros comme un seul nœud (et non comme une somme disjointe de deux petites choses isolées et ne se parlant pas entre elles). Peut-être que ce n'est pas la bonne définition de "fédéré", mais c'est la bonne définition de ce que je veux (et alors "fédéré" ne serait pas le bon concept).
Posté par gasche .
En réponse au sondage Le libre et mon activité.
Évalué à 5.
Dernière modification le 12 novembre 2012 à 11:39.
Le précédent gouvernement avait une politique d'exploitation économique des résultats de la recherche ("intelligence économique" bla bla) à vomir, mais malheureusement le nouveau ne fait pas beaucoup d'efforts pour corriger la tendance. L'idée reste globalement que si tu as une bonne idée, la première étape devrait être de contacter dans le secret un partenaire industriel pour faire du fric avec, la deuxième de breveter et la troisième, si vraiment tu penses que ça ne vaut rien, de publier. C'est beau la valorisation.
Mettre une licence libre sur ton travail est une très bonne idée : le Copyright peut rester à l'employeur (c'est ce qui lui importe en général) tout en assurant une distribution large des résultats, ce qui est ce que les chercheurs veulent en général. Ça marche encore très bien dans les schémas de financement bizarres où le chercheur est plus ou moins mis à disposition d'un organisme tiers qui réclame le copyright. Dans tous les cas il faudrait quand même demander l'accord formel de l'employeur avant de choisir la licence en principe, mais si on travaille sur un truc qui est déjà en GPL il n'y a pas besoin puisqu'il n'y a pas le choix…
PS: perso j'ai classé ce genre de comportement dans la catégorie 2, "ne rentre pas dans le modèle de l'entreprise mais on le fait quand ça fait du sens", parce que même si sur le papier c'est un peu "en douce" dans les faits c'est une pratique reconnue et acceptée dans le milieu de la recherche, donc un peu plus que "en douce".
La très intéressante remarque de Tanguy ne porte pas directement sur l'utilisation de logiciels libres (je ne pense pas que ça nous apporte grand chose de savoir qu'une écrasante majorité de gens utilisent des logiciels libres dans le cadre de leur travail), mais sur le fait que leur utilisation justifie le fait qu'il contribue au libre sur son temps de travail. Utiliser LibreOffice c'est bien, mais cela t'a-t-il déjà conduit à rapporter un bug ou envoyer un patch pour corriger un problème ? La question est justement de savoir si tu te permets cette contribution, et si elle est considérée comme faisant légitimement partie de ton temps de travail. Et là tout de suite je pense que ça concerne beaucoup moins de gens—ce qui rend la remarque pertinente.
Avoir 2 runtimes (un perl et un python) pour finallement en exécuter un autre (JS),
en passant son temps à faire des bindings dans tout les sens ces contre-productifs
et contre-performant.
Pas du tout, s'ils sont dans cette situation c'est parce que c'était le plus simple étant donné leurs besoins et les circonstances. Ou alors tu penses que les développeurs de Firefox ont fait exprès des choix contre-productifs, par erreur ou aveuglement, et que leur donner un message aussi utile et construit que "bouh le bloatware c'est mal" va les aider à sortir de leur erreur et donc leur rendre grand service. Des erreurs arrivent toujours, et c'est bien de prendre soin d'éduquer les développeurs, mais il se trouve que dans ce cas précis je pense pouvoir prédire sans me tromper qu'utiliser à la fois du software perl et du software python leur a vraiment simplifié la vie, et que supprimer l'un des deux leur demanderait du travail pour un bénéfice qui n'en vaut pas la peine.
Bien sûr si toi tu accordes une importance supérieure à ces questions (tu choisis de favoriser la propreté du design plutôt que les besoins objectifs, ce qui peut avoir un intérêt, je le dis en perfectionniste averti), tu es libre de donner ton propre temps pour résoudre cette situation, c'est beau le logiciel libre. Mais bon écrire des articles rageux dans Communication of the ACM (ou des réponses un peu creuses sur LinuxFR) c'est quand même plus simple.
Je ne sais pas ce que tu veux dire par "en lisant un peu plus", j'ai bien sûr lu le billet avant de le critiquer.
Le texte que tu cites n'a rien de particulièrement convaincant : tu peux avoir un paquet Firefox qui dépend du paquet Toto qui lui-même dépend du paquet Tiff pour certaines de ses fonctionnalités, que Firefox lui-même n'utilise pas (genre, au hasard, un truc à la ImageMagick qui supporte 60 formats dont 59 intéressent Firefox).
Avec un gestionnaire de paquets source, tu peux gérer un peu finement les dépendances de tes dépendances (genre les USE flags de gentoo), mais déjà ça suppose que Toto a été pensé pour pouvoir désactiver sélectivement des formats (pas forcément la priorité des développeurs), et ensuite les packageurs binaires vont souvent faire le choix simplificateur d'activer tous les formats pour pouvoir servir tous les paquets utilisant Toto et pas juste Firefox et se simplifier la vie de gestionnaire de dépôts—et parce qu'ils s'en moquent que l'auteur du billet fasse une crise de nerf parce que Firefox installe libtiff.
De même, Firefox peut décider d'utiliser deux bibliothèques super utiles, une pour parser le HTML et l'autre pour communiquer à travers le réseau, l'une étant écrite en Python et l'autre en Perl, deux langages qui demandent un support runtime donc doivent être installés avec ces libs. Qu'est-ce que l'auteur aigri conseille aux développeurs de Firefox (ou autre) de faire en ce cas ? Ré-écrire l'une des bibliothèques dans l'autre langage pour n'installer qu'un seul runtime ? Demain il refait un billet pour dire que c'est un scandale, son système a voulu installer deux bibliothèques implémentant le même algorithme, et ce dans deux langages différents.
Peut-être que dans son esprit les développeurs et packageurs de Firefox devraient se plier en quatre pour, surtout surtout, n'avoir aucune dépendance superflue et porter les bibliothèques en Perl vers Python pour simplifier encore les dépendances. Sauf que dans la vraie vie ces gens-là ont bien plus intéressant et utile à faire de leur temps et leur énergie, pour aider à résoudre d'autres problèmes qui font certainement râler quelqu'un d'autre sur le net. Et si un jour ces problèmes deviennent gênants (oui ça arrive), les gens investissent plus d'effort là-dedans, on a un peu plus de cathédrale et un peu moins de bazaar le temps d'une restructuration, et ça repart.
PS: et tout ce que j'ai dit est assez évident, tu aurais certainement pu faire l'effort de dérouler cette argumentation toi-même.
Cet article est fade et les arguments sont mauvais. L'auteur a fait des choses très bien et publie dans un média impressionnant par ses connotations scientifiques, mais à part les anecdotes historiques qui sont toujours enrichissantes ça reste une râlerie moyenne d'un utilisateur aigri.
L'auteur râle parce qu'un paquet donné a trop de dépendances. En même temps il râle parce que certains codes sont copiés dans plein de paquets différents. C'est quoi la solution pour résoudre son deuxième problème ? Factoriser le code comme un paquet et en faire… une dépendance supplémentaire. Bonjour la contradiction.
L'écosystème logiciel est complexe. Il y a beaucoup de programmes différents, qui ont beaucoup de dépendances (pour éviter la redondance). Selon les sous-communautés, les organisations sociales, les moyens disponibles, les gens vont avoir un processus de développement structuré de façon plus ou moins rigide. Il n'y a pas une seule bonne manière de faire, mais des choses qui sont adaptées dans certaines situations et pas dans d'autres. Donc au final quand on regarde dans la nature sauvage on observe… un continuum d'états entre "la cathédrale" et "le bazaar" (modèles caricaturaux et extrêmes), avec tout au milieu. Structurer en cathédrale c'est bien pour certains usages, mais ça demande de l'énergie, et en pratique les projets évoluent en moindre effort et les gens font de leur mieux. Il est illusoire de penser qu'on pourrait magiquement, en râlant, faire passer tout le monde à un style particulier donné, ça ne résoudrait rien et ça n'est tout simplement pas la façon dont les choses se passent.
Des choses intéressantes ont été dites sur le "bloat" des logiciels modernes. Le projet STEPS du Viewpoint Research Institute, auquel participe notamment Alan Kay, essaie de concevoir le logiciel d'un ordinateur personnel en moins de 20 000 lignes de code. John Regehr dit des choses intéressantes sur la question ici (Can Simplicity Scale) et là (It's All About Interfaces). En comparaison, l'article de cette dépêche fait pâle figure, énumérant les jérémiades sans lien logique ou proposition constructive.
Inria est un institut de recherche en informatique qui emploie plus de 4000 personnes et contient environ 180 équipes-projets, donc c'est très large. Je ne comprends pas trop ta question; mais tous les contributeurs ne font pas partie de cette équipe de recherche (c'est un projet libre donc il y a pas mal de gens de la communauté qui ont contribué quelque chose, ne serait-ce qu'en rapportant des bugs et en aidant les débutants sur la mailing-list, mais aussi de plus grosses contributions). De mémoire (et sans garantie que c'est correct) je dirais que les principaux mainteneurs de fait ces derniers mois sont, dans le désordre, Xavier Leroy et Damien Doligez (équipe Gallium), Alain Frisch (Lexifi (industrie)) et Jacques Garrigue (Université de Nagoya).
Je lis souvent ces brèves et je n'ai jamais eu ce sentiment de "personne qui veut montrer son savoir". Je pense que le texte envoyé par CrEv est neutre de ce point de vue-là, et que cette lecture psychologique est ajoutée de ton côté : sans vouloir faire de la psychologie à la con, je parierais que ça se comprendrait plutôt à partir de tes propres peurs que du contenu réel de ces dépêches.
Si je peux fournir une explication sur la quantité de lien : l'idée est un peu que chacun va y piocher ce qui l'intéresse vraiment au lieu de se forcer à tout lire. L'auteur (ou les auteurs) li(sen)t tout car ça correspond exactement à ses/leurs centres d'intérêt. Pour toi c'est périphérique donc il faut s'investir moins. En ces temps où l'information est facilement accessible, il faut se forcer à filtrer et s'investir avec soin.
Un service ce n'est ni propriétaire ni libre, c'est un service.
Je ne suis pas d'accord. Un service c'est du logiciel qui tourne, et ce logiciel peut être libre ou propriétaire. Quel est le différence aujourd'hui entre faire tourner du logiciel dans une page web (que l'exécution se fasse chez le client ou le serveur) et dans un "logiciel lourd" ? Quand j'utilise un logiciel je veux pouvoir l'utiliser librement, étudier son fonctionnement et tester des versions modifiées. Quand j'utilise un service je veux pouvoir l'utiliser librement, étudier son fonctionnement et tester des versions modifiées.
T'es juste en train de dire "oui mais c'est pas grave si je pousse les gens à répondre à leur besoin en utilisant du code qu'on n'a pas le droit de voir, ça se passe à travers un navigateur donc ça va". Ce qui nous fera une belle jambe quand tout se fera à travers un navigateur.
Le passage aux logiciels distribués ajoute une nouvelle problématique d'accès aux données qui était moins forte dans le logiciel tout-client. Et encore, les formats fermés posaient déjà ce problème; selon ton principe de "données mieux que code" il vaut mieux utiliser un logiciel propriétaire qui comprend un format standard qu'un logiciel libre qui utilise son propre format maison (au hasard LaTeX). Je ne dis pas que c'est tout le temps faux, au contraire je pense que dans certaines situations tu as raison, mais il n'empêche que le code reste un point important et que dire "c'est un service donc on s'en fout" est un sacré aveuglement.
Donc avec le logiciel distribué il faut donc demander :
(comme avant) du logiciel libre
(comme avant) des données dans un format ouvert
(nouveau) l'accès facile à ses données pour (comme avant) éviter le verrouillage technologique
(nouveau) le fait que les vilains n'aient pas accès à nos données privées (soit on choisit où les stocker, soit elles sont chiffrées en local)
Le choix de la décentralisation me paraît plutôt être un choix technique indépendant, mais ça reste intéressant (du point de vue de la robustesse et pour faciliter l'ouverture), et qui est au passage une bonne façon de garantir un certain respect des points (2), (3) et (4).
Si certains pensent que c'est une bonne nouvelle, pour ma part, cela signifie une nouvelle fragmentation du marché Linux déjà bien petit (pour les jeux en tout cas).
Je ne comprends pas cet argument. Pour moi plus de points de distribution ça va faire au contraire augmenter la taille du marché au lieu de le fragmenter. Les joueurs qui font tout sur Steam pourront demain envisager de faire pareil, mais sous GNU/Linux, et donc augmenter le "marché des jeux" pour cette plateforme. Ça pourrait être mauvais si ça risquait de tuer des petits acteurs du secteur, mais Desura est déjà en compétition avec Steam sur les autres plateformes et ne fait pas spécialement son beurre sur GNU/Linux il me semble, et sinon il reste l'Ubuntu Store que tu ne dois pas non plus porter dans ton cœur…
J'insiste sur le fait que tu lui proposes un service propriétaire au lieu d'un service libre. Pour profiter de la décentralisation il faut utiliser des technologies qui permettent d'agréger l'audience (par exemple… des flux de syndication), donc il y a un intérêt à passer (ou se dupliquer) sur un service centralisé pour capter son public. Ce qui m'importe dans le message ci-dessus, c'est avant tout le côté libre ou propriétaire du service.
Mais pour qu'un service libre soit vraiment bon il faut qu'il supporte de la décentralisation avec agrégation. C'est bien d'avoir les sources de LinuxFR et de pouvoir les modifiers, mais tout l'aspect "modifier pour soi et diffuser les modifications aux autres" est difficile à mettre en place si tu ne peux pas proposer ta propre porte d'entrée sur le contenu de LinuxFR (donc du contenu agrégé). Ça reste utile pour proposer des améliorations à LinuxFR, et pour créer d'autres sites sur la même base de code, mais le top ce serait de pouvoir proposer aux gens qui le souhaitent d'accéder au même contenu en utilisant une autre version du code.
Donc tu proposes l'utilisation d'un service centralisé propriétaire plutôt que sa solution libre, décentralisée et auto-hébergée, pour gagner en ergonomie ? Je ne dis pas que l'ergonomie n'est pas importante, mais vu la perte en liberté ça ressemble plutôt, tout compte fait, à une régression…
Il n'empêche que l'implémentation de YARV fait qu'à un instant donné un seul thread Ruby peut s'exécuter, il y a un "Big Interpreter Lock" comme je l'ai dit dans mon message (l'intérêt d'avoir plusieurs threads dans ce cas est d'utiliser l'outillage de l'OS, de faire tourner des threads C en parallèle avec des threads Ruby (ce qui encourage les gens à coder de plus grosses parties de leur programme en C), ou encore de donner le contrôle à un autre thread si tu bloques sur une grosse entrée/sortie (mais il faut explicitement coder la relâche du verrou global)). Au contraire la JVM permet de faire tourner du bytecode vraiment en parallèle sur plusieurs cœurs, donc si tu écris tes programmes pour (il faut éviter les data races) tu pourrais avoir des gains en performance.
Je n'ai pas suivi la 2.0 mais il faudrait partir d'une source un peu plus intéressante qu'une demi-phrase sur "un bytecode plus optimisé" dans un article grand public.
Ce que je prends correspond en gros au haut de taille d'écran en "ultrabook" (mais la dénomination n'existait pas quand j'ai commencé à chercher ce modèle), pour m'en servir comme station de travail principale (quitte à prévoir un écran externe dans certains lieux fixes) en faisant un compromis entre la portabilité et le confort (14" c'est le pied, 13" c'est bien, en dessous c'est limite).
Visiblement on n'a pas les même priorités (moi la dalle de l'écran, bon), mais je trouve que tu te focalises un peu sur les gros chiffres du processeur. Un processeur moins puissant peut être un bon choix si tu veux une plus longe autonomie par exemple (processus à bas voltage). Tout ça pour dire que je trouve normal d'avoir des 13" optimisés pour la taille à des prix égaux à un 17" sans contrainte de poids et donc avec du matos plus générique.
Ah oui, et zut aux gens qui ont "inutilé" ton post à 0 alors que la question est légitime et que la dépêche ou les liens qu'elle fournit ne lui apporte pas vraiment de réponse claire.
Posté par gasche .
En réponse à la dépêche JRuby 1.7.0.
Évalué à 5.
Dernière modification le 26 octobre 2012 à 17:04.
Dans la vraie vie ça ne marche pas toujours aussi bien : la JVM a été pensée pour Java et la viser depuis un autre langage peut poser problème si ta sémantique est vraiment différente. Typiquement tu ne vas pas pouvoir réutiliser le modèle objet (mais invoke_dynamic est censé aider pour ça), ou alors ton langage utilise beaucoup les appels terminaux qui ne sont pas optimisés en Java pour des raisons moisies, ou tu utilises des exceptions qui se traînent le ventre par terre sur la JVM ou sur la machine virtuelle .NET.
Même pour les langages dynamiques implémentés avec les pieds comme Python, PHP ou Ruby, les gens pensaient avoir de gros gains en utilisant un runtime "state of the art" comme Java ou un JIT existant comme LLVM, et en fait c'est loin d'être aussi simple, la perte de contrôle sur la représentation des données ou certains points d'optimisation fait que c'est finalement assez dur de faire franchement beaucoup mieux en peu d'efforts; et même quand tu y arrives, tu découvres que les utilisateurs ont codé les bouts performance-critiques en C en passant par une FFI toute moche reposant sur des détails internes de l'implémentation précédente, et t'es mort. C'est pour ça que les projets style Rubinius, JRuby, Pypy et compagnie ont la vie dure.
En gros les gens espèrent récupérer les bonnes propriétés des machines virtuelles Java optimisées à mort : compilation JIT optimisée à mort, et runtime qui supporte bien le parallélisme multi-thread (alors que les implémentations maisons reposent souvent sur un Big Interpreter Lock et ne peuvent donc faire que du parallélisme multi-process). Tant mieux si tu as en plus accès aux librairies Java (mais en pratique les interfaces sont tellement différentes que ça n'est pas si commode), aux outils qui travaillent directement sur le bytecode (test de sécurité ou de bugs, instrumentation etc.).
C'est partiellement liés aux raisons que les gens de Google ont utilisé quand ils ont écrit Gerrit, une implémentation d'un logiciel de revue de code basée sur un backend Git: au lieu de prendre l'implémentation Git officielle en C, ils utilisent une ré-implémentation de Git en java, JGit, parce qu'ils préfèrent administrer des trucs qui tournent sur la JVM.
Justement j'aimerais bien trouver ces informations dans la dépêche (ou éventuellement ses commentaires). Là tu me suggères de télécharger des codes sources au hasard en espérant trouver dedans la ou les constructions qui répondent à ma question et la comprendre (alors que justement elle est sans doute nouvelle et spécifique), ou alors chercher dans des tutoriels qui sont sans doute destinés aux débutants plutôt qu'aux gens qui se posent cette question. Tu n'as pas une indication plus précise ?
En quoi les besoins de développement de jeu vidéo nécessitent-ils un nouveau langage, plutôt qu'une nouvelle bibliothèque pour un langage existant ?
(Je ne pose pas une question rjétorique par malice, pour suggérer que la réponse est "en rien". C'est une question sérieuse.)
Je trouve que la dépêche manque d'exemples de code. Avez-vous des exemple de code qui mettent en valeur les fonctionnalités spécifique de Bennu, et donc l'intérêt de définir un nouveau langage ?
Ça a un peu trollé sur reddit à l'annonce de la sortie, et j'ai été amener à ramener à l'audience, de la façon la plus neutre et la plus impartiale possible, les "torts" que la communauté du libre reproche factuellement au projet Mono. C'est par ici, et pour les paresseux anglophones je me permets de copier le message ci-dessous.
I am not part of the GNU project (nor of the Mono community), and I definitely think Mono has managed impressive technical achievements, but I would like to point out that the story is more nuanced as you make it seem.
The general perspective is that people have been opposed to introducing Microsoft technologies in the free software stack, and regularly claimed that Mono raised patent issues and was a danger (on one side, you could say that most software raises patent issues and most developers boldly ignore them, but on the other you could say that Microsoft is a particularly nasty player, as indeed the later Android patent racket has again confirmed). So the Mono project has been the target of more scrutiny and criticisms than most others, with discussions for example of which part of Mono are safe because of .NET ECMA standardization (answer: essentially only the core). No judgment on my part here, that is only an explanation of the general context, which I believe is fair.
Here are the few objective facts that raised concerns over Mono as a free software project and fueled what you call "shit from the GNU community"
In November 2006, Novell made a deal with Microsoft. The deal was itself never disclosed entirely (not that it should have been), but some information were released publicly. There was some money exchanged, agreement to distribute products from the other, and time-limited license grants for some technology allegedly covered by intellectual property. The part of concern here is that both Microsoft and Novell claimed that Mono (along with some other projects such as Samba) was covered by the deal. This meant that Novell customers could safely use Mono without fear of patent litigation. This also meant that non-customers were explicitly excluded from a license grant on Mono, and therefore could fear patent litigation. This was terrible for Mono's reputation, as it hinted at patent dangers (why would otherwise Microsoft give an explicit license grant?) and created an unfairness in the field, with some users of free software more equals than others. I'm not aware of Microsoft having in fact used Mono-related intellectual property to conclude other licensing deals, and I think Mono is now covered by the Open Invention Network that provides some more guarantees of safety. But at the time Ballmer was roaring about how Microsoft would have to defend its intellectual property, and a hidden agreement on Mono licensing was very badly perceived. (Note that the deal does not specifically originates from Mono and I have no idea whether they even requested being covered by this patenting deal.)
the second issue is how Moonlight was supported by Microsoft. When the Mono project successfully demonstrated a prototype Silverlight implementation, Microsoft decided to help them to get up to speed (assumption: Microsoft wanted to be able to say that Silverlight is a cross-platform technology to help adoption). The Mono team signed a non-disclosure agreement (NDA) and was given preferential access to non-public documentation and test suites, and Microsoft made a very specific patent grant saying essentially "you're safe if you use the Novell-provided product". Again, the free software community resented the unfairness introduced by this procedure (what about alternative implementations? users of non-Novell distributions?). Note that this kind of "NDA over private documentation" is not new, it has been done in a few cases of device drivers for the Linux Kernel, and publicly criticized by the BSD folks that would like the additional documentation to be made public instead. Yet this is highly unusual for desktop technologies and the Mono project has been criticized for that move.
I believe it is fair to say that in those two cases, the Mono project was in a situation benefiting its own interest (being a privileged Microsoft partner) while increasing the perceived risk for the rest of the free software community, and creating a fragmentation of different rights. Whether you think this is an important issue, and how you compare that to the technological benefits brought by having a reasonable free software implementation of a part of the .NET stack, that is entirely up to you.
[^] # Re: Lennart va nous faire un ulcère
Posté par gasche . En réponse au journal Trolldi : Lennart en pleine forme. Évalué à 5.
Je ne connaissais pas ce blog de l'auteur de upstart. Après avoir lu l'article que tu cites sur son départ de Canonical, écrit il y a un an, je suis allé à la racine pour me faire une idée de ce qu'il écrit en ce moment. Et c'est là qu'est l'ironie du sort, car son dernier billet (fin octobre 2012) c'est Goodbye Ubuntu.
En même temps le premier article que j'ai trouvé de lui sur un sujet qui m'intéresse, Revision Control and Unit Tests considered Harmful, est stupide. Je passe mon chemin.
# Bof
Posté par gasche . En réponse à la dépêche Les journaux LinuxFr.org les mieux notés de la semaine 46/2012. Évalué à 5. Dernière modification le 19 novembre 2012 à 14:54.
Je n'ai pas aimé le journal De l'inéluctable progrès de l'informatique, ou pas, c'est une râlerie comme des dizaines d'autres qui n'a rien de nouveau et qui ne sert à rien. Je trouve dommage que ce journal ait un score de 44 alors qu'un journal qui apporte une information et amène à une discussion intéressante comme Le store d'Ubuntu et les logiciels proprios se trouve à 13. À croire que les journaux où il n'y a rien à dire attirent les gens qui ne disent rien, mais pertinentent plus que la moyenne.
# Morceaux
Posté par gasche . En réponse au journal Cinema - Skyfall. Évalué à 2.
Sommaire
J'ai passé un bon moment en voyant ce James Bond (sans m'attendre non plus à un grand film, ce n'est pas mon genre de toute façon). J'ai surtout apprécié les images que j'ai trouvé très belles (en particulier le passage à Shanghai) et le changement d'idée permis par une scène de poursuite. Il y a quelques bonnes trouvailles et quelques choses improbables ou incohérentes, mais j'ai surtout été interpellé par certains aspects du film.
Les personnages féminins sont décevants
Le personnage est macho et couche avec tout ce qui bouge, c'est une évidence sur laquelle il n'y a à mon avis pas grand chose à dire : certains trouvent ça normal et faisant partie du personnage, moi je ne suis pas fan mais en effet c'est attendu quand on va voir un James Bond.
Par contre indépendamment des coucheries, j'ai été frappé par le fait que tous les personnages féminins sont décevants ou au moins ambivalents :
M pourrait être la "femme forte" de l'épisode, mais à partir du milieu du film est prend le statut au contraire de personnage vulnérable à protéger; ça fait partie du scénario, mais je ne comprends pas pourquoi sa vulnérabilité est accentuée ("je n'ai jamais su tirer", ça serait à mon avis autant plus marrant qu'elle sache vraiment tirer)
l'agent qui aide James Bond au début de l'épisode se débrouille délicieusement bien sur le terrain, mais finit secrétaire. Cette partie du scénario est vraiment ambiguë à mon avis, oscillant entre "promotion vers un poste à responsabilités" (la façon dont j'avais envie de comprendre) et "t'es une ratée qui sait pas tirer, donc tu t'auto-censures en choisissant la vie de bureau". Dans les deux cas c'est décevant et personnellement je me serais bien passé du côté "référence arrière finale" pour une vraie agent de terrain qui s'éclate dans son rôle et qui retourne au boulot.
le non-personnage à qui James Bond fait l'amour une demi-seconde avant d'aller se bourrer la gueule dans un bar sur une plage turque. Est-ce la personne qui a sauvé James Bond d'une mort attendue ? Comment s'appelle-t-elle ?
la copine du méchant, qui commence dans un rôle actif et égal à James Bond (on ne la voit rien faire vraiment, mais dans le début de leur dialogue commun il et elle sont sur un pied d'égalité en démasquant les armes de l'autre) mais bascule rapidement dans un rôle de femme terrifiée que James Bond manipule pour son but propre et est vaguement déçu de voir tuer rapidement (même s'il pouvait difficilement avoir prévu autre chose)
Le personnage de James Bond est remis en question dans cet épisode, son statut de surhomme mis à mal par la vieillesse ou la fatigue. Si on se permet cette (agréable) remise en question du personnage, je pense qu'il est aussi temps de penser à des personnages féminins qui pètent, qu'ils soient gentils ou méchants, meurent à la fin ou non. Pourquoi pas une complice qui s'en sort mieux que lui pour une fois, ou une grande méchante, pour le prochain film ?
Le MI6 est son propre ennemi
Il y a un pseudo-discours politique dans le film, oscillant entre "maintenant les ennemis sont les terroristes et on est désemparés" et "le gouvernement nous casse vraiment les pieds", auquel à mon avis il ne faut pas attacher trop d'importance car je ne pense pas que ce soit le but du film. Un point intéressant qui n'est en fait pas du tout traité dans le film est que la menace dont il est question ici a été entièrement créée par le MI6: c'est un ex-agent qui attaque la maison mère. Donc autant le film montre le MI6 comme ayant un rôle véritable et utile à jouer dans l'ombre de la vie publique, autant la cause même de la violence et de l'insécurité dans ce film est provoquée par cette mécanique même, ce qui la remet en question au moins aussi sérieusement à mon avis que la demande de transparence et démocratie évoquée dans le film.
La vision de l'informatique est intéressante
Les gens des milieux techniques qui commentent James Bond ont fait des remarques en passant sur le traitement grotesque de l'informatique, et en particulier la sécurité, dans le film. Il y a une remarque effectivement qui m'a fait bien rire du style (je paraphrase) "le mail est protégé par un algorithme asymétrique… donc il se duplique en copies actives sur plein de serveurs dans le monde", et la scène où ils déchiffrent des données protégées est évidemment irréaliste. Ceci dit il y a plusieurs points qui m'ont semblé intéressants dans le traitement de l'informatique dans le film :
Le pirate attaque le MI6 en ayant prévu qu'ils brancheraient son ordinateur à leur réseau pour l'analyser; c'est stupide vous me direz, quand on a une machine à priori hostile, de la brancher à un réseau sensible. Mais dans la vraie vie ce genre de problèmes (machines sensible branchée au réseau) arrive régulièrement, et cette stupidité peut vite être commise par des gens qui devraient savoir les problèmes que ça pose ("mais ça arrive aux autres, pas à moi").
Le beurre du grand méchant est l'attaque de systèmes informatiques vulnérables. Tous les méfaits qu'il cite ont été accomplis avec l'informatique. On oscille entre du FUD sur la cyber-guerre et le terrorisme informatique et une mention réaliste d'un monde sur-connecté qui présente de nouvelles vulnérabilités. "Changer le résultat d'un vote électronique en Ouganda, en faveur du plus offrant ? Facile.". À méditer.
Dans un contexte moins technique "ouech gros pro de la crypto", internet est bien présent dans ce film. C'est là que le pirate formule son attaque personnelle contre M. Quand il commence à divulger les noms de la liste d'agents infiltrés, ce n'est pas en les envoyant aux grands journaux, mais en postant des vidéos Youtube. L'informatique telle qu'elle est perçue par le grand public est bien présente dans ce film, et même un point clé du scénario, et ça je trouve que c'est très intéressant.
[^] # Re: En douce
Posté par gasche . En réponse au sondage Le libre et mon activité. Évalué à 7.
Tout à fait d'accord. J'irai même plus loin en disant qu'un chercheur a la responsabilité d'assurer la diffusion la plus large de ses résultats, et qu'un chercheur qui respecterait des règles illégitimes de son employeur ou éditeur ne permettant pas cette diffusion fait un mauvais travail, et qu'on peut le lui reprocher.
[^] # Re: Décentralisation et fédération
Posté par gasche . En réponse au journal MediaGoblin : le futur c'est maintenant !. Évalué à 2.
Je dirais qu'un outil décentralisé est fédéré à partir du moment où la réunion de deux nœuds peut se comporter en gros comme un seul nœud (et non comme une somme disjointe de deux petites choses isolées et ne se parlant pas entre elles). Peut-être que ce n'est pas la bonne définition de "fédéré", mais c'est la bonne définition de ce que je veux (et alors "fédéré" ne serait pas le bon concept).
[^] # Re: En douce
Posté par gasche . En réponse au sondage Le libre et mon activité. Évalué à 5. Dernière modification le 12 novembre 2012 à 11:39.
Le précédent gouvernement avait une politique d'exploitation économique des résultats de la recherche ("intelligence économique" bla bla) à vomir, mais malheureusement le nouveau ne fait pas beaucoup d'efforts pour corriger la tendance. L'idée reste globalement que si tu as une bonne idée, la première étape devrait être de contacter dans le secret un partenaire industriel pour faire du fric avec, la deuxième de breveter et la troisième, si vraiment tu penses que ça ne vaut rien, de publier. C'est beau la valorisation.
Mettre une licence libre sur ton travail est une très bonne idée : le Copyright peut rester à l'employeur (c'est ce qui lui importe en général) tout en assurant une distribution large des résultats, ce qui est ce que les chercheurs veulent en général. Ça marche encore très bien dans les schémas de financement bizarres où le chercheur est plus ou moins mis à disposition d'un organisme tiers qui réclame le copyright. Dans tous les cas il faudrait quand même demander l'accord formel de l'employeur avant de choisir la licence en principe, mais si on travaille sur un truc qui est déjà en GPL il n'y a pas besoin puisqu'il n'y a pas le choix…
PS: perso j'ai classé ce genre de comportement dans la catégorie 2, "ne rentre pas dans le modèle de l'entreprise mais on le fait quand ça fait du sens", parce que même si sur le papier c'est un peu "en douce" dans les faits c'est une pratique reconnue et acceptée dans le milieu de la recherche, donc un peu plus que "en douce".
[^] # Re: Patchs
Posté par gasche . En réponse au sondage Le libre et mon activité. Évalué à 6.
La très intéressante remarque de Tanguy ne porte pas directement sur l'utilisation de logiciels libres (je ne pense pas que ça nous apporte grand chose de savoir qu'une écrasante majorité de gens utilisent des logiciels libres dans le cadre de leur travail), mais sur le fait que leur utilisation justifie le fait qu'il contribue au libre sur son temps de travail. Utiliser LibreOffice c'est bien, mais cela t'a-t-il déjà conduit à rapporter un bug ou envoyer un patch pour corriger un problème ? La question est justement de savoir si tu te permets cette contribution, et si elle est considérée comme faisant légitimement partie de ton temps de travail. Et là tout de suite je pense que ça concerne beaucoup moins de gens—ce qui rend la remarque pertinente.
[^] # Re: Inepties
Posté par gasche . En réponse à la dépêche « Une génération perdue dans le bazar ». Évalué à 4.
Pas du tout, s'ils sont dans cette situation c'est parce que c'était le plus simple étant donné leurs besoins et les circonstances. Ou alors tu penses que les développeurs de Firefox ont fait exprès des choix contre-productifs, par erreur ou aveuglement, et que leur donner un message aussi utile et construit que "bouh le bloatware c'est mal" va les aider à sortir de leur erreur et donc leur rendre grand service. Des erreurs arrivent toujours, et c'est bien de prendre soin d'éduquer les développeurs, mais il se trouve que dans ce cas précis je pense pouvoir prédire sans me tromper qu'utiliser à la fois du software perl et du software python leur a vraiment simplifié la vie, et que supprimer l'un des deux leur demanderait du travail pour un bénéfice qui n'en vaut pas la peine.
Bien sûr si toi tu accordes une importance supérieure à ces questions (tu choisis de favoriser la propreté du design plutôt que les besoins objectifs, ce qui peut avoir un intérêt, je le dis en perfectionniste averti), tu es libre de donner ton propre temps pour résoudre cette situation, c'est beau le logiciel libre. Mais bon écrire des articles rageux dans Communication of the ACM (ou des réponses un peu creuses sur LinuxFR) c'est quand même plus simple.
[^] # Re: Inepties
Posté par gasche . En réponse à la dépêche « Une génération perdue dans le bazar ». Évalué à 10. Dernière modification le 09 novembre 2012 à 23:20.
Je ne sais pas ce que tu veux dire par "en lisant un peu plus", j'ai bien sûr lu le billet avant de le critiquer.
Le texte que tu cites n'a rien de particulièrement convaincant : tu peux avoir un paquet Firefox qui dépend du paquet Toto qui lui-même dépend du paquet Tiff pour certaines de ses fonctionnalités, que Firefox lui-même n'utilise pas (genre, au hasard, un truc à la ImageMagick qui supporte 60 formats dont 59 intéressent Firefox).
Avec un gestionnaire de paquets source, tu peux gérer un peu finement les dépendances de tes dépendances (genre les USE flags de gentoo), mais déjà ça suppose que Toto a été pensé pour pouvoir désactiver sélectivement des formats (pas forcément la priorité des développeurs), et ensuite les packageurs binaires vont souvent faire le choix simplificateur d'activer tous les formats pour pouvoir servir tous les paquets utilisant Toto et pas juste Firefox et se simplifier la vie de gestionnaire de dépôts—et parce qu'ils s'en moquent que l'auteur du billet fasse une crise de nerf parce que Firefox installe libtiff.
De même, Firefox peut décider d'utiliser deux bibliothèques super utiles, une pour parser le HTML et l'autre pour communiquer à travers le réseau, l'une étant écrite en Python et l'autre en Perl, deux langages qui demandent un support runtime donc doivent être installés avec ces libs. Qu'est-ce que l'auteur aigri conseille aux développeurs de Firefox (ou autre) de faire en ce cas ? Ré-écrire l'une des bibliothèques dans l'autre langage pour n'installer qu'un seul runtime ? Demain il refait un billet pour dire que c'est un scandale, son système a voulu installer deux bibliothèques implémentant le même algorithme, et ce dans deux langages différents.
Peut-être que dans son esprit les développeurs et packageurs de Firefox devraient se plier en quatre pour, surtout surtout, n'avoir aucune dépendance superflue et porter les bibliothèques en Perl vers Python pour simplifier encore les dépendances. Sauf que dans la vraie vie ces gens-là ont bien plus intéressant et utile à faire de leur temps et leur énergie, pour aider à résoudre d'autres problèmes qui font certainement râler quelqu'un d'autre sur le net. Et si un jour ces problèmes deviennent gênants (oui ça arrive), les gens investissent plus d'effort là-dedans, on a un peu plus de cathédrale et un peu moins de bazaar le temps d'une restructuration, et ça repart.
PS: et tout ce que j'ai dit est assez évident, tu aurais certainement pu faire l'effort de dérouler cette argumentation toi-même.
# Inepties
Posté par gasche . En réponse à la dépêche « Une génération perdue dans le bazar ». Évalué à 7.
Cet article est fade et les arguments sont mauvais. L'auteur a fait des choses très bien et publie dans un média impressionnant par ses connotations scientifiques, mais à part les anecdotes historiques qui sont toujours enrichissantes ça reste une râlerie moyenne d'un utilisateur aigri.
L'auteur râle parce qu'un paquet donné a trop de dépendances. En même temps il râle parce que certains codes sont copiés dans plein de paquets différents. C'est quoi la solution pour résoudre son deuxième problème ? Factoriser le code comme un paquet et en faire… une dépendance supplémentaire. Bonjour la contradiction.
L'écosystème logiciel est complexe. Il y a beaucoup de programmes différents, qui ont beaucoup de dépendances (pour éviter la redondance). Selon les sous-communautés, les organisations sociales, les moyens disponibles, les gens vont avoir un processus de développement structuré de façon plus ou moins rigide. Il n'y a pas une seule bonne manière de faire, mais des choses qui sont adaptées dans certaines situations et pas dans d'autres. Donc au final quand on regarde dans la nature sauvage on observe… un continuum d'états entre "la cathédrale" et "le bazaar" (modèles caricaturaux et extrêmes), avec tout au milieu. Structurer en cathédrale c'est bien pour certains usages, mais ça demande de l'énergie, et en pratique les projets évoluent en moindre effort et les gens font de leur mieux. Il est illusoire de penser qu'on pourrait magiquement, en râlant, faire passer tout le monde à un style particulier donné, ça ne résoudrait rien et ça n'est tout simplement pas la façon dont les choses se passent.
Des choses intéressantes ont été dites sur le "bloat" des logiciels modernes. Le projet STEPS du Viewpoint Research Institute, auquel participe notamment Alan Kay, essaie de concevoir le logiciel d'un ordinateur personnel en moins de 20 000 lignes de code. John Regehr dit des choses intéressantes sur la question ici (Can Simplicity Scale) et là (It's All About Interfaces). En comparaison, l'article de cette dépêche fait pâle figure, énumérant les jérémiades sans lien logique ou proposition constructive.
[^] # Re: Maintenance par l'inria ?
Posté par gasche . En réponse au journal Annonce : un blog sur une équipe de recherche en langages de programmation. Évalué à 7.
Inria est un institut de recherche en informatique qui emploie plus de 4000 personnes et contient environ 180 équipes-projets, donc c'est très large. Je ne comprends pas trop ta question; mais tous les contributeurs ne font pas partie de cette équipe de recherche (c'est un projet libre donc il y a pas mal de gens de la communauté qui ont contribué quelque chose, ne serait-ce qu'en rapportant des bugs et en aidant les débutants sur la mailing-list, mais aussi de plus grosses contributions). De mémoire (et sans garantie que c'est correct) je dirais que les principaux mainteneurs de fait ces derniers mois sont, dans le désordre, Xavier Leroy et Damien Doligez (équipe Gallium), Alain Frisch (Lexifi (industrie)) et Jacques Garrigue (Université de Nagoya).
[^] # Re: Bonjour l'infobésite™
Posté par gasche . En réponse à la dépêche De tout, de rien, des bookmarks, du bla‐bla #45. Évalué à 4.
Je lis souvent ces brèves et je n'ai jamais eu ce sentiment de "personne qui veut montrer son savoir". Je pense que le texte envoyé par CrEv est neutre de ce point de vue-là, et que cette lecture psychologique est ajoutée de ton côté : sans vouloir faire de la psychologie à la con, je parierais que ça se comprendrait plutôt à partir de tes propres peurs que du contenu réel de ces dépêches.
Si je peux fournir une explication sur la quantité de lien : l'idée est un peu que chacun va y piocher ce qui l'intéresse vraiment au lieu de se forcer à tout lire. L'auteur (ou les auteurs) li(sen)t tout car ça correspond exactement à ses/leurs centres d'intérêt. Pour toi c'est périphérique donc il faut s'investir moins. En ces temps où l'information est facilement accessible, il faut se forcer à filtrer et s'investir avec soin.
[^] # Re: Bonjour l'infobésite™
Posté par gasche . En réponse à la dépêche De tout, de rien, des bookmarks, du bla‐bla #45. Évalué à 3.
Je ne suis pas d'accord. Un service c'est du logiciel qui tourne, et ce logiciel peut être libre ou propriétaire. Quel est le différence aujourd'hui entre faire tourner du logiciel dans une page web (que l'exécution se fasse chez le client ou le serveur) et dans un "logiciel lourd" ? Quand j'utilise un logiciel je veux pouvoir l'utiliser librement, étudier son fonctionnement et tester des versions modifiées. Quand j'utilise un service je veux pouvoir l'utiliser librement, étudier son fonctionnement et tester des versions modifiées.
T'es juste en train de dire "oui mais c'est pas grave si je pousse les gens à répondre à leur besoin en utilisant du code qu'on n'a pas le droit de voir, ça se passe à travers un navigateur donc ça va". Ce qui nous fera une belle jambe quand tout se fera à travers un navigateur.
Le passage aux logiciels distribués ajoute une nouvelle problématique d'accès aux données qui était moins forte dans le logiciel tout-client. Et encore, les formats fermés posaient déjà ce problème; selon ton principe de "données mieux que code" il vaut mieux utiliser un logiciel propriétaire qui comprend un format standard qu'un logiciel libre qui utilise son propre format maison (au hasard LaTeX). Je ne dis pas que c'est tout le temps faux, au contraire je pense que dans certaines situations tu as raison, mais il n'empêche que le code reste un point important et que dire "c'est un service donc on s'en fout" est un sacré aveuglement.
Donc avec le logiciel distribué il faut donc demander :
Le choix de la décentralisation me paraît plutôt être un choix technique indépendant, mais ça reste intéressant (du point de vue de la robustesse et pour faciliter l'ouverture), et qui est au passage une bonne façon de garantir un certain respect des points (2), (3) et (4).
# Fragmentation du marché ?
Posté par gasche . En réponse au journal Desura, la véritable plate-forme de distribution de jeux vidéo en ligne disponible sous Linux. Évalué à 9.
Je ne comprends pas cet argument. Pour moi plus de points de distribution ça va faire au contraire augmenter la taille du marché au lieu de le fragmenter. Les joueurs qui font tout sur Steam pourront demain envisager de faire pareil, mais sous GNU/Linux, et donc augmenter le "marché des jeux" pour cette plateforme. Ça pourrait être mauvais si ça risquait de tuer des petits acteurs du secteur, mais Desura est déjà en compétition avec Steam sur les autres plateformes et ne fait pas spécialement son beurre sur GNU/Linux il me semble, et sinon il reste l'Ubuntu Store que tu ne dois pas non plus porter dans ton cœur…
[^] # Re: Bonjour l'infobésite™
Posté par gasche . En réponse à la dépêche De tout, de rien, des bookmarks, du bla‐bla #45. Évalué à 1.
J'insiste sur le fait que tu lui proposes un service propriétaire au lieu d'un service libre. Pour profiter de la décentralisation il faut utiliser des technologies qui permettent d'agréger l'audience (par exemple… des flux de syndication), donc il y a un intérêt à passer (ou se dupliquer) sur un service centralisé pour capter son public. Ce qui m'importe dans le message ci-dessus, c'est avant tout le côté libre ou propriétaire du service.
Mais pour qu'un service libre soit vraiment bon il faut qu'il supporte de la décentralisation avec agrégation. C'est bien d'avoir les sources de LinuxFR et de pouvoir les modifiers, mais tout l'aspect "modifier pour soi et diffuser les modifications aux autres" est difficile à mettre en place si tu ne peux pas proposer ta propre porte d'entrée sur le contenu de LinuxFR (donc du contenu agrégé). Ça reste utile pour proposer des améliorations à LinuxFR, et pour créer d'autres sites sur la même base de code, mais le top ce serait de pouvoir proposer aux gens qui le souhaitent d'accéder au même contenu en utilisant une autre version du code.
[^] # Re: Bonjour l'infobésite™
Posté par gasche . En réponse à la dépêche De tout, de rien, des bookmarks, du bla‐bla #45. Évalué à 2.
Donc tu proposes l'utilisation d'un service centralisé propriétaire plutôt que sa solution libre, décentralisée et auto-hébergée, pour gagner en ergonomie ? Je ne dis pas que l'ergonomie n'est pas importante, mais vu la perte en liberté ça ressemble plutôt, tout compte fait, à une régression…
[^] # Re: Utilité ?
Posté par gasche . En réponse à la dépêche JRuby 1.7.0. Évalué à 3.
Il n'empêche que l'implémentation de YARV fait qu'à un instant donné un seul thread Ruby peut s'exécuter, il y a un "Big Interpreter Lock" comme je l'ai dit dans mon message (l'intérêt d'avoir plusieurs threads dans ce cas est d'utiliser l'outillage de l'OS, de faire tourner des threads C en parallèle avec des threads Ruby (ce qui encourage les gens à coder de plus grosses parties de leur programme en C), ou encore de donner le contrôle à un autre thread si tu bloques sur une grosse entrée/sortie (mais il faut explicitement coder la relâche du verrou global)). Au contraire la JVM permet de faire tourner du bytecode vraiment en parallèle sur plusieurs cœurs, donc si tu écris tes programmes pour (il faut éviter les data races) tu pourrais avoir des gains en performance.
Je n'ai pas suivi la 2.0 mais il faudrait partir d'une source un peu plus intéressante qu'une demi-phrase sur "un bytecode plus optimisé" dans un article grand public.
[^] # Re: Portables moins chers?
Posté par gasche . En réponse au journal bsd/linux ou gnu/linux ?. Évalué à 3.
Ce que je prends correspond en gros au haut de taille d'écran en "ultrabook" (mais la dénomination n'existait pas quand j'ai commencé à chercher ce modèle), pour m'en servir comme station de travail principale (quitte à prévoir un écran externe dans certains lieux fixes) en faisant un compromis entre la portabilité et le confort (14" c'est le pied, 13" c'est bien, en dessous c'est limite).
Visiblement on n'a pas les même priorités (moi la dalle de l'écran, bon), mais je trouve que tu te focalises un peu sur les gros chiffres du processeur. Un processeur moins puissant peut être un bon choix si tu veux une plus longe autonomie par exemple (processus à bas voltage). Tout ça pour dire que je trouve normal d'avoir des 13" optimisés pour la taille à des prix égaux à un 17" sans contrainte de poids et donc avec du matos plus générique.
[^] # Re: Utilité ?
Posté par gasche . En réponse à la dépêche JRuby 1.7.0. Évalué à 2.
Ah oui, et zut aux gens qui ont "inutilé" ton post à 0 alors que la question est légitime et que la dépêche ou les liens qu'elle fournit ne lui apporte pas vraiment de réponse claire.
[^] # Re: Utilité ?
Posté par gasche . En réponse à la dépêche JRuby 1.7.0. Évalué à 5. Dernière modification le 26 octobre 2012 à 17:04.
Dans la vraie vie ça ne marche pas toujours aussi bien : la JVM a été pensée pour Java et la viser depuis un autre langage peut poser problème si ta sémantique est vraiment différente. Typiquement tu ne vas pas pouvoir réutiliser le modèle objet (mais invoke_dynamic est censé aider pour ça), ou alors ton langage utilise beaucoup les appels terminaux qui ne sont pas optimisés en Java pour des raisons moisies, ou tu utilises des exceptions qui se traînent le ventre par terre sur la JVM ou sur la machine virtuelle .NET.
Même pour les langages dynamiques implémentés avec les pieds comme Python, PHP ou Ruby, les gens pensaient avoir de gros gains en utilisant un runtime "state of the art" comme Java ou un JIT existant comme LLVM, et en fait c'est loin d'être aussi simple, la perte de contrôle sur la représentation des données ou certains points d'optimisation fait que c'est finalement assez dur de faire franchement beaucoup mieux en peu d'efforts; et même quand tu y arrives, tu découvres que les utilisateurs ont codé les bouts performance-critiques en C en passant par une FFI toute moche reposant sur des détails internes de l'implémentation précédente, et t'es mort. C'est pour ça que les projets style Rubinius, JRuby, Pypy et compagnie ont la vie dure.
[^] # Re: Utilité ?
Posté par gasche . En réponse à la dépêche JRuby 1.7.0. Évalué à 4.
En gros les gens espèrent récupérer les bonnes propriétés des machines virtuelles Java optimisées à mort : compilation JIT optimisée à mort, et runtime qui supporte bien le parallélisme multi-thread (alors que les implémentations maisons reposent souvent sur un Big Interpreter Lock et ne peuvent donc faire que du parallélisme multi-process). Tant mieux si tu as en plus accès aux librairies Java (mais en pratique les interfaces sont tellement différentes que ça n'est pas si commode), aux outils qui travaillent directement sur le bytecode (test de sécurité ou de bugs, instrumentation etc.).
C'est partiellement liés aux raisons que les gens de Google ont utilisé quand ils ont écrit Gerrit, une implémentation d'un logiciel de revue de code basée sur un backend Git: au lieu de prendre l'implémentation Git officielle en C, ils utilisent une ré-implémentation de Git en java, JGit, parce qu'ils préfèrent administrer des trucs qui tournent sur la JVM.
[^] # Re: Pourquoi un nouveau langage ?
Posté par gasche . En réponse à la dépêche Développez vos jeux vidéo facilement avec BennuGD. Évalué à 5.
Justement j'aimerais bien trouver ces informations dans la dépêche (ou éventuellement ses commentaires). Là tu me suggères de télécharger des codes sources au hasard en espérant trouver dedans la ou les constructions qui répondent à ma question et la comprendre (alors que justement elle est sans doute nouvelle et spécifique), ou alors chercher dans des tutoriels qui sont sans doute destinés aux débutants plutôt qu'aux gens qui se posent cette question. Tu n'as pas une indication plus précise ?
# Pourquoi un nouveau langage ?
Posté par gasche . En réponse à la dépêche Développez vos jeux vidéo facilement avec BennuGD. Évalué à 6.
En quoi les besoins de développement de jeu vidéo nécessitent-ils un nouveau langage, plutôt qu'une nouvelle bibliothèque pour un langage existant ?
(Je ne pose pas une question rjétorique par malice, pour suggérer que la réponse est "en rien". C'est une question sérieuse.)
Je trouve que la dépêche manque d'exemples de code. Avez-vous des exemple de code qui mettent en valeur les fonctionnalités spécifique de Bennu, et donc l'intérêt de définir un nouveau langage ?
# Les performances ?
Posté par gasche . En réponse à la dépêche JRuby 1.7.0. Évalué à 4.
Ça va vite, il y a de jolis dessins à montrer ? En comparant à la version précédente mais aussi à l'implémentation officielle de Ruby ?
# Le casier judiciaire de Mono
Posté par gasche . En réponse à la dépêche Mono 3.0 est disponible. Évalué à 8.
Ça a un peu trollé sur reddit à l'annonce de la sortie, et j'ai été amener à ramener à l'audience, de la façon la plus neutre et la plus impartiale possible, les "torts" que la communauté du libre reproche factuellement au projet Mono. C'est par ici, et pour les paresseux anglophones je me permets de copier le message ci-dessous.