Jiehong a écrit 592 commentaires

J'ai bien parlé du tracé à la main à l'école (papier millimétré linéaire, semi-log, et log-log). J'ai ensuite dit « à la main numérique », je trouvais ça marrant.

Néanmoins, je suis tout à fait d'accord qu'il faut savoir tracer des courbes à la main sur papier, car c'est très formateur. Même si au collège/lycée, la droite de régression c'est un peu du pipeau, puisqu'on la trace souvent à vu, au lieu d'en calculer la valeur par une méthode genre celle de la médiane de médianes (qui permet de ne pas apporter trop de statistiques au début).

Bon, mais de manière générale, à la main il est plus simple de faire une ébauche de courbe, et d'obtenir un rendu propre en numérique. C'est le meilleur des deux mondes ;)

Oui, bien sûr. Par grilles, je parlais de l'arrière plan gris du graphique.

Si tu créé un graph, sous « Backpane1 », tu peux choisir de quelle manière s'effectue le remplissage. Dans le type « pattern », tu peux choisir pleins de grilles, mais elles sont hyper serrées. Si tu regarde la capture d'écran faite avec Pandas, par exemple, tu peux voir une petite grille blanche pour les valeurs principales.

Je ne sais pas si ces grilles-là sont trop serrées par défaut, ou alors c'est à cause de mon écran qui est à « dpi = 192 ».

Mettons qu'une dépêche partent en modération, et qu'elle est publiée. Dans ce cas, lorsque l'auteur reçoit un mél lui indiquant que sa dépêche à été acceptée, il pourrait également recevoir un fichier diff contenant la différence entre ce qu'il a envoyé en modération, et ce qui vient d'être publié.

Chaque dépêche pourrait contenir un lien « correction de la modération », sur la ligne sous le titre.

Ce n'est pas la panacée, mais ça permettrait un retour aux utilisateurs, sans demander plus de boulot aux modérateurs.

Néanmoins, ça ne marcherait pas pour les refus. Mais peut-être que dans ce cas-là, quand le dépêche retourne en rédaction, le modérateur pourrait poster un petit message sur la dépêche concernée expliquant pourquoi elle a été refusée ?
Il est également possible de demander à la tribune pourquoi une dépêche a été refusée.

Je m'attendais vraiment à ce que quelqu'un montre le résultat d'un autre tableur, mais apparemment, les outils à scripts ont plus la côte.

Dans ce journal, je voulais aussi que les gens voient que l'ergonomie de ces logiciels pour faire des graphiques est vraiment moyenne : c'est à se demander si les tableurs ne servent pas à faire des graphiques du tout.

Pourtant, en entreprise, le pourcentage de gens qui font leurs graphiques avec un tableur sont pléthores.

Je me disais donc, que si tant de gens font des graphiques comme ça, c'est que ça doit être pas trop compliqué, et bien fait. Mais je ne trouve pas que ce soit le cas, sauf sur Gnumeric.

À quoi servent les tableurs finalement ? Je trouve ça plus simple est puissant de travailler avec des matrices de valeurs avec des logiciels dédiés (comme R), où y faire des graphiques n'est pas si compliqué.

Les suites libres de bureautiques doivent-elles continuer à maintenir leurs tableurs / graphiques ?

Peut-être que c'est le même propos que word VS Latex pour les tableurs :)

C'est quand même assez illisible : regarde les valeurs en abscisse et en ordonnée, la légende est tronquée.

L'avantage de Pandas/R, c'est que le fichier csv est parsé pour toi en 1 ligne.

Aurais-tu le fichier data.dat ?

Si tu utilises Pandas, ton code va franchement être plus court.

Sinon, du noir sur du bleu, c'est pas lisible, et changer ça, c'est une bonne idée.

Pour ton abscisse, matplotlib est capable de gérer les dates correctement si ce sont de vrais objets dates, mais pas des chaînes de caractères. Ce fil sur stackoverflow peut sûrement t'aider.

Ça à l'air de d'avoir pris pas mal de temps tous ces tests en tout cas. Bizarrement, la présentation semble plus sympa que sous LO ou Calligra avec les grapheurs javascripts.

Je crois avoir déjà répondu à ça dans le journal :

Je m'intéresse ici à l'évolution de la population humaine de -10 000 AEC à 2010 EC

Je souhaite simplement voir comment ça évolue dans le temps. C'est assez simple. J'en ai simplement profité pour voir comment produire un graphique de type XY se fait dans un tableur.

Non, mais tu peux essayer ;)

J'ai plus l'impression que c'est pour développer des extensions à l'origine.

Merci bien !

Il semble qu'il existe également une page de Mozilla redirigeant vers Pocket. Sur la page de l'extension, il est mentionné qu'elle ne sera plus maintenu, et elle renvoie à la page sus citée.

C'est un peu bizarre de ne plus avoir de 6.0, mais pourquoi pas. Néanmoins, qu'en est-il de LLVM par rapport à GCC ?

Il me semble que le noyau compile maintenant avec clang, et que OpenMP 3.0 est géré par clang.

« Customize » ?

Je me ravise : j'ai quelques warnings qui apparaissent de temps en temps qui semblent liés à une extension en particulier.

Hmm… rapport de bogue ?

Je viens de tester de mettre à vrai reader.parse-on-load.enabled, et j'obtiens une icône reader comme sur mobile (Firefox 38, sous arch)

Bon, mais ça ne marche pas à tous les coups. Par exemple, sur cette page, il n'y a pas de commentaires :

Sous Arch, et j'ai pas ce comportement (plasma 5) : rien sur stdout, et rien dans journalctl. J'ai pas syslog.

Est-ce un truc avec Gnome ?

C'était un peu trollesque, c'est vrai. En même temps, je suis moi même dev. C++, et je vois passer des vertes et des pas mûrs (j'en fait aussi). On utilise aussi Valgrind, analyse statique, tests unitaires, tests de non-régression, etc, et pourtant, comme sur FF, ça arrive. C'est juste tellement plus facile de rater des trucs qu'en Haskell par exemple.

Bref, ce commentaire réduit l'intérêt de l'article, et montre le sérieux des préjugés de l'auteur.

En une ligne, on peut aussi voir la facilité avec laquelle tu juges les gens. À moins que ce soit exagéré.
Même si je pourrais argumenter que, par définition, un préjugé n'est pas vraiment sérieux, j'espère simplement que le reste de l'article t'as plu…

je dirai que l'inverse (compresser quelquechose de déjà crypter, soir LZ4(AES(texte_en_clair))) ne donnerai pas un bon ratio de compression (mais un peu qd même), du fait que le cryptage rend trés aléatoire les données; mais je me trompe peut être ?

Tu peux t'amuser à essayer, mais ça ne servira à rien du tout (voire à augmenter sa taille). Dans le cas contraire, j'aurais pas trop confiance en l'algorithme de chiffrement utilisé.

Tu aurais pu donner quelques références.

Je pense que tu fais référence à l'attaque CRIME qui s'est intéressé au fait que TLS utilise la compression de données pour deviner quelques choses à propos des cookies de l'utilisateur.

L'idée générale étant que la compression réduit la taille en s'intéressant aux redondances. Si l'attaquant arrive à ajouter un mot au cookie qui n'est pas présent dans le cookie, alors la taille du cookie compressé puis chiffré va augmenter. Mais si la taille n'augmente pas notablement, cela veut dire que le texte ajouté était présent dans le cookie. Cela donne ainsi des informations sur le texte en clair, et ça casse le chiffrement.
Au sein de l'attaque, le vecteur était que la page d'un site web https faisait référence à une autre page qui envoyait le texte à tester. Après plusieurs essais, l'attaquant à un avantage non négligeable, et c'est la merde.

Dans l'absolue, cette attaque ne devrait pas avoir beaucoup d'impact sur le cas ici présent, à moins que tu ne t'amuses à compresser et chiffrer plusieurs fois le même fichier légèrement modifié par un tiers.

Chiffrer uniquement pourquoi pas, mais l'authenticité/intégrité de ton message/fichier n'est absolument pas garantie.

Je te proposerais d'utiliser AES-GCM après l'étape de compression (ça utilise AES en mode CTR, et tu peux authentifier tes données).
Bon, mais il semblerait que ça soit vraiment compliqué de chiffrer des fichiers, puisque j'ai pas vraiment trouvé d'outils le faisant.

Bon, mais sinon, gpg te propose de chiffrer et de compresser via la même commande.

Wow ! C'est vraiment super lent.

Je viens d'essayer, et j'obtiens ça la première fois (zsh) :

$ time systemctl status cups
● cups.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)
systemctl status cups  0.00s user 0.02s system 34% cpu 0.058 total

Je suis aussi sous Archlinux, mais là ça me paraît vraiment bizarre que ça soit aussi lent chez toi pour un service inactif. Chez moi, c'est une partition Btrfs. J'ai testé avec bash, mais c'est quasiment identique (pour avoir la même commande time que toi).

le mode texte se lit avec n'importe quel éditeur de texte

Dans l'absolu, on peut lire n'importe quel fichier en mode binaire (via un éditeur hex par exemple), mais de là à le comprendre, c'est autre chose ^{^}

Bon, mais tous ces formats c'est quand même bien la merde (par exemple, un fichier texte en chinois encodé en big5, et illisible en supposant que c'est de l'utf-8 par défaut).

J'ai pas le souci (c'est près de 100 × plus rapide).

Mais c'est peut-être lié, en effet.

J'ai limité la taille des logs à 100 Mio dans journald.conf, et si tu n'as pas besoin de tant de journaux, c'est peut-être une bonne idée de changer la taille par défaut (10 % de la taille de la partition, variable SystemMaxUse).

As-tu regardé la taille de ton /var/log/journal par hasard ?

Avec une limite à 100 Mio, j'ai mes journaux système depuis le 5 novembre 2014, et potentiellement pour plus longtemps (machine de bureau).

J'ai pas autant de logs que toi, mais avec 10 % de tes logs, j'ai ça :

# time journalctl --no-pager | wc -l 
18719
journalctl --no-pager  0.18s user 0.04s system 88% cpu 0.249 total
wc -l  0.00s user 0.04s system 16% cpu 0.249 total

En supposant que ce serait linéaire, j'obtiendrais 0,249 × 213361 ÷ 18719 = 2,838 secondes. Ça me paraît pas trop mal.

Tu peux aussi restreindre la sortie de journalctl au boot actuel avec -b, ce qui limite les lignes inutiles, et sera plus rapide.

T'as peut-être un souci, car chez moi c'est instantané.