Victor a écrit 1388 commentaires

Et bien peut-être qu'il n'y a pas assez de gens qui utilisent testing ?

Parce que je suis sûr que gnome a du y passer un peu de temps en testing avant d'arriver dans core/extra, et si le problème avait été vu, on est d'accord pour dire qu'ils ne l'auraient pas laisser passer, vu qu'il est si gros…

On tourne en rond : le fond du problème c'est que si personne ne fait le boulot, personne ne fera le boulot !

Bon, on va arrêter avec les « si tu vois ce que je veux dire » parce que en fait, je crois que tu vois pas ce que je veux dire, et moi je vois pas ce que tu veux dire.

Ce que je veux dire, c'est que si tu veux une distrib magique qui marche parfaitement mais que TU (toi ou celui qui se plaint) ne fait pas d'effort pour que cette distrib marche parfaitement (par exemple en payant les gens qui s'en occupent, puisque TU l'as proposé, ça vient pas de moi cette idée) alors tu te fais des films :)

Voilà, ce que je veux dire, c'est qu'il faut d'abord te bouger le cul et ensuite tu pourras te plaindre en expliquant que les mecs ils sont payés pour faire ça et que c'est des SALOOOWW ils testent pas avant.

Même si ça marche pas toujours, c'est un peu réducteur ce que tu dis là ;)

Bah ouais alors faudrait que quelqu'un leur file de la thune, si tu vois ce que je veux dire ? :D
Alors ceux qui se plaignent que Arch ne « fasse pas son boulot », qu'ils se sentent concernés.

Bon, de toute façon moi j'ai jamais dit que y'avait pas de problèmes avec Arch, juste que la situation actuelle m'allait bien et que pour le coup, le problème venait du noyau et que donc « ce qu'on voit ce qu'on veut dire ».

Et j'ajouterais à ça que perso j'ai pas de problèmes ou quasiment jamais, et quand j'en ai, bah je rapporte les bugs, je participe comme je peux (ou pas, et alors je me plains pas), epistoo!

Oui enfin bon, on est dans le monde du libre et de l'opensource : l'idée c'est quand même que les utilisateurs participent au processus de fabrication du logiciel comme il peuvent, et faire du betatesting, ça en fait parti !

Je suis pas sûr que les mecs qui maintiennent archlinux soient payés pour faire ça, si tu vois ce que je veux dire.

Bah c'est la faute des dev noyau qui ont sorti une nouvelle version buggée alors !

Moi je n'ai aucun problème !

On parle bien d'utiliser Gnome sur une install normale et à jour ?

C'est plutôt celui-là non ? http://www.bodum.com/fr/fr/shop/detail/11067-01/

Avec le piston intégré ?

Le problème c'est le café qu'on achète !

Ici au boulot on a des super machines à expresso… et on y met du grain de robusta à 5€ le kilo de chez Carrefour : bah c'est dégueulasse et on est au bord de la crise cardiaque à tout instant !

C'est pas facile de trouver des trucs bons et abordable (le café Illy, censé être le SUPER bon café italien, est surtout SUPER cher !), en iIalie les café de marque de distributeurs sont juste bons !

Pour faire du café, le mieux et pas cher, c'est une cafetière moka à l'italienne (mais avec du bon café hein !)
Tu peux t'en prendre une électrique (la marque phare italienne, bialetti, en a à 50€ quand même, faut un peu investir, mais des marques moins connues font moins cher… mais faut que la cafetière marche bien).

L'aéropress, ça donne envie, mais ça a l'air un peu chiant à utiliser… enfin c'est ce que j'avais ressenti en regardant des vidéos de test sur youtube quand on a commencé à en parler. J'avais le sentiment qu'il fallait beaucoup de manip' relous pour se faire un café.

Mais bon, dernièrement je réfléchis sérieusement à investir aussi :)

C'est pas vraiment pareil quand même… l'aeropress (jamais testé) est censé te donner quelque chose ressemblant à de l'expresso grâce à une pression très forte pour le passage de l'eau dans le café.

La cafetière à piston (french press) tu laisse le café tremper dans l'eau, puis tu pousses pour mettre le café de côté et ne garder que le café liquide.

Le goût est différent : un expresso (ou tout café où l'eau passe très rapidement dans le café) a très peu de caféine, alors qu'avec la french press, l'eau se gorge plus de caféine !

Par hélicoptère, et hop!

Oui je sais comment ça marche, je bosse aussi dans ce genre de trucs, mais ça reste quand même un problème ouvert de savoir comment gérer le "rejeu" quand certains des services humains ou informatique échouent à traiter un truc dans un processus plus grand.

Je dis pas que ce qui existe est nul, mais on doit pouvoir faire mieux certainement…

Enfin bon, toute la discussion était que c'est un changement de paradigme (qu'on l'appelle SOA, orienté messages, orienté acteur voire orienté agent), et que c'est pas ça qui va venir concurrencer la résolution du problème du typage d'une fonction :)

C'est une vision claire de pour quoi est fait python, mais alors moi ce qui m'échappe, c'est comment tu gères justement cette difficulté de fournir l'objet bien "formaté" à la méthode ?
Parce que pour des petits trucs c'est simple, mais dès qu'il y a un peu de complexité, tu te retrouves à ne plus savoir ce que doit fournir ton objet comme méthode, voire à devoir faire le même travail de filtrage (métier) de ta méthode pour savoir quelle méthodes doit avoir ton objet…

Ou alors après l'idée c'est "juste" de se reposer sur les tests pour faire cette détection ? Ce que je peux comprendre !

À noter aussi que des langages comme Scala ont du duck typing, appelé structural typing, où tu dis qu'une méthode ne peut prendre en paramètre qu'un objet qui a telle ou telle méthode ou particularité dans sa structure.
Évidemment ça a ses limites puisque tu ne peux pas "ajouter" des méthodes à l'objet en cours de vie, donc c'est l'utilisation du structural typing est un peu différent de l'utilisation du duck typing de Python (donc je raconte juste ça pour ajouter de l'information, pas pour infirmer ou réfuter quoi que ce soit).

Oui :)

Nan mais bien sûr, je parle justement de langages typés à la compilation !

Bon pour des string je sais pas, mais généralement, ce genre de fonction/méthode sont des utilitaires qui sont éprouvés par le temps, documentés et dont on a l'habitude.
En revanche pour du code plus métier qui touche à, par exemple, des fonctionnalités originales, c'est souvent des types un peu plus complexe qui sont passé en paramètre, ou simplement des modèles simples mais représentés par des types différents.
Le type représente la sémantique des paramètres, et le compilateur vérifie cette sémantique !
D'où l’intérêt du typage :)

Ouais enfin en disant ça, tu ré-inventes ce à quoi servent les types… sauf qu'au lieu de reposer sur une gestion de la cohérence de ton modèle qui se passe dans ta tête, les types ont toute une théorie mathématique qui permet de faciliter beaucoup de choses.

Je dis pas que python ou le typage dynamique c'est mal, mais juste que si tu te retrouves à réinventer le concept de types alors il y a un peut-être un problème dans ton choix de langage :)

En fait on parle pas de la même chose je pense : pour moi (et flan apparemment), on parle d'un cas d'utilisation où tu programmes une application où il y a par exemple une méthode/fonction appelée avec des arguments venant d'une source non contrôlée, genre un utilisateur : dans ce genre de cas, le paradigme mis en avant par Erlang ne sert à rien.

Toi tu parles d'une situation (théorique à mon gout) où comme un acteur envoi à une autre des arguments incorrects, il fait planter l'autre, mais l'autre et relancé et le premier acteur "apprend" (d'une façon ou d'une autre) de son erreur et ne recommence pas, ou on "change" le code de l'acteur qui a planté et ça recommence pas.

Mais bon, c'est bien joli dans la théorie, mais dans la pratique, toute la difficulté va être cet "apprentissage" dont je parle (et j'inclue là dedans un apprentissage simple tout comme un apprentissage complexe, je ne suis pas en train de parler d'IA hein) ou encore de gérer le fait que ce qui a déjà craché ne peut pas être oublié (parce que si c'est ta déclaration d'impôts qui a crashée, tu vas pas trop aimer que le worker qui devait la prendre en compte ait été redémarré et que, dans le pire des cas elle soit zappée, et dans le meilleur des cas tu doivent la refaire :)
Alors c'est sûr que la question de l’interprétation des paramètres devient secondaire dans ce cadre, mais c'est une autre discussion et tu peux pas juste dire : easy on va changer le paradigme et faire restarter les méthodes/fonctions qui crashent ou easy on va changer le code qui crash at runtime.

Et vraie question pas pour troller : ça apporte quoi d'utiliser python dans ce cadre ?

Mais si le code n'est pas buggué, ce n'est pas un problème.

"LOL"

Et pour avoir du code pas bugger il vaut mieux… le vérifier : tu peux la faire à la main, mais c'est quand même plus agréable d'allouer 100% de son cerveau à la logique métier plutôt que sur les problèmes de types ou de syntaxe :)

Oui enfin programmer en Erlang comme ça ça demande quand même d'organiser ton programme de façon complètement différente, c'est un autre paradigme de programmation et ça ne se prête pas à n'importe quelle application !

Design ça se traduit par conception, et policy par politique :)

Bon après pour le tout, va savoir comment le traduire sans que ça fasse pitié…

Oui c'est une réflexion très intelligente : au moins avec MS, les autres aussi paient, on est pas les seuls !

À la fin des comptes, si la France fait ça, elle aura déboursée autant pour un résultat bien plus pérenne, faut arrêter d'aller regarder si les autres en profitent ou pas ! On est bien content d'avoir des machines sous Linux qui marchent bien parce que certains des bugs ont été corrigés par des entreprises américaines ou russes.

Nan mais le problème c'est que dès qu'il y a UN seul spam, son serveur redirecteur est blacklisté donc bon…

Donc OVH, quand tu leur a posé le problème, t'a répondu d'aller te faire voir, c'est ça ?