pulkomandy a écrit 1703 commentaires

  • [^] # Re: "panne mondiale"

    Posté par  (site web personnel, Mastodon) . En réponse au journal Gitlab, Github & Stackoverflow sont inaccessibles simultanément. Évalué à 5. Dernière modification le 09 juin 2021 à 08:58.

    Euh, je me connecte sans problème avec mon compte github ou gitlab.com sur plein d'autres instances Gitlab (et même sur certaines instances de Gerrit) sans problème.

    Mais du coup, quand github ou gitlab.com sont cassés, ça ne marche pas non plus.

  • [^] # Re: Et pourtant ...

    Posté par  (site web personnel, Mastodon) . En réponse au journal Gitlab, Github & Stackoverflow sont inaccessibles simultanément. Évalué à 6. Dernière modification le 08 juin 2021 à 22:30.

    Heureusement que Github n'utilise pas SVN transporté par HTTP :)

    Ça me rappelle des souvenirs de projets hébergés sur BerliOS ou régulièrement on ne pouvait pas faire de commits le week-end parce que… le disque dur du serveur était plein. Et il fallait attendre le lundi pour que l'admin fasse un peu de ménage.

    Ça a bien changé l'informatique, quand même.

  • [^] # Re: Mon père automaticien me raconte souvent un histoire du même genre...

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche La voiture allergique à la glace à la vanille, et autres bugs. Évalué à 6.

    Pour les deux qui sont listées dans la dépêche, au moins, la trame de l'histoire est vraiment trop proche (si on lit les versions originales en anglais). Mon avis est que quelqu'un a raconté la même histoire en la modernisant, en remplaçant le lecteur de disquettes par une XBox.

    D'où l'ajout du paragraphe sur les légendes urbaines en introduction (pas seulement pour cette raison, en fait: l'histoire de la glace à la vanille, a priori, c'est aussi du flan).

    Pour cette histore de rayon de soleil mal placé, j'ai cherché un peu, mais je n'ai pas trouvé de sources plus anciennes que la newsletter de BeOS. Celle-ci présente déjà l'histoire comme un "conte de fées" et ne prétend donc pas être très sérieuse. Mais j'avoue m'être souvenu de cette histoire comme si c'était réellement arrivé directement au responsable des tests de BeOS, avant de retrouver et de relire ce numéro de la newsletter et de me rendre compte que j'avais donc fait partie de la propagation de la légende urbaine.

    Finalement c'est peut être l'aspect le plus intéressant de ces histoires: mener l'enquête pour trouver d'où elles viennent, comment elles se propagent, et comment elles évoluent au cours du temps.

  • [^] # Re: Je m’étonne

    Posté par  (site web personnel, Mastodon) . En réponse au journal De la notation sur les contenus et les commentaires. Évalué à 9.

    Sans cela, pourquoi ne voteraient-ils que ‘inutile’ ? Ça semble tellement négatif comme approche…

    Un vote "pertinent" sur un commentaire qui est déjà visible, ça ne change pas grand chose. Un vote "inutile", ça permet de masquer un commentaire s'il atteint une note négative.

    Le vote "inutile" est donc plus utile que le vote "pertinent"?

    Il faudrait regarder plus en détail, mais ça me semble pas délirant de se dire que des gens n'utilisent le vote que pour masquer les messages vraiment inutiles (spam, par exemple). Et quand on les utilise dans cette logique, le vote pertinent ne sert à rien, ou éventuellement à rendre visible un commentaire qui ne l'est normalement pas, mais c'est un cas qui doit se produire assez rarement, je pense (difficile de savoir, puisqu'on a pas d'historique des votes sur la durée de vie d'un commentaire?).

  • [^] # Re: Le plantage horaire

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche La voiture allergique à la glace à la vanille, et autres bugs. Évalué à 10.

    On peut mélanger les deux:

    Pourquoi les informaticiens confondent noël et halloween?

    Parce que 25 DEC = 31 OCT

  • [^] # Re: Le plantage horaire

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche La voiture allergique à la glace à la vanille, et autres bugs. Évalué à 4.

    Je pense que je vois le problème mais je ne veux pas donner la réponse tout de suite pour laisser les autres lecteurs chercher un peu :)

  • # Une autre histoire

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche La voiture allergique à la glace à la vanille, et autres bugs. Évalué à 10.

    Je viens de lire l'histoire de l'imprimante qui ne fonctionne que quand la porte de da pièce est ouverte:

    https://twitter.com/ASeemueller/status/1351137587960930304?s=20

  • [^] # Re: opportunité pour les entreprises de changer/s'améliorer

    Posté par  (site web personnel, Mastodon) . En réponse au journal Je veux pas y retourner. Évalué à 6.

    Inversement, l'équipe commerciale dans mon entreprise sait très bien jouer le discours "votre projet est techniquement pointu et compliqué, on a mis nos meilleurs geeks-en-T-shirt sur le coup" aux clients et a priori ça convient plutôt bien à tout le monde. Chaque entreprise peut choisir de donner l'image qu'elle veut.

  • [^] # Re: Ni pour, ni contre, on s'y prépare

    Posté par  (site web personnel, Mastodon) . En réponse au journal Je veux pas y retourner. Évalué à 5.

    Il n'y a pas de problème à avoirune équipe de développeurs en télétravail, et effectivement, y'a plein de projets de logiciels libre qui fonctionnent comme ça et qui fonctionnent très bien.

    Le truc, c'est que ça demande une organisation complètement différente. Il faut faire de la communication asynchrone (par mail, via un bugtracker, etc) et de la documentation écrite (messages de commit, wiki, …) alors que quand on a tous les dévelopeurs dans la même pièce et dans le même fuseau horaire, on peut faire du peer programming, échanger des infos par oral, etc.

    Il n'y en a pas un qui marche mieux que l'autre, c'est juste que c'est différent.

    Là ou ça devient compliqué, c'est quand on a une équipe qui mélange les deux modes. Parce que la cummunication asynchrone avec le collègue assis juste à côté, c'est pas pratique. Parce que la visiocunférence avec le collègue qui est à l'autre bout de la planète à un horaire improbable, c'est pas génial non plus. Et donc c'est compliqué d'avoir une organisation qui convient à tout le monde.

  • [^] # Re: approximation trompeuse

    Posté par  (site web personnel, Mastodon) . En réponse au journal Je veux pas y retourner. Évalué à 3.

    Il faut comparer une équipe de N personnes avec N équipes de 1 personne, pour voir l'efficacité à resources constantes

  • # étiquettes

    Posté par  (site web personnel, Mastodon) . En réponse au lien Hackaday: vendu!. Évalué à 3.

    Bonjour la modération,

    Je pense que l'étiquette "revente" https://linuxfr.org/tags/revente/public pourrait être masquée au profit de "vente"? Ou inversement. En tout cas ça étiquette des choses assez semblables.

  • [^] # Re: Pas tant qu'ils seront gonflés à l'hélium

    Posté par  (site web personnel, Mastodon) . En réponse au lien Retour des dirigeables géants, une solution écologique pour le transport?. Évalué à 5.

    Facile: ça sera réglé quand on saura faire des centrales électriques à fusion nucléaire!

    Plus sérieusement, quelqu'un a déjà fait le calcul et si je comprend bien après un survol rapide de l'article, la production d'hélium dans une centrale à fusion ne suffirait même pas à couvrir ses propres besoins en hélium pour le refroidissement.

    Cet article donne les infos sur les réserves d'hélium disponible, également.

  • # Bonne nouvelle

    Posté par  (site web personnel, Mastodon) . En réponse au lien GCC fait sauter l'exigence d'attribution du copyright à la FSF. Évalué à 10.

    Nous allons enfin pouvoir intégrer les changements nécessaires pour utiliser gcc sous Haiku. Ces changements remontent à très longtemps (cela a commencé à l'époque de gcc2…) et ont toujours été diffusés sous licence GPL, mais tous les auteurs n'ont pas cédé leurs droits à la FSF. Aujourd'hui il serait difficile de recontacter tout le monde pour obtenir cet accord.

  • # Bleu

    Posté par  (site web personnel, Mastodon) . En réponse au lien Capgemini et Orange créent un cloud souverain Azure et Microsoft 365 - via sebsauvage. Évalué à 3.

    Donc Orange crée une entreprise qui s’appelle Bleu. Je sais pas trop pour le nuage souverain, mais en tout cas, on va pas tarder à avoir l'arc-en-ciel au grand complet!

  • # "ruisseaux"

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche Le protocole QUIC désormais normalisé. Évalué à 10.

    Qui utilise le mot "ruisseau" pour traduire "stream"? Est-ce que "flux" ne serait pas plus usité en français?

    Je veux bien qu'on essaie d'éviter les anglicismes, mais les traductions littérales approximatives, c'est pas toujours mieux pour rendre les choses lisibles et compréhensibles…

  • [^] # Re: Différence entre les langages

    Posté par  (site web personnel, Mastodon) . En réponse au lien J'avoue que je n'avais pas pensé à ce type d'utilisation quand je me suis mis à Nim. Évalué à 3.

    Les antivirus détectent des "signatures" assez vagues finalement. Par exemple, la plupart des exécutables compressés sont détectés comme suspects. Avoir un compilateur qui utilise des instructions un peu différentes ou pas mises dans le même ordre peut alors être suffisant pour échapper à ce type de détection générique.

    Mais je pense que l'argument est plutôt du côté des outils d'ingénierie inverse comme Ghidra. Ce genre d'outil connaît le fonctionnement des compilateurs courants, et permet par exemple de regénérer du code C++ à partir du binaire, en détectant les vtable car le code pour y accéder est facilement reconaissable. Si un hrogramme utiliseun autre langage, il faut développer les outils nécessaires dans Ghidra (ou équivalent) pour reconnaître les bouts de codes typiques et regénérer un code source lisible correspondant.

    On doit pouvoir s'y retrouver à peu près sans ça (en générant un truc qui ressemble à du C) mais ça sera moins lisible. Par exemple il peut y avoir des pointeurs de fonctions dans tous les sens. Oubien des trucs qui ne se représe/tent pas bien en C, comme des coroutines.

    Rien de vraiment bloquant, mais ça fait perdre du temps (ou gagner du temps pour l'attaquant).

  • [^] # Re: Triste

    Posté par  (site web personnel, Mastodon) . En réponse au journal Multiple démissions dans l'équipe du réseau IRC Freenode. Évalué à 5.

    Bon XMPP n'est peut être pas parfait mais ça m'étonn rait qu'on trouve beaucoup de clients ou de serveurs qui ne soient pas capables de remplacer IRC, ce qui était le sujet de départ.

    Et d'autre part, avoir un protocole qui n'évolue pas trop vite, ça permet aussi d'avoir plus de clients et de serveurs qui arrivent à suivre. Si ça change trop tout le temps, il finit par y avoir une seule implémentation qui décide de tout.

    Exemples qui me viennent en tête: Haskell avec le compilateur ghc qui a plein d'extensions par rapport à la spécification. Et peut-être bientôt, Chrome avec le web…

  • [^] # Re: plus de liens

    Posté par  (site web personnel, Mastodon) . En réponse au journal Multiple démissions dans l'équipe du réseau IRC Freenode. Évalué à 5.

    J'imagine que Discord a attiré pas mal les projets de jeux vidéo libres parce qu'il est populaire du côté "jeu vidéo"? Mais ça semble être moins le cas pour les autres projets (à vue de nez pour les quelques uns que je suis, hein).

    Mais bon, globalement j'imagine que effectivement on va voir des projets migrer aussi vers Slack ou d'autres solutions proprio. Et aussi probablement vers des solutions libres qui ne manquent pas: Matrix, Signal, XMPP, Mattermost, Zulip, RocketChat, …

  • [^] # Re: plus de liens

    Posté par  (site web personnel, Mastodon) . En réponse au journal Multiple démissions dans l'équipe du réseau IRC Freenode. Évalué à 3. Dernière modification le 20 mai 2021 à 19:32.

    Pour un grand nombre de projets de logiciels libres sur Freenode, la migration a plutôt l'air de se faire vers d'autres serveurs IRC (principalement libera.chat et oftc), soit vers Matrix. Ce qui semble cohérent avec la culture du logiciel libre, au moins.

    Des exemples de communautés qui ont migré vers Discord?

  • [^] # Re: Triste

    Posté par  (site web personnel, Mastodon) . En réponse au journal Multiple démissions dans l'équipe du réseau IRC Freenode. Évalué à 4.

    Il va falloir prévenir https://irc.com parce que visiblement ils ne sont pas au courant!
    Et ceux de https://ircv3.net au passage.

  • [^] # Re: Triste

    Posté par  (site web personnel, Mastodon) . En réponse au journal Multiple démissions dans l'équipe du réseau IRC Freenode. Évalué à 8. Dernière modification le 20 mai 2021 à 14:50.

    Qu'est-ce que tu appelles un bon client natif ?

    Un client natif pour Haiku c'est un client qui utilise nos APIs natives pour l'interface graphique. Donc pas de Qt et encore moins de GTK (parce qu'on a un port de Qt fonctionnel, mais pas encore de GTK).

    Au niveau des fonctionnalités, je ne suis pas très exigeant dans ce cas précis, puisque le but est de remplacer IRC. Mais en gros on a besoin de:

    • Un client utilisant l'API native pour l'interface graphique
    • Logiciel libre
    • La possibilité d'avoir des utilisateurs sans création de compte (car le client est préinstallé sur Haiku et ça permet à n'importe quel utilisateur de nous contacter facilement)

    Et dans les trucs sympas supplémentaires: la possibilité d'accéder aux archives de messages du canal.

    Enfin, rien que XMPP ne sache pas déjà faire. Je travaille sur le client en question (http://github.com/haikuarchives/renga) et il est déjà pas mal avancé mais il manque encore quelques trucs (notifications sonores et visuelles pour les messages reçus, par exemple, mais plein d'autres choses aussi). Il faut que je me dépêche de finir avant de me faire rattraper par les gens qui développent un client Matrix, c'est tout :>

    Le but dans un premier temps est d'avoir au moins de quoi remplacer IRC, et ensuite on verra pour ajouter plein de fonctionnalités plus poussées.

  • [^] # Re: Triste

    Posté par  (site web personnel, Mastodon) . En réponse au journal Multiple démissions dans l'équipe du réseau IRC Freenode. Évalué à 4.

    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.

  • [^] # Re: Triste

    Posté par  (site web personnel, Mastodon) . En réponse au journal Multiple démissions dans l'équipe du réseau IRC Freenode. Évalué à 6.

    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.

  • [^] # Re: Triste

    Posté par  (site web personnel, Mastodon) . En réponse au journal Multiple démissions dans l'équipe du réseau IRC Freenode. Évalué à 10.

    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.

  • [^] # Re: La migration a commencé vers libera.chat ,GeekNode, OFTC, etc.

    Posté par  (site web personnel, Mastodon) . En réponse au journal Multiple démissions dans l'équipe du réseau IRC Freenode. Évalué à 6.

    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…)