freem a écrit 5019 commentaires

Ding ding ding! On a un gagnant. Les us ont effectivement une croûte de racisme très épaisse. C’est illustré précisément par l’utilisation abusive de maître/esclave.

Mince alors, moi qui avais cru lire "Petr Baudis dit quand même que c’est un mauvais terme et qu’il a été choisi principalement à cause de son manque de maîtrise de l’anglais à l’époque."… ou alors ce "Petr Bandis" serait un citoyen des USA qui ne parle pas anglais?
Possible, mais vu que j'imagine que cet individu est celui auquel réfère "Founder Interview with Chief AI Architect Petr Baudiš | Rossum" j'en doute fort, ou alors on m'a menti et les anglais connaissent les accents?

En fait le problème avec ce renommage, c'est qu'il se base sur des problèmes intrinsèquement locaux aux USA mais touche tout le monde.
Peut-être que ce problème de racisme et d'esclavagisme noir est encore réel et présent aux USA, mais personnellement, si un jour je tombe sur un projet qui arbore un Svastika (hé oui, c'est moi qui l'ait atteint! Enfin, pas encore rattrapé mon retard, peut-être que quelqu'un l'a eu avant…) je n'irai pas leur demander de le changer sous prétexte que ma région du monde a un très, très mauvais souvenir de ce symbole.

Restent les questions suivantes par contre: à partir de combien d'utilisateurs gênés doit-on changer des choses? Et une fois ce seuil établi, pourrait-on avoir les études qui estiment le nombre d'utilisateurs gênés par le terme master anciennement utilisé par git, par défaut?

À noter quand même, qu'au final, ce changement n'a aucun impact sur ceux qui utilisent le site, tout comme pour github: c'est le nom de la branche par défaut…

Je sais pas pour vous, mais moi, je commence par coder dans un dépôt local, puis éventuellement je crée un repo accessible aux autres, puis j'y pousse mes modifications.
De ce fait, le changement de nom de la branche principale, ben, je le verrais juste passer quand Debian intégrera la version de git qui le change. Mon code n'est pas organisé par des trucs comme github ou gitlab: ces machins ne sont que de stupides outils, que j'évite d'ailleurs au maximum tant je trouve coûteux en temps le fait d'utiliser ces «forges», qui sont en réalité bien plus proches de «places du marché» tellement on y cause et on y crie plus qu'autre chose.

Par contre, les cookies, perso, ça va pas me manquer. Pour ce qui est du système de certificats, ma foi, un client pourrait très bien trouver un moyen de rendre ça ergonomique. Je ne sais pas comment, il faudrait y réfléchir, évidemment, mais au moins ça sera pas juste un workaround parce que le protocole n'incluais pas la possibilité dès le départ, contrairement au web. Pour lequel il s'agit même d'un workaround sur-exploité.

À ce sujet, j'ai récemment été "râler" sur IRC que kristall ne permettait pas de faire de saisie sur gopher://gopher.floodgap.com:70/7/v2/vs et ça a été corrigé rapidement. Ce qui en fait le 3ème bug que je rapporte qui est corrigé en moins de deux semaines, je crois.
L'idée d'intégrer les certificats clients pour des forums pourrais probablement faire son chemin aussi, reste à construire et défendre l'idée suffisamment pour qu'elle séduise les devs, et éventuellement à l'implémenter soi-même s'ils ne sont assez convaincu que par l'idée, mais ont la flemme de l'implémenter (ils ne sont pas payés, après tout).

pas de formulaire pour publier

Effectivement. Enfin, oui et non… il reste possible d'envoyer des données au serveur, techniquement, mais ça reste bien plus primitif.

Par contre, les cookies, perso, ça va pas me manquer. Pour ce qui est du système de certificats, ma foi, un client pourrait très bien trouver un moyen de rendre ça ergonomique. Je ne sais pas comment, il faudrait y réfléchir, évidemment, mais au moins ça sera pas juste un workaround parce que le protocole n'incluais pas la possibilité dès le départ, contrairement au web. Pour lequel il s'agit même d'un workaround sur-exploité.

Par contre, on peut fort bien tenir un blog

Exactement, et je pense que c'est la l'intérêt principal: une page gemini, c'est pas de prise de tête pour la présentation, pas de prise de tête pour le certificat TLS, contrairement au web, pour lequel ces deux aspects nécessitent quand même un peu plus que de simples notions.

Et du coup, c'est une photo "en fonctionnement" la, ou bien en cours de travaux?

J'espère que ceux qui ont des backups à ressortir pourront les exploiter dans de bonnes conditions.

Qu'est-ce qui pourrait empêcher d'appliquer un backup à une autre machine?

Non, finalement on peut surtout se demander pourquoi se rendre toujours plus dépendants des bons vouloirs d'une grosse boite dont on sait qu'elle n'est pas notre pote.
Qu'est-ce qui empêchera Google un matin de décider que le serveur de sync exigera une signature fournie uniquement par la version proprio de Chrome?

Perso, je me suis fait mordre une fois par opera, même si certes, je ne payais pas la synchro, mais depuis, c'est niet les trucs de synchro. À la rigueur, si j'en avais le contrôle, pourquoi pas, mais je préfère ne rien avoir plutôt qu'avoir un truc qui risque d'être viré aléatoirement sans que l'on ne puisse discuter la décision (de mémoire, j'avais reçu un mail comme quoi j'étais banni alors que je n'avais fait qu'essayer d'utiliser une des fonctionnalité, sans y arriver?).

Comme on dit, mieux vaut être seul que mal accompagné.

Et ça, ça vaut clairement autant pour la MoFo, la MoCorp, vivaldi (la boîte derrière) ou Alphabet.
Si un navigateur proposait, nativement un service de synchro qui soit configurable sans aller modifier à la main le about:config (que je considère l'équivalent de regedit, en moins bien foutu), j'y réfléchirais.
Je viens de regarder, ce n'est pas le cas de firefox: dans les préférences, il ne semble pas y avoir moyen de renseigner une URI de référence pour «sync».

c'est quoi la part des utilisateurs qui diraient "bouh vilains méchants" avant d'installer Chrome (mais "à contre-cœur", bien entendu) ?

Ben vois-tu, déjà je pense que tous les utilisateurs de vivaldi ou opera râleraient sévère. Ceux qui utilisent chromium sur Debian feraient la gueule, et je n'ai aucun doute que ça finirait à ce que Debian maintienne chromium. Probablement avec l'aide des devs de vivaldi et opera, ainsi que d'autres ici et la (otter browser, peut-être? Tiens, ça fait longtemps que j'ai vérifié ce qu'il vaut…).

Ça n'est certes pas au niveau des devs de Firefox, donc le résultat serait certainement à la ramasse comparé à Chrome, mais je pense que pas mal d'utilisateurs de ces solutions préféreraient largement ça. De ce que j'ai lu, il semble (basé sur le très sérieux indicateur pifométrique(tm), édité par la société très professionnelle MyFeelingCorp) que les utilisateurs de vivaldi me ressemblent sur un point: il préféraient utiliser un opera 12 non maintenu, plutôt que firefox ou chromium ou opera-blink, après tout.

Mais on est dans l'idée du « something like 64k ».

Oui, clairement. Et je soupçonne cette limite d'avoir une raison d'être de type (oui, je sais, c'est vieux, mais c'est un des docs avec lesquels j'ai appris à coder début 2000 :) et en français s'il vous plaît!) "on copie la ROM BIOS dans la RAM pour l'exécuter, sans nettoyer derrière, voire en réutilisant" des très, très vieilles applications, qui du coup ont un intérêt à mapper cette plage mémoire.

/------------------------\        \              \
|   64ko BIOS            |FFFFFFH |              |
|   carte mere           |FF0000H |zone dupliquee|
|------------------------|        | de 0E0000H   |
|Libre extension         |FEFFFFH |  a 0FFFFFH   |
|BIOS carte mere         |FE0000H |              | 
|------------------------|        /              |
|                        |FDFFFFH                |
|     Libre              |                       |
|  extension RAM systeme |                       |
|                        |100000H                |
|------------------------|                       /
|       128ko BIOS       |0FFFFFH                \
|      ROM carte mere    |                       |
|                        |0E0000H                |
|------------------------|                       |
|    Libre extension     |0DFFFFH                |
|    BIOS cartes ext     |0C8000H                |
|------------------------|                       |
|          32ko          |0C7FFFH                | 1Mo
|    extension BIOS      |                       |
|    ROM video VGA       |                       |
|                        |0C0000H                |
|------------------------|                       |
|         256ko          |0BFFFFH                |
|       RAM video        |                       |
|                        |0A0000H                |
|------------------------|                       |
|        128ko           |09FFFFH                |
|   extension RAM systeme|                       |
|                        |080000H                |
|------------------------|                       |
|   512ko RAM Systeme    |07FFFFH                |
|                        |000500H\               |
|                        |       | Reserve BIOS  |
\------------------------/000000H/               /

Cela dis, je n'ai aucune certitude (j'avais lu pas mal de trucs sur le boot à l'époque, comprendre les séquences initiales m'a toujours botté…) ça date trop.

Très probablement.
En l'occurrence, on parle de synchroniser les bases de données sous-jacentes, n'étant pas utilisateur, je ne sais pas si la connection se fait en permanence ou ponctuellement, mais même le cas du "en permanence", en pratique, tu ouvres une connection TCP/TLS, dès qu'un passe ou un truc est ajouté/supprimé, tu balances ton message au serveur, qui redonde sur les autres clients connectés.
Quand un client s'ouvre, il récupère son retard, quand un client se ferme, il vérifie (par acquis de conscience) que tout est OK.
Rien de bien sorcier à priori.

De l'autre côté, tu as l'UI. La, je me risquerais déjà pas à implémenter la gestion des onglets, des boîtes de dialogues et tout le toutim sans une bibliothèque (c'est ce qu'ils font d'ailleurs, gtk me semble?). Bon, on peut déléguer à une lib, mais il reste à faire une UI qui plaise et qui soit portable et qui s'intègre pas trop mal dans les OS supportés. Très, très difficile ça.

Et le pire, c'est le rendu des pages elles-mêmes. Tu dois interpréter/compiler 3 langages, dont l'un est "turing-complete". La complexité par rapport aux 2 autres éléments est nettement supérieure, sans même y ajouter de gestion des plugins et des hooks.

c'est un prérequis […] pour avoir accès au port 80.

Perso, sur mon serveur, j'ai dans /etc/runit/2 (entres autres):

iptables -t nat -A PREROUTING -i ens3 -p tcp --dport 80  -j REDIRECT --to-port 8080
iptables -t nat -A PREROUTING -i ens3 -p tcp --dport 443 -j REDIRECT --to-port 8443

Puis dans le sv/httpd/run:

#!/bin/sh

. /etc/runit/common
exec ./darkhttpd /home/user/www

Et: sv/httpsd/run:

#!/bin/sh

. /etc/runit/common

exec hitch --log-level=2 '--frontend=[51.178.51.166]:8443' '--backend=[51.178.51.166]:8080' https.pem

Bref, je vois pas en quoi c'est un problème, de pas être root. Bon, ce serveur est un jouet mal géré, faut que je nettoie, mais quand même, pas grand chose n'a ma confiance pour être lancé avec les droits root dessus.

Je sais, les processus peuvent drop les droits, en théorie. Sauf que bon, même si j'essaie d'aller lire le code un minimum, je trouve tellement plus simple qu'il n'aient pas à le faire eux-mêmes, ça m'évite d'aller lire le code en détails.

Non, ça ne répond pas à la question du forum^W journal, certes, mais bon, ça répon au "besoin d'être root" par l'exemple.

Non, c'est pas vivable. donc… sudo su - root FTW.

Utiliser sudo -i fait le job aussi, non?

Vu la "customabilité" de sa méthode de découverte (pkg-config, un fichier .cmake, autre-chose-fais-toi-plaisir ?)

Yep. Et les .cmake qui sont préférés, sont clairement pas aussi simples à écrire que les .pc utilisés par pkg-config. Je regrette personnellement que tant de projets se basent sur les .cmake (certes, pkg-config existe que sous linux, et probablement *BSD, mais tout de même), d'ailleurs.

Clairement, ça donne envie. Gentoo, hein… non pas que j'ai jamais eu envie, certes, mais bon,ma machine est un peu plus musclée qu'avant, et idem pour mes connaissances… pourquoi pas…

ne vérifie pas que le binaire soit déjà dans le $PATH

Sauf qu'il y a de très, très grandes chances que le binaire ne soit pas dedans. Le %PATH% sous windows était une grosse blague, a vent, et même en supposant que ça ait changé, parce que justement maintenant il y a un gestionnaire de paquet un peu moins mal foutu, rien ne me permets de supposer que le %PATH% est à jour (il me semble que c'est comme ça, et non … laissez-moi profiter aussi :)).
Pour rappel, on parle du système pour lequel de nombreux logiciels sont encore compilés et empaquetés pour du 32 bits! en 2021…

C'est la qu'est l'os…

Moi qui croyais que l'os était à côté du volet, me voila bien embêté!

Bon, je dis ça en blaguant un peu plus qu'à moitié, parce que bon… l'instance de forge en question semble être resté coincée dans les années 90… mais je pense qu'il y a pas plus libre, en gratuit.

C'est hébergé par les gens de GNU, mais le nom vient du fait que c'est pour les projets certes libres, mais pas sous leur ombrelle.

Après, si tu veux du pas gratuit mais libre, je dirais sourcehut, qui a une instance payante. Au pire tu peux l'héberger toi-même (comme tu pourrais t'héberger un redmine ou trac ou…) mais bon, ça implique un (léger) coût financier et temporel (location de server + location de domaine pour le coût financier, et pour le temporel, ben faut installer et administrer, pas sûr que ça en vaille le coup).

Peut-être qu'il existe des gens qui fournissent des instances pour fossil, ça serait vraiment pas mal, mais j'en ai jamais entendu parler.
Ça serait vraiment pas mal, parce que du coup fossil, c'est dépôt de source, bugtracker, wiki, blog, le tout, avec un seul fichier à trimbaler, déjà transportable et fonctionnel sur linux, windows et les BSD, minimum.
L'avantage, c'est l'hyper-décentralisation du truc, contrairement à toutes les autres solutions.

Si on suit ce raisonnement, alors la notion même d'apprendre linux n'a pas beaucoup de sens.
À la rigueur, on devrais parler de GNU/Linux, ou de Linux sur le bureau… parce qu'il existe de très nombreux matériels utilisant linux sans GNU, sans bureau (mais avec écran et périphérique de saisie), et ils auront leurs propres réglages noyau, leur couches d'abstractions de config (buildroot doit proposer un minimum d'outils j'imagine? J'ai vu l'autre jour sur #busybox quelqu'un penser que /etc/init.d était géré/rempli par busybox itself après tout…)?

J'espère que ces explications éclaireront mon propos, et surtout permettront aux gens de comprendre qu'il n'y a aucun jugement ici

T'inquiètes, mon propos n'étais absolument pas de ce type.

Je me posais vraiment la question sur ce point précis, puisque je l'ai vu passer dans un bugtracker: un bug spécifique à Slackware, de mémoire non rencontré sur gentoo, et je ne sais pas pour LFS mais de toute façons, LFS c'est pas une distro.

Pour le reste, je rejoins en partie ton avis, mais je considère personnellement que les réglages du noyau spécifiques à une distro sont… spécifiques à la distro, justement, d'autant plus s'ils ont un impact sur le userland.

Dans ce cas précis, non, ça ne sera pas la seule application, j'en ai vu d'autres listées sur le wiki de debian (pas beaucoup, certes, moins d'une dizaine) et on parle au final d'un truc assez spécifique.

La ou ça serait une faille de sécurité, mais pas un "trou béant" au final, c'est si l'application fait des accès mémoire foireux (pas improbable, je sais), alors que typiquement, un émulateur de système (DOS, par example) utiliseras les pages basses de la mémoire par simplicité/réalisme.
Ici, unvanquished utilise NaCL pour exécuter le code des mods. Je ne connais pas assez les détails, mais je ne serais pas surpris que ça soit la cause racine, et je serais surpris que seul unvanquished ait utilisé NaCl.

J'aurai bien aimé voir la valeur par défaut de slackware, ça m'aurait permis d'essayer de raisonner un peu sur le "ils savent configurer un noyau mais on le savait déjà". Les mesures de mitigations, pour moi, peuvent vite devenir cause de code legacy oublié de tous quand les raisons n'en sont pas connue (bus factor).

Oui, mais non.

Quand je visite un site, je "signe un contrat". Ici, c'est un site qui vient pomper les autres, sans me demander mon avis ni informer personne.
D'ailleurs, je doute que ça soit légal, en europe (il faut explicitement accepter, après tout), justement. Bon, je t'avoues ne pas aller voir tes liens, perso je me contente de rien mettre de vraiment sensible sur le net, mais ça m'intrigue quand même.

Il fallait lui apprendre le C ou le C++, ça l'aurait bien encouragé à franchir le pas: coder en C ou C++ sous windows, c'est juste l'enfer, quand il faut installer toutes les libs au bon endroit puis les configurer une par une dans l'IDE…

si tu dois te limiter aux paquets Elementary/TrisquelOS

Bah, déjà, vu que ton wifi ne marchera pas, vu que de nos jours, il n'y a plus de prise ethernet ni de lecteur externe, et que la tendance est à la disparition des prises, y compris les USB, un jour, tu finiras par ne plus pouvoir les utiliser pour accéder à internet. Donc, pas de mises à jour: problème résolu, non? :D

Une entreprise configure son active directory, ce qui implique des réglages au niveau domaine.
L'auteur montre qu'on peut désactiver, tu penses vraiment que quelqu'un qui gère le SI d'une entreprise est incapable de faire ça?

Après, c'est vrai, il y a aussi les entreprises ou chacun est root sur sa machine, tout le monde a accès au (même) code wifi, peut sniffer tout ce qui passe sur le broadcast, dont le LAN est une cascade de switch formant une toile d'araignée et qui ne paye personne pour s'occuper du SI.
Mais perso, ces entreprises la, je me dis qu'en vrai, elles en ont rien à foutre, et du coup mieux vaut que les gens chopent un maximum de logiciels sur le dépôt Debian Windows, question de sécurité… à moins que tu n'aies jamais connu de PC dont la moitié de la hauteur de l'écran du navigateur web (pas juste IE, FF était touché aussi) était blindé de "toolbar", idem pour le systray rempli de malwares? Tu en as, de la chance. Dis, tu me files l'adresse de ce monde de bisounours? Ça m'intéresse…

Du coup, question certainement bête, mais ça marche comment, le «droit à l'oubli», avec ces systèmes d'archivages longue durée?

Non parce que hein, facebook, linkedin, google, etc sont scannés aussi j'imagine?
Certains espaces ne serait-ils pas destinés à être tels des mandala, et ne serait-ce pas mieux qu'ils le restent?

je ne peux le faire qu'avec Linux et cgroupv2 (qui lui exige Systemd)

Vraiment? Ce n'est pas du tout ce que j'ai lu, au contraire même. J'ai plutôt lu (entres autres) que les développeurs de systemd voulaient qu'un seul processus ait la maîtrise complète des cgroups, mais que ça avait été refusé.

De ce que je sais, les cgroups, c'est «juste un système de fichiers» qui peut être manipulé même en shell (si quelqu'un est assez motivé), et jusqu'à preuve du contraire, aucun shell ne dépend de systemd…

Du coup, je suis preneur de la littérature qui explique que cgroupv2 requiert systemd. Tu aurais des liens?

Et donc oui, la Slackware propose des noyaux Linux paramétrés, ce qui - je pense - ne surprendra personne…

Les questions sont plutôt:

1) quel est le réglage de slackware pour ce réglage-ci
2) si, à ce qu'il semblerait, ce réglage est bel et bien trop haut, pourquoi, compte tenu du fait que ça casse des applications?

Dans la même veine, on pourrait arguer que, si ce bug est bien spécifique à slackware (et ses réglages, dont je ne remets pas en cause la légitimité), alors utiliser slackware ne permettrait-il pas, tout comme debian (ou arch, ou fedora, ou k1ss, ou…), non pas «d'apprendre linux» mais bien d'«apprendre slackware»?

[edit]

oups, j'aurai du lire tout avant :)

La Slackware ne fait pas de choix pour toi : un paquet Slackware s'installe et se paramètre de la façon dont les auteurs du logiciels l'ont prévus.

Du coup, question, c'est combien la valeur par défaut utilisée par le kernel de slackware, pour le paramètre mmap_min_addr?

Si c'est la même valeur que la version par défaut du noyau, ça devrais être 0:

mmap_min_addr

This file indicates the amount of address space which a user process will be restricted from mmapping. Since kernel null dereference bugs could accidentally operate based on the information in the first couple of pages of memory userspace processes should not be allowed to write to them. By default this value is set to 0 and no protections will be enforced by the security module. Setting this value to something like 64k will allow the vast majority of applications to work correctly and provide defense in depth against future potential kernel bugs.

Le gras est de moi.

Pourtant, en me promenant sur les internets, je suis tombé sur ceci:

Unvanquished failed to start on Slackware 14.2 #944

Et le fix:

 if (problemDetected) {
        Sys::Error("Your system is configured with a sysctl option which makes the game unable to run.\n"
                   "To permanently fix the configuration, run the following commands:\n"
                   "\n"
                   "    echo vm.mmap_min_addr=65536 | sudo dd of=/etc/sysctl.d/daemonengine-nacl-mmap.conf\n"
                   "    sudo /sbin/sysctl --system");
    }

En gros: configurer le système pour mettre cette valeur à 64Kio.

Je trouve ça amusant vu que justement tu citais unvanquished :)