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 ?)
Posté par raphj .
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 ?
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 !
Posté par raphj .
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 :
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 :-)
conçu un feu langage syntaxiquement proche de php nommé hack
Oui, beaucoup d'efforts pour "rester" sur PHP (ou un truc qui en est proche) ;-).
Peut-être que c'est parce qu'à ce moment là, la quantité de code PHP devenait trop grande pour migrer cela dit.
OwnCloud a clairement choisi PHP car on ouvre plus d'hébergement LAMP que python, perl ou ruby.
tout ce fait à l’exécution et non en amont et finalement si on veut vérifier du typage avant la mise en prod, on s'appuie sur l'IDE
Comment ça ? En Python par exemple, les annotations de types sont ignorées à l'exécution, et on peut lancer mypy en ligne de commande sans problème sans passer par un IDE pour vérifier le typage ?
la syntaxe juste imbuvable quand on a connu d'autres choses
J'ai connu d'autres choses et d'autres langages, et ce n'est pas mon sentiment. Mais ne nous arrêtons pas à des sentiments et constatons : tout porte à croire que Facebook, Wordpress, Wikipedia, Nextcloud, et plein d'autres projets continuent à bien évoluer malgré (grâce à ?) PHP. On est loin du site amateur ! Ces projets auraient-ils dû choisir un autre langage ?
Je ne comprends pas cette haine contre PHP. Malgré ses défauts (il en a plein), il permet de construire à la fois facilement des sites amateurs et de faire tourner certains des sites les plus visités du monde, ce n'est quand même pas rien.
Et si Wikipedia (2001) et Wordpress (2003) existent depuis longtemps et changer de langage pourrait être difficile pour ces projets, Facebook aurait certainement eu les moyens de faire des réécritures si PHP avait été un gros frein à son développement et ownCloud, en 2010, aurait pu choisir Python (c'était la version 2.7, pas trop mal !).
Rejeter ce langage d'un revers de manche parait un peu réducteur.
Finalement, j'ai l'impression qu'il y a une tendance un peu commune, en tout cas dans les langages de scripts répandus, notamment sur des notations de types de plus en plus utiles et puissantes, qui dépassent (enfin ?) ce que permet le C (pas tant de choses que ça finalement), et notamment en permettant les unions. Et c'est bien que ces langages de script répandus intègrent ça, parce que c'est rapidement inconfortable dans un gros projet de ne pas les avoir. Les gens qui s'occupent de ces langages en ont conscience et le montrent (enfin !).
Aussi, j'ai l'impression que PHP reprend des bonnes idées d'autres langages : les paramètres nommés de Python, le startsWith / endsWidth de Java / Javascript, le WeakMap et l'opérateur de chainage de Javascript, les notations de types de mypy / Typescript, le match venant des langages fonctionnels et récemment adopté par Python, bien plus lisible, adapté, clair, concis et moins casse gueule qu'un switch dans beaucoup de situations. Je salue aussi les paramètres constructeurs, je trouve les langages orientés objets tellement ennuyeux et lourdauds sans…
Une petite mention pour la possibilité d'utiliser mixed, ça m'avait manqué quand j'avais essayé d'utiliser les annotations de types en PHP.
Bref, ces petits changements qui améliorent la vie ces derniers temps dans les langages de programmations répandus, même si je n'utilise pas PHP tous les jours, m'enthousiasment pas mal, et franchement, je ne sais pas pour vous, mais chaque nouvelle version de PHP semble arriver avec son lot de bonnes surprises, de bons choix et le langage semble évoluer vite.
Finalement, PHP deviendrait presque plus sérieux et agréable que Javascript, pourtant il y avait du chemin : il a un match, des paramètres nommés, des notations de types (accessibles uniquement dans les projets qui ont décidés de passer à Typescript) !
C'est un langage qui continue à exceller dans son rôle original de moteur de templates HTML facile à déployer (quel bonheur de ne pas devoir configurer et démarrer un service par application et de pouvoir laisser le serveur HTTP gérer les URLs - que ce soit en tant que développeur ou utilisateur - un plaisir pour la maintenance d'un service), avec de plus en plus tous les outils qu'on trouve dans les langages de programmation modernes. Franchement, ça donne envie de s'y remettre.
Prochaine étape : la gestion de l'ownership / du borrowing dans les langages de scripts répandus !
Ou, sur un environnement de bureau moderne, tu recherches "Chromium" dans le menu, ça se rend compte qu'il n'est pas installé, ça te propose "Installer Chromium", tu cliques et ça s'installe. Imbattable.
Le 12 décembre 2018 TheFatRat reçoit un "Copyright Claim", c'est-à-dire qu'une requête a été envoyée à YouTube pour signaler que la vidéo de sa musique "The Calling" contient des médias dont il n'a pas les droits. Il s'avère que le "Copyright Claim" indique que sa musique ressemble trop à un remix de cette même musique, publié par un fan à posteriori et contreviendrai au droit d'auteur. La situation est ubuesque, surtout que ce n'est pas le remixeur qui a envoyé la requête mais une société du nom de "Ramjets Group" qui fait des "Copyright Claim" frauduleux afin de récupérer les droits et les revenus publicitaires de diverses musiques ne leur appartenant pas. TheFatRat engage une procédure judiciaire et récupère finalement les droits de sa musique, de plus, la musique "The Calling" est sous licence Creative Commons ce qui avait permis au remixeur de faire son œuvre dérivée. Il a aussi publié une vidéo dénonçant les failles de ContentID, le robot de YouTube permettant d'identifier les contenus sous droits d'auteur, ainsi que de l'incapacité de la plateforme à régler les conflits relatifs aux droits d'auteur quand il a vu que le litige ne se résolvait pas et lancé une pétition qui a recueilli plus de 100 000 signatures.
Incident du 12 mai 2019
Le 12 mai 2019, 5 mois après l'incident du 12 décembre 2018, le musicien TheFatRat voit sa chaine YouTube supprimée pour raison de "Manquements graves ou répétés aux règles de YouTube concernant le spam, les pratiques trompeuses et les contenus mensongers, ou d'autres infractions aux conditions d'utilisation.". Après discussion avec YouTube, la chaîne de TheFatRat est à nouveau en ligne depuis le matin du 13 mai 2019[réf. souhaitée].
Et l'astuce qu'il est obligé d'appliquer pour ne plus avoir de problème avec ContentID, par exemple sur un de ses morceaux :
Rule The World is 👉 FREE to use on YouTube. HOWEVER TO PROTECT YOU FROM INVALID CLAIMS YOU WILL GET A CLAIM FROM MY MCN "THE DISTRICT". You can dispute that claim, saying you have a license, and then simply put "TheFatRat" (without parentheses) into the note section. No further explanation needed. In addition please make sure to credit me properly and add the link to this video. The claim will be released and you can monetize the video yourself. Also you won't lose any revenue that's made between the claim and the release. YouTube holds it back for you.
Ça a l'air dur, de faire de la musique libre sur YouTube… tout semble adapté et pensé autour de l'industrie classique…
Le choix précis du nombre de lettres et de leur score est dérivé d'une analyse fréquentielle, mais n'est-il pas, lui, spécifique au Scrabble ? Qu'est-ce qui, au regard de la loi / du droit d'auteur / des marques le différencie-t-il de la disposition des lettres/mots compte double/triple sur le plateau ?
# "L’application de chiffrement de bout-en-bout est distribuée sous une licence commerciale"
Posté par raphj . 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 . 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 . 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 . 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 . 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 . 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 . 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 . 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 . 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 . 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 . 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 . 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 . 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 . 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 . 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 . 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 :-)
[^] # Re: Des bonnes idées
Posté par raphj . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 3. Dernière modification le 30 novembre 2020 à 07:21.
Oui, beaucoup d'efforts pour "rester" sur PHP (ou un truc qui en est proche) ;-).
Peut-être que c'est parce qu'à ce moment là, la quantité de code PHP devenait trop grande pour migrer cela dit.
Bon point !
[^] # Re: Des bonnes idées
Posté par raphj . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 8.
Comment ça ? En Python par exemple, les annotations de types sont ignorées à l'exécution, et on peut lancer mypy en ligne de commande sans problème sans passer par un IDE pour vérifier le typage ?
J'ai connu d'autres choses et d'autres langages, et ce n'est pas mon sentiment. Mais ne nous arrêtons pas à des sentiments et constatons : tout porte à croire que Facebook, Wordpress, Wikipedia, Nextcloud, et plein d'autres projets continuent à bien évoluer malgré (grâce à ?) PHP. On est loin du site amateur ! Ces projets auraient-ils dû choisir un autre langage ?
Je ne comprends pas cette haine contre PHP. Malgré ses défauts (il en a plein), il permet de construire à la fois facilement des sites amateurs et de faire tourner certains des sites les plus visités du monde, ce n'est quand même pas rien.
Et si Wikipedia (2001) et Wordpress (2003) existent depuis longtemps et changer de langage pourrait être difficile pour ces projets, Facebook aurait certainement eu les moyens de faire des réécritures si PHP avait été un gros frein à son développement et ownCloud, en 2010, aurait pu choisir Python (c'était la version 2.7, pas trop mal !).
Rejeter ce langage d'un revers de manche parait un peu réducteur.
# Des bonnes idées
Posté par raphj . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 10. Dernière modification le 29 novembre 2020 à 00:03.
Finalement, j'ai l'impression qu'il y a une tendance un peu commune, en tout cas dans les langages de scripts répandus, notamment sur des notations de types de plus en plus utiles et puissantes, qui dépassent (enfin ?) ce que permet le C (pas tant de choses que ça finalement), et notamment en permettant les unions. Et c'est bien que ces langages de script répandus intègrent ça, parce que c'est rapidement inconfortable dans un gros projet de ne pas les avoir. Les gens qui s'occupent de ces langages en ont conscience et le montrent (enfin !).
Aussi, j'ai l'impression que PHP reprend des bonnes idées d'autres langages : les paramètres nommés de Python, le startsWith / endsWidth de Java / Javascript, le WeakMap et l'opérateur de chainage de Javascript, les notations de types de mypy / Typescript, le match venant des langages fonctionnels et récemment adopté par Python, bien plus lisible, adapté, clair, concis et moins casse gueule qu'un switch dans beaucoup de situations. Je salue aussi les paramètres constructeurs, je trouve les langages orientés objets tellement ennuyeux et lourdauds sans…
Une petite mention pour la possibilité d'utiliser
mixed, ça m'avait manqué quand j'avais essayé d'utiliser les annotations de types en PHP.Bref, ces petits changements qui améliorent la vie ces derniers temps dans les langages de programmations répandus, même si je n'utilise pas PHP tous les jours, m'enthousiasment pas mal, et franchement, je ne sais pas pour vous, mais chaque nouvelle version de PHP semble arriver avec son lot de bonnes surprises, de bons choix et le langage semble évoluer vite.
Finalement, PHP deviendrait presque plus sérieux et agréable que Javascript, pourtant il y avait du chemin : il a un match, des paramètres nommés, des notations de types (accessibles uniquement dans les projets qui ont décidés de passer à Typescript) !
C'est un langage qui continue à exceller dans son rôle original de moteur de templates HTML facile à déployer (quel bonheur de ne pas devoir configurer et démarrer un service par application et de pouvoir laisser le serveur HTTP gérer les URLs - que ce soit en tant que développeur ou utilisateur - un plaisir pour la maintenance d'un service), avec de plus en plus tous les outils qu'on trouve dans les langages de programmation modernes. Franchement, ça donne envie de s'y remettre.
Prochaine étape : la gestion de l'ownership / du borrowing dans les langages de scripts répandus !
[^] # Re: Debian
Posté par raphj . En réponse au journal Installer Chromium sur Ubuntu via Nix. Évalué à 2.
Ou, sur un environnement de bureau moderne, tu recherches "Chromium" dans le menu, ça se rend compte qu'il n'est pas installé, ça te propose "Installer Chromium", tu cliques et ça s'installe. Imbattable.
# Debian
Posté par raphj . En réponse au journal Installer Chromium sur Ubuntu via Nix. Évalué à 7.
C'est un ancien mot africain qui veut dire « J'arrive pas à configurer Ubuntu » ?
[^] # Re: Ça ne date pas d'hier…
Posté par raphj . En réponse au lien YouTube ajoute des publicités sur certaines vidéos sans rémunérer les créateurs. Évalué à 3.
C'est une limitation curieuse. Le mode Picture in Picture de Firefox et Chrome devrait aider cela dit ?
[^] # Re: Ça ne date pas d'hier…
Posté par raphj . En réponse au lien YouTube ajoute des publicités sur certaines vidéos sans rémunérer les créateurs. Évalué à 5.
Je suis curieux de connaitre la suite.
Ça fait penser à TheFatRat, un compositeur qui sort beaucoup de ses morceaux sous licence libre.
Il a eu pas mal de déboires avec YouTube. Cf sa page Wikipedia, section Incidents :
Et l'astuce qu'il est obligé d'appliquer pour ne plus avoir de problème avec ContentID, par exemple sur un de ses morceaux :
Ça a l'air dur, de faire de la musique libre sur YouTube… tout semble adapté et pensé autour de l'industrie classique…
[^] # Re: Ça ne date pas d'hier…
Posté par raphj . En réponse au lien YouTube ajoute des publicités sur certaines vidéos sans rémunérer les créateurs. Évalué à 2.
Et du coup, est-ce que l'auteur mentionné par l'encart est rémunéré quand on regarde ta vidéo ?
[^] # Re: Gaffe au cease and desist
Posté par raphj . En réponse à la dépêche Trivabble, l’aventure continue. Évalué à 3. Dernière modification le 18 novembre 2020 à 22:46.
Le choix précis du nombre de lettres et de leur score est dérivé d'une analyse fréquentielle, mais n'est-il pas, lui, spécifique au Scrabble ? Qu'est-ce qui, au regard de la loi / du droit d'auteur / des marques le différencie-t-il de la disposition des lettres/mots compte double/triple sur le plateau ?