Guillaume Knispel a écrit 2474 commentaires

Ah, et tu veux lester les futurs papa et leur faire prendre des vomitifs pendant la grossesse de madame aussi ?

Le système de barrière/bornes d'achats de tickets/etc. étant déjà en place, supprimer toutes ces barrières, ce qui est loin d'être trivial techniquement parlant, aurait un coût particulièrement élevé ;

Tu commences par débrayer les portiques, le démantèlement peut se faire en douceur.

Dans ce cas pourquoi les accès sont barrés par des portiques ?

Il parait que ça marche.

Franchement les sociétés organisatrices doivent être plus éclairées que moi sur la question, mais en région parisienne au moins ça m'étonne beaucoup que ça dissuade qui que ce soit. D'ailleurs je crois qu'il est plus "intéressant" statistiquement de ne jamais payer de billet et de payer les amendes, et je pense que certaines personnes pratiquent carrément la chose.

Il suffit de mettre quelques tourniquet (même pas forcement systématiquement) entre deux zones, sans nécessairement de traçage, et encore moins de traçage nominatif.

Si un passe illimité ne peut être anonyme, j'imagine que l'existence des passes "découverte" va bientôt engendrer la destruction de l'univers.

Encore un truc probablement programmé par des nains de jardin sous amphétamine.

Cela ressemble au chant du cygne d’un admin qui n’a pas envie de tout réapprendre ni monter en compétence pour utiliser un outil plus performant.

Pour référence, je suis pas admin du tout (enfin bon, disons je suis admin à 2% dont 1% des 2% à gérer des trucs de boot) mais ingé travaillant en ce moment dans le logiciel de base + électronique, j'ai simplement trouvé l'opinion intéressante même si assez, hm, disons "forte", et susceptible de générer des débats et des opinions contradictoires venant largement contrebalancer le parti pris initial, ce qui n'a pas manqué de ce produire.

Mon opinion perso est que je trouve que systemd va trop loin en s'écartant du KISS et que D-Bus… sérieusement ?—mais j'avoue que dans certains contexte je pourrais fort bien m'en servir. Honnêtement apprendre à s'en servir doit être plutôt rapide.

Enfin je trouve même que sur certains de ses arguments Leszek Urbanski était, disons, léger.

traduire un article vieux de 10 mois (il y a plus de 15 releases de systemd dans l’intervalle), faire un procès d’intention (Lennart s’en fout des serveurs)

Concernant le nombre de versions de systemd ayant été publiées entre l'article d'origine, ça n'enlève rien au fond qui traite de l'architecture et de la liste de ce que systemd veut gérer. Concernant la structure de la phrase citée, elle confond implicitement le traducteur et l'auteur d'origine.

Le travail de traduction m'a pris je pense un peu plus d'une heure. (Voire peut-être deux, je sais plus trop.) Si j'avais voulu écrire mon opinion perso sur le sujet, un tel temps m'aurait permis de le faire plus directement. Mais je n'ai pas autant de choses à dire.

En tout cas j'ai trouvé certaines argumentations en commentaire de ce journal assez intéressantes, donc de mon point de vue mon appeau à troll c'est révélé aller au delà de mes espérances sur ses fonctions.

Étant donné que le projet n'a pas d'intérêt, le fait qu'il soit édulcoré ne le rend pas louable. Et ne fait pas disparaître tous les risques. On passe juste d'un rapport bénéfice / risque de 0 à un 0 un peu moins violent.

Un fichier n'est pas une institution. De plus les risques sont biens identifiés, les avantages inexistants, d'autres fichiers supposés moins problématiques ont prouvé un taux effectif de problèmes démesuré, le fichier défie donc le bon sens et le projet devrait être foutu à la poubelle. Pourquoi ne l'a-t-il pas été, c'est plutôt ça la bonne question (sans pour autant nier l’intérêt de toute mise en perspective historique)

Les smartphones x86 t'enfermeront tout autant, voir plus (intel à les moyens de lever la barre très très haut).

Tu effectue une mauvaise déduction sur la corrélation qu'il semble y avoir entre enferment et processeur ARM pour les gadgets grand public.

On ne peut pas comprendre les raisons des choix techniques de RH sans s'intéresser à sa politique en matière de support.

Tout le monde se fiche de launchd et smf. (au sens où ça a beaucoup moins d'impact indirect, les gens directement intéressés ne s'en fichent évidemment pas)
Le problème de systemd, c'est que RH compte dominer la planète GNU/Linux grâce à ce truc (et à d'autres bidules du même genre) avec des effets collatéraux relous en passant.

Dans certains cas oui. Néanmoins comme tu le dis certains firmware bootent en 3 plombes, et il vaut mieux s'y attaquer en cas de besoin de démarrage rapide sur un serveur et viser des choses comme coreboot par exemple. De plus systemd n'améliore pas tant que ça le temps entre le démarrage et la disponibilité réelle de tous les services, et s'il y a peu de services c'est facile d'obtenir un résultat encore plus proche en se passant de sa complexité (et en gagnant au passage en modularité et possibilité de combinaison non prévues par les concepteurs). Enfin systemd est fourni avec des chaînes dorées que l'on peut sous un certain angle trouver confortables et certains sont tentés de s'attacher avec (ou font carrément exprès car ils kiffent les effets de bords de ces chaînes qui permettent aussi d'asservir des tiers), ce qui présente un grave risque pour l'écosystème du LL.

j'ai absolument rien contre de la branlette théorique, mais à part vouloir faire chier le monde, c'est quoi ton problème ?

Pour 1, 2 et 4, Wayland va régler le problème comment ?

le monde propriétaire quand il livre des immondices sans specs : l'éco système linux fait la même chose

Euh c'est en fait pire que ça. Le monde propriétaire à bien souvent l'habitude de livrer des immondices certes, mais habituellement AVEC specs.

Moi si.

Il est vrai qu'il est rare qu'un auteur cède son droit moral. Par exemple en France on ne peut pas abdiquer son droit patrimonial (être l'auteur), mais il semblerait que ce soit possible aux États-Unis.

Il y a une petite confusion sur les droits moraux vs. patrimoniaux : cf. http://www.sacd.fr/Droit-moral-droit-patrimonial.91.0.html

Vu que le marché sera obligatoire et monopolistique par dessein, il n'y aura pas de possibilité effective de faire des logiciels libres sous Windows.
(Techniquement oui, mais un logiciel libre qui par une pirouette vient chez l'utilisateur possédant la machine sans la possibilité pour lui d'exercer ses droits, j'appelle plus cela du logiciel vraiment libre - d'ailleurs certaines licences libres le reconnaissent et interdisent une exploitation dans un tel contexte de d’emprisonnement.)

uefi, le standard merdique concu par intel et ms, avec des noms imbitables (UUID pour choisir le périph de boot, \ à la place de / comme séparateur, ...)

Si les UUID n'étaient là que pour identifier les périphs de boot, tout ne serait pas aussi pourri. Un disque ou un filesystem se prête bien à l'identification par UUID. Et les distributions GNU/Linux repèrent leur filesystem ainsi depuis un bout de temps.

En fait les UUID dans UEFI sont partout. Y compris pour la liaison dynamique des API en lieu et place de symboles. Y compris pour pas mal d'API au coeur d'UEFI.

C'est principalement relou parce que ça complique le reverse engineering. (Quoiqu'avec quelques scripts IDA bien placés, on doit pouvoir limiter la gène.)

Quant à ACPI, pas autant d'UUID, mais des symboles de 4 caractères, une syntaxe de langage source idiote, une sémantique super complexe, une inspiration venant tout droit de l'architecture de l'IBM PC original dans beaucoup de domaines, une norme qui maintenant fait quasiment 1000 pages et fait référence à des dizaines d'autres, une rétrocompatibilité qui remonte jusqu'à la nuit des temps tout en n'étant probablement pas effective et donc qui serait très avantageuse remplacé par du phase-out. Bref pas plus bandant qu'UEFI.

La plateforme PC est historiquement une horreur et c'est de pire en pire. Certes, ça marchote, mais à quel prix ? Si on veut une plateforme plus cohérente que l'écosystème actuel pour arm sous Linux, autant jeter UEFI et ACPI à la poubelle et choisir des choses moins absurdes. Enfin bon vu que tout le monde verrouille son bootloader et développe sa plateforme ARM comme un driver d'imprimante windows (gruik, fire and forget), j'ai du mal à voir comment ça pourrait arriver. Il faudrait qu'un core kernel hackeur tape une crise et impose de la propreté. (Malheureusement vu que Linus surkif le fait que tous les constructeurs mettent des DRM partout sur leur matos, on risque d'être durablement dans la merde)

Ça signifie qu'il y a uniquement $5k qui viennent d'ailleurs que Google pour Python3. Je pense qu'avec un peu de pub, ça pourrait monter plus haut.

Sans rentrer dans les détails, cela signifie a peu près la même chose que lorsque l'on remarque que gcc est une implémentation de C en C.

En rentrant un peu plus dans les détails (j'espère que je ne vais pas dire de connerie, je ne suis pas ce projet de très près), PyPy est une VM (avec un JIT généré d'une manière stylée, cf http://tratt.net/laurie/tech_articles/articles/fast_enough_vms_in_fast_enough_time ) écrite en RPython qui est un sous-ensemble de Python suffisamment souple pour écrire des choses intéressantes avec, et suffisamment restreint pour que de l'inférence de type des autres trucs funs soient possible, permettant la compilation en un code efficace.

Effectivement aujourd'hui tout le monde considère tristement cela.

Pourtant le code génétique d'Internet, et ce qui se passait réellement au bon vieux temps, c'est que les réseaux faisaient du routage IP et que le TCP était oppaque pour lui exactement au même titre que l'UDP ou le protocole perso que tu expérimentes entre ton garage et celui de ton pote.

Un problème basique de neutralité des réseaux.

C'est clair qu'il serait appréciable que les boites qui aujourd'hui mentent en se faisant passer pour des FAI (hint : 99.99% d'entre elles) annoncent clairement la couleur et disent qu'elles sont des fournisseurs d'accès UDP+TCP sur des ports bridés à leur discrétion, et qu'elles écoutent pour se faire toutes nos communications. Compliqué d'un point de vue marketing ? On peut pas avoir le beurre, l'argent du beurre, et le cul de la crémière à la fois.

Pas uniquement pour vmware. Pour tous. Ceci étant dit je suis bien conscient que je n'apporte aucun argument concret pour appuyer cette théorie.