Je vois plusieurs problème potentiels avec ce code :
le test dépend de requêtes HTTP externes, ce qui introduit certainement beaucoup de variabilité, potentiellement plus grande que celle entre threads et green threads
la méthode pour faire ces requêtes n'est pas la même
tu ne mesures pas vraiment green thread vs thread système, mais asyncio vs threads systèmes en Python. Bon, pas le choix que de tester des implems existantes, mais peut-être que l'asynchrone Python n'est pas très performant par exemple, alors que peut-être que ce n'est pas une limite théorique des green threads (je ne connais pas très bien les green threads ni asyncio cela dit)
de ce que je comprends du code, tu ne lisses pas les résultats en exécutant plusieurs fois les tests, dans des ordres différents (tu risques de "chauffer" et donc favoriser le deuxième test en exécutant le premier d'une manière ou d'une autre, donc il est important d'alterner les tests)
Cela dit, ton résultat ne m'étonne pas : je m'attends à ce qu'un processus parallélisable s'exécute plus vite sur plusieurs threads systèmes que sur plusieurs green threads placés sur un seul thread système : il n'y a pas de parallélisme dans ce cas ! :-) Et c'est probablement ce que fait ressortir ton test.
Les vraies questions à mon avis seraient plutôt :
est-ce que si on implémente intelligemment les green threads sur plusieurs threads systèmes (éventuellement, en fixant ces threads sur des cœurs), on peut gagner en perf (en utilisant X green threads sur N cœurs versus X threads systèmes sur N cœurs) ?
est-ce que pour un ensemble de tâches non parallélisables / non parallélisées, on arrive à une meilleure perf avec plusieurs plusieurs green threads sur un seul thread système versus plusieurs threads systèmes sur un seul cœur ?
j'imagine que Barmic à plus ça en tête. Effectivement, il est possible que le "switch" soit plus léger au moins dans ce deuxième cas, voire dans le premier si c'est bien gérer (mais le risque dans le premier cas c'est de se payer aussi les context switch des threads systèmes en plus de entre les green threads si c'est mal géré…).
je ne pense pas que ça reste isolé à mon cercle de connaissance
Eh bien… regarde ici : on commente sur une dépêche dont 12 personnes ont participé à l'écriture, pertinentée par au moins 34 personnes en l'espace de 2 jours.
Peut-être que c'est mal vu / puni de montrer de l'intérêt pour PHP dans ton entourage alors les gens n'osent peut-être pas (franchement, perso, j'ai pas mal observé ça - par défaut quand tu lances une discussion sur PHP, on te fait comprendre que c'est nul, qu'il ne faut pas utiliser ça, X c'est mieux, etc (au moins parce qu'il est convenable de le faire) - sauf quand tu critiques négativement le langage, là tu gagnes du karma facilement - donc tu ignores ces remarques et parfois les gens t'écoutent quand même, ou alors c'est parfois juste plus simple de parler d'autre chose surtout quand tu connais plein d'autres trucs, en particulier des langages bien vus, sinon tu te tais, ça marche aussi ; selon les milieux, ça peut arriver avec Javascript aussi), ou gens n'ont effectivement pas d'intérêt, ou, simplement, les langages dont vous parlez sont plus récents, ou popularisent / rendent pratiques des concepts qui ne l'étaient pas avant ; quelque part, PHP c'est « ennuyeux », tout existe ailleurs alors pourquoi s'y attarder ?
Mais ici, c'est clair, il y a des gens qui montrent de l'intérêt et/ou de la curiosité pour PHP, y compris des gens qui connaissent, apprécient et pratiquent - parfois principalement - d'autres langages au quotidien, occasionnellement ou précédemment ; et des discussions intéressantes sur PHP peuvent avoir lieu :-)
Je comprends la frustration et le dérapage de barmic, notre interlocuteur a quand même plus ou moins fait comprendre à tous les participants de ce fil de discussion, et à une partie de ses lecteurs, et de ses lectrices…
je dirais qu'un dev qui va promouvoir PHP est un dev qui n'a eu que très peu d'autres expériences de langages (ou alors sur des trucs tellement plus archaïque qu'il n'est pas vraiment objectif).
Dire le contraire c'est ce voiler la face.
… qu'on était inexpérimentés / qu'on se voilait la face. Ce qui est peut-être vrai après tout mais bof. Comme communication bienveillante et ouverte, on a vu mieux et ça manque incroyablement d'humilité. Maintenant, même effectivement si elle m'a bien fait rire, cette remarque de barmic est déplacée et c'est bien d'avertir. Merci !
Globalement je pense qu'on peut arrêter ce débat ici, ça fait un moment qu'il est devenu stérile et ça commence sérieusement à tourner en boucle. Circulez, il n'y a plus rien à voir.
vu que le PHP des début ne ressemble à presque plus rien de ce qu'il est actuellement… je serais au commande, je ferais évoluer PHP pour que ça soit 100% compatible Python3 à la version 10
Je n'espère pas, mon code PHP d'il y a 10 ans tourne sans modification sur les dernières versions de PHP, pour faire du Python, j'ai déjà… Python :-)
conçu un feu langage syntaxiquement proche de php nommé hack
Oui, beaucoup d'efforts pour "rester" sur PHP (ou un truc qui en est proche) ;-).
Peut-être que c'est parce qu'à ce moment là, la quantité de code PHP devenait trop grande pour migrer cela dit.
OwnCloud a clairement choisi PHP car on ouvre plus d'hébergement LAMP que python, perl ou ruby.
tout ce fait à l’exécution et non en amont et finalement si on veut vérifier du typage avant la mise en prod, on s'appuie sur l'IDE
Comment ça ? En Python par exemple, les annotations de types sont ignorées à l'exécution, et on peut lancer mypy en ligne de commande sans problème sans passer par un IDE pour vérifier le typage ?
la syntaxe juste imbuvable quand on a connu d'autres choses
J'ai connu d'autres choses et d'autres langages, et ce n'est pas mon sentiment. Mais ne nous arrêtons pas à des sentiments et constatons : tout porte à croire que Facebook, Wordpress, Wikipedia, Nextcloud, et plein d'autres projets continuent à bien évoluer malgré (grâce à ?) PHP. On est loin du site amateur ! Ces projets auraient-ils dû choisir un autre langage ?
Je ne comprends pas cette haine contre PHP. Malgré ses défauts (il en a plein), il permet de construire à la fois facilement des sites amateurs et de faire tourner certains des sites les plus visités du monde, ce n'est quand même pas rien.
Et si Wikipedia (2001) et Wordpress (2003) existent depuis longtemps et changer de langage pourrait être difficile pour ces projets, Facebook aurait certainement eu les moyens de faire des réécritures si PHP avait été un gros frein à son développement et ownCloud, en 2010, aurait pu choisir Python (c'était la version 2.7, pas trop mal !).
Rejeter ce langage d'un revers de manche parait un peu réducteur.
Finalement, j'ai l'impression qu'il y a une tendance un peu commune, en tout cas dans les langages de scripts répandus, notamment sur des notations de types de plus en plus utiles et puissantes, qui dépassent (enfin ?) ce que permet le C (pas tant de choses que ça finalement), et notamment en permettant les unions. Et c'est bien que ces langages de script répandus intègrent ça, parce que c'est rapidement inconfortable dans un gros projet de ne pas les avoir. Les gens qui s'occupent de ces langages en ont conscience et le montrent (enfin !).
Aussi, j'ai l'impression que PHP reprend des bonnes idées d'autres langages : les paramètres nommés de Python, le startsWith / endsWidth de Java / Javascript, le WeakMap et l'opérateur de chainage de Javascript, les notations de types de mypy / Typescript, le match venant des langages fonctionnels et récemment adopté par Python, bien plus lisible, adapté, clair, concis et moins casse gueule qu'un switch dans beaucoup de situations. Je salue aussi les paramètres constructeurs, je trouve les langages orientés objets tellement ennuyeux et lourdauds sans…
Une petite mention pour la possibilité d'utiliser mixed, ça m'avait manqué quand j'avais essayé d'utiliser les annotations de types en PHP.
Bref, ces petits changements qui améliorent la vie ces derniers temps dans les langages de programmations répandus, même si je n'utilise pas PHP tous les jours, m'enthousiasment pas mal, et franchement, je ne sais pas pour vous, mais chaque nouvelle version de PHP semble arriver avec son lot de bonnes surprises, de bons choix et le langage semble évoluer vite.
Finalement, PHP deviendrait presque plus sérieux et agréable que Javascript, pourtant il y avait du chemin : il a un match, des paramètres nommés, des notations de types (accessibles uniquement dans les projets qui ont décidés de passer à Typescript) !
C'est un langage qui continue à exceller dans son rôle original de moteur de templates HTML facile à déployer (quel bonheur de ne pas devoir configurer et démarrer un service par application et de pouvoir laisser le serveur HTTP gérer les URLs - que ce soit en tant que développeur ou utilisateur - un plaisir pour la maintenance d'un service), avec de plus en plus tous les outils qu'on trouve dans les langages de programmation modernes. Franchement, ça donne envie de s'y remettre.
Prochaine étape : la gestion de l'ownership / du borrowing dans les langages de scripts répandus !
Ou, sur un environnement de bureau moderne, tu recherches "Chromium" dans le menu, ça se rend compte qu'il n'est pas installé, ça te propose "Installer Chromium", tu cliques et ça s'installe. Imbattable.
Le 12 décembre 2018 TheFatRat reçoit un "Copyright Claim", c'est-à-dire qu'une requête a été envoyée à YouTube pour signaler que la vidéo de sa musique "The Calling" contient des médias dont il n'a pas les droits. Il s'avère que le "Copyright Claim" indique que sa musique ressemble trop à un remix de cette même musique, publié par un fan à posteriori et contreviendrai au droit d'auteur. La situation est ubuesque, surtout que ce n'est pas le remixeur qui a envoyé la requête mais une société du nom de "Ramjets Group" qui fait des "Copyright Claim" frauduleux afin de récupérer les droits et les revenus publicitaires de diverses musiques ne leur appartenant pas. TheFatRat engage une procédure judiciaire et récupère finalement les droits de sa musique, de plus, la musique "The Calling" est sous licence Creative Commons ce qui avait permis au remixeur de faire son œuvre dérivée. Il a aussi publié une vidéo dénonçant les failles de ContentID, le robot de YouTube permettant d'identifier les contenus sous droits d'auteur, ainsi que de l'incapacité de la plateforme à régler les conflits relatifs aux droits d'auteur quand il a vu que le litige ne se résolvait pas et lancé une pétition qui a recueilli plus de 100 000 signatures.
Incident du 12 mai 2019
Le 12 mai 2019, 5 mois après l'incident du 12 décembre 2018, le musicien TheFatRat voit sa chaine YouTube supprimée pour raison de "Manquements graves ou répétés aux règles de YouTube concernant le spam, les pratiques trompeuses et les contenus mensongers, ou d'autres infractions aux conditions d'utilisation.". Après discussion avec YouTube, la chaîne de TheFatRat est à nouveau en ligne depuis le matin du 13 mai 2019[réf. souhaitée].
Et l'astuce qu'il est obligé d'appliquer pour ne plus avoir de problème avec ContentID, par exemple sur un de ses morceaux :
Rule The World is 👉 FREE to use on YouTube. HOWEVER TO PROTECT YOU FROM INVALID CLAIMS YOU WILL GET A CLAIM FROM MY MCN "THE DISTRICT". You can dispute that claim, saying you have a license, and then simply put "TheFatRat" (without parentheses) into the note section. No further explanation needed. In addition please make sure to credit me properly and add the link to this video. The claim will be released and you can monetize the video yourself. Also you won't lose any revenue that's made between the claim and the release. YouTube holds it back for you.
Ça a l'air dur, de faire de la musique libre sur YouTube… tout semble adapté et pensé autour de l'industrie classique…
Le choix précis du nombre de lettres et de leur score est dérivé d'une analyse fréquentielle, mais n'est-il pas, lui, spécifique au Scrabble ? Qu'est-ce qui, au regard de la loi / du droit d'auteur / des marques le différencie-t-il de la disposition des lettres/mots compte double/triple sur le plateau ?
Attention avec Thunderbird, le jour où le profil est planté ça peut être un peu pénible. Avec des sauvegardes du profil Thunderbird ça peut se faire, faut bien garder à l'esprit qu'une fois qu'un profil est ouvert avec une version récente de Thunderbird, l'ouverture avec des ancienne version de Thunderbird est bloquée. On peut contourner mais la réussite n'est bien sûr pas garantie.
J'avais récupéré localement le contenu complet d'une boite mail avant sa destruction avec un outil en ligne de commande. Je crois que c'était OfflineIMAP. Il est peut-être possible d'ouvrir le résultat avec Thunderbird mais je n'ai pas essayé.
Je développe pas mal avec les technos du web. En perso, principalement parce que ça permet de donner une URL aux gens et ils n'ont besoin de rien installer.
Effectivement on peut faire des trucs jolis avec HTML / CSS / JS et c'est un aspect que j'aime bien. Par contre attention au manque de composants standards, surtout quand on vient d'une boîte à outils comme Qt. On se retrouve vite à réinventer la roue dans chaque nouveau projet, ou devoir embarquer une bibliothèque lourde. Ext.js semble fournir des composants comme pourrait s'attendre quelqu'un qui a fait du Qt. Je n'ai jamais essayé. Ils n'ont pas l'air de surfer sur le modèle du DOM virtuel ou équivalent (faut dire qu'ils sont apparus avant), cher aux dev frontend d'aujourd'hui, mais peut être que quand on n'a pas besoin de recoder le monde entier, c'est moins important.
Si, c'est ce que j'ai voulu dire par "quantité […] de code exécuté" (en nombre d'instructions). Pour une boucle, ça tiendrait compte du nombre d'itérations par ex. Mais la phrase était ambiguë, on aurait pu comprendre la taille du code en nombre de caractères.
En particulier, l'EFF estime que les références aux 3 vidéos dans le code mentionné par la requête DMCA rentreraient dans le cadre du « fair use » (grosso modo récupérer une copie ne veut pas dire enfreindre un copyright). GitHub et l'EFF estiment que youtube-dl a par ailleurs plein d'usages légitimes et légaux. Du coup, ce code aurait même pu rester tel quel et sa présence dans l'historique ne serait même pas un problème. On peut supposer que les avocats de la RIAA sont experts en la matière et comprennent parfaitement bien ces subtilités, ce qui poussent certains à affirmer qu'ils ont peut être testé les limites, « tenté le coup » en sachant très bien que l'argumentation était essentiellement bidon. Mais bon, bien sûr, retirer le code permet de « montrer » que des efforts sont faits, avec bonne foi et c'est utile pour ça. Ça rend plus « défendable » dans tous les cas, parce que l'intention compte dans le système légal.
Je n'aime pas GitHub mais je trouve leur gestion de cette affaire raisonnable voire exemplaire sachant qu'ils renforcent leurs procédures pour mieux gérer ce genre de cas à l'avenir et éviter que des requêtes DMCA permettent trop facilement de bloquer un dépôt. Alors c'est peut être en réponse à une grosse protestation, et ils cherchent peut-être à limiter la mauvaise pub lié à cet évènement voire à en tirer une bonne pub, mais pour moi ça marche, d'autant que s'ils appliquent ce qu'ils disent, ce n'est pas juste des paroles. Ils ont écouté.
Je ne sais pas s'ils auraient pu mieux gérer cette histoire en restant dans les clous de la loi. Ils auraient pu appliquer les améliorations qu'ils présentent dans leur article de blog, mais « hindsight is 20/20 » ça parait concevable et compréhensible qu'ils n'avaient pas anticipé ce genre de chose.
Avec une couleur et/ou un icône, et un texte « INUTILEMENT LOURD ».
Ou qu'à partir d'une certaine quantité calculée intelligemment de données transférée ou de code exécuté, le navigateur pause le chargement et affiche un message du style « Cette page consomme beaucoup de ressources. Elle vous oblige à remplacer votre matériel un peu ancien mais toujours capable par un supercalculateur et vous fait subir malgré tout des lenteurs, des saccades, une autonomie réduite, l'abîme en le faisant chauffer, consomme votre forfait internet alors que c'est vous qui le payez et vous fait attendre inutilement. Voulez-vous continuer le chargement ? »
On peut toujours rêver…
(bien sûr, il y a des cas où un site consomme légitimement des ressources, par exemple une application dans laquelle on fait de la vidéo / visio, donc c'est quand même compliqué).
[^] # Re: Des bonnes idées
Posté par raphj . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 2. Dernière modification le 06 décembre 2020 à 19:04.
Je vois plusieurs problème potentiels avec ce code :
Cela dit, ton résultat ne m'étonne pas : je m'attends à ce qu'un processus parallélisable s'exécute plus vite sur plusieurs threads systèmes que sur plusieurs green threads placés sur un seul thread système : il n'y a pas de parallélisme dans ce cas ! :-) Et c'est probablement ce que fait ressortir ton test.
Les vraies questions à mon avis seraient plutôt :
j'imagine que Barmic à plus ça en tête. Effectivement, il est possible que le "switch" soit plus léger au moins dans ce deuxième cas, voire dans le premier si c'est bien gérer (mais le risque dans le premier cas c'est de se payer aussi les context switch des threads systèmes en plus de entre les green threads si c'est mal géré…).
[^] # Re: Des bonnes idées
Posté par raphj . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 2.
À la compilation (ou en lançant le vérificateur de type - mypy) ça ne me parait pas déconnant si tu n'utilises pas d'IDE.
[^] # Re: Des bonnes idées
Posté par raphj . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 3.
Il l'a surtout complémenté, dans beaucoup de cas. Il y a souvent Apache derrière Nginx.
[^] # Re: Des bonnes idées
Posté par raphj . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 3.
D'ailleurs, tes réponses sont intéressantes !
[^] # Re: Des bonnes idées
Posté par raphj . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 3. Dernière modification le 30 novembre 2020 à 23:31.
Eh bien… regarde ici : on commente sur une dépêche dont 12 personnes ont participé à l'écriture, pertinentée par au moins 34 personnes en l'espace de 2 jours.
Peut-être que c'est mal vu / puni de montrer de l'intérêt pour PHP dans ton entourage alors les gens n'osent peut-être pas (franchement, perso, j'ai pas mal observé ça - par défaut quand tu lances une discussion sur PHP, on te fait comprendre que c'est nul, qu'il ne faut pas utiliser ça, X c'est mieux, etc (au moins parce qu'il est convenable de le faire) - sauf quand tu critiques négativement le langage, là tu gagnes du karma facilement - donc tu ignores ces remarques et parfois les gens t'écoutent quand même, ou alors c'est parfois juste plus simple de parler d'autre chose surtout quand tu connais plein d'autres trucs, en particulier des langages bien vus, sinon tu te tais, ça marche aussi ; selon les milieux, ça peut arriver avec Javascript aussi), ou gens n'ont effectivement pas d'intérêt, ou, simplement, les langages dont vous parlez sont plus récents, ou popularisent / rendent pratiques des concepts qui ne l'étaient pas avant ; quelque part, PHP c'est « ennuyeux », tout existe ailleurs alors pourquoi s'y attarder ?
Mais ici, c'est clair, il y a des gens qui montrent de l'intérêt et/ou de la curiosité pour PHP, y compris des gens qui connaissent, apprécient et pratiquent - parfois principalement - d'autres langages au quotidien, occasionnellement ou précédemment ; et des discussions intéressantes sur PHP peuvent avoir lieu :-)
[^] # Re: Des bonnes idées
Posté par raphj . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 2. Dernière modification le 30 novembre 2020 à 21:46.
Je comprends la frustration et le dérapage de barmic, notre interlocuteur a quand même plus ou moins fait comprendre à tous les participants de ce fil de discussion, et à une partie de ses lecteurs, et de ses lectrices…
… qu'on était inexpérimentés / qu'on se voilait la face. Ce qui est peut-être vrai après tout mais bof. Comme communication bienveillante et ouverte, on a vu mieux et ça manque incroyablement d'humilité. Maintenant, même effectivement si elle m'a bien fait rire, cette remarque de barmic est déplacée et c'est bien d'avertir. Merci !
Globalement je pense qu'on peut arrêter ce débat ici, ça fait un moment qu'il est devenu stérile et ça commence sérieusement à tourner en boucle. Circulez, il n'y a plus rien à voir.
[^] # Re: Des bonnes idées
Posté par raphj . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 4.
Je n'espère pas, mon code PHP d'il y a 10 ans tourne sans modification sur les dernières versions de PHP, pour faire du Python, j'ai déjà… Python :-)
[^] # Re: Des bonnes idées
Posté par raphj . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 3. Dernière modification le 30 novembre 2020 à 07:21.
Oui, beaucoup d'efforts pour "rester" sur PHP (ou un truc qui en est proche) ;-).
Peut-être que c'est parce qu'à ce moment là, la quantité de code PHP devenait trop grande pour migrer cela dit.
Bon point !
[^] # Re: Des bonnes idées
Posté par raphj . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 8.
Comment ça ? En Python par exemple, les annotations de types sont ignorées à l'exécution, et on peut lancer mypy en ligne de commande sans problème sans passer par un IDE pour vérifier le typage ?
J'ai connu d'autres choses et d'autres langages, et ce n'est pas mon sentiment. Mais ne nous arrêtons pas à des sentiments et constatons : tout porte à croire que Facebook, Wordpress, Wikipedia, Nextcloud, et plein d'autres projets continuent à bien évoluer malgré (grâce à ?) PHP. On est loin du site amateur ! Ces projets auraient-ils dû choisir un autre langage ?
Je ne comprends pas cette haine contre PHP. Malgré ses défauts (il en a plein), il permet de construire à la fois facilement des sites amateurs et de faire tourner certains des sites les plus visités du monde, ce n'est quand même pas rien.
Et si Wikipedia (2001) et Wordpress (2003) existent depuis longtemps et changer de langage pourrait être difficile pour ces projets, Facebook aurait certainement eu les moyens de faire des réécritures si PHP avait été un gros frein à son développement et ownCloud, en 2010, aurait pu choisir Python (c'était la version 2.7, pas trop mal !).
Rejeter ce langage d'un revers de manche parait un peu réducteur.
# Des bonnes idées
Posté par raphj . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 10. Dernière modification le 29 novembre 2020 à 00:03.
Finalement, j'ai l'impression qu'il y a une tendance un peu commune, en tout cas dans les langages de scripts répandus, notamment sur des notations de types de plus en plus utiles et puissantes, qui dépassent (enfin ?) ce que permet le C (pas tant de choses que ça finalement), et notamment en permettant les unions. Et c'est bien que ces langages de script répandus intègrent ça, parce que c'est rapidement inconfortable dans un gros projet de ne pas les avoir. Les gens qui s'occupent de ces langages en ont conscience et le montrent (enfin !).
Aussi, j'ai l'impression que PHP reprend des bonnes idées d'autres langages : les paramètres nommés de Python, le startsWith / endsWidth de Java / Javascript, le WeakMap et l'opérateur de chainage de Javascript, les notations de types de mypy / Typescript, le match venant des langages fonctionnels et récemment adopté par Python, bien plus lisible, adapté, clair, concis et moins casse gueule qu'un switch dans beaucoup de situations. Je salue aussi les paramètres constructeurs, je trouve les langages orientés objets tellement ennuyeux et lourdauds sans…
Une petite mention pour la possibilité d'utiliser
mixed, ça m'avait manqué quand j'avais essayé d'utiliser les annotations de types en PHP.Bref, ces petits changements qui améliorent la vie ces derniers temps dans les langages de programmations répandus, même si je n'utilise pas PHP tous les jours, m'enthousiasment pas mal, et franchement, je ne sais pas pour vous, mais chaque nouvelle version de PHP semble arriver avec son lot de bonnes surprises, de bons choix et le langage semble évoluer vite.
Finalement, PHP deviendrait presque plus sérieux et agréable que Javascript, pourtant il y avait du chemin : il a un match, des paramètres nommés, des notations de types (accessibles uniquement dans les projets qui ont décidés de passer à Typescript) !
C'est un langage qui continue à exceller dans son rôle original de moteur de templates HTML facile à déployer (quel bonheur de ne pas devoir configurer et démarrer un service par application et de pouvoir laisser le serveur HTTP gérer les URLs - que ce soit en tant que développeur ou utilisateur - un plaisir pour la maintenance d'un service), avec de plus en plus tous les outils qu'on trouve dans les langages de programmation modernes. Franchement, ça donne envie de s'y remettre.
Prochaine étape : la gestion de l'ownership / du borrowing dans les langages de scripts répandus !
[^] # Re: Debian
Posté par raphj . En réponse au journal Installer Chromium sur Ubuntu via Nix. Évalué à 2.
Ou, sur un environnement de bureau moderne, tu recherches "Chromium" dans le menu, ça se rend compte qu'il n'est pas installé, ça te propose "Installer Chromium", tu cliques et ça s'installe. Imbattable.
# Debian
Posté par raphj . En réponse au journal Installer Chromium sur Ubuntu via Nix. Évalué à 7.
C'est un ancien mot africain qui veut dire « J'arrive pas à configurer Ubuntu » ?
[^] # Re: Ça ne date pas d'hier…
Posté par raphj . En réponse au lien YouTube ajoute des publicités sur certaines vidéos sans rémunérer les créateurs. Évalué à 3.
C'est une limitation curieuse. Le mode Picture in Picture de Firefox et Chrome devrait aider cela dit ?
[^] # Re: Ça ne date pas d'hier…
Posté par raphj . En réponse au lien YouTube ajoute des publicités sur certaines vidéos sans rémunérer les créateurs. Évalué à 5.
Je suis curieux de connaitre la suite.
Ça fait penser à TheFatRat, un compositeur qui sort beaucoup de ses morceaux sous licence libre.
Il a eu pas mal de déboires avec YouTube. Cf sa page Wikipedia, section Incidents :
Et l'astuce qu'il est obligé d'appliquer pour ne plus avoir de problème avec ContentID, par exemple sur un de ses morceaux :
Ça a l'air dur, de faire de la musique libre sur YouTube… tout semble adapté et pensé autour de l'industrie classique…
[^] # Re: Ça ne date pas d'hier…
Posté par raphj . En réponse au lien YouTube ajoute des publicités sur certaines vidéos sans rémunérer les créateurs. Évalué à 2.
Et du coup, est-ce que l'auteur mentionné par l'encart est rémunéré quand on regarde ta vidéo ?
[^] # Re: Gaffe au cease and desist
Posté par raphj . En réponse à la dépêche Trivabble, l’aventure continue. Évalué à 3. Dernière modification le 18 novembre 2020 à 22:46.
Le choix précis du nombre de lettres et de leur score est dérivé d'une analyse fréquentielle, mais n'est-il pas, lui, spécifique au Scrabble ? Qu'est-ce qui, au regard de la loi / du droit d'auteur / des marques le différencie-t-il de la disposition des lettres/mots compte double/triple sur le plateau ?
[^] # Re: Autre solution avec un client mail "lourd"
Posté par raphj . En réponse à la dépêche Lighten Mailbox : archivez vos courriels. Évalué à 2. Dernière modification le 18 novembre 2020 à 18:39.
Attention avec Thunderbird, le jour où le profil est planté ça peut être un peu pénible. Avec des sauvegardes du profil Thunderbird ça peut se faire, faut bien garder à l'esprit qu'une fois qu'un profil est ouvert avec une version récente de Thunderbird, l'ouverture avec des ancienne version de Thunderbird est bloquée. On peut contourner mais la réussite n'est bien sûr pas garantie.
J'avais récupéré localement le contenu complet d'une boite mail avant sa destruction avec un outil en ligne de commande. Je crois que c'était OfflineIMAP. Il est peut-être possible d'ouvrir le résultat avec Thunderbird mais je n'ai pas essayé.
[^] # Re: un langage pour des petits GUI
Posté par raphj . En réponse au journal Retour d'expérience sur les langages de programmation. Évalué à 2.
Je développe pas mal avec les technos du web. En perso, principalement parce que ça permet de donner une URL aux gens et ils n'ont besoin de rien installer.
Effectivement on peut faire des trucs jolis avec HTML / CSS / JS et c'est un aspect que j'aime bien. Par contre attention au manque de composants standards, surtout quand on vient d'une boîte à outils comme Qt. On se retrouve vite à réinventer la roue dans chaque nouveau projet, ou devoir embarquer une bibliothèque lourde. Ext.js semble fournir des composants comme pourrait s'attendre quelqu'un qui a fait du Qt. Je n'ai jamais essayé. Ils n'ont pas l'air de surfer sur le modèle du DOM virtuel ou équivalent (faut dire qu'ils sont apparus avant), cher aux dev frontend d'aujourd'hui, mais peut être que quand on n'a pas besoin de recoder le monde entier, c'est moins important.
[^] # Re: Sac
Posté par raphj . En réponse à la dépêche Trivabble, l’aventure continue. Évalué à 3.
J'aime beaucoup cette version :-)
[^] # Re: Plateau rectangulaire
Posté par raphj . En réponse à la dépêche Trivabble, l’aventure continue. Évalué à 2.
Serait-ce possible d'avoir une capture d'écran ?
Il ne faut pas hésiter à rapporter le bug sur la forge du projet ou par mail :-)
[^] # Re: Il faudrait que ça soit affiché dans le navigateur
Posté par raphj . En réponse au lien Webbloatscore: estimer la bloatitude de votre site web. Évalué à 2.
Ah yes. Sur Twitter et Facebook, ça pourrait faire défiler la page en même temps.
[^] # Re: Il faudrait que ça soit affiché dans le navigateur
Posté par raphj . En réponse au lien Webbloatscore: estimer la bloatitude de votre site web. Évalué à 2.
Si, c'est ce que j'ai voulu dire par "quantité […] de code exécuté" (en nombre d'instructions). Pour une boucle, ça tiendrait compte du nombre d'itérations par ex. Mais la phrase était ambiguë, on aurait pu comprendre la taille du code en nombre de caractères.
[^] # Re: Unité énergie
Posté par raphj . En réponse au journal Slimbook version KDE. Évalué à 4.
Tu ne te déplaces pas en km·h toi ? 😊
[^] # Re: L'historique
Posté par raphj . En réponse au lien Youtube-dl est de retour sur GitHub - sebsauvage. Évalué à 8. Dernière modification le 17 novembre 2020 à 00:25.
GitHub explique leur démarche ici : https://github.blog/2020-11-16-standing-up-for-developers-youtube-dl-is-back/
en réaction à une lettre de l'EFF : https://github.com/github/dmca/blob/master/2020/11/2020-11-16-RIAA-reversal-effletter.pdf
En particulier, l'EFF estime que les références aux 3 vidéos dans le code mentionné par la requête DMCA rentreraient dans le cadre du « fair use » (grosso modo récupérer une copie ne veut pas dire enfreindre un copyright). GitHub et l'EFF estiment que youtube-dl a par ailleurs plein d'usages légitimes et légaux. Du coup, ce code aurait même pu rester tel quel et sa présence dans l'historique ne serait même pas un problème. On peut supposer que les avocats de la RIAA sont experts en la matière et comprennent parfaitement bien ces subtilités, ce qui poussent certains à affirmer qu'ils ont peut être testé les limites, « tenté le coup » en sachant très bien que l'argumentation était essentiellement bidon. Mais bon, bien sûr, retirer le code permet de « montrer » que des efforts sont faits, avec bonne foi et c'est utile pour ça. Ça rend plus « défendable » dans tous les cas, parce que l'intention compte dans le système légal.
Je n'aime pas GitHub mais je trouve leur gestion de cette affaire raisonnable voire exemplaire sachant qu'ils renforcent leurs procédures pour mieux gérer ce genre de cas à l'avenir et éviter que des requêtes DMCA permettent trop facilement de bloquer un dépôt. Alors c'est peut être en réponse à une grosse protestation, et ils cherchent peut-être à limiter la mauvaise pub lié à cet évènement voire à en tirer une bonne pub, mais pour moi ça marche, d'autant que s'ils appliquent ce qu'ils disent, ce n'est pas juste des paroles. Ils ont écouté.
Je ne sais pas s'ils auraient pu mieux gérer cette histoire en restant dans les clous de la loi. Ils auraient pu appliquer les améliorations qu'ils présentent dans leur article de blog, mais « hindsight is 20/20 » ça parait concevable et compréhensible qu'ils n'avaient pas anticipé ce genre de chose.
# Il faudrait que ça soit affiché dans le navigateur
Posté par raphj . En réponse au lien Webbloatscore: estimer la bloatitude de votre site web. Évalué à 2. Dernière modification le 16 novembre 2020 à 23:46.
Avec une couleur et/ou un icône, et un texte « INUTILEMENT LOURD ».
Ou qu'à partir d'une certaine quantité calculée intelligemment de données transférée ou de code exécuté, le navigateur pause le chargement et affiche un message du style « Cette page consomme beaucoup de ressources. Elle vous oblige à remplacer votre matériel un peu ancien mais toujours capable par un supercalculateur et vous fait subir malgré tout des lenteurs, des saccades, une autonomie réduite, l'abîme en le faisant chauffer, consomme votre forfait internet alors que c'est vous qui le payez et vous fait attendre inutilement. Voulez-vous continuer le chargement ? »
On peut toujours rêver…
(bien sûr, il y a des cas où un site consomme légitimement des ressources, par exemple une application dans laquelle on fait de la vidéo / visio, donc c'est quand même compliqué).