Pour Signal, c'est corrigé depuis fin 2019 d'après l'article cité, très peu de temps après le signalement de la faille. Pourquoi citer Signal, de toute les applications concernées, alors que ça fait plus d'un an que cette application spécifique n'est plus concernée ?
Et puis alors, « sur écoute », c'est bon, quoi. Là on sort du domaine « pas très frais » pour sauter à pieds joints dans le domaine du « titre racoleur et moisi ».
Je n'ai pas utilisé eOS (c'est bien /e/ ?), mais je suppose que ça ressemble pas mal à LineageOS + microG que j'ai utilisé, niveau utilisabilité. Je crois que /e/ inclut microG par défaut.
Pour quelqu'un comme moi qui a toujours refusé d'utiliser des applications propriétaires sur le téléphone, c'était plutôt bien. Je recommande à quiconque ayant besoin de rester sur Android pour le moment d'utiliser ça, ou LineageOS + microG.
Cela dit, il y a un truc que tous ces systèmes ne dégooglisent pas : c'est la feuille de route d'Android. C'est important, parce qu'il n'est pas dans l'intérêt de Google. En pratique, dans les conséquences, on a :
des fonctionnalités (de plus en plus ?) Google qui ne sont pas implémentées en libre (le Face Unlock par exemple, le Gesture typing, et certainement plein d'autres choses)
des choses appréciées qui sont retirées (la possibilité d'exécuter des programmes qu'on compile sur le téléphone lui-même, si on utilise Termux par exemple), ou un système chrooté (?)
J'ai beaucoup d'espoir que les systèmes libres alternatifs à Android et iOS décollent et deviennent utilisables / fiables au quotidien pour un assez grand nombre de gens, et qu'ils permettent de faire confortablement ce qu'on attend aujourd'hui d'un téléphone : appels, SMS, Navigation GPS, surf, Photos, chat… On n'y est pas encore, mais il y a eu un sacré progrès avec la communauté qui s'est formée autour du PinePhone et du Librem 5.
Il y a encore du chemin, en particulier sur les versions du NDK disponibles et le sdkmanager qui sert à automatiser l'installation, mais ça permet déjà de faire des choses.
il y a aussi toutes ces applications libres qui ont la fâcheuse tendance sous Android à contenir des blobs propriétaires, on peut retrouver des versions déblobées sur F-Droid.
Et sinon, comme alternative à l'écosystème Android, il y a les téléphones sous GNU/Linux qui pointent le bout de leur nez et qui sont prometteurs à défaut d'être à 100% utilisables.
Un des commentateurs cite la phrase "Mapbox proudly embraces our open source roots" présente sur leur site. L'employé répond qu'il a écrit ce paragraphe et qu'il est d'accord avec la décision de changer la licence de Mapbox GL JS. Le commentateur répond qu'il est d'accord avec les entreprises choisissant de faire du non libre, mais qu'il trouve qu'avec la fermeture d'un projet open source avec une communauté active, la pilule est dure à avaler.
L'employé répond :
I won't get into all the context, but I think we should consider whether a community without contributors is a community. GL JS never had major active contributors outside of the company, and there are no self-funded webgl experts with lots of time who are ready to maintain a fork.
OSS, we hoped, was about enabling people and unlocking people's ability to collaborate. It turns out that in 2020, it's mostly helping companies and getting nothing in return. That's not a dynamic you can build a sustainable business on.
Traduction :
Je ne vais pas rentrer dans tous les détails, mais je pense qu'on devrait juger si une communauté sans contributeurs est une communauté. GL JS n'a jamais eu de contributeur majeur actif hors de l'entreprise, et il n'y a pas d'expert WebGL indépendant avec beaucoup de temps prêt à maintenir un fork.
Nous avions espéré que l'open source permettait aux gens de collaborer. Il se trouve qu'en 2020, ça consiste surtout à aider des entreprises et ne rien recevoir en retour. Ce n'est pas une dynamique sur laquelle vous pouvez construire une activité commerciale viable.
Ils empêchent violamment les forks qui se connectent à leurs propres serveurs, mais le code de leur client reste en GPL et forker Signal est autorisé, pourvu que les forks redistribués ne se connectent pas à leurs serveurs.
Oui, ça se comporte comme une ancre classique. Je préfère le comportement du dièse, en parlant d'HN je ne faisais que mentionner un comportement alternatif mais un lien vers un commentaire dans la page c'est ce qui me parait le plus utile.
(edit: je viens de comprendre ce que tu dis)
Alors pour les touches j et k, j'ai remarqué que ça existait et c'est une fonctionnalité sympathique mais je ne l'ai pas intégrée, j'ai plutôt pris l'habitude d'utiliser les flèches de la barre en bas pour naviguer sur les commentaires non lus :-)
De toute façon je crois que j'ai rarement besoin de naviguer entre les commentaires, juste les commentaires non lus.
ça m'épate toujours ces utilisateurs qui ne donnent le lien que vers le commentaire isolé
À mon avis il y a une bonne raison à ça : je pense que l'interface encourage trop à faire ça, et cache trop la bonne manière de faire.
Il m'est arrivé de vouloir récupérer le lien d'un commentaire, et vu que le titre est un lien on se dit vite que c'est la manière de faire sans forcément prêter attention au petit dièse à peine visible à côté. En fait, ça m'est arrivé de chercher à donner un lien vers un commentaire dans sont contexte et pas trouver le dièse… et de me demander à quoi servait vraiment cette page avec le commentaire seul, sans pouvoir accéder à son parent.
Il me parait très rare d'avoir besoin de faire un lien vers un commentaire sans son contexte.
Peut-être que le lien du titre devrait être celui du dièse (et que le dièse devrait disparaître, éventuellement) ? (Quitte à mettre un petit lien plus discret ailleurs pour le commentaire seul si on y tient)
Ou alors adopter le fonctionnement d'Hacker News : un lien vers un commentaire affiche le sous-arbre entier de commentaires, et un lien vers le parent.
Ça me parait ok de faire de la promotion pour un logiciel libre ici. Il faut juste que ça reste intéressant et informatif. Après tout, on est beaucoup à le faire :-)
Je pense que ce serait une bonne idée que dans ce genre de situation que MariePa se présente clairement.
L’application de chiffrement de bout-en-bout est distribuée sous une licence commerciale.
Du coup, cette application n'est pas vraiment un outil open source permettant de sécuriser le travail collaboratif (l'objet annoncé du journal)… c'est bien tout le problème de ownCloud et une des raisons pour lesquelles ses développeurs principaux sont partis développer NextCloud. C'est de l'open core et des fonctionnalités essentielles ne sont pas libres. Il me semble qu'il aurait été beaucoup plus naturel de citer cette dernière solution à la place, qui fournit nativement le chiffrement bout en bout en open source.
Sinon, ce journal manque cruellement d'une mention à Collabora Online, qu'on peut installer sur un serveur que l'équipe de travail contrôle. Je suppose que ce n'est pas e2ee vu que LibreOffice tourne sur le serveur et s'occupe du rendu, par contre les communications sont chiffrées (HTTPS) et tous les bouts sont sous contrôle, ce qui peut suffire selon la situation. Du coup, si l'approche n'est pas vraiment similaire à celle d'OnlyOffice, je pense qu'on peut le présenter comme solution intéressante malgré tout.
le Centre national d'études spatiales a tout simplement demandé à ne pas effectuer les simulations de vol pour ces appareils, ce qui devait ainsi lui permettre d'économiser 800 000 francs sur le coût des préparatifs avant-lancement. Réalisées en laboratoire après la catastrophe, ces simulations ont justement permis de vérifier que l'explosion était inéluctable
C'est sûr que si on ne respecte pas les procédures et qu'on ne lance pas les tests, bah ça peu foirer. À moins d'avoir un code et du matériel prouvé correct, mais bon courage avec ça.
Ou ce passage ?
Après enquête, les ingénieurs du CNES se sont aperçus que par mesure d'économie, le logiciel de navigation de la fusée Ariane 5 était celui qui avait été conçu pour Ariane 4, ce qui a induit une incompatibilité entre le logiciel et le matériel.
C'est sûr que si on ne fait pas correspondre le matériel avec le logiciel, ça peut aussi mal se passer.
Que voulais-tu montrer avec ton lien ? Que les catastrophes sont souvent dues à une succession de décisions foireuses indépendantes des technologies utilisées ? Félicitations, c'est réussi, mais tu aurais pu être plus explicite. Je suis bien d'accord avec toi, c'est triste qu'on continue à faire des économies de bouts de chandelles de ce type, c'est comme si on n'avait rien appris du naufrage du Titanic et c'est regrettable.
Ou alors tu voulais illustrer le fait que Ada est un choix répandu pour concevoir des systèmes industriels embarqués critiques ? Drôle d'exemple pour ça, mais bon pourquoi pas. Un exemple n'est pas vraiment suffisant mais de toute façon je crois qu'on est tous convaincus qu'Ada est un très bon choix pour faire de l'embarqué critique même s'il ne peut malheureusement pas résoudre les problèmes causés par les décisions foireuses donc ce n'est pas très grave.
(et sinon, une discussion honnête et bienveillante, ça te dit ?)
Je n'utilise pas GDM non plus. Mais effectivement, peut-être que les outils GNOME s'attendent à avoir un gestionnaire de sesssion ?
l'objectif des flatpak et autres,soyez honnêtes
Mhm, peut-être, mais ça cherche à résoudre un vrai problème de distribution de logiciels aussi. Cf cette session Q&A avec Linus Torvalds en 2014 où il passe un peu de temps sur le sujet : https://www.youtube.com/watch?v=5PmHRSeA2c8 (ils ne fournissaient tout simplement pas de binaire de Subsurface pour Linux parce que c'est trop compliqué. Un peu con quand même !
Oui, zut, moi aussi, je n'avais pas remarqué que Evince et simple-scan ne fonctionnaient pas sur mon environnement de bureau Plasma… (j'avoue, je n'ai pas essayé de me passer de systemd. Mais pourquoi le faire ? C'est le meilleur système d'init sous Linux !! (ah ah)).
Plus sérieusement :
Il n'y aucune raison ici qui puisse justifier que je dépense du temps et de l'énergie à debug ceci. CE N'EST PAS NORMAL!
Un outil est développé dans un cadre et est fourni gratuitement, tu veux utiliser cet outil mais tu refuses de l'utiliser le périmètre dans lequel il est conçu, très bien c'est ton droit, mais les développeurs n'ont aucun compte à te rendre. Je suis sûr qu'en les aidant ou en leur soulevant le problème de façon intelligente ça peut se résoudre, mais ils ne sont pas plus obligés que toi de déboguer ton environnement. Tu sembles passer un temps fou à casser ton système, ok, alors déjà il ne faut pas s'étonner que des trucs ne fonctionnent pas bien, et aussi, si tu veux utiliser ces applications, tu peux essayer de sortir gdb et strace pour voir d'où vient le problème. Ce n'est pas en vociférant dans le vide que le problème va se corriger tout seul. Les développeurs ne te doivent rien et pour eux, tout marche bien dans le cadre prévu.
Evince et Simple Scan fonctionnent très bien sans Gnome puisqu'ils fonctionnent chez moi, et j'imagine qu'ils fonctionnent également très bien sur Devuan alors ils doivent pouvoir fonctionner sans systemd aussi. Le problème est probablement chez toi.
Ce qui n'est pas normal, c'est passer du temps à casser son système et après venir râler et s'insurger quand les choses ne fonctionnent pas sans même avoir cherché à diagnostiquer. C'est cool de bidouiller, je le fais aussi, mais alors il faut rester lucide et assumer.
Non ! :-P
Mais bonne idée, ça aurait pu.
Le délai d'affichage est complètement arbitraire et n'est pas forcément utilisé par les téléphones. Je ne sais même pas pourquoi il est spécifié.
Justement, le but du E2E n'est-il pas de ne pas devoir faire confiance en l'hébergeur ?
Après je n'ai pas trop creusé, j'héberge ma propre instance, je ne me suis pas trop intéressé au E2E. Globalement, si quelqu'un accède à ma machine, je suis déjà dans la panade.
Je ne sais pas ce qu'il vaut, mais est-ce que ça ne serait pas plus pratique d'utiliser le chiffrement bout en bout de Nextcloud ? (et, éventuellement, appliquer une solution de chiffrement locale qui n'est pas nécessairement par fichier)
Je ne sais pas si le jeu en vaut la chandelle, tout dépend du but, mais en tout cas il est exigeant. Le sujet est intéressant, mais si on veut faire bien les choses, je pense que déjà, la question doit être précisée parce qu'on ne sait pas trop ce qu'on cherche :
que mesure-t-on ?
que compare-t-on ?
quelle définition de green threads utilise-t-on ? (est-ce qu'on prend en compte tous les styles de threads en espace utilisateur possibles, en incluant des choses du style des go-routines, réparties efficacement sur plusieurs threads systèmes, ou se limite-t-on aux green threads de Java, tournant tous sur le même thread système abandonnés dans le début des années 2000 vues les limitations ?)
sur quel genre de charge de travail ? (les résultats seront probablement différent si on fait de l'I/O, des opérations bloquantes ou du calcul pur)
Et ensuite, il faudrait le jouer complètement avec des mesures et une démarche rigoureuse convaincante. J'ai été un peu sévère en jugeant tes mesures, et ce n'est pas pour être pénible, c'est juste qu'il y a mille et une manière de foirer ses mesures sur ce genre de chose. Je le sais, j'ai fait des études dans un domaine relatif à ce genre de questions, puis travaillé dans une équipe de recherche et été entouré de gens travaillant sur des questions de perf. C'est compliqué à faire correctement. Ce n'est pas ma spécialité, mais je vais avoir du mal à trouver les résultats fiables sans ça.
Ton script illustre que de l'asynchrone sur 1 thread pour faire 3 opérations d'I/O probablement bloquantes "suffisamment longues" est plus lent que 3 threads pour faire ces opérations en parallèle. Ok, en fait, l'inverse m'aurait étonné. C'est super d'avoir fait l'effort de mesurer et en plus de publier le script, ça permet une discussion concrète (et ça expose à la critique). Il a d'ailleurs permis de préciser les choses. Mais pour moi ça ne répond pas vraiment au problème qu'on a du mal à poser : est-ce que les green threads* sont plus efficaces que les threads natifs ? et dans quels cas ? (je m'attends à des résultats variés selon la charge de travail). En même temps, la question est vaste en fait !
C'est beaucoup de travail, c'est presque de la recherche. Il faut clairement poser le problème, éventuellement faire un état de l'art (des mesures existantes, types de charges de travail typiques, des techniques d'ordonnancement des threads système et en espace utilisateur), proposer un protocole expérimental rigoureux, l'appliquer et exploiter les résultats. Ça peut être fun et des gens adorent faire ça, mais clairement, je n'ai pas prévu de le faire maintenant xD. Il y a probablement des papiers là dessus, je n'ai malheureusement rien trouvé de récent après une recherche rapide. Il y a peut-être des choses intéressantes à ce sujet du côté de Go ou Haskell mais une recherche rapide n'a rien donné non plus. Il y a peut-être des articles de blog détaillés sur le sujet :-)
* disons, les threads en espace utilisateur, je suis assez persuadé que les greens threads limités de Java il y a 20 ans n'étaient pas vraiment performants - ce n'était d'ailleurs pas vraiment leur objectif, leur objectif c'était il me semble surtout de ne pas trop dépendre des spécificités de chaque système d'exploitation pour avoir un mécanisme plus ou moins concurrent.
Je vois plusieurs problème potentiels avec ce code :
le test dépend de requêtes HTTP externes, ce qui introduit certainement beaucoup de variabilité, potentiellement plus grande que celle entre threads et green threads
la méthode pour faire ces requêtes n'est pas la même
tu ne mesures pas vraiment green thread vs thread système, mais asyncio vs threads systèmes en Python. Bon, pas le choix que de tester des implems existantes, mais peut-être que l'asynchrone Python n'est pas très performant par exemple, alors que peut-être que ce n'est pas une limite théorique des green threads (je ne connais pas très bien les green threads ni asyncio cela dit)
de ce que je comprends du code, tu ne lisses pas les résultats en exécutant plusieurs fois les tests, dans des ordres différents (tu risques de "chauffer" et donc favoriser le deuxième test en exécutant le premier d'une manière ou d'une autre, donc il est important d'alterner les tests)
Cela dit, ton résultat ne m'étonne pas : je m'attends à ce qu'un processus parallélisable s'exécute plus vite sur plusieurs threads systèmes que sur plusieurs green threads placés sur un seul thread système : il n'y a pas de parallélisme dans ce cas ! :-) Et c'est probablement ce que fait ressortir ton test.
Les vraies questions à mon avis seraient plutôt :
est-ce que si on implémente intelligemment les green threads sur plusieurs threads systèmes (éventuellement, en fixant ces threads sur des cœurs), on peut gagner en perf (en utilisant X green threads sur N cœurs versus X threads systèmes sur N cœurs) ?
est-ce que pour un ensemble de tâches non parallélisables / non parallélisées, on arrive à une meilleure perf avec plusieurs plusieurs green threads sur un seul thread système versus plusieurs threads systèmes sur un seul cœur ?
j'imagine que Barmic à plus ça en tête. Effectivement, il est possible que le "switch" soit plus léger au moins dans ce deuxième cas, voire dans le premier si c'est bien gérer (mais le risque dans le premier cas c'est de se payer aussi les context switch des threads systèmes en plus de entre les green threads si c'est mal géré…).
je ne pense pas que ça reste isolé à mon cercle de connaissance
Eh bien… regarde ici : on commente sur une dépêche dont 12 personnes ont participé à l'écriture, pertinentée par au moins 34 personnes en l'espace de 2 jours.
Peut-être que c'est mal vu / puni de montrer de l'intérêt pour PHP dans ton entourage alors les gens n'osent peut-être pas (franchement, perso, j'ai pas mal observé ça - par défaut quand tu lances une discussion sur PHP, on te fait comprendre que c'est nul, qu'il ne faut pas utiliser ça, X c'est mieux, etc (au moins parce qu'il est convenable de le faire) - sauf quand tu critiques négativement le langage, là tu gagnes du karma facilement - donc tu ignores ces remarques et parfois les gens t'écoutent quand même, ou alors c'est parfois juste plus simple de parler d'autre chose surtout quand tu connais plein d'autres trucs, en particulier des langages bien vus, sinon tu te tais, ça marche aussi ; selon les milieux, ça peut arriver avec Javascript aussi), ou gens n'ont effectivement pas d'intérêt, ou, simplement, les langages dont vous parlez sont plus récents, ou popularisent / rendent pratiques des concepts qui ne l'étaient pas avant ; quelque part, PHP c'est « ennuyeux », tout existe ailleurs alors pourquoi s'y attarder ?
Mais ici, c'est clair, il y a des gens qui montrent de l'intérêt et/ou de la curiosité pour PHP, y compris des gens qui connaissent, apprécient et pratiquent - parfois principalement - d'autres langages au quotidien, occasionnellement ou précédemment ; et des discussions intéressantes sur PHP peuvent avoir lieu :-)
Je comprends la frustration et le dérapage de barmic, notre interlocuteur a quand même plus ou moins fait comprendre à tous les participants de ce fil de discussion, et à une partie de ses lecteurs, et de ses lectrices…
je dirais qu'un dev qui va promouvoir PHP est un dev qui n'a eu que très peu d'autres expériences de langages (ou alors sur des trucs tellement plus archaïque qu'il n'est pas vraiment objectif).
Dire le contraire c'est ce voiler la face.
… qu'on était inexpérimentés / qu'on se voilait la face. Ce qui est peut-être vrai après tout mais bof. Comme communication bienveillante et ouverte, on a vu mieux et ça manque incroyablement d'humilité. Maintenant, même effectivement si elle m'a bien fait rire, cette remarque de barmic est déplacée et c'est bien d'avertir. Merci !
Globalement je pense qu'on peut arrêter ce débat ici, ça fait un moment qu'il est devenu stérile et ça commence sérieusement à tourner en boucle. Circulez, il n'y a plus rien à voir.
vu que le PHP des début ne ressemble à presque plus rien de ce qu'il est actuellement… je serais au commande, je ferais évoluer PHP pour que ça soit 100% compatible Python3 à la version 10
Je n'espère pas, mon code PHP d'il y a 10 ans tourne sans modification sur les dernières versions de PHP, pour faire du Python, j'ai déjà… Python :-)
# Info pas très fraîche et titre malhonnête
Posté par raphj (site web personnel) . En réponse au lien Signal et Messenger sur écoute. Évalué à 4. Dernière modification le 25 janvier 2021 à 21:48.
Pour Signal, c'est corrigé depuis fin 2019 d'après l'article cité, très peu de temps après le signalement de la faille. Pourquoi citer Signal, de toute les applications concernées, alors que ça fait plus d'un an que cette application spécifique n'est plus concernée ?
Et puis alors, « sur écoute », c'est bon, quoi. Là on sort du domaine « pas très frais » pour sauter à pieds joints dans le domaine du « titre racoleur et moisi ».
[^] # Re: Android SDK
Posté par raphj (site web personnel) . En réponse à la dépêche Changeons ces logiciels open source qui nous espionnent. Évalué à 6.
Justement, un niveau de confort tel que celui d'un bureau Linux d'aujourd'hui m'irait amplement :-P
[^] # Re: Android SDK
Posté par raphj (site web personnel) . En réponse à la dépêche Changeons ces logiciels open source qui nous espionnent. Évalué à 4.
Je n'ai pas utilisé eOS (c'est bien /e/ ?), mais je suppose que ça ressemble pas mal à LineageOS + microG que j'ai utilisé, niveau utilisabilité. Je crois que /e/ inclut microG par défaut.
Pour quelqu'un comme moi qui a toujours refusé d'utiliser des applications propriétaires sur le téléphone, c'était plutôt bien. Je recommande à quiconque ayant besoin de rester sur Android pour le moment d'utiliser ça, ou LineageOS + microG.
Cela dit, il y a un truc que tous ces systèmes ne dégooglisent pas : c'est la feuille de route d'Android. C'est important, parce qu'il n'est pas dans l'intérêt de Google. En pratique, dans les conséquences, on a :
J'ai beaucoup d'espoir que les systèmes libres alternatifs à Android et iOS décollent et deviennent utilisables / fiables au quotidien pour un assez grand nombre de gens, et qu'ils permettent de faire confortablement ce qu'on attend aujourd'hui d'un téléphone : appels, SMS, Navigation GPS, surf, Photos, chat… On n'y est pas encore, mais il y a eu un sacré progrès avec la communauté qui s'est formée autour du PinePhone et du Librem 5.
# Android SDK
Posté par raphj (site web personnel) . En réponse à la dépêche Changeons ces logiciels open source qui nous espionnent. Évalué à 7.
Là aussi, il faut accepter une licence à la con.
Un travail de recompilation a lieu ici : https://android-rebuilds.beuc.net/
Il y a encore du chemin, en particulier sur les versions du NDK disponibles et le sdkmanager qui sert à automatiser l'installation, mais ça permet déjà de faire des choses.
il y a aussi toutes ces applications libres qui ont la fâcheuse tendance sous Android à contenir des blobs propriétaires, on peut retrouver des versions déblobées sur F-Droid.
Et sinon, comme alternative à l'écosystème Android, il y a les téléphones sous GNU/Linux qui pointent le bout de leur nez et qui sont prometteurs à défaut d'être à 100% utilisables.
[^] # Re: L'open source tant qu'il y a besoin de se faire connaître, mais après...
Posté par raphj (site web personnel) . En réponse au journal mapbox n'est plus libre, vive maplibre. Évalué à 9.
(sans me prononcer moi-même sur le sujet)
Un des employés de Mapbox s'est exprimé sur le passage en proprio il y a 26 jours ici : https://news.ycombinator.com/item?id=25348131
Un des commentateurs cite la phrase "Mapbox proudly embraces our open source roots" présente sur leur site. L'employé répond qu'il a écrit ce paragraphe et qu'il est d'accord avec la décision de changer la licence de Mapbox GL JS. Le commentateur répond qu'il est d'accord avec les entreprises choisissant de faire du non libre, mais qu'il trouve qu'avec la fermeture d'un projet open source avec une communauté active, la pilule est dure à avaler.
L'employé répond :
Traduction :
[^] # Re: Alternatives plus libres ou respectueuses de la vie privée
Posté par raphj (site web personnel) . En réponse au journal 4 outils open-source pour sécuriser le travail collaboratif en ligne. Évalué à 3.
Ils empêchent violamment les forks qui se connectent à leurs propres serveurs, mais le code de leur client reste en GPL et forker Signal est autorisé, pourvu que les forks redistribués ne se connectent pas à leurs serveurs.
[^] # Re: Signal ?
Posté par raphj (site web personnel) . En réponse au journal 4 outils open-source pour sécuriser le travail collaboratif en ligne. Évalué à 1. Dernière modification le 17 décembre 2020 à 07:35.
Oui, ça se comporte comme une ancre classique. Je préfère le comportement du dièse, en parlant d'HN je ne faisais que mentionner un comportement alternatif mais un lien vers un commentaire dans la page c'est ce qui me parait le plus utile.(edit: je viens de comprendre ce que tu dis)
Alors pour les touches j et k, j'ai remarqué que ça existait et c'est une fonctionnalité sympathique mais je ne l'ai pas intégrée, j'ai plutôt pris l'habitude d'utiliser les flèches de la barre en bas pour naviguer sur les commentaires non lus :-)
De toute façon je crois que j'ai rarement besoin de naviguer entre les commentaires, juste les commentaires non lus.
[^] # Re: Signal ?
Posté par raphj (site web personnel) . En réponse au journal 4 outils open-source pour sécuriser le travail collaboratif en ligne. Évalué à 7.
À mon avis il y a une bonne raison à ça : je pense que l'interface encourage trop à faire ça, et cache trop la bonne manière de faire.
Il m'est arrivé de vouloir récupérer le lien d'un commentaire, et vu que le titre est un lien on se dit vite que c'est la manière de faire sans forcément prêter attention au petit dièse à peine visible à côté. En fait, ça m'est arrivé de chercher à donner un lien vers un commentaire dans sont contexte et pas trouver le dièse… et de me demander à quoi servait vraiment cette page avec le commentaire seul, sans pouvoir accéder à son parent.
Il me parait très rare d'avoir besoin de faire un lien vers un commentaire sans son contexte.
Peut-être que le lien du titre devrait être celui du dièse (et que le dièse devrait disparaître, éventuellement) ? (Quitte à mettre un petit lien plus discret ailleurs pour le commentaire seul si on y tient)
Ou alors adopter le fonctionnement d'Hacker News : un lien vers un commentaire affiche le sous-arbre entier de commentaires, et un lien vers le parent.
[^] # Re: "L’application de chiffrement de bout-en-bout est distribuée sous une licence commerciale"
Posté par raphj (site web personnel) . En réponse au journal 4 outils open-source pour sécuriser le travail collaboratif en ligne. Évalué à 9.
Ça me parait ok de faire de la promotion pour un logiciel libre ici. Il faut juste que ça reste intéressant et informatif. Après tout, on est beaucoup à le faire :-)
Je pense que ce serait une bonne idée que dans ce genre de situation que MariePa se présente clairement.
# "L’application de chiffrement de bout-en-bout est distribuée sous une licence commerciale"
Posté par raphj (site web personnel) . En réponse au journal 4 outils open-source pour sécuriser le travail collaboratif en ligne. Évalué à 10.
Concernant ownCloud :
Du coup, cette application n'est pas vraiment un outil open source permettant de sécuriser le travail collaboratif (l'objet annoncé du journal)… c'est bien tout le problème de ownCloud et une des raisons pour lesquelles ses développeurs principaux sont partis développer NextCloud. C'est de l'open core et des fonctionnalités essentielles ne sont pas libres. Il me semble qu'il aurait été beaucoup plus naturel de citer cette dernière solution à la place, qui fournit nativement le chiffrement bout en bout en open source.
Sinon, ce journal manque cruellement d'une mention à Collabora Online, qu'on peut installer sur un serveur que l'équipe de travail contrôle. Je suppose que ce n'est pas e2ee vu que LibreOffice tourne sur le serveur et s'occupe du rendu, par contre les communications sont chiffrées (HTTPS) et tous les bouts sont sous contrôle, ce qui peut suffire selon la situation. Du coup, si l'approche n'est pas vraiment similaire à celle d'OnlyOffice, je pense qu'on peut le présenter comme solution intéressante malgré tout.
[^] # Re: Des bonnes idées
Posté par raphj (site web personnel) . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 2. Dernière modification le 13 décembre 2020 à 12:48.
Tu fais références à ce passage ?
C'est sûr que si on ne respecte pas les procédures et qu'on ne lance pas les tests, bah ça peu foirer. À moins d'avoir un code et du matériel prouvé correct, mais bon courage avec ça.
Ou ce passage ?
C'est sûr que si on ne fait pas correspondre le matériel avec le logiciel, ça peut aussi mal se passer.
Que voulais-tu montrer avec ton lien ? Que les catastrophes sont souvent dues à une succession de décisions foireuses indépendantes des technologies utilisées ? Félicitations, c'est réussi, mais tu aurais pu être plus explicite. Je suis bien d'accord avec toi, c'est triste qu'on continue à faire des économies de bouts de chandelles de ce type, c'est comme si on n'avait rien appris du naufrage du Titanic et c'est regrettable.
Ou alors tu voulais illustrer le fait que Ada est un choix répandu pour concevoir des systèmes industriels embarqués critiques ? Drôle d'exemple pour ça, mais bon pourquoi pas. Un exemple n'est pas vraiment suffisant mais de toute façon je crois qu'on est tous convaincus qu'Ada est un très bon choix pour faire de l'embarqué critique même s'il ne peut malheureusement pas résoudre les problèmes causés par les décisions foireuses donc ce n'est pas très grave.
(et sinon, une discussion honnête et bienveillante, ça te dit ?)
[^] # Re: moi c'est l'inverse
Posté par raphj (site web personnel) . En réponse au journal Linux ne m'intéresse plus. Évalué à 2. Dernière modification le 11 décembre 2020 à 20:55.
Je n'utilise pas GDM non plus. Mais effectivement, peut-être que les outils GNOME s'attendent à avoir un gestionnaire de sesssion ?
Mhm, peut-être, mais ça cherche à résoudre un vrai problème de distribution de logiciels aussi. Cf cette session Q&A avec Linus Torvalds en 2014 où il passe un peu de temps sur le sujet : https://www.youtube.com/watch?v=5PmHRSeA2c8 (ils ne fournissaient tout simplement pas de binaire de Subsurface pour Linux parce que c'est trop compliqué. Un peu con quand même !
[^] # Re: moi c'est l'inverse
Posté par raphj (site web personnel) . En réponse au journal Linux ne m'intéresse plus. Évalué à 8. Dernière modification le 11 décembre 2020 à 08:57.
Oui, zut, moi aussi, je n'avais pas remarqué que Evince et simple-scan ne fonctionnaient pas sur mon environnement de bureau Plasma… (j'avoue, je n'ai pas essayé de me passer de systemd. Mais pourquoi le faire ? C'est le meilleur système d'init sous Linux !! (ah ah)).
Plus sérieusement :
Un outil est développé dans un cadre et est fourni gratuitement, tu veux utiliser cet outil mais tu refuses de l'utiliser le périmètre dans lequel il est conçu, très bien c'est ton droit, mais les développeurs n'ont aucun compte à te rendre. Je suis sûr qu'en les aidant ou en leur soulevant le problème de façon intelligente ça peut se résoudre, mais ils ne sont pas plus obligés que toi de déboguer ton environnement. Tu sembles passer un temps fou à casser ton système, ok, alors déjà il ne faut pas s'étonner que des trucs ne fonctionnent pas bien, et aussi, si tu veux utiliser ces applications, tu peux essayer de sortir gdb et strace pour voir d'où vient le problème. Ce n'est pas en vociférant dans le vide que le problème va se corriger tout seul. Les développeurs ne te doivent rien et pour eux, tout marche bien dans le cadre prévu.
Evince et Simple Scan fonctionnent très bien sans Gnome puisqu'ils fonctionnent chez moi, et j'imagine qu'ils fonctionnent également très bien sur Devuan alors ils doivent pouvoir fonctionner sans systemd aussi. Le problème est probablement chez toi.
Ce qui n'est pas normal, c'est passer du temps à casser son système et après venir râler et s'insurger quand les choses ne fonctionnent pas sans même avoir cherché à diagnostiquer. C'est cool de bidouiller, je le fais aussi, mais alors il faut rester lucide et assumer.
[^] # Re: C'est aussi mon avis
Posté par raphj (site web personnel) . En réponse au journal Linux ne m'intéresse plus. Évalué à 9.
Il y a toujours les téléphones sous GNU/Linux. Plus on est de fous, plus on rit !
[^] # Re: nimages ?
Posté par raphj (site web personnel) . En réponse au journal Réception d'un MMS difficile. Évalué à 2.
Non ! :-P
Mais bonne idée, ça aurait pu.
Le délai d'affichage est complètement arbitraire et n'est pas forcément utilisé par les téléphones. Je ne sais même pas pourquoi il est spécifié.
[^] # Re: Nextcloud - chiffrement bout en bout
Posté par raphj (site web personnel) . En réponse au journal Remplacer Encfs ? Oui, mais par quoi ?. Évalué à 2.
Justement, le but du E2E n'est-il pas de ne pas devoir faire confiance en l'hébergeur ?
Après je n'ai pas trop creusé, j'héberge ma propre instance, je ne me suis pas trop intéressé au E2E. Globalement, si quelqu'un accède à ma machine, je suis déjà dans la panade.
# Nextcloud - chiffrement bout en bout
Posté par raphj (site web personnel) . En réponse au journal Remplacer Encfs ? Oui, mais par quoi ?. Évalué à 6.
Je ne sais pas ce qu'il vaut, mais est-ce que ça ne serait pas plus pratique d'utiliser le chiffrement bout en bout de Nextcloud ? (et, éventuellement, appliquer une solution de chiffrement locale qui n'est pas nécessairement par fichier)
https://nextcloud.com/endtoend/
[^] # Re: Des bonnes idées
Posté par raphj (site web personnel) . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 2. Dernière modification le 06 décembre 2020 à 23:25.
Je ne sais pas si le jeu en vaut la chandelle, tout dépend du but, mais en tout cas il est exigeant. Le sujet est intéressant, mais si on veut faire bien les choses, je pense que déjà, la question doit être précisée parce qu'on ne sait pas trop ce qu'on cherche :
Et ensuite, il faudrait le jouer complètement avec des mesures et une démarche rigoureuse convaincante. J'ai été un peu sévère en jugeant tes mesures, et ce n'est pas pour être pénible, c'est juste qu'il y a mille et une manière de foirer ses mesures sur ce genre de chose. Je le sais, j'ai fait des études dans un domaine relatif à ce genre de questions, puis travaillé dans une équipe de recherche et été entouré de gens travaillant sur des questions de perf. C'est compliqué à faire correctement. Ce n'est pas ma spécialité, mais je vais avoir du mal à trouver les résultats fiables sans ça.
Ton script illustre que de l'asynchrone sur 1 thread pour faire 3 opérations d'I/O probablement bloquantes "suffisamment longues" est plus lent que 3 threads pour faire ces opérations en parallèle. Ok, en fait, l'inverse m'aurait étonné. C'est super d'avoir fait l'effort de mesurer et en plus de publier le script, ça permet une discussion concrète (et ça expose à la critique). Il a d'ailleurs permis de préciser les choses. Mais pour moi ça ne répond pas vraiment au problème qu'on a du mal à poser : est-ce que les green threads* sont plus efficaces que les threads natifs ? et dans quels cas ? (je m'attends à des résultats variés selon la charge de travail). En même temps, la question est vaste en fait !
C'est beaucoup de travail, c'est presque de la recherche. Il faut clairement poser le problème, éventuellement faire un état de l'art (des mesures existantes, types de charges de travail typiques, des techniques d'ordonnancement des threads système et en espace utilisateur), proposer un protocole expérimental rigoureux, l'appliquer et exploiter les résultats. Ça peut être fun et des gens adorent faire ça, mais clairement, je n'ai pas prévu de le faire maintenant xD. Il y a probablement des papiers là dessus, je n'ai malheureusement rien trouvé de récent après une recherche rapide. Il y a peut-être des choses intéressantes à ce sujet du côté de Go ou Haskell mais une recherche rapide n'a rien donné non plus. Il y a peut-être des articles de blog détaillés sur le sujet :-)
*disons, les threads en espace utilisateur, je suis assez persuadé que les greens threads limités de Java il y a 20 ans n'étaient pas vraiment performants - ce n'était d'ailleurs pas vraiment leur objectif, leur objectif c'était il me semble surtout de ne pas trop dépendre des spécificités de chaque système d'exploitation pour avoir un mécanisme plus ou moins concurrent.[^] # Re: Des bonnes idées
Posté par raphj (site web personnel) . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 2. Dernière modification le 06 décembre 2020 à 19:04.
Je vois plusieurs problème potentiels avec ce code :
Cela dit, ton résultat ne m'étonne pas : je m'attends à ce qu'un processus parallélisable s'exécute plus vite sur plusieurs threads systèmes que sur plusieurs green threads placés sur un seul thread système : il n'y a pas de parallélisme dans ce cas ! :-) Et c'est probablement ce que fait ressortir ton test.
Les vraies questions à mon avis seraient plutôt :
j'imagine que Barmic à plus ça en tête. Effectivement, il est possible que le "switch" soit plus léger au moins dans ce deuxième cas, voire dans le premier si c'est bien gérer (mais le risque dans le premier cas c'est de se payer aussi les context switch des threads systèmes en plus de entre les green threads si c'est mal géré…).
[^] # Re: Des bonnes idées
Posté par raphj (site web personnel) . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 2.
À la compilation (ou en lançant le vérificateur de type - mypy) ça ne me parait pas déconnant si tu n'utilises pas d'IDE.
[^] # Re: Des bonnes idées
Posté par raphj (site web personnel) . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 3.
Il l'a surtout complémenté, dans beaucoup de cas. Il y a souvent Apache derrière Nginx.
[^] # Re: Des bonnes idées
Posté par raphj (site web personnel) . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 3.
D'ailleurs, tes réponses sont intéressantes !
[^] # Re: Des bonnes idées
Posté par raphj (site web personnel) . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 3. Dernière modification le 30 novembre 2020 à 23:31.
Eh bien… regarde ici : on commente sur une dépêche dont 12 personnes ont participé à l'écriture, pertinentée par au moins 34 personnes en l'espace de 2 jours.
Peut-être que c'est mal vu / puni de montrer de l'intérêt pour PHP dans ton entourage alors les gens n'osent peut-être pas (franchement, perso, j'ai pas mal observé ça - par défaut quand tu lances une discussion sur PHP, on te fait comprendre que c'est nul, qu'il ne faut pas utiliser ça, X c'est mieux, etc (au moins parce qu'il est convenable de le faire) - sauf quand tu critiques négativement le langage, là tu gagnes du karma facilement - donc tu ignores ces remarques et parfois les gens t'écoutent quand même, ou alors c'est parfois juste plus simple de parler d'autre chose surtout quand tu connais plein d'autres trucs, en particulier des langages bien vus, sinon tu te tais, ça marche aussi ; selon les milieux, ça peut arriver avec Javascript aussi), ou gens n'ont effectivement pas d'intérêt, ou, simplement, les langages dont vous parlez sont plus récents, ou popularisent / rendent pratiques des concepts qui ne l'étaient pas avant ; quelque part, PHP c'est « ennuyeux », tout existe ailleurs alors pourquoi s'y attarder ?
Mais ici, c'est clair, il y a des gens qui montrent de l'intérêt et/ou de la curiosité pour PHP, y compris des gens qui connaissent, apprécient et pratiquent - parfois principalement - d'autres langages au quotidien, occasionnellement ou précédemment ; et des discussions intéressantes sur PHP peuvent avoir lieu :-)
[^] # Re: Des bonnes idées
Posté par raphj (site web personnel) . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 2. Dernière modification le 30 novembre 2020 à 21:46.
Je comprends la frustration et le dérapage de barmic, notre interlocuteur a quand même plus ou moins fait comprendre à tous les participants de ce fil de discussion, et à une partie de ses lecteurs, et de ses lectrices…
… qu'on était inexpérimentés / qu'on se voilait la face. Ce qui est peut-être vrai après tout mais bof. Comme communication bienveillante et ouverte, on a vu mieux et ça manque incroyablement d'humilité. Maintenant, même effectivement si elle m'a bien fait rire, cette remarque de barmic est déplacée et c'est bien d'avertir. Merci !
Globalement je pense qu'on peut arrêter ce débat ici, ça fait un moment qu'il est devenu stérile et ça commence sérieusement à tourner en boucle. Circulez, il n'y a plus rien à voir.
[^] # Re: Des bonnes idées
Posté par raphj (site web personnel) . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 4.
Je n'espère pas, mon code PHP d'il y a 10 ans tourne sans modification sur les dernières versions de PHP, pour faire du Python, j'ai déjà… Python :-)