freem a écrit 5019 commentaires

  • [^] # Re: Prendre des preuves que le billet n'est pas en vente

    Posté par  . En réponse au message Où acheter des trajets SNCF courts que la SNCF refuse de vendre ?. Évalué à 5.

    Et payer 10€ de frais d'émission à bord du train, de mémoire?

  • [^] # Re: sudo cul

    Posté par  . En réponse au journal CVE-2021-3156 Vulnérabilité majeure dans sudo. Évalué à 5.

    Le sumo est trop gros, passera pas.

  • [^] # Re: Les DNS...

    Posté par  . En réponse au message La fibre chez SFR. Évalué à 3. Dernière modification le 25 janvier 2021 à 11:40.

    Sinon, les bons outils de gestion réseau permettent de surcharger ça en théorie. Je parle de théorie parce que jamais utilisé, mais ça permets d'éviter 1) d'installer un nouvel outil 2) d'être indépendant du DHCP utilisé (le wifi, c'est pour bouger…)

  • [^] # Re: et si tu changes de DNS ?

    Posté par  . En réponse au message La fibre chez SFR. Évalué à 7.

    Et pour les flemmards:

    Ils sont disponibles aux adresses IPv4 et IPv6 suivantes :

    ns0.fdn.fr : 80.67.169.12 ou 2001:910:800::12
    ns1.fdn.fr : 80.67.169.40 ou 2001:910:800::40

  • [^] # Re: df -h

    Posté par  . En réponse au message Espace disque dur. Évalué à 2.

    Je te suggère d'utiliser un outil comme ncdu (console), baobab (gtk3, donc plutôt gnome), pour analyser l'espace disque de ta partition racine… ceci dit, si je mets en parallèle ce que j'ai lu avec ton df -h, je dirais que tu as abusé des installations par snap. Je parie que ce sont les environnements de ces logiciels qui te bouffent toute la place.

    PS: tout ça n'a rien à voir avec C++, mais alors vraiment rien. Je ne sais pas ce que tu connais de C++ ou de la programmation en général, mais pour remplir ne serait-ce que 1 giga octet avec un binaire exécutable ou un code source C++, il va te falloir beaucoup de temps… si tu compiles toi-même par contre, oui, les fichiers intermédiaires peuvent être lourds, mais si tu compiles toi-même, tu dois savoir qu'il faut nettoyer les fichiers objets, sauf si tu comptes patcher toi-même (et vu ton discours, je doute que ça soit ton cas, sans vouloir te vexer)

  • [^] # Re: C'est une manie

    Posté par  . En réponse au lien Google retire à Chromium la possibilité d'utiliser certains de ses services. Évalué à 4.

    Finalement, les liens sont utiles. Parce que s'il fallait faire un bookmark pour chaque service supprimé de google, il y aurait plus d'articles sur google que sur linux, ici :D (oui, oui, je sais, c'est pas bien les hyperboles de bon lundi)

  • [^] # Re: pourquoi s'acharner...

    Posté par  . En réponse au journal Fin des résultats directs sans Javascript sur Google. Évalué à 1. Dernière modification le 23 janvier 2021 à 18:48.

    "Tu n'es pas un pur libriste Gilet_sans_manches, nous te condamnons à l'éxile. La sanction est irrévocable!(ta ta taaaaa!!!)"

    Je serais mal placé pour reprocher ça, vu que j'utilise moi-même plusieurs logiciels non libres sans le moindre complexe:

    • vivaldi
    • virtualbox
    • un firefox supportant les DRMs (à vérifier, ça remarque)
    • quelques VMs avec windows
    • pilotes WiFi
    • une chiée de firmwares
    • parfois les pilotes NVidia de mes vieilles 8400GS

    Bref, je serais vraiment mal placé pour reprocher a quelqu'un l'usage de logiciels non libre. Et encore, je n'ai pas abordé la chiée de services web, parce qu'au final, à ma connaissance, le code derrière duckduckgo, notamment, n'est pas libre.

    Mon point se posais uniquement sur l'absence de critique réelle (une opinion n'est pas une critique) dans les messages que je lis et qui vantent la pertinence de google vs ddg.

  • [^] # Re: Ça ne répond pas à la question...

    Posté par  . En réponse au message fichiers qui s'effacent tout seul au reboot. Évalué à 2. Dernière modification le 23 janvier 2021 à 18:42.

    … mais 4 ko c'est beaucoup pour 2 octets de données.

    Non, c'est juste la taille d'une page, d'un bloc, d'un cluster. Ça peut se modifier dans le FS soit pour avoir des blocs plus grands (permets de réduire la fragmentation -utile sur disque mécanique!- et diminue l'espace disque consommé par les inodes) ou pour avoir des blocs plus petits (permets de réduire le gâchis d'espace, mais augmente la fragmentation et la zone réservées aux inodes).

    Bon, ok, pour voir ça, il faut utiliser le commutateur -s de ls, par exemple.

  • [^] # Re: pourquoi s'acharner...

    Posté par  . En réponse au journal Fin des résultats directs sans Javascript sur Google. Évalué à 2.

    Ça va la tétracapilectomie?

    Mieux que la vasectomie, je dirais.

    Plus sérieusement, c'est bien pour ça que je te demande des exemples, parce que justement, je n'ai pas la même expérience que toi. Et peut-être que le problème viens aussi du fait que ce que toi, tu appelles non-pertinent l'est pour moi, et vice versa.

  • [^] # Re: Programmation

    Posté par  . En réponse au journal Ça y est!! Je suis passé au bépo…. Évalué à 3.

    En php, la position du $ n’est pas du tout optimale (en haut à gauche). Donc c’est un peu pénible car c’est utilisé à chaque manipulation de variable.

    Donc encore pire pour le shell (tiens, un délire pour le jour ou je m'ennuie: compter le nombre d'instance de chaque caractère dans mes codes, et classer par langage…)

    Quelques fois il m’arrive de taper des espaces insécables (maj + espace)

    Ça, ça m'arrive aussi avec azerty… et libinput aime pas. Enfin, quand je suis sous zsh, j'ai pas le problème, il doit comprendre qu'une espace, c'est une espace putain… mais avec bash, bien souvent, "command not found", virer une espace et hop, ça marche. Évidemment, moi de pester avec le shell à la con ensuite (même si le vrai problème, c'est moi, mais quand même!)

  • [^] # Re: Super retour !

    Posté par  . En réponse au journal Ça y est!! Je suis passé au bépo…. Évalué à 2.

    Ça semble logique, mais bon, d'un autre côté ça permets d'apprendre, au moins visuellement, la disposition (parce que du coup, le smartphone, faut lire les touches, elles sont sous tes yeux…), ce qui doit rendre la transition moins raide ensuite sur un vrai outil de travail (on pardonne plus facilement une lenteur d'écriture sur tél que sur clavier je pense).

  • [^] # Re: pourquoi s'acharner...

    Posté par  . En réponse au journal Fin des résultats directs sans Javascript sur Google. Évalué à 0.

    Je pourrais piper ton texte dans sed -e 's/ddg/google/' -e 's/google/ddg' que mon commentaire aurait autant d'intérêt que le tiens: une assertion péremptoire sans preuve.

    Pourrais-tu nous indiquer quels termes, je cite, font que l'on "ne trouve rien"? Ainsi nous pourrions juger…

    Pour moi, ne rien trouver, c'est arriver sur une page blanche, pour info. Trouver des résultats non pertinents, c'est autre chose, et plus compliqué à définir. D'où ma question plus haut, en fait.

  • [^] # Re: À votre service

    Posté par  . En réponse au journal Orwell dans le domaine public: nouvelle traduction chez Agone (et deux autres chez Gallimard). Évalué à 0.

    J'aurai utilisé «pensée parallèle» moi.

  • [^] # Re: Wesh gros frère

    Posté par  . En réponse au journal Orwell dans le domaine public: nouvelle traduction chez Agone (et deux autres chez Gallimard). Évalué à 7.

    Désolé de te détromper. Quand j'ai lu le roman, à l'époque, je n'ai pas vraiment fait le lien avec Staline. Ce n'étais pour moi «qu'une uchronie de plus» dans les oeuvres lues (une excellente, certes).

    Le roman que j'ai lu étais un traduction française, j'avais 16 ans, et, oui, je connaissais l'histoire de la guerre froide.

    Il n'empêche que dans mes souvenirs, l'auteur décrit très clairement 3 blocs, tous les mêmes, et jamais on ne sait dans lequel on se situe d'ailleurs, c'est loin de «la nuit des temps» de Barjavel sur ce point, très, très loin. Devant.

    Bref, que j'aie tort ou raison de ne pas avoir fait le mélange avec Staline, ça n'empêche pas que cette affirmation "tout le monde pense à Staline en lisant le roman." est fausse, moi n'ayant pas eu de telle pensée.

  • [^] # Re: dommage...

    Posté par  . En réponse au lien Luciole : une police de caractère conçue spécifiquement pour les personnes malvoyantes. Évalué à 3.

    Pas faux.

  • [^] # Re: dommage...

    Posté par  . En réponse au lien Luciole : une police de caractère conçue spécifiquement pour les personnes malvoyantes. Évalué à 2. Dernière modification le 18 janvier 2021 à 13:29.

    Vous connaissez une police qui gère cela ?

    Non, mais j'ajoute ça à ma TODO-list, effectivement des Z e des 7 barrés, et ce genre de choses ne seraient pas un luxe pour coder, si ça peut ma permettre d'avoir des fontes plus petites tout aussi lisibles, moi, je prend! (parce que plus je vois de contexte de mon code, plus je suis heureux)

  • [^] # Re: dommage...

    Posté par  . En réponse au lien Luciole : une police de caractère conçue spécifiquement pour les personnes malvoyantes. Évalué à 3.

    Tiens, j'avais complètement oublié, à force de lire du texte écrit à la machine, que le 7 et le Z avaient des barres! Merci, du coup!

    Sinon, je lis cela : Des versions spécifiques pour les webdesigners (webfonts) sont disponibles sur demande. Je ne vois pas bien pourquoi ne pas mettre en libre téléchargement si le projet est libre…

    Certains projets libres font payer les binaires windows (hexchat par exemple fait payer le truc intégré au "store" MS de W10, mais pas l'installateur pour W7 et plus récent), par exemple. Je ne vois pas d'inconvénient à ça, perso, libre ne devrais pas vouloir dire "on fait tout le boulot pour vous, à l'oeil".

  • [^] # Re: pourquoi s'acharner...

    Posté par  . En réponse au journal Fin des résultats directs sans Javascript sur Google. Évalué à 3.

    Oui mais non. Même sur "toutes les régions", le contenu qui apparaît est, par exemple, majoritairement français, sur une recherche telle que "test".

  • # dommage...

    Posté par  . En réponse au lien Luciole : une police de caractère conçue spécifiquement pour les personnes malvoyantes. Évalué à 7.

    … ça ne passe pas "le test du O0" pour moi. C'est dommage, parce que même sans être malvoyant, j'aime avoir des fontes pour lesquelles je ne peux pas confondre deux caractères usuels. Par contre ça passe celui du 1Il, toutes les fontes ne peuvent pas en dire autant.

  • [^] # Re: pourquoi s'acharner...

    Posté par  . En réponse au journal Fin des résultats directs sans Javascript sur Google. Évalué à 4.

    Intéressant. Le meilleur selon quels critères?

    Parce que perso, je trouve les résultats de ddg largement satisfaisants. Quand je ne trouve pas sur ddg et que je cherche sur google, je ne trouve pas plus, en fait. Mais c'est peut-être le fait que, n'ayant pas assez d'infos sur moi, google ne peux pas facilement me mettre dans "la bonne bulle"?

    Déjà que depuis peu (quelques mois) ddg me mets dans la bulle "france" et ça me fait chier, je n'ose imaginer ou je finirai avec google.

    Outre ce critère, il y a aussi la syntaxe bang! que j'utilisais beaucoup, avant de prendre l'habitude d'enregistrer moi-même mes moteurs de recherche spécialisés, dont j'ai pas souvenir que google ait un équivalent?

    Je peux aussi citer la structure d'affichage des recherches, mais ça je crois que google a rattrapé son retard dessus, au moins en partie… après vérification, non, en fait, l'UI est toujours aussi foireuse (question de goûts, sûrement).

    Du coup, comment tu évalues "le meilleur"? Je n'ai ici abordé, tu l'auras remarqué, que des questions terre-à-terre, si on commence a aborder le problème de l'éthique (supposée) de ddg vs celle de google, bon… voila quoi. Mais il est probable qu'il y ait mieux.
    En fait, "le meilleur", ça dépend de chacun, et des priorités de la personne qui le proclame. Pour moi, le moteur de recherche de google est loin d'être le meilleur.

  • [^] # Re: Energie grise

    Posté par  . En réponse à la dépêche Mesurer la consommation d'énergie des projets informatique, depuis les serveurs, avec scaphandre. Évalué à 5. Dernière modification le 17 janvier 2021 à 20:06.

    Même si les terminaux et la fabrication du serveurs coûtent, ce dont je ne doute pas, les optimisations (parce qu'au final, pour réduire la facture, faut optimiser ou virer des fonctionnalités lourdes, j'imagine) qui permettent de consommer moins (de RAM, de CPU, d'espace disque) ne peuvent-elles pas du même coup rendre le soft utilisable, justement, sur du plus vieux matériel?

    Quand je vois que par exemple sur mes systèmes (Debian 10, fonctionnant sur runit) les processus qui gèrent les daemons (runsv pour la gestion d'un daemon, svlogd pour gérer ses logs) ont un coût de RSS (mémoire résidente) de 740Kio en moyenne, pour un coût total de ~1.5Mio par daemon, je me pose des questions. Ces outils ne faisant quasi rien…

    Une rapide comparaison très biaisée indique, pour int main() { for( ;; ); }:

    • gcc dynamique: RSS:744Kio, VSZ:2144Kio, taille binaire: 14Kio
    • gcc statique: RSS:4Kio, VSZ:964Kio, taille binaire: 667Kio
    • musl dynamique: RSS:4Kio, VSZ:872Kio, taille binaire: 14Kio
    • musl statique: RSS:4Kio, VSZ:172Kio, taille binaire: 14Kio

    Le VSZ, on s'en fout un peu (c'est la mémoire utilisée, mais pas réservée. Si je dis pas de conneries, lancer 2 processus images du même programme auront notamment les sections .text communes, les lib partagées également, etc, sans compter la mémoire réservée mais pas utilisée (overcommit) et ce genre de joyeusetés).
    La taille de binaire est surtout pertinente du fait que, ben, ça prend de la bande passante quand il faut installer, l'espace disque est aussi un argument, mais il me semble moins pertinent. N'empêche que ça reste un argument (la bande passante, ça fait chauffer pleins de machines).
    Par contre, le RSS, ça me semble pertinent: c'est une pas si mauvaise approximation de l'impact sur la RAM (pas exacte, cependant, par exemple GNU free -h ou busybox free -m ne me donnent pas du tout les mêmes valeurs, GNU free étant inférieur à la somme des RSS de tous les processus, la ou busybox trouve justement cette valeur).

    Bon, évidemment, le programme ici ne fait tellement rien (d'autre que monter un coeur à 100%) que ces résultats ne peuvent pas servir de manière brute.

    Sur de gros programmes, le coût est probablement négligeable: par exemple, sur ma machine, free rapporte 3.5Gio utilisés pour 183 lignes dans ps -A.
    Un calcul rapide (et surtout bien pourri) permettrait de dire "(744 - 4 )*183 => ~132Mio soit ~3.7% économisés".
    C'est évidemment faux, ne serait-ce que parce que ps -A montre aussi des éléments du noyau je crois (rcu_sched, migration/3, etc) ce qui implique que le résultat est trop élevé par rapport à la réalité.

    N'empêche que si on prend un système moins puissant que mon PC de bureau, et plus vieux, par exemple une beaglebone black (512Mio de RAM).
    Le surcoût de pas loin de 1.5Mio gâchés par daemon (on pourrait même dire de 2.1Mio pour la plupart des daemon, puisqu'eux aussi souffrent de ce problème), multiplié par le nombre de daemons d'un système (cron, getty, client dhcpd, cups, mpd, caches dns parfois, proxy ldap (nslcd), etc) peut vite représenter une valeur non négligeable.
    Disons 10 daemons. 15Mio. 512Mio de RAM dispo. Presque 3%. Si on compte le daemon lui même, on monte donc à 21Mio, soit plus de 4%.

    Bref.

    En réduisant ces coûts, je pense qu'il est probable que l'on puisse aussi utiliser plus longtemps les vieux systèmes, et donc baisser l'impact énergétique de l'informatique puisque l'on diminuerais le nombre de machines jetées à la benne en plus de diminuer légèrement la consommation fonctionnelle.

  • [^] # Re: Flutter et le libre...

    Posté par  . En réponse à la dépêche Changeons ces logiciels open source qui nous espionnent. Évalué à -1. Dernière modification le 17 janvier 2021 à 18:30.

    Le web avec flutter est toujours en beta.

    Ben, le truc en fait, c'est que le web, il est toujours en alpha, donc bon, déjà atteindre le stade beta c'est un exploit pour moi…

    Parce que beta ça veut dire:

    La phase bêta commence généralement lorsque le logiciel est assez complet, mais susceptible de contenir un certain nombre de bugs

    Hors, si je ne m'abuse, le web semble ne toujours pas être assez complet. On est donc bien dans de l'alpha perpétuelle.

  • # pourquoi s'acharner...

    Posté par  . En réponse au journal Fin des résultats directs sans Javascript sur Google. Évalué à 10.

    … à utiliser google?

    Peut-être que certains (meta-)moteurs de la concurrence te permettraient d'éviter le problème, sans prise de tête et sans bidouille?

    Pour ma part, j'utilise ddg, qui utilise aussi du JS et de la redirection dans ses liens, il me semble. En théorie pour nous protéger, de mémoire, mais je t'avoue ne pas avoir creusé (j'en doute, hein, mais bon, sait-on jamais).
    Je ne doute pas qu'il en existe d'autres, d'ailleurs.

  • # ne marche pas avec mawk

    Posté par  . En réponse au journal TapTempo contest : un peu moins d'octets en Awk. Évalué à 2.

    Ne marche pas avec mawk pour le coup. Je pense que c'est lié à l'utilisation de comparaison pour les patterns, alors que ça devrais puisque le standard (POSIX-10031-2017) dit:

    An awk program is composed of pairs of the form:
    pattern { action }

    plus loin:

    Patterns
    A pattern is any valid expression, a range specified by two expressions separated by a comma, or one of the two special patterns BEGIN or END.

    Du coup, je me demande si ça ne serait pas un bug de mawk? Ça y ressemble en tout cas beaucoup?
    Peut-être spécifique à debian?

    Pour info:
    ```sh
    % mawk -W version
    mawk 1.3.3 Nov 1996, Copyright (C) Michael D. Brennan

    compiled limits:
    max NF 32767
    sprintf buffer 2040
    ```

  • [^] # Re: ...

    Posté par  . En réponse au journal Un hacker français finance l'alt right US avec Bitcoin. Évalué à 10.

    dans les récipients

    Tant qu'ils brisent pas la cruche à force de trop mettre le récipient à l'eau, moi je dis, tout va bien.