xulops a écrit 303 commentaires

Au moins le capteur utilisé (SCD30) est un vrai capteur CO2. Il existe un tas de capteurs beaucoup moins chers mais pas du tout fiables.
Celui-ci, son seul défaut est son prix.
52 euros en France (15 euros livré en Chine, ça donne une idée de la marge de l'importateur), ce n'est pas donné.
Bref les pièces pour 77 euros (version ESP32, la moins chère) c'est cher payé pour savoir s'il faut ouvrir ou fermer une fenêtre pour aérer la pièce à vivre.
Les serres industrielles s'en servent pour booster le taux de CO2 à la valeur optimale de croissance des plantes, là évidemment le coût est moins bloquant.

Bassiste aussi (dans une vie antérieure), pour les reprises j'utilisais em premier Tuxguitar, parce que les fichiers qu'on récupère sur internet sont souvent des fichiers GuitarPro que TuxGuitar ouvre sans problème. Je virais les autres pistes, transposais si besoin dans TuxGuitar, et exportais au format lylipond. Puis dans lylipond, qui affiche quand même les partitions vachement mieux que TuxGuitar, j'exportais la partoche en PDF.
Un PDF, ça s'affiche partout, même sur une tablette, pratique.

Les deux peuvent avoir leur utilité. La fameuse phrase où il vaut mieux apprendre à quelqu'un la pêche que de lui donner un poisson, c'est vrai quand il n'y a pas urgence. Un gars qui n'a pas mangé depuis 3 jours, il vaut mieux lui filer un poisson tout de suite, et lui apprendre à pêcher plus tard.

Moi c'est "un outil qui va vous éviter de devoir suivre les bonnes pratiques de sécurité à chaque fois que vous avez besoin d’un serveur web" qui m'inquiète un peu. Me dire que je ne dois pas suivre les bonnes pratiques, heu … ou alors c'est la phrase qui est mal tournée ? Du coup je me demande en quoi c'est plus sécurisé qu'un apache (que je connais mieux que nginx) normalement configuré.

La sauvegarde, c'est pas juste réinstaller un paquet quand ton disque meurt ou ton datacenter brûle. On est quand même en train de parler d'un logiciel qui gère tes factures, ta compta, tes devis, tes clients, tes produits et services, tous les documents que tu uploades (genre attestation de CA, URSAFF…), les mouvements bancaires, et j'en passe. Bref c'est la vie de ton business là.
Avec l'install du paquet .deb, tes données, elles sont majoritairement dans la base de données (/var/lib/mysql/nom_de_la_bdd), mais pas que. Elles sont aussi dans les fichiers auto-générés (PDF, CSV…) et ta bibliothèque (/var/lib/dolibarr/documents). Tu dois ajouter les fichiers de conf dans /etc/dolibarr, éventuellement la config apache/ngix.
Et plus, je conseille (c'est ce que je fais) de sauvegarder aussi le code applicatif (/usr/share/dolibarr) parce qu'en cas de réinstall d'urgence, c'est mieux d'être certain que la structure des données sauvegardées et le code qui les exploitent soient au même niveau (la structure de la base de données évolue au fil des versions, c'est normal), au lieu de paniquer à rechercher le paquet avec la bonne version , en admettant qu'on se souvienne à quelle version on en était).
Si tu ne sauvegardes pas tout ça correctement, c'est la mort du petit cheval.
En cas d'install manuelle, tu as la base de données à sauvegarder et un répertoire (et ses sous-répertoires), et éventuellement la config apache/ngix. C'est quand même plus simple de ne rien oublier, et plus simple à remettre en place en cas de panne.
Je dis ça juste à titre de conseil, ensuite chacun fait comme il veut, mais dans tous les cas c'est davantage qu'un paquet à réinstaller.

En fait tous les scripts php sont dans ce répertoire, et dans la config d'apache, tu as un alias du genre :

Alias /phpmyadmin /usr/share/phpmyadmin


Le config.inc.php est dans /etc/phpmyadmin
Le config.sample.inc.php est dans /usr/share/phpmyadmin
Le blowfish_secret.inc.php est dans /var/lib/phpmyadmin

… et tout ça doit être accessible par l'utilisateur qui fait tourner le serveur web (www-data pour apache par exemple). C'est plus compliqué que d'avoir tout dans le même répertoire en cas d'install à la mano, enfin, c'est mon avis, comme on dit : chacun voit midi à sa porte.

Tu veux dire qu'il respecte Filesystem Hierarchy Standard ?

Oui, et c'est normal pour un paquet .deb de le respecter. Mais ce n'est pas très pratique pour les applis type "web". Regarde le bordel pour PhpMyAdmin, avec des fichiers de config dans tous les coins.

Pas la peine de jeter le bébé avec l'eau du bain, Dolibarr c'est super, je l'utilise personnellement, je l'ai conseillé à d'autres, j'héberge quelques instances, … bref, c'est bon, mangez-en.
Juste que le paquet debian en fout partout, donc pour sauvegarder (base de données, fichiers uploadés et auto-générés, fichiers de conf…) c'est un peu compliqué. Ce n'est pas spécifique à Dolibarr, c'est le cas des applis web empaquetées en général. Mon propos est qu'il vaut mieux se faire une installation manuelle.

Tu as bien fait de le faire remarquer, en effet, donc correction : Il ne vaut mieux pas installer les .deb fournis par le site officiel Dolibarr.

La bonne pratique au départ, sur un serveur Debian, c'est de ne pas installer Dolibarr via le paquet Debian qui en fout partout (bon courage pour faire la sauvegarde), et qui n'est mis à jour qu'à la prochaine version de Debian (quand c'est prêt, donc). Vaut mieux installer soit même, ou faire installer et maintenir par quelqu'un qui a le savoir nécessaire, à partir de la version stable du moment.

En pratique on aurait alors eu des dizaines de journaux attribués à Anonyme, avec des scores fortement négatifs, …

Ben non, puisque les vieux messages n'ont pas de raisons d'être modérés. Seuls les dernières dérives du gars en question auraient été modérées. Impact minimal, boulot de modération mininal, clair pour tout le monde… que demande le peuple ?

J'ai bien lu (et compris, au cas où…) tous les comentaires, etc, avant de poster.
Modéré des vieux messages longtemps après leur publication reste incompréhensible et illogique.

Que le gars aient ouvert 40 comptes, et qu'il fallait un geste fort pour qu'il comprenne, ce ne sont pas des raisons valables pour changer d'avis de modération sur des vieux messages, ils étaient valables avant.

Ysabeau, donner mon avis entre plus dans une démarche d'amélioration future que de critique de la modération actuelle, faut pas le prendre mal ni personnellement. Je pense que tout le monde est assez mature pour savoir que de modérer un site comme linuxfr n'est pas facile, mais si on ne peut plus dire si c'est un bon choix ou pas qui a été fait, autant interdire les commentaires sur le journal.

Les mesures d'exceptions ont toutes une facheuse tendance à devenir une habitude.

Le mieux n'aurait-il pas été de remplacer le texte du journal d'origine par un message disant qu'il a été modéré pour telles et telles raisons ? je pense que ça aurait été bien mieux qu'une supression pure et simple.

On a bien pensé aux effets de bords, mais… cela aurait aussi demandé un sacré travail de lecture, de filtres, de tris, voire des discussions. Et c'est terriblement chronophage.

Je suis relativement plutôt d'accord avec Krunch pour le coup.
Avec mon humble karma et ma jeunesse linuxfrienne, je viens quand même donner mon avis, faites-en ce que vous voulez : ce que vous avez fait, c'est ouvrir la porte à toutes les fenêtres.

Que l'utilisateur soit banni, pas de problème (si c'est mérité, bien entendu).
Mais venir a posteriori supprimer des vieux messages ou journaux, c'est de la censure sans fondement. Des vieux messages qui n'ont pas été modérés à l'époque n'ont pas de raisons d'être modérés ou supprimés maintenant, ça aurait du être fait à ce moment là s'ils contrevenaient aux règles du site (les règles n'ont sans doute pas changé entre temps).
Sur la forme, c'est aussi une mauvaise idée : supprimer tout simplement les messages en question les font disparaître aux yeux des utilisateurs, qui du coup ont un doute sur ce qui était là avant ou pas. Et si les modo de linuxfr se font infiltrés par des méchants (j'aime la science-fiction, mais elle devient parfois la réalité), d'autres contenus pourraient aussi disparaître comme ça, d'un coup, sans que les utilisateurs n'en sache quoi que ce soit. Il aurait mieux valu remplacer le texte des messages supprimés par "contenu supprimé par l'équipe de modération", ça aurait été clair pour tout le monde qu'il y avait un message avant, et qu'il ne respectait pas les règles, ce n'est pas supprimé en loucedé (en douce, en louchebem), et ce journal n'aurait pas de raison d'être.

J'ai un xiaomi notebook pro depuis trois ans environ, et j'en suis très content : coque arrière en alu, donc assez rigide pour le transport (il en a fait des voyages), écran assez grand en 1920x1080, disque SSD, tout fonctionne d'office sous Xubuntu, wifi, camera, son, … aucun problème. Pas fan des touchpads, j'utilise une souris bluetooth, donc je ne peux pas dire si le touchpad est bien ou pas. J'utilise massivement le clavier, aucun soucis à l'horizon. Après 3 ans, la batterie tient encore ses 5 ou 6 heures.
Si un achat d'un pc chinois ne rebute pas, c'est un bon choix : joli, solide et rapide.
Autre avantage : le transfo est tout petit, presque comme une alim de téléphone portable (il se branche d'ailleurs en USB-C).
Seul défaut : un peu lourd.

Je ne vais pas reprendre les réponses pertinentes de mes petits camarades, mais je ne comprends pas du tout ta réaction. Tu sembles oublier les propose de l'auteur sur l'absence de recherche par les labos et sur le complet dévoiement des brevets.

Pour avoir un master en chimie organique en ayant fait un an de recherche sur la synthèse de nouveaux médicaments, je sais pertinemment que de la recherche, il y en a, aussi bien privée que publique.
Sur le cas précis de cet article, à 100 dollars le coût de production et 84000 la vente, il y a clairement abus, on est tous d'accord (sauf peut-être le labo en question). Que ce soit un rachat de brevet à la place d'une recherche à la base ne fausse pas le raisonnement, le rachat a un coût qui doit être amorti et rentabilisé (dans la limite de l'acceptable, bien entendu, pas comme ici).

Les pays avec une vraie sécurité sociale qui peut peser sur le prix de vente, il n'y en a pas tant que ça dans le monde: Par expérience, le prix des médocs en Chine est folklorique, du simple au décuple entre la pharmacie de quartier et l'hôpital. Une opération de l'appendice peut coûter entre quelques milliers de RMB et quelques centaines de milliers suivant l'hôpital choisi.
Des pays avec l'état qui finance clairement la recherche sans que ça tombe dans la poche des grosses entreprises pour rien… c'est aussi pas gagné (merci les faux projets ANVAR et compagnies. Par exemple j'ai bossé dans une PME qui avait décroché un budget de recherche de 5 millions d'euros pour étudier des méthodes de filtration de granulés, le dossier était sciemment complètement bidon, aucun résultat, 5 millions net dans les caisses de la boîte, sans aucune contrepartie… bravo).

Le but de mon primo commentaire était de dire que tout n'est pas noir ni blanc. Une entreprise se doit de gagner de l'argent mais il y a aussi des excès, des magouilles, des détournements d'usage des brevets, etc, bien entendu. Mais c'est la plaie de tous les domaines, pas seulement de l'industrie pharmaceutique, sauf qu'ici ça a un impact direct sur la santé des gens. Donc oui, les états devrait encadrer davantage les prix, voire faire tomber un brevet dans le domaine public dans les cas graves.

Tout ça est un peu plus complexe que de dire "les salopiots, ils vendent plus cher que le prix de production".

La recherche de nouveaux médicaments n'étant que très peu financée par l'état, ce sont des fonds privés qui financent… et espèrent avoir un retour sur investissement. La recherche, c'est risqué, rien ne laisse prévoir un résultat de recherche rapide, ni même un résultat tout court. Donc il est normal que ce coût de la recherche se répercute sur le prix de vente afin de rentabiliser l'investissement (le salaire des chercheurs, les matos, les labos, les tests, etc).
Les entreprises pharmaceutiques n'étant pas philanthropes, non seulement elles incluent les coûts de recherche, mais elles ajoutent aussi une marge (incroyable, hein !), comme toutes les entreprises vendant des produits.

Donc rien d'étonnant d'avoir un prix de vente supérieur au prix de production. Maintenant, est-ce normal de passer de 100 dollars à 84 000 dollars ? Probablement pas. Il est fort à parier que dans ce cas le groupe pharmaceutiques en question profite de sa situation monopolistique (un seul fournisseur car brevet), encore faudrait-il avoir les chiffres du coût de la recherche et le marché potentiel pour estimer tout ça.
L'autorisation de mise sur le marché d'un médicament devrait prendre en compte cet aspect prix et le plafonner en cas d'excès notoire.

Vu le prix délirant dans ce cas précis, je me demande s'il est possible pour un malade de se rendre dans un pays n'appliquant pas les brevets et qui produit à bas coût pour se faire soigner.

Je confirme, ça fonctionne très bien en Chine où le paiment par Alipay peut se faire à la caisse simplement en montrant son visage à la caméra, sans avoir à sortir son téléphone, avec ou sans masque sur le visage.

Oui, l'envoi d'une newsletter est différent et l'étaler dans le temps ne pose généralement pas de problème, contrairement à un mail d'inscription qui doit être envoyé dans la minute.

Vu le coût assez faible (dans ta réponse en dessous), il n'y a pas urgence à changer.

Moi aussi, parce qu'envoyer 3500 mails par semaine, c'est presque rien.

Un serveur mail bien configuré peut faire le boulot sans problème. Le mien en envoie plus que ça sans se faire blacklister (majoritairement des mails d'inscriptions et autres notifications d'un site communautaire, mais pas que).
C'est du boulot pour tout configurer comme il faut (reverse DNS, SPF, DKIM et tout le toutim), certes, mais après ça roule sans y toucher plus que ça. Donc je pense que ça vaut la peine d'investir du temps au départ pour ne pas avoir de dépenses récurrentes ensuite.

Ce n'est pas du tout comme ça que je lis le titre ni le billet. Il ne parle pas de comparer la performance entre les langages mais dans chaque langage. Et s'il produit une liste multi langage il montre pour chacun le gain entre idiomatique et optimisé.

Il suffit de regarder la conclusion pour s'en convaincre.

On ne doit avoir lu le même billet alors.
Pour le titre, s'il ne voulait pas comparer les langages entre-eux à la base, il aurait du choisir un truc du genre : "Performance comparison in counting words, study cases in various languages.", sinon c'est ce qu'on appelle un titre putaclick.

Quand à la conclusion, la moitié est consacrée au tableau de comparaison entre langages, et ensuite viennent quelques pensées qu'il en tire, avec en premier : "I think it’s the simple, idiomatic versions that are the most telling. This is the code programmers are likely to write in real life.", alors que j'ai prouvé ci-dessus que ce n'est pas le cas, les developpeurs ne ponderont pas tous le même code dans la vie réelle, il existera des versions différentes avec des performances elles aussi bien différentes.

Le problème est certainement lié à une autre de ses pensées : "I still think this interview question is a good one for a coding question". Si cette question m'était posée telle que lors d'un entretien (hypothèse improbable), je demanderais à l'examinateur dans quel contexte le programme est censé s'exécuter, quels sont les critères importants : performance à tout prix ? code facile à maintenir même 20 ans plus tard par un nouvel arrivant ? Empreinte mémoire minimale ? Espace disque ou IO minimum ? … Même si dans la vie réelle c'est souvent un équilibre entre tous ces critères, rien ne permet de deviner le choix de l'examinateur. Au final il y aura autant de versions que ce choix d'équilibre entre ces critères.

Je veux bien entendre tes arguments, mais quand le titre est "Performance comparison: counting words in Python, Go, C++, C, AWK, Forth, and Rust", le but du jeu est clairement de comparer les perfomances entre ces langages, ce n'est pas "tiens, vu qu'on a déjà fait le truc dans plusieurs langages, on pourrait aussi les comparer tant qu'on y est".
L'optimisation, le profilage, c'est visiblement plus un bonus que le but du jeu.

J'ai pris le cas de PHP parce que je connais ce langage bien mieux que les autres (voire pas du tout pour certains). Des petites modifs ayant un impact important sur la performance, il y a sûrement moyen d'en faire aussi dans les autres langages dont ceux de Ben, et là on ne parle pas des versions optimisées avec des algos spécifiques, juste des petits modifs ne touchant pas à la logique de la version simple. Du coup, la comparaison est fantaisiste, car quand décide-t-on que la version simple est la plus "apte" pour la comparaison ? Dans cinq ans, il y a un gars qui dira : "en Lua, si on fait comme ça, on va 3 fois plus vite" et donc Lua qui n'était pas considéré comme rapide ces cing dernières années va devenir plus rapide que d'autres langages. C'est tiré par les cheveux. (j'ai pris Lua au pif, hein)

Je ne connais pas Ben et ça n'enlève pas son mérite d'avoir proposé des algos dans plusieurs langages. Juste que comparer les performances des langages n'est pas aussi simple que ça en a l'air, et que ce n'est pas une bonne idée de juste regarder le tableau final en pensant que le langage Machin est plus performant que le langage Truc.

Alors, si je comprends bien, tu gagnes 0.08s chez toi en remplaçant …

Non. Retirer un test fait bien entendu gagner un peu, mais le plus gros du gain vient du remplacement du preg_split par un explode.

Est-ce que c'est crade ? oui, je l'ai dit. Pas de surprise. Ce n'est pas un truc à faire en dehors de ce cadre spécial. Le but était de démontrer d'une mesure de temps d'exécution est fantaisiste car il y a moultes façons d'écrire ce programme, avec des temps d'exécution fort différents.

Passer de 0.19 à 0.11, ce n'est pas gagner 100%, mais plutôt 40%, comme je l'ai également écrit. Les pourcentages, faut toujours se baser sur ce qui représente 100% (ici le temps de la version d'origine). Et c'est "presque" (le mot est important) passer du double au simple (en gros passer de 19 à 11 au lieu de 19 à 9.5 sans le presque), mais on peut toujours chipoter.

Il faudrait retirer la partie "sortie standard" du calcul de temps d'exécution

Je m'auto-quote (oui monsieur!) en voyant après coup que le gars envoie tout sur /dev/null, du coup les temps sont plus stables (0.01s environ), confirmant l'influence du terminal sur la fluctuation des temps si on affiche les résultats.

Pour prendre le langage que je connais le mieux, PHP, j'ai zieuté vite fait le code proposé, et qui est plutôt court :
```
<?php
$words = [];
while (($line = fgets(STDIN)) !== false) {
foreach (preg_split('/ +/', strtolower(trim($line)), -1, PREG_SPLIT_NO_EMPTY) as $word) {
if (!isset($words[$word])) {
$words[$word] = 0;
}
$words[$word]++;
}
}

arsort($words);

foreach($words as $word => $count) {
echo "$word $count\n";
}
```
Il y a moyen de faire rapido plus court et plus rapide d'environ 30 ou 40% (j'y reviens plus bas) :

while (($line = fgets(STDIN)) !== false) {
    foreach (explode(" ", strtolower(trim($line))) as $word) {
        @$words[$word]++;
    }
}
unset($words[""]);
arsort($words);
foreach($words as $word => $count) echo "$word $count\n";

Certes c'est moins "propre" : pas bien de ne pas déclarer le tableau (auto en PHP non-strict), peut-être moins clair de ne pas initialiser à 0 l'élément du tableau (auto en PHP), et encore moins d'utiliser l'arobase pour faire tomber aux oubliettes le warning sur l'élément non-déclaré. Mais c'est un test de performance, non ? Même résultat en plus rapide.

Ce "plus rapide" est difficile à estimer car sur ma machine, qui n'est pourtant pas de première jeunesse, le script PHP d'origine s'exécute en 0.19s (en moyenne), et la version modifiée en 0.11s (en moyenne aussi). En moyenne car d'un lancement à l'autre ça fluctue beaucoup (de 0.03s environ).

Bref, comparer des langages alors que de toutes petites modifs comme celle que j'ai faites peuvent faire passer le résultat presque du simple au double (ou l'inverse), ça ne veut plus dire grand chose.
Il faudrait retirer la partie "sortie standard" du calcul de temps d'exécution car les buffers de sorties des consoles (xfce4-terminal dans mon cas) doivent influencer pas mal le résultat ; et partir sur un jeu d'entrée beaucoup plus gros pour allonger le temps de traitement (viser au moins 30s) pour voir réellement des différences.

Je n'ai pas acheté la bête qui n'a pas beaucoup plus d'info que ça sur taobao, mais à vue de nez ça n'a pas l'air d'être exactement 100% le produit que vous voulez créer, par exemple (et c'est logique vu le prix) ça n'intègre pas un SSD.
Ca ne veut pas dire que ça n'existe pas déjà, le problème de la recherche, c'est de taper les bons mots-cles, je ne sais déjà pas comment appeler ce truc en français, alors en chinois… mais vu tout ce qu'on peut trouver de farfelu et/ou d'extraordinaire sur taobao, je ne doute pas un seul instant que ce produit existe déjà.

Faudrait commencer par faire un tour sur aliexpress (fr.aliexpress.com) qui a le bon goût d'être en français, même s'il n'offre qu'une toute petite partie du catalogue de taobao.

Sinon, plus globalement, je fais partie des gens qui voyagent léger au point de ne plus embarquer d'appareil photo, les smartphones faisant des photos de plus en plus qualitatives. Un smartphone ne remplace pas un appareil photo professionnel dans les mains d'un pro, mais dans les miennes, le résultat est à peu près équivalent; au mois suffisamment proche pour que le ratio poids/qualité penche en faveur du smartphone.

Moi je sais comment transférer mes photos du smartphone sur mon PC, mais j'ai constaté que c'est loin d'être le cas de tout le monde. Il y a peut-être un truc à creuser là.