Debian ? Mageia ? Est-ce que ce compte quand c'est l'inverse ? Tous les contributeurs qui jouent les bourrins comme les projets suckless ? Sinon tu as les projets Apache. Guido Van Rossum ou Larry Wall bien que taxé de "dictateurs" bienveillants sont plutôt diplomates il me semble (ou peut être qu'il se sont assagi, je sais Guido n'est plus du tout au commande).
L'univers des logiciels libres s'est construit avec des fortes têtes (coucou Theo de Raadt) et des communautés plus douce (salut Mageia).
On parle d'une machine qui a 40 ans. Il y a une forme de prescription. Quels sont les problèmes potentiels ?
quelqu'un peu aujourd'hui accéder à cette installation, ils ont pas modifiés leur mot de passe depuis donc il peut se connecter en tant qu'eux ?
ils continuent à réutiliser leur mot de passe un peu partout ? Du coup je peux accéder à leur compte github ? Et depuis 40 ans ils croisent les doigts qu'un blackhat n'est pas passé par là ?
Il aurait pu être courtois de les prévenir avant, mais d'un point de vu de sécurité le problème ne vient pas du travaille en question ni de la publication en question…
Tu parle de haveibeenpowned, mais on peut régulièrement trouver des publications des mot de passe faibles les plus souvent utilisés. En publiant ça, on publie beaucoup plus de mot de passe fonctionnant pour beaucoup plus de monde sur beaucoup plus de plateformes et actuels. Et personne ne vient pleurer « Vous avez publié mon mot de passe "azerty123" ! Vous vous rendez-compte de ce que vous faites ?! ».
Au passage si vraiment ça pose problème faudra éviter de republier la news 2 fois sur linuxfr par exemple (+ 1 sur le compte twitter) ;)
p/q2-q4* est une ouverture très connue aux échecs : Pion (p) devant la dame (q = queen) avance de deux cases, de la ligne 2 à la ligne 4 (q2-q4). Avec la notation moderne des échecs, on utilise plutôt **1. d4. Voir aussi les ouvertures fermées et semi‑fermées.
Ça me fait imaginer qu'on pourrait utiliser les algo de rubik's cube pour ça aussi…
Par contre les algo de rubik's ont un alphabet plus simple : uUdDrRlLfFbBmMeEsSxyz' → 22 (éventuellement on peut ajouter les parenthèses et les chiffres pour passer à 34).
Donc sur 8 caractère on a une entropie d'environ 36… (41 avec les parenthèses) et encore ça ne prend pas en compte la syntaxe (On ne verra pas de )(0Uu par exemple).
Pour le coup c'est eux qui ont publier leur mot de passe, encodé certes mais avec des techniques désuètes. Voir un whitehat les publier est sans le moindre doute, la moins pire des sanctions qu'ils encourraient.
L'erreur est humaine, mais internet n'oublie pas. À eux d'assumer ce problème.
Après on peut sans doute imaginer qu'après 40 ans ils ont changé leur mot de passe.
Donc pour faire simple :
qu’est-ce qui autorisait un chercheur a publier sa trouvaille sans demander leur avis aux intéressés ?
C'est eux qui ont publié leur mot de passe. Le chercheur n'a fait que traiter des données accessible publiquement et a rendu son travail publique.
A quel point la valeur historique/culturelle de ces mots de passe justifie son action ?
Montrer les usages à l'époque ?
Montrer comment on peut péter ces encodages ?
Montrer que publier ces mots de passe même encoder c'est belle idée de merde ?
Hé hé tu joue les blasé. Si tu n'y voyais si peux d'intérêt, tu n'aurais pas pris le temps d'en faire un journal ;)
Ton journal montre beaucoup de compétences utiles. Les partager au travers d'un cadre trivial permet à ceux qui s'y connaissent moins de découvrir et de pouvoir reproduire.
Toi tu t'es amusé tout en vérifiant qu'une partie du noyau fonctionne effectivement comme ton intuition l'imaginait
T'es lecteurs soir auront le même gain que toi, soit vingt découvrir des techniques et méthodes.
Ça a beaucoup plus d'intérêt que de passer le triple de temps pour savoir quel type de personne est RMS. En tout cas c'est mon point de vue
Je ne suis pas d'accord. La démarche est très cool. Jouer avec ce qui nous entour c'est le meilleur moyen de les comprendre et de se les approprier. C'est une excellente démarche en info comme dans tous les domaines (prendre le temps de regarder un peu plus en détail notre moyen de locomotion par exemple).
Après je ne suis pas très bière donc je ne cautionnerais pas :p
Pour la prochaine fois, pro-tip, c'est plus efficace de déposer un bug plutôt que se plaindre sur un forum sans vraiment vérifier…
Oui faut arrêtez de FUD à tout va avant même d'avoir cherché à comprendre.
Ça vaut pour créer des journaux, commenter ces journaux ou envoyer des tickets… Les gars ont suffisamment de travail sans avoir à se prendre ce genre de FUD puis devoir détricoter des allégations comme ça.
À partir du moment où on utilises un mot c'est qu'on en connait au moins une définition, parce qu'on comprend ce qu'on dit.
C'est tellement hors de propos… La question qui a générée ce thread c'est l'utilisation de mot qui n'ont pas de définition qui font référence… Bien sûr que tu donne un sens à tes mots. Tu donne même du sens à tes babillements. Mais ça n'est pas notre sujet.
Je répondais à quelqu'un qui se plaignait de l'utilisation de mots qui ne sont pas parfaitement défini en expliquant qu'on le fait tous. Rien de plus.
exception faite des hommes politiques et des journalistes
Comme toi, ils commentent sans se chercher à comprendre le sujet. Contrairement à toi, eux sont payés pour ça.
On fait trop souvent confusion entre le mot "Web" qui était un ensemble de protocoles et d'applications avec le seul nom d'une application nommée "Word Wide Web".
J'avais en tête qu'il y avait eu un glissement de web → internet à web → http/html.
En voulant vérifier je n'ai rien qui remontait à plus vieux que le document de T. Berners-Lee pour décrire le WorlWideWeb. Et ce que j'en comprends c'est que l'on appel "web" un ensemble de liens. Mais que le World Wide Web et du coup LE web, c'est bien http+html. Je ne pense pas qu'il s'agisse d'une confusion.
Gopher était bien un acteur du Web, parmi d'autres.
Je pense qu'il constituait et constitue encore un web en lui-même.
Il n'y a jamais eu d'hostilité, à l'époque, entre le monde Gopher et celui du www. "WWW" a remplacé Gopher de façon naturelle, pas à la suite d'une quelconque guerre.
C'est probablement plus subtile que ça. Le World Wide Web a pour objectif d'être totalement omniscient. T. Berners-Lee décrit les problèmes lié à la multiplication des plateformes incompatibles et propose de fournir un protocole unique pour n'avoir plus qu'un seul web. S'il ne s'agit pas d'une guerre, l'essence même du www est d'éliminer gopher et tout autre alternative.
Il dit que RHEL8 n’aura plus Python (2 ?) d’installé d’office (pas qu’il ne sera plus disponible !), et ça sera peut-être également le cas de Perl plus tard.
Perl est particulièrement populaire en administration système où il est utilisé pour faire des scripts shell en mieux. On peut le voir dans la communauté des mongueurs de perl une partie non négligeable de leur publication est dans ce domaine. On peut le voir aussi avec les agents et plugins nagios. Il ne sera peut être pas installé par défaut, mais je doute qu'il ne soit pas assez rapidement réinstallé par les admin au moins sur les serveurs RedHat :)
Il donne toute une série de signes négatifs sur la popularité de Perl : sa baisse quelle que soit la mesure (Google Trends, entre autres).
Ouai il va un peu vite. Je ne doute pas que Perl soit en perte de vitesse, mais j'aurais était intéressé de voir l'évolution du trafic sur les maillings lists et des contributions sur le langages. Ce sont des métriques plus pertinentes car nécessaire au langage et il me semble qu'elles ont moins de biais que ce qu'il présente. Cela donnerais amha une représentation bien plus clair d'à quel point il perd en popularité.
Ce qui est bien conçu/découpé, quitte en effet à faire peu mais bien et stable, n'a pas vraiment besoin de changer. Le changement ne vient alors que de nouveaux besoins à travers de nouvelles API.
Non malloc(3) en est l'exemple le plus criant. Il y a un tas d'API très simple qui ont posé problèmes et qui se sont donc fait remplacer ou ont dû évoluer.
Ce que je visais, c'est l'effet délétère de l'agile sur le développement informatique réfléchi en général. Un vrai carnage dès qu'il est sorti de son cadre initial (les IHM, essentiellement) pour arriver sur des fondamentaux plateforme.
J'adore les injonctions bien péremptoire comme ça. Tu as la vision totale et complète de ce qu'est un projet informatique de manière générale et tu sais ce qui est bien de ce qui ne l'est pas. Tous ceux qui n'allant pas dans ton sens étant dans l'erreur…
On est complètement dans la dichotomie de « la cathédrale et du bazar ». Les méthodes agiles servent à donner un cadre au bazar. Elles sont extrêmement pertinentes quand le demandeur du projet a du mal à formaliser son besoin. Il y a d'autres endroit où la cathédrale fait du sens, je ne remet pas du tout en cause ça.
Dans un monde parfait oui le versionnement suffirait, mais personne n'est capable de garantir qu'un changement ne va pas casser une compatibilité. Donc non changer une micro n'est jamais anodin pour un projet.
De même pour la stabilité des API l'esprit humain n'est pas capable de lire l'avenir donc tu n'a aucune garanti que l'API que tu décris est stable ou non. Ce qui tiens un peu mieux que les autres c'est les API qui font le minimum de choses.
En résumé: Les dépendances ont toujours été un problème, il va croissant avec les process généralisés ces 10 dernières années (totalement sortis de leur contexte initial, il faut le dire). Et en prime, aucun langage moderne ne sait plus s'en passer! De quoi expliquer le problème posé, certes, mais de là à le justifier…
J'ai rien compris… Pour la première partie je sais pas trop ce que tu veux dire. Pour la seconde, euh… Tu connais beaucoup de logiciels en C qui utilisent que la libc (qui ne permet pas de créer de thread) ? Ou qui n'utilisent que la libc + les appels système (ça te permet d'avoir des threads) ?
La gestion des dépendances est bien plus complexe que ce que tu semble croire. Beaucoup plus complexe.
Il y a généralement beaucoup de conflit entre des besoins différents par des gens différents.
le développeur
Son cheval de bataille c'est les fonctionnalités (c'est ce que les utilisateurs demandent).
C'est celui qui code l'appli. Il a un besoin primordial : gérer les dépendances en dehors du système. Il doit pouvoir avoir différentes versions d'une même bibliothèque sans détruire son système y compris un build de la version pas encore sorti.
Ensuite il a des besoins: comme l'envi de ne pas avoir à supporter des versions de dépendance toujours plus exotiques, ne pas être contraint par les cycles de vie de chaque SE et distributions, ne pas empaqueter des millions de fois son logiciel,…
opérationnel/admin sys
Lui quand on lui parle fonctionnalités, il voit nouveaux bugs.
Son besoin primordial c'est que les logiciels fonctionnent bien sur son système et pour ça il faut que le logiciel se plie totalement à son système. Donc utilise le système de packaging qui va bien, les dépendances du système uniquement, si vraiment une dépendance n'existe pas sur le système (pourquoi diable être allé chercher cette obscure dépendance ?) la packager séparément, etc
(évidemment j'exagère)
Les 2 points de vues ne sont pas réconciliables ils sont opposés. Le seul endroit où ça peut fonctionner c'est dans le cadre du devops où il n'y a qu'une seule cible de déploiement et les ops et les dev discutent. Aucun langage n'a résolu cette problématique, absolument aucun. Ni les vieux comme C ni les plus jeunes comme rust ou julia. Ceux qui te semblent avoir réussi ont juste privilégiés ton point de vue.
J'entends aussi (concernant le choix nodejs) c'est le même langage que le front : c'est faux !!!
En fait tu te concentre sur la technique, mais c'est pas le plus important là. Tu peux partager du code métier entre ton front et ton back et ça peut être très utile. Il peut facilement arriver qu'une logique implémenter coté client soit finalement plus utile dans le serveur et vice et versa.
Ça n'est pas compliqué d'avoir de la logique métier qui ne soit pas adhérente à ton framework (ça a aussi pleins de bonnes propriétés en particulier pour les tests) et ça te donne beaucoup de flexibilités d'évolutions.
Il n'a plus la hype, mais non il est encore très bien. Dango est une solution complète qui vient avec une opinion. Il t'expliquer comment accéder à ta base de données, comment faire de l'authentification, etc. Flask et les autres microframworks sont beaucoup plus petits, ils font donc bien moins de choses et on leur ajoute des plugins du coup.
Si ton but est de recréer un site web complet "classique" ou si tu veux être guidé, django est vraiment très bien. Si tu veux juste faire une API et que tu veux faire les choses à ta façon (possiblement mal) les microframworks sont là pour toi.
Tu retrouve la même dichotomie en ruby avec rail et synatra, en perl avec catalyst et dancer en java avec spring et vertx, en scala avec play et scalatra. Dédicace tout de même à python avec zope2 et java avec javaee d'avoir des trucs encore plus lourd.
Les pythonistes aiment bien taper sur les javaistes mais pourtant copient de plus en plus de choses des inférieurs :o La dernière en date est la syntaxe des annotations :)
Enfant on t'a appris à parler sans te faire ouvrir un dictionnaire et je présume que tu n'a pas remis en cause la définition de chaque mot que tu as appris à cette époque.
C'est marrant, c'est tout le contraire de mon enfance.
Tu as appris bien tardivement à parler.
Ah l'influençabilité (autre néologisme puisqu'on y est) par quelque algorithme.
Tu vois tu passe d'un terme neutre à un terme que tu veux politiser. Si j'ai appris une chose de linuxfr, c'est qu'il vaut que je me garde de parler politique sur linuxfr ^^1. Je laisse ceux qui ont pleins d'idées en faire la publicité.
il m'arrive encore de faire l'erreur, mais je finis toujours par le regretter ↩
Comme nous réécrivons l’API, c’est le moment de remettre en question le choix de Flask. D’où la découverte des nombreux nouveaux cadriciels web et l’envie d’écrire un journal pour partager.
Mon commentaire ne remet pas en cause le fais d'aller regarder autre chose. Pas mal de frameworks réactifs ont des fonctionnalités vraiment sympas et sont plutôt agréables à utiliser. On peut utiliser quelque chose de très performant pour des raisons autres que la performance ;)
Mais nos collègues développeurs Web aimeraient bien en profiter pour centraliser et rationaliser les API et avoir partout la même technologie : TypeScript et Node.js 😳
OSEF ? Le troll des langages c'est bien pour essayer d'amuser la galerie sur linuxfr, mais sorti de là ça n'a plus vraiment de sens. Tu regarde s'il y a des contraintes technologiques fortes, puis tu établi les procédés que tu souhaite mettre en place (performance, tests, qualité de code, que sais-je encore) et te regarde comment les mettre en place avec les langages proposés. Bref il y a moyen d'avoir une méthodologie pour répondre à cette question qui renvoie les remarques classiques aux cours de récréations d'écoles primaires.
Que valent ces bench ?
J'en sais rien, mais des graph comme ça ne veulent rien dire (mais bon la dépêche elle-même comporte les même biais).
« La performance » ça n'a pas de sens en soit. Ton besoin c'est quoi ? De fonctionner sur PI0 ? D'encaisser 10⁹⁹⁹⁹ requêtes/s ? De faire du temps réel dur ? Sans définir ton besoin de performance un bench n'est pas plus pertinent que de comparer les palettes de couleurs des sites des techno dont tu parle1.
Si tu veux répondre extrêmement vite, il vaut probablement mieux partir sur du C/C++/rust.
Si tu veux être en capacité d'encaisser énormément de requêtes, c'est une architecture reactive dont tu va avoir besoin (donc oui node, asgi, go, vertx, whatever).
etc
Après il faut aussi être humble, est-ce que ce que la charge que vous devez supporter est vraiment importante ? Aujourd'hui n'importe qui peut monter des infrastructures en recopiant ce que peuvent faire Instagram, Facebook, Google, Youtube,… pour gérer 20 requêtes/jour. C'est rigolo2, mais c'est typiquement de l'overengenering.
Que penser des nouveaux cadriciels Python ?
Qu'ils sont juste dans la veine actuelle. Tous les écosystèmes qui font du web sont entrain d'y passer. Ils ne sont ni les premiers ni particulièrement originaux.
La façon dont tu pose la question me donne l'impression que la performance n'est pas une vraie contrainte pour vous (tout du moins sur cette partie là). Vous ne virer flask que parce qu'on vous a dit qu'il y a quelque chose de plus hype et pas parce qu'il vous contraint. Donc pourquoi essayer de faire un choix en fonction de la perf alors que ça n'est pas si important ?
ça peut être un choix totalement assumé et c'est très bien. Mais alors le besoin ce n'est pas de faire de la performance, mais de s'amuser avec de la techno. ↩
[^] # Re: .
Posté par barmic 🦦 . En réponse au journal Du Rififi chez les gnous.... Évalué à 10.
Tout ça pour 4 utilisateurs, c'est vraiment un projet ouf !
Je taquine ne le pends pas mal 😛
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: .
Posté par barmic 🦦 . En réponse au journal Du Rififi chez les gnous.... Évalué à 6.
Debian ? Mageia ? Est-ce que ce compte quand c'est l'inverse ? Tous les contributeurs qui jouent les bourrins comme les projets suckless ? Sinon tu as les projets Apache. Guido Van Rossum ou Larry Wall bien que taxé de "dictateurs" bienveillants sont plutôt diplomates il me semble (ou peut être qu'il se sont assagi, je sais Guido n'est plus du tout au commande).
L'univers des logiciels libres s'est construit avec des fortes têtes (coucou Theo de Raadt) et des communautés plus douce (salut Mageia).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ethique ?
Posté par barmic 🦦 . En réponse à la dépêche Les mots de passe des premiers développeurs‐utilisateurs d’UNIX, notamment celui de Ken Thompson. Évalué à 2.
On parle d'une machine qui a 40 ans. Il y a une forme de prescription. Quels sont les problèmes potentiels ?
Il aurait pu être courtois de les prévenir avant, mais d'un point de vu de sécurité le problème ne vient pas du travaille en question ni de la publication en question…
Tu parle de haveibeenpowned, mais on peut régulièrement trouver des publications des mot de passe faibles les plus souvent utilisés. En publiant ça, on publie beaucoup plus de mot de passe fonctionnant pour beaucoup plus de monde sur beaucoup plus de plateformes et actuels. Et personne ne vient pleurer « Vous avez publié mon mot de passe "azerty123" ! Vous vous rendez-compte de ce que vous faites ?! ».
Au passage si vraiment ça pose problème faudra éviter de republier la news 2 fois sur linuxfr par exemple (+ 1 sur le compte twitter) ;)
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Rubik's
Posté par barmic 🦦 . En réponse à la dépêche Les mots de passe des premiers développeurs‐utilisateurs d’UNIX, notamment celui de Ken Thompson. Évalué à 2.
Ça me fait imaginer qu'on pourrait utiliser les algo de rubik's cube pour ça aussi…
Par contre les algo de rubik's ont un alphabet plus simple :
uUdDrRlLfFbBmMeEsSxyz'→ 22 (éventuellement on peut ajouter les parenthèses et les chiffres pour passer à 34).Donc sur 8 caractère on a une entropie d'environ 36… (41 avec les parenthèses) et encore ça ne prend pas en compte la syntaxe (On ne verra pas de
)(0Uupar exemple).https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ethique ?
Posté par barmic 🦦 . En réponse à la dépêche Les mots de passe des premiers développeurs‐utilisateurs d’UNIX, notamment celui de Ken Thompson. Évalué à 2.
Pour le coup c'est eux qui ont publier leur mot de passe, encodé certes mais avec des techniques désuètes. Voir un whitehat les publier est sans le moindre doute, la moins pire des sanctions qu'ils encourraient.
L'erreur est humaine, mais internet n'oublie pas. À eux d'assumer ce problème.
Après on peut sans doute imaginer qu'après 40 ans ils ont changé leur mot de passe.
Donc pour faire simple :
C'est eux qui ont publié leur mot de passe. Le chercheur n'a fait que traiter des données accessible publiquement et a rendu son travail publique.
Montrer les usages à l'époque ?
Montrer comment on peut péter ces encodages ?
Montrer que publier ces mots de passe même encoder c'est belle idée de merde ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Sympa !
Posté par barmic 🦦 . En réponse au journal Comment rendre le shebang plus festif. Évalué à 1.
lisp par exemple.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Sympa !
Posté par barmic 🦦 . En réponse au journal Comment rendre le shebang plus festif. Évalué à 4.
Hé hé tu joue les blasé. Si tu n'y voyais si peux d'intérêt, tu n'aurais pas pris le temps d'en faire un journal ;)
Ton journal montre beaucoup de compétences utiles. Les partager au travers d'un cadre trivial permet à ceux qui s'y connaissent moins de découvrir et de pouvoir reproduire.
Ça a beaucoup plus d'intérêt que de passer le triple de temps pour savoir quel type de personne est RMS. En tout cas c'est mon point de vue
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Sympa !
Posté par barmic 🦦 . En réponse au journal Comment rendre le shebang plus festif. Évalué à 10.
Je ne suis pas d'accord. La démarche est très cool. Jouer avec ce qui nous entour c'est le meilleur moyen de les comprendre et de se les approprier. C'est une excellente démarche en info comme dans tous les domaines (prendre le temps de regarder un peu plus en détail notre moyen de locomotion par exemple).
Après je ne suis pas très bière donc je ne cautionnerais pas :p
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Licence ?
Posté par barmic 🦦 . En réponse au journal Extension installée de force dans Thunderbird ?. Évalué à 4.
Oui faut arrêtez de FUD à tout va avant même d'avoir cherché à comprendre.
Ça vaut pour créer des journaux, commenter ces journaux ou envoyer des tickets… Les gars ont suffisamment de travail sans avoir à se prendre ce genre de FUD puis devoir détricoter des allégations comme ça.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Aucune majuscule
Posté par barmic 🦦 . En réponse au journal Les mots de passe des premiers développeurs/utilisateurs d'UNIX, notamment celui de Ken Thompson. Évalué à 1.
Je ne connais pas bien le qwerty, mais ils n'ont pas utilisé que des caractères en accès direct ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: indéchiffrable
Posté par barmic 🦦 . En réponse au journal Les mots de passe des premiers développeurs/utilisateurs d'UNIX, notamment celui de Ken Thompson. Évalué à 1.
Il y a aussi le lien wikipedia vers les ouvertures aux échecs qui est mal luné.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: H.S.: Youtube
Posté par barmic 🦦 . En réponse à la dépêche Portrait de Ken Thompson. Évalué à 3.
C'est tellement hors de propos… La question qui a générée ce thread c'est l'utilisation de mot qui n'ont pas de définition qui font référence… Bien sûr que tu donne un sens à tes mots. Tu donne même du sens à tes babillements. Mais ça n'est pas notre sujet.
Je répondais à quelqu'un qui se plaignait de l'utilisation de mots qui ne sont pas parfaitement défini en expliquant qu'on le fait tous. Rien de plus.
Comme toi, ils commentent sans se chercher à comprendre le sujet. Contrairement à toi, eux sont payés pour ça.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: web ou gopher
Posté par barmic 🦦 . En réponse au journal Site Gopher du magazine Taz. Évalué à 1.
J'avais en tête qu'il y avait eu un glissement de web → internet à web → http/html.
En voulant vérifier je n'ai rien qui remontait à plus vieux que le document de T. Berners-Lee pour décrire le WorlWideWeb. Et ce que j'en comprends c'est que l'on appel "web" un ensemble de liens. Mais que le World Wide Web et du coup LE web, c'est bien http+html. Je ne pense pas qu'il s'agisse d'une confusion.
Je pense qu'il constituait et constitue encore un web en lui-même.
C'est probablement plus subtile que ça. Le World Wide Web a pour objectif d'être totalement omniscient. T. Berners-Lee décrit les problèmes lié à la multiplication des plateformes incompatibles et propose de fournir un protocole unique pour n'avoir plus qu'un seul web. S'il ne s'agit pas d'une guerre, l'essence même du www est d'éliminer gopher et tout autre alternative.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Une distribution Linux sans Perl ?
Posté par barmic 🦦 . En réponse au lien Perl est-il un langage de programmation mourant ?. Évalué à 2.
Perl est particulièrement populaire en administration système où il est utilisé pour faire des scripts shell en mieux. On peut le voir dans la communauté des mongueurs de perl une partie non négligeable de leur publication est dans ce domaine. On peut le voir aussi avec les agents et plugins nagios. Il ne sera peut être pas installé par défaut, mais je doute qu'il ne soit pas assez rapidement réinstallé par les admin au moins sur les serveurs RedHat :)
Ouai il va un peu vite. Je ne doute pas que Perl soit en perte de vitesse, mais j'aurais était intéressé de voir l'évolution du trafic sur les maillings lists et des contributions sur le langages. Ce sont des métriques plus pertinentes car nécessaire au langage et il me semble qu'elles ont moins de biais que ce qu'il présente. Cela donnerais amha une représentation bien plus clair d'à quel point il perd en popularité.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Bazar!
Posté par barmic 🦦 . En réponse à la dépêche Python — partie 3 — Installation de Python et de paquets. Évalué à 1.
Non
malloc(3)en est l'exemple le plus criant. Il y a un tas d'API très simple qui ont posé problèmes et qui se sont donc fait remplacer ou ont dû évoluer.J'adore les injonctions bien péremptoire comme ça. Tu as la vision totale et complète de ce qu'est un projet informatique de manière générale et tu sais ce qui est bien de ce qui ne l'est pas. Tous ceux qui n'allant pas dans ton sens étant dans l'erreur…
On est complètement dans la dichotomie de « la cathédrale et du bazar ». Les méthodes agiles servent à donner un cadre au bazar. Elles sont extrêmement pertinentes quand le demandeur du projet a du mal à formaliser son besoin. Il y a d'autres endroit où la cathédrale fait du sens, je ne remet pas du tout en cause ça.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Bazar!
Posté par barmic 🦦 . En réponse à la dépêche Python — partie 3 — Installation de Python et de paquets. Évalué à 1.
Je ne suis pas d'accord.
Dans un monde parfait oui le versionnement suffirait, mais personne n'est capable de garantir qu'un changement ne va pas casser une compatibilité. Donc non changer une micro n'est jamais anodin pour un projet.
De même pour la stabilité des API l'esprit humain n'est pas capable de lire l'avenir donc tu n'a aucune garanti que l'API que tu décris est stable ou non. Ce qui tiens un peu mieux que les autres c'est les API qui font le minimum de choses.
J'ai rien compris… Pour la première partie je sais pas trop ce que tu veux dire. Pour la seconde, euh… Tu connais beaucoup de logiciels en C qui utilisent que la libc (qui ne permet pas de créer de thread) ? Ou qui n'utilisent que la libc + les appels système (ça te permet d'avoir des threads) ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Bazar!
Posté par barmic 🦦 . En réponse à la dépêche Python — partie 3 — Installation de Python et de paquets. Évalué à 2.
Bon je me lance…
La gestion des dépendances est bien plus complexe que ce que tu semble croire. Beaucoup plus complexe.
Il y a généralement beaucoup de conflit entre des besoins différents par des gens différents.
le développeur
Son cheval de bataille c'est les fonctionnalités (c'est ce que les utilisateurs demandent).
C'est celui qui code l'appli. Il a un besoin primordial : gérer les dépendances en dehors du système. Il doit pouvoir avoir différentes versions d'une même bibliothèque sans détruire son système y compris un build de la version pas encore sorti.
Ensuite il a des besoins: comme l'envi de ne pas avoir à supporter des versions de dépendance toujours plus exotiques, ne pas être contraint par les cycles de vie de chaque SE et distributions, ne pas empaqueter des millions de fois son logiciel,…
opérationnel/admin sys
Lui quand on lui parle fonctionnalités, il voit nouveaux bugs.
Son besoin primordial c'est que les logiciels fonctionnent bien sur son système et pour ça il faut que le logiciel se plie totalement à son système. Donc utilise le système de packaging qui va bien, les dépendances du système uniquement, si vraiment une dépendance n'existe pas sur le système (pourquoi diable être allé chercher cette obscure dépendance ?) la packager séparément, etc
(évidemment j'exagère)
Les 2 points de vues ne sont pas réconciliables ils sont opposés. Le seul endroit où ça peut fonctionner c'est dans le cadre du devops où il n'y a qu'une seule cible de déploiement et les ops et les dev discutent. Aucun langage n'a résolu cette problématique, absolument aucun. Ni les vieux comme C ni les plus jeunes comme rust ou julia. Ceux qui te semblent avoir réussi ont juste privilégiés ton point de vue.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Et Django?
Posté par barmic 🦦 . En réponse au journal Python pour la rentrée 2019 - Hors Série - Python revient dans la course face à Node.js. Évalué à 0.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Et Django?
Posté par barmic 🦦 . En réponse au journal Python pour la rentrée 2019 - Hors Série - Python revient dans la course face à Node.js. Évalué à 4.
En fait tu te concentre sur la technique, mais c'est pas le plus important là. Tu peux partager du code métier entre ton front et ton back et ça peut être très utile. Il peut facilement arriver qu'une logique implémenter coté client soit finalement plus utile dans le serveur et vice et versa.
Ça n'est pas compliqué d'avoir de la logique métier qui ne soit pas adhérente à ton framework (ça a aussi pleins de bonnes propriétés en particulier pour les tests) et ça te donne beaucoup de flexibilités d'évolutions.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: [aiohttp|flask|bottle|pyramid] + hapic + [marshmallow|serpyco]
Posté par barmic 🦦 . En réponse au journal Python pour la rentrée 2019 - Hors Série - Python revient dans la course face à Node.js. Évalué à 2.
C'était uniquement pour la symétrie. OSEF qui aurait inventé ou pas ce genre de choses.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Et Django?
Posté par barmic 🦦 . En réponse au journal Python pour la rentrée 2019 - Hors Série - Python revient dans la course face à Node.js. Évalué à 7.
Il n'a plus la hype, mais non il est encore très bien. Dango est une solution complète qui vient avec une opinion. Il t'expliquer comment accéder à ta base de données, comment faire de l'authentification, etc. Flask et les autres microframworks sont beaucoup plus petits, ils font donc bien moins de choses et on leur ajoute des plugins du coup.
Si ton but est de recréer un site web complet "classique" ou si tu veux être guidé, django est vraiment très bien. Si tu veux juste faire une API et que tu veux faire les choses à ta façon (possiblement mal) les microframworks sont là pour toi.
Tu retrouve la même dichotomie en ruby avec rail et synatra, en perl avec catalyst et dancer en java avec spring et vertx, en scala avec play et scalatra. Dédicace tout de même à python avec zope2 et java avec javaee d'avoir des trucs encore plus lourd.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: [aiohttp|flask|bottle|pyramid] + hapic + [marshmallow|serpyco]
Posté par barmic 🦦 . En réponse au journal Python pour la rentrée 2019 - Hors Série - Python revient dans la course face à Node.js. Évalué à 1.
Les pythonistes aiment bien taper sur les javaistes mais pourtant copient de plus en plus de choses des inférieurs :o La dernière en date est la syntaxe des annotations :)
cf
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: H.S.: Youtube
Posté par barmic 🦦 . En réponse à la dépêche Portrait de Ken Thompson. Évalué à 5.
Tu as appris bien tardivement à parler.
Tu vois tu passe d'un terme neutre à un terme que tu veux politiser. Si j'ai appris une chose de linuxfr, c'est qu'il vaut que je me garde de parler politique sur linuxfr
^^1. Je laisse ceux qui ont pleins d'idées en faire la publicité.il m'arrive encore de faire l'erreur, mais je finis toujours par le regretter ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Performance
Posté par barmic 🦦 . En réponse au journal Python pour la rentrée 2019 - Hors Série - Python revient dans la course face à Node.js. Évalué à 2.
Mon commentaire ne remet pas en cause le fais d'aller regarder autre chose. Pas mal de frameworks réactifs ont des fonctionnalités vraiment sympas et sont plutôt agréables à utiliser. On peut utiliser quelque chose de très performant pour des raisons autres que la performance ;)
De rien :)
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Performance
Posté par barmic 🦦 . En réponse au journal Python pour la rentrée 2019 - Hors Série - Python revient dans la course face à Node.js. Évalué à 10.
OSEF ? Le troll des langages c'est bien pour essayer d'amuser la galerie sur linuxfr, mais sorti de là ça n'a plus vraiment de sens. Tu regarde s'il y a des contraintes technologiques fortes, puis tu établi les procédés que tu souhaite mettre en place (performance, tests, qualité de code, que sais-je encore) et te regarde comment les mettre en place avec les langages proposés. Bref il y a moyen d'avoir une méthodologie pour répondre à cette question qui renvoie les remarques classiques aux cours de récréations d'écoles primaires.
J'en sais rien, mais des graph comme ça ne veulent rien dire (mais bon la dépêche elle-même comporte les même biais).
« La performance » ça n'a pas de sens en soit. Ton besoin c'est quoi ? De fonctionner sur PI0 ? D'encaisser 10⁹⁹⁹⁹ requêtes/s ? De faire du temps réel dur ? Sans définir ton besoin de performance un bench n'est pas plus pertinent que de comparer les palettes de couleurs des sites des techno dont tu parle1.
Si tu veux répondre extrêmement vite, il vaut probablement mieux partir sur du C/C++/rust.
Si tu veux être en capacité d'encaisser énormément de requêtes, c'est une architecture reactive dont tu va avoir besoin (donc oui node, asgi, go, vertx, whatever).
etc
Après il faut aussi être humble, est-ce que ce que la charge que vous devez supporter est vraiment importante ? Aujourd'hui n'importe qui peut monter des infrastructures en recopiant ce que peuvent faire Instagram, Facebook, Google, Youtube,… pour gérer 20 requêtes/jour. C'est rigolo2, mais c'est typiquement de l'overengenering.
Qu'ils sont juste dans la veine actuelle. Tous les écosystèmes qui font du web sont entrain d'y passer. Ils ne sont ni les premiers ni particulièrement originaux.
La façon dont tu pose la question me donne l'impression que la performance n'est pas une vraie contrainte pour vous (tout du moins sur cette partie là). Vous ne virer flask que parce qu'on vous a dit qu'il y a quelque chose de plus hype et pas parce qu'il vous contraint. Donc pourquoi essayer de faire un choix en fonction de la perf alors que ça n'est pas si important ?
c'est évidement éxagéré ↩
ça peut être un choix totalement assumé et c'est très bien. Mais alors le besoin ce n'est pas de faire de la performance, mais de s'amuser avec de la techno. ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll