pulkomandy a écrit 1957 commentaires

Il faudrait savoir, le problème, c'est qu'il appartient au passé, ou qu'il continue d'évoluer?

Je veux bien entendre les deux critiques séparément, mais les deux en même temps, ça me semble compliqué à tenir comme argumentation.

Et pourtant, quand on regarde les chiffres, il y a ~750 serveurs sur https://compliance.conversations.im/ (à comparer avec les 487 réseaux IRC)

Nombre de fédérations IRC publiques: 487
Nombre de fédérations XMPP publiques: 1

Il faut comparer ce qui est comparable :)

J'ai pas cherché les stats sur le nombre de serveurs IRC dans chaque réseau, mais à mon avis ça dépasse facilement les 750 au total.

Personellement je pense que avoir 1 seule fédération (et donc des identifiants qui fonctionnent partout et la possibilité de rejoindre n'importe quel salon), c'est mieux. Mais XMPP reste un petit réseau, malheureusement.

Pour Haiku on se pose la question (entre XMPP et Matrix) et pour l'instant le sujet est suspendu en attente d'avoir un bon client natif pour l'un ou pour l'autre.

C'est plus compliqué que ça pour Freenode. Il y a des éléments qui sont centralisés parce que techniquement y'a pas trop le choix: les noms de domaines, et le site internet. Il y a des éléments dont la gestion est répartie entre plusieurs admins qui y ont accès (les services chanserv, nickserv, etc). Il y a des éléments qui sont complètement décentralisés (les serveurs IRC qui sont hébergés à différents endroits et gérés par différents "sponsors").

Là il y a eu prise de contrôle sur le site web et le nom de domaine. Les admins des services ont démissionné en masse. Pour les serveurs et les sponsors, on va voir ce qu'il se passe, est-ce qu'ils vont rester avec le nouveau freenode, décider de se fédérer avec le nouveau libera.chat, ou bien arrêter de sponsoriser le truc parce qu'ils ont autre chose à faire. Ça va sûrement prendre un peu plus de temps pour qu'il y aie une éventuelle réaction de ce côté là.

Et enfin il y a les usagers du réseau, qui eux aussi peuvent choisir de rester ou de migrer. L'avantage d'IRC c'est qu'il y a de nombreux autres réseaux et que la migration n'est finalement pas si complexe que ça (avantage lié à la simplicité du service et à la quasi absence de stockage de données). Sans parler de ceux qui ont profité de l'occasion pour migrer vers un autre protocole.

Il n'empêche qu'en pratique, la personne qui détient les noms de domaine et le site web, elle possède le nom "freenode". Mais finalement, on dirait bien qu'il ne va lui rester que le nom, et qu'une grande partie des usagers sont en train d'aller voir ailleurs.

Haiku est en train de déménager vers OFTC: https://www.haiku-os.org/news/2021-05-19_haiku_is_moving_to_oftc/

(si jamais l'envie vous prend de venir discuter…)

L'article parle également de l'architecture de Harvard avec plusieurs arguments qui expliquent pourquoi ça ne suffit pas:

• D'abord, l'architecture de Harvard "pure" ne permet pas de charger du code arbitraire (puisque la mémoire programme est en lecture seule), et donc, ça limite les possibilités.
• Un contournement de cette limitation est possible: ajouter une instruction qui permet d'écrire dans la mémoire programme, mais dans ce cas l'instruction en question peut également être exploitée pour injecter du code, et donc on a rien gagné,
• Sur les ordinateurs récents, il n'est pas rare d'avoir du code interprété (scripts bash, python, javascript, ou tout simplement exécution de commandes sur un prompt shell) et cela pourrait être exploité également,
• Enfin, il existe des attaques dans lesquelles il n'y a pas à proprement parler d'injection de code. Par exemple le "return oriented programming" qui consiste à appeler des petits bouts de code existants et à les enchaîner de façon à faire ce qu'on veut.

En pratique, sur les ordinateurs modernes, on est pas loin d'avoir une architecture de Harvard, avec la MMU qui peut indiquer quelles zones de la mémoire peuvent être écrites et quelles zones peuvent être exécutées (en principe ce ne sont pas les mêmes). C'est apparu sur les processeurs x86 en 2003 par exemple: https://fr.wikipedia.org/wiki/NX_Bit et on peut pas vraiment dire que ça a bouché d'un coup toutes les failles, même si ça a sûrement rendu le travail des vilains pirates un peu plus difficile.

"sans patch possible", vraiment? L'article dit exactement le contraire et propose deux façons de corriger l'implémentation (c'est pas difficile à trouver, c'est le chapitre "Mitigations"):

1) Valider les entrées, en particulier vérifier qu'il n'y a que des 1 et des 0 dedans (la machine représente chaque case par un octet et utilise en interne d'autres valeurs "A" et "B", et ne vérifie pas avant de démarrer l'exécution que le programme ne contient pas autre chose que des 1 et des 0)

2) Spécifier complètement la machine, en gros dans le code il y a des tests du genre if (valeur == 0) { … } else { … } sous-entendant que le else s'exécute pour valeur == 1, mais en fait il s'exécute aussi pour "A" et "B". Donc on peut réécrire le code: if (valeur == 0) { … } else if (valeur == 1) { … } else { erreur }

Les problèmes ne sont pas dans l'idée même d'une machine de Turing universelle, mais bien dans cette implémentation spécifique. Implémentation dont le but était, non pas d'être sécurisée, mais d'être le plus simple possible.

J'utilise vim avec youcompleteme et la première chose qu'il fait avant de charger quoi que ce soit, c'est de me dire qu'il a détecté une config d'autocomplétion dans le projet et de me demander si je veux la charger. Si je dis non, la complétion intelligente et l'analyse de syntaxe sont désactivées.

Je peux également faire une liste verte des dossiers qui sont autorisés (dans laquelle je met mes projets "sûrs" pour ne pas avoir à répondre à la question chaque fois que j'ouvre un éditeur)

Ça m'est arrivé quelquefois de contribuer un peu à une dépêche pour essayer de la faire avancer, et franchement, je pense que ça n'en vaut pas la peine et qu'il vaut mieux supprimer les dépêches inactives avant que plein de gens aient commencé à passer des heures à se demander ce qu'on en fait et à essayer de compléter.

Le travail de remise à jour + les efforts pour essayer d'avoir un truc structuré et cohérent sont trop élevés, si bien que c'est plus simple de repartir de 0.

Je pense par exemple à "la voiture allergique à la glace à la vanille", créée par quelqu'un qui a juste mis un lien vers un site en anglais et demandé la permission à l'auteur de ce site de faire une traduction, et n'a pas donné suite. J'ai rédigé quelques paragraphes dedans, mais ça ne m'intéresse pas plus que ça (sous cette forme en tout cas… il y aurait des choses à dire sur comment les légendes urbaines se forment), j'aurais mieux fait de la laisser mourir.

Maintenant j'éviterai de faire des modifs de ce genre sur les dépêches inactives pour ne pas les garder en vie plus longtemps que nécessaire.

La solution à "y'a trop de code" serait donc d'ajouter du code pour empêcher le code de s'exécuter… intéressant comme approche…

Ouais le coup de l'oomkiller c'est un peu une fausse critique. Il préfère un système qui freeze quand il n'a plus de mémoire (et donc qui te force à killer toutes les applis via un cold reboot), ou un système qui fera le ménage de lui-même dans ce cas ?

Pourquoi ça ferait un freeze?

Sous Haiku, quand il n'y a plus de mémoire, malloc() se met à retourner NULL, et les applications peuvent traiter le problème et afficher un message de type "désolé, y'a plus de mémoire, essaie de fermer une application pour faire de la place".

Et on laisse l'utilisateur (ou l'application elle-même) décider quoi fermer.

Sous Linux, avec l'OOM Killer activé, malloc ne retourne jamais NULL. Et donc les applications n'ont aucune chance de pouvoir intercepter et traiter l'erreur. Elles se font tuer directement.

En effet. Il n'y a que les schémas et pas les typons (il faudrait donc refaire le routage des cartes électroniques), mais c'est déjà pas mal.

Il n'y a pas de license indiquée dans le pdf du schéma, est-ce que la license cc-by-sa de la page s'applique aussi au pdf lié, ou pas?

Ça m'embête un peu de lire que Purism fait du open hardware. Ce n'est pas le cas pour l'instant, les schémas électriques et mécaniques ne sont pas publiés.

C'est la toute dernière étape dans leur "freedom roadmap" ici: https://puri.sm/learn/freedom-roadmap/ et ce n'est pas clair si cette roadmap concerne également les téléphones, ou seulement les PC.

Ça ne dit pas si ces schémas seront publié sous licence open hardware, d'ailleurs. Pour que ce soit du vrai open hardware, il faudrait les mettre sous une licence autorisant d'autres gens à produire le même téléphone ou des versions améliorées.

De plus cette list n'a pas été mise à jour depuis 2018.

Du côté du Pine Phone, c'est un peu mieux puisque les schémas sont disponibles (https://wiki.pine64.org/index.php/PinePhone) mais je ne vois pas d'indication de licence. Et le seul schéma électronique n'est pas suffisant pour en faire du open hardware (il faudrait les typons pour pouvoir produire les cartes électroniques, au moins).

Je prend cette définition sur Wikipedia (https://fr.wikipedia.org/wiki/Mat%C3%A9riel_libre):

« Le Matériel OpenSource (OSHW – OpenSource Hardware) est un terme qui regroupe des artéfacts tangibles — machines, dispositifs ou toutes choses physiques — dont les plans ont été rendus publics d’une telle façon que quiconque puisse les fabriquer, modifier, distribuer et les utiliser. Le but de cette définition est de donner des lignes directrices pour le développement et l’évaluation de licences pour du Matériel OpenSource. »

On y est pas encore, ni pour le Pine Phone ni pour les machines de chez Purism.

Et j'imagine qu'à la base le problème est un simple problème de paramétrage de la commande git. Le mec avait un git config --global user.email "<adresse@gmail.com>" et n'a pas pensé à changer la variable locale sur sa branche locale du repos git du kernel pour y mettre son email pro et son supérieur l'a remis à l'ordre.

Il ne s'agit pas d'un identifiant dans un commit, il s'agit d'une addresse de contact dans le fichier "MAINTAINERS" qui est maintenu à la main et indique qui contacter lorsqu'on veut envoyer un patch pour chaque partie du noyau Linux.

Donc ça me semble difficile de mettre la mauvaise adresse à cet endroit par erreur.

Pour le reste, les commentaires au-dessus sont corrects: a priori c'est comme ça que ça fonctionne aux USA, l'employeur peut avoir des droits y compris sur le code développé sur du temps perso. Ce n'est pas le cas en France.

Pendant 20 ans les moules se sont plaint des journaux bookmark, tout ça pour en arriver là…

Alors en fait, les numéros de ports sont associés à des noms et on peut utiliser par exemple getaddrinfo() pour faire la résolution du nom vers le numéro correspondant.

La RFC https://tools.ietf.org/html/rfc6335 explique les procédures non seulement pour demander la réservation d'un port, mais aussi la façon dont les ports peuvent être révoqués à la demande de la personne qui a fait la réservation, ou sur décision de l'IANA (c'est une nouveauté par rapport aux versions précédentes de la RFC).

Ils ont aussi calculé que au rythme actuel d'allocation des ports, on était tranquilles pour 85 ans avant de devoir ré-allouer des ports. On peut espérer que d'ici là, FTP sera bien mort et enterré?

C'est le premier lien dans le journal, la liste des ports TCP et UDP avec une recherche sur ceux qui sont "réservés". Il n'y a pas plus de détails.

Mais ça n'indique pas l'API "choix d'un port au hasard". Cependant, s'agissant d'une API, c'est plutôt du côté de la spécification POSIX que des RFC qu'il faudrait chercher.

Allez, reste GNOME… Sur le desktop, soit l'endroit où le libre n'a pas percé et il y a KDE au pire si pas de fork si GNU disparaît.

GNOME n'est pas un projet lié à GNU ou à la FSF.

Le seul environnement graphique disponible dans GNU, c'est emacs.

J'ai pas dit qu'ils étaient parfaits, juste qu'ils ont fait mieux que la fsf. Et oui, c'est très facile de faire mieux que la fsf.

Bah pour le coup respecté une demande faite par une minorités (3028 - 1 contre RMS vs 6261 pour RMS) c'est pas non plus tip top.

Ça serait plutôt aux Organisations qui ont signées contre RMS qui devraient remettre en question leur légitimité.

J'en prend quelques unes au hasard parmi la liste des 60 organisations signataires (pour l'instant):

• GNOME
• Framasoft
• GNU Radio
• LineageOS
• Mozilla
• The Tor Project

D'une part, ça fait que chacun de ces votes vaut plus de 1 personne (puisque les décideurs de chacune de ces organisations se sont mis d'accord pour signer), donc la bête comparaison par nombre de signatures, ça marche pas trop. Et d'autre part, Dire que ces gens là ne sont pas légitimes, comment dire, ça me semble un peu osé. Chacune de ces organisations prise individuellement a fait plus pour le logiciel libre ces 20 dernières années que la FSF.

Même à l'intérieur de la FSF et du projet GNU le board de la FSF est lâché par pas mal de monde. Par exemple le projet gcc envisage sérieusement de quitter la FSF et le projet GNU et d'être hébergé ailleurs.

Bon j'ai pas tout compris

Si j'ai bien suivi, le principe est de trier plein d'histoires de "pourquoi rien ne marche en informatique et pourquoi ça sera toujours compliqué" et de les trier par ordre des plus connues aux plus obscures.

Il y a des liens pour chacune d'entre elles, donc si y'a quelque chose qui vous dit rien, c'est l'occasion de cliquer dessus et de devenir un peu plus désespéré sur le fait que toute l'informatique (et par conséquent probablement une grosse partie de la civilisation humaine) tient debout grace à des bouts de scotchs et des ficelles.

Je te rejoins par rapport à tout ceci. Le client Signal est libre, mais pas toutes l'infrastructure derrière, puisque cela repose sur un service centralisé. Il me semble que le client Telegram (officiel) est libre, en tout cas ils contribuent, j'ai l'impression, autant au libre que Signal

Pour Signal, le code du serveur est également libre (sous license AGPL). Pour Telegram, ce n'est pas le cas.

Ça fait quand même une différence (importante ou pas, à chacun d'en décider).

J'en pense que je vais continuer à utiliser XMPP, un système décentralisé avec plein d'acteurs, comme ça si un développeur de lcient ou de serveur ou un hébergeur de serveur fait n'importe quoi, je peux juste changer de crèmerie tout en continuant à discuter avec mes contacts.

Je ne pense pas que les solutions de type "libre mais centralisé" soient très intéressantes par rapport aux solutions non libres.

…et moi je devrais faire un journal sur le portage de ACE de MorphOS vers Haiku (note: projet non libre).

Si ça continue on va avoir plus d'émulateurs que d'utidisateurs potentiels :o)

C'est pas que tu (Zenitram) dis de la merde, c'est que tu emballes le contenu dans de la merde.

En fait c'est une bête histoire de rapport signal/bruit?