Pour demander quoi ? Qu'un imbécile qui vient d'arriver arrête d'être un imbécile ?
Il faut se barrer, c'est probablement douloureux parce que les employés ont un attachement à la boite et à ce qu'est twitter. De toute façon c'est ce qu'il semble chercher. Il faut faire son deuil twitter ne sera plus ce que c'était ne pas être triste que ça n'existe plus, mais être content que ça ai existé et aller vivre d'autres aventures ailleurs. L'employabilité de la plus part de ses gens ne doit être un grand problème.
S'il y a mépris, ce serait plutôt dans l'autre sens, en assénant que le développement du noyau gagnerait on ne sait quoi en se fardant en plus d'un forum web (parce-que n'ayant pas déjà assez à faire ?)
Qui a dit ça ? Je vois des gens parler de leur expérience dans l'une des directions ou l'autre. Mais y associer des valeurs je ne le vois que dans un sens (tu ne me fera pas croire que parler des gens "préoccupés de clignotement dans tous les sens" n'est pas péjoratif par exemple).
Les communautés font ce qu'elles souhaitent en choisissant via leur modèle de gouvernance qui tu es frustré que des projets font ce genre de choix c'est peut être plus ça qu'il faut interroger que l'outil.
Oui mais est-ce une bonne raison de choix quand on sait que cela va vachement influé le choix des successeurs possibles de jpg et autres formats ? Cela ressemble plus à de la paresse ou à un conflit d'intérêt qu'un choix fondé, non ?
Il me semble que Google avec ses intégrations très vertical a tout à gagner à prendre le meilleur format. De l'hébergement au navigateur jusqu'au support dans les mobiles (à l'affichage mais aussi en push par exemple).
Je n'ai aucune idée de si c'est le meilleur choix, mais google me semble être confronté à un nombre important de problématiques que ce choix importe. Après je ne sais pas si google sait prendre une décision cohérente pour l'ensemble.
Jon Sneyer a aussi ces propres biais puisque si j'ai bien compris il est impliqué dans l'un des formats.
Je doute que le noyau Linux et d'autres se privent de gens qui sont plus préoccupés de clignotement dans tous les sens (avec le gaspillage de ressource qui va avec) qu'autre chose.
Ça c'est du mépris de classe1. J'ai failli dans ma tête envoyer bouler tout ton message, te moinsser et passer à autre chose. C'est dommage parce que ton argument est intéressant.
autant d'identifiants et mots de passes à retenir, autant de profils à remplir, et j'en passe)
Tu as déjà un compte dans chacun des projets actuellement, il t'en faut un pour pouvoir participer aux tickets, il va aussi falloir quelque choses pour que tu ai le droit de pousser du code. Bref créer un compte tu l'a déjà fait, mais dans le web aujourd'hui on ne crée plus de compte, on s'appuie sur un compte que tu as déjà. Éventuellement on te demande des trucs en plus, mais c'est rare. Et non tu n'es pas obligé de passer par un GAFAM, linuxfr.org le propose.
et à l'arrivé j'ai juste cessé de contribuer parce-que je ne passe pas mes journées à ouvrir un/une onglet/fenêtre sur chaque forum (à courir après les discussions qui avant venaient à moi)
Je ne suis pas certain de ce que tu dis mais, je ne connais pas de forum qui n'ai pas option "envoyer une notification par mail lorsque je reçois une réponse".
Si tu parle de messages qui ne te sont pas destinés particulièrement. Je comprends. Pour la montée en charge avec le nombre de projets (j'imagine a faible activité), ça n'est pas confortable.
en plus il fallait jouer de clics dans tous les sens pour trouver les nouveaux messages répartis dans diverses catégories/sections.
Je n'ai jamais utilisé discuss mais sur phpbb je naviguais dedans comme 5 j'aurais navigué dans mutt. De plus il faut voir la communauté, celle de gnome utilise probablement plus evolution ou thunderbird que mu4e, je ne pense pas que les clics leur donne des boutons.
rapidement comme je ne doute pas que ça va tiquer. Tu présente ceux qui préfèrent le web aux ML comme des "gens qui sont plus préoccupés de clignotement dans tous les sens". Si ce n'est pas une façon de mépriser une classe ou une catégorie de personnes. Bref ↩
Et c'est ce que font les projets qui font ce genre de migration. Problèmes rencontrés sur un outil (ou possibilité de faire mieux1), ils discutent, choisissent en fonction et prennent le temps de migrer tranquillement (syndrome NIH en moins).
Ce n'est peut-être pas ce qu'a fait Gnome mais c'est une question de gouvernance du projet pas d'outils ou d'importance de la brique.
comme pour l'adoption de bitkeeper quelques années auparavant ↩
Je n'ai jamais vraiment utilisé ce genre de logiciel. Quand je veux qu'un processus soit persistant à ma déconnexion j'utilise nohup.
nohup me permet au passage de garder la sortie standard du processus et c'est important pour moi.
De ce que je comprends de ton schéma, il n'y a rien pour ça dans diss ? À moins qu'une socket unix ai un buffer illimité on ne retrouve que les dernières lignes de la sortie standard ?
À chaque fois au moins une personne m’a opposé que cette migration ne de devrait pas être faite parce que « un tel changement serait extrêmement difficile à faire passer car complètement incompatible avec les usages de la majorité des développeurs (incompatible est encore trop faible comme mot d'ailleurs, on peut même parler de destruction d'outil de travail) ».
C'est exactement ce qu'a fait Linus Torvald, il a saboté l’environnement de travail des développeurs du noyau en leur changeant de gestionnaire de version, de la destruction d'outils de travail et j'espère bien que toute la communauté de la LKML est monté au créneau pour lui dire ses 4 vérités à se p'tit jeune qui vient leur foutre le boxon.
Après t'en fais pas moi j'ai rien compris au copyleft et à quel point il s'étend et à chaque fois que la question se pose les réponses sont différentes. J'ai définitivement arrêté d'essayer de comprendre et je laisse la question aux juristes.
Mais dommage que tu n'ai pas participé à la dépêche pour le coup.
Il s'est passé moins de 24h entre la publication de son journal et celui de cette dépêche. Ça fait court pour avoir des participations. Malgré ça l'entête semble dire qu'il y a participé.
Tu aime bien faire des schemas et c'est très bien, mais je vois quelques petits défauts :
tes flèches ne se distinguent que par les couleurs, utiliser différents pointillés pour ce qui est manuel par exemple ou partage par exemple permettrait de s'y retrouver même si on a un problème avec les couleurs
encore sur les couleurs la flèche verte n'a pas le même vert que sa légende
tu as laissé la correction orthographique, du souligné rouge sur du texte rouge n'aide pas la lecture
Il me semble que l'organisation de ton shemas est un peu confuse en organisant un peu à l'arrache j'aurais personnellement plutôt fais comme ça :
On a moins de flèches toutes proches les unes des autres.
Il me semble que github utilise ça pour gérer les droits (organisations etc). Alors github / git c'est des mot clefs qui sont difficiles à chercher, mais j'avais vu passer cette info.
D'un point de vue client, le chargement est bien plus rapide. Du static répondra toujours plus rapidement qu'un traitement côté serveur. Donc évidemment qu'en latence tu y gagne. Sans compter que pour les prochaines requêtes, il ne fait même plus les appels en Ajax s'il reste sur la page de 1Ko ou qu'il navigue sur une précédemment chargé même si c'est sur des données différentes.
Si j'ai bien compris c'est l'inverse il utilise intensivement xhr. Il utilise sqlite comme un client et les données sont récupérées via des requêtes range.
I implemented a virtual file system that fetches chunks of the database with HTTP Range requests when SQLite tries to read from the filesystem.
Tout à fait, mais c'est une moyenne dont je ne connais pas l'écart type. Déjà en France il semble varier de 8 à 26% selon les régions et il me semble que le facteur de charge s'améliore continuellement (je crois que c'est lié aux capacités des éoliennes à se déclencher avec moins de vent et à continuer à être utiliser malgré des plus grand vents).
Bref je n'y connais pas grand chose, mais il faut bien plus contextualiser pour pouvoir épiloguer sur la pertinence d'un site.
Je me lancerais pas dans les calculs mais d'après Wikipedia le facteur de charge moyen pour de l'éolien terrestre en Europe est de 24%. Donc ça paraît pas déconnant.
Après chacun ses choix, mais je n'ai pas l'impression personnelle que prendre en compte les quelques défauts de certains clients WebDAV est plus long que discuter de tout ça sur LinuxFR ;)
Je pense que tu sois estime grandement le travail que ça représente. Tu dois créer une heuristique, être en mesure de déduire ses choix après coup pour pouvoir aider tes utilisateurs, tu va devoir la tester sur un paquet d'implémentations sur différents os voir différentes versions tout ça pour un truc qui aura pleins de cas aux limites (git n'a pas de sémantique de move dans les patch et tu perds facilement la continuité).
C'est vrai qu'on a oublié de faire de l'authentification dans HTTP ⸮
Je rappel la phrase qui m'a fait tiquer :
Mais si tu ne propose pas du WebDAV, ça veut dire que tu ne permet pas à tes utilisateurs de récupérer les fichiers, comme ils le veulent, avec l'OS qu'ils veulent, donc le besoin n'a rien à voir :)
Tu peux parfaitement permettre aux utilisateurs de récupérer leurs fichiers en HTTP pur. Oui il y a moins de fonctionnalités, mais ce n'est pas de l'enfermement.
Mais si tu ne propose pas du WebDAV, ça veut dire que tu ne permet pas à tes utilisateurs de récupérer les fichiers, comme ils le veulent, avec l'OS qu'ils veulent, donc le besoin n'a rien à voir :)
Je comprends pas. HTTP n'a pas besoin de webdav pour télécharger des fichiers.
Si je peux faire une suggestion, les fichiers semblent trié par ordre alphabétique, je pense que par date et par taille peut aussi être utile quand tu veux faire de la place dans ton dossier.
[^] # Re: grève ?
Posté par barmic 🦦 . En réponse au lien « Dirigeant toxique », une définition . Évalué à 2. Dernière modification le 01 novembre 2022 à 12:02.
Pour demander quoi ? Qu'un imbécile qui vient d'arriver arrête d'être un imbécile ?
Il faut se barrer, c'est probablement douloureux parce que les employés ont un attachement à la boite et à ce qu'est twitter. De toute façon c'est ce qu'il semble chercher. Il faut faire son deuil twitter ne sera plus ce que c'était ne pas être triste que ça n'existe plus, mais être content que ça ai existé et aller vivre d'autres aventures ailleurs. L'employabilité de la plus part de ses gens ne doit être un grand problème.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Les mailing lists c'est pas pratique
Posté par barmic 🦦 . En réponse à la dépêche La communauté GNOME remplace ses listes de discussion par Discourse. Évalué à 3.
Qui a dit ça ? Je vois des gens parler de leur expérience dans l'une des directions ou l'autre. Mais y associer des valeurs je ne le vois que dans un sens (tu ne me fera pas croire que parler des gens "préoccupés de clignotement dans tous les sens" n'est pas péjoratif par exemple).
Les communautés font ce qu'elles souhaitent en choisissant via leur modèle de gouvernance qui tu es frustré que des projets font ce genre de choix c'est peut être plus ça qu'il faut interroger que l'outil.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Je savais même pas qu'il était né, moi...
Posté par barmic 🦦 . En réponse au journal Vie et mort (?) de JPEG-XL. Évalué à 2.
Il me semble que Google avec ses intégrations très vertical a tout à gagner à prendre le meilleur format. De l'hébergement au navigateur jusqu'au support dans les mobiles (à l'affichage mais aussi en push par exemple).
Je n'ai aucune idée de si c'est le meilleur choix, mais google me semble être confronté à un nombre important de problématiques que ce choix importe. Après je ne sais pas si google sait prendre une décision cohérente pour l'ensemble.
Jon Sneyer a aussi ces propres biais puisque si j'ai bien compris il est impliqué dans l'un des formats.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Les mailing lists c'est pas pratique
Posté par barmic 🦦 . En réponse à la dépêche La communauté GNOME remplace ses listes de discussion par Discourse. Évalué à 6.
Ça c'est du mépris de classe1. J'ai failli dans ma tête envoyer bouler tout ton message, te moinsser et passer à autre chose. C'est dommage parce que ton argument est intéressant.
Tu as déjà un compte dans chacun des projets actuellement, il t'en faut un pour pouvoir participer aux tickets, il va aussi falloir quelque choses pour que tu ai le droit de pousser du code. Bref créer un compte tu l'a déjà fait, mais dans le web aujourd'hui on ne crée plus de compte, on s'appuie sur un compte que tu as déjà. Éventuellement on te demande des trucs en plus, mais c'est rare. Et non tu n'es pas obligé de passer par un GAFAM, linuxfr.org le propose.
Je ne suis pas certain de ce que tu dis mais, je ne connais pas de forum qui n'ai pas option "envoyer une notification par mail lorsque je reçois une réponse".
Si tu parle de messages qui ne te sont pas destinés particulièrement. Je comprends. Pour la montée en charge avec le nombre de projets (j'imagine a faible activité), ça n'est pas confortable.
Je n'ai jamais utilisé discuss mais sur phpbb je naviguais dedans comme 5 j'aurais navigué dans mutt. De plus il faut voir la communauté, celle de gnome utilise probablement plus evolution ou thunderbird que mu4e, je ne pense pas que les clics leur donne des boutons.
rapidement comme je ne doute pas que ça va tiquer. Tu présente ceux qui préfèrent le web aux ML comme des "gens qui sont plus préoccupés de clignotement dans tous les sens". Si ce n'est pas une façon de mépriser une classe ou une catégorie de personnes. Bref ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: nohup
Posté par barmic 🦦 . En réponse au journal diss, gestionnaire de session terminal en rust. Évalué à 2.
Je sais très bien tout ça.
Ma question c'est est-ce que diss a un mécanisme pour garder la sortie des processus qu'il gère ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: L’accompagnement au changement
Posté par barmic 🦦 . En réponse à la dépêche La communauté GNOME remplace ses listes de discussion par Discourse. Évalué à 2.
Et c'est ce que font les projets qui font ce genre de migration. Problèmes rencontrés sur un outil (ou possibilité de faire mieux1), ils discutent, choisissent en fonction et prennent le temps de migrer tranquillement (syndrome NIH en moins).
Ce n'est peut-être pas ce qu'a fait Gnome mais c'est une question de gouvernance du projet pas d'outils ou d'importance de la brique.
comme pour l'adoption de bitkeeper quelques années auparavant ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# nohup
Posté par barmic 🦦 . En réponse au journal diss, gestionnaire de session terminal en rust. Évalué à 4.
Je n'ai jamais vraiment utilisé ce genre de logiciel. Quand je veux qu'un processus soit persistant à ma déconnexion j'utilise nohup.
nohup me permet au passage de garder la sortie standard du processus et c'est important pour moi.
De ce que je comprends de ton schéma, il n'y a rien pour ça dans diss ? À moins qu'une socket unix ai un buffer illimité on ne retrouve que les dernières lignes de la sortie standard ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: L’accompagnement au changement
Posté par barmic 🦦 . En réponse à la dépêche La communauté GNOME remplace ses listes de discussion par Discourse. Évalué à 4.
C'est exactement ce qu'a fait Linus Torvald, il a saboté l’environnement de travail des développeurs du noyau en leur changeant de gestionnaire de version, de la destruction d'outils de travail et j'espère bien que toute la communauté de la LKML est monté au créneau pour lui dire ses 4 vérités à se p'tit jeune qui vient leur foutre le boxon.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Merci
Posté par barmic 🦦 . En réponse au journal Comprendre les licences, mon impossible quête. Évalué à 4.
Après t'en fais pas moi j'ai rien compris au copyleft et à quel point il s'étend et à chaque fois que la question se pose les réponses sont différentes. J'ai définitivement arrêté d'essayer de comprendre et je laisse la question aux juristes.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Licence de la dépêche
Posté par barmic 🦦 . En réponse à la dépêche Memtest86+ v6.00 est sorti. Évalué à 2.
Il s'est passé moins de 24h entre la publication de son journal et celui de cette dépêche. Ça fait court pour avoir des participations. Malgré ça l'entête semble dire qu'il y a participé.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# GNU/RMS
Posté par barmic 🦦 . En réponse au journal Comprendre les licences, mon impossible quête. Évalué à 4.
Il y a quelques années le parti pirate a fait un peu la même erreur en pensant que le copyright était néfaste. Voila une explication de RMS : Pourquoi les propositions du Parti pirate suédois se retournent contre le logiciel libre
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Licence de la dépêche
Posté par barmic 🦦 . En réponse à la dépêche Memtest86+ v6.00 est sorti. Évalué à 2.
C'est la dépêche qui est placéE.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Schema
Posté par barmic 🦦 . En réponse au journal Sauvegarde et archivage, encore !!!. Évalué à 2.
Tu aime bien faire des schemas et c'est très bien, mais je vois quelques petits défauts :
Il me semble que l'organisation de ton shemas est un peu confuse en organisant un peu à l'arrache j'aurais personnellement plutôt fais comme ça :
On a moins de flèches toutes proches les unes des autres.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: j'affiche pas la barre d'onglet
Posté par barmic 🦦 . En réponse au lien Que pensez-vous du nouveau bouton dans Firefox 106 ?. Évalué à 2.
Pareil et j'utilise pas la synchronisation. J'avoue ne pas trop savoir ce que c'est (par contre j'envoie des onglets d'un firefox à un autre).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Idée interessante
Posté par barmic 🦦 . En réponse au lien Dolt : une base de données versionnée. Évalué à 2.
Il me semble que github utilise ça pour gérer les droits (organisations etc). Alors github / git c'est des mot clefs qui sont difficiles à chercher, mais j'avais vu passer cette info.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Quelle bonne idée
Posté par barmic 🦦 . En réponse au lien Héberger une base de données SQLite sur Github Pages (ou un autre hébergement statique). Évalué à 3. Dernière modification le 19 octobre 2022 à 16:00.
Si j'ai bien compris c'est l'inverse il utilise intensivement xhr. Il utilise sqlite comme un client et les données sont récupérées via des requêtes range.
Et le code est sur github : sql.js-httpvfs
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Sous exploité
Posté par barmic 🦦 . En réponse au journal Foehn - Exploration des données SCADA du parc éolien de la Haute Borne. Évalué à 2.
Tout à fait, mais c'est une moyenne dont je ne connais pas l'écart type. Déjà en France il semble varier de 8 à 26% selon les régions et il me semble que le facteur de charge s'améliore continuellement (je crois que c'est lié aux capacités des éoliennes à se déclencher avec moins de vent et à continuer à être utiliser malgré des plus grand vents).
Bref je n'y connais pas grand chose, mais il faut bien plus contextualiser pour pouvoir épiloguer sur la pertinence d'un site.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Sous exploité
Posté par barmic 🦦 . En réponse au journal Foehn - Exploration des données SCADA du parc éolien de la Haute Borne. Évalué à 5.
Je me lancerais pas dans les calculs mais d'après Wikipedia le facteur de charge moyen pour de l'éolien terrestre en Europe est de 24%. Donc ça paraît pas déconnant.
Facteurs de charges typiques
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Websocket
Posté par barmic 🦦 . En réponse à la dépêche WebDAV Manager, un client WebDAV ultra-léger en JS. Évalué à 3.
Je pense que tu sois estime grandement le travail que ça représente. Tu dois créer une heuristique, être en mesure de déduire ses choix après coup pour pouvoir aider tes utilisateurs, tu va devoir la tester sur un paquet d'implémentations sur différents os voir différentes versions tout ça pour un truc qui aura pleins de cas aux limites (git n'a pas de sémantique de move dans les patch et tu perds facilement la continuité).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Websocket
Posté par barmic 🦦 . En réponse à la dépêche WebDAV Manager, un client WebDAV ultra-léger en JS. Évalué à 2.
C'est vrai qu'on a oublié de faire de l'authentification dans HTTP ⸮
Je rappel la phrase qui m'a fait tiquer :
Tu peux parfaitement permettre aux utilisateurs de récupérer leurs fichiers en HTTP pur. Oui il y a moins de fonctionnalités, mais ce n'est pas de l'enfermement.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Websocket
Posté par barmic 🦦 . En réponse à la dépêche WebDAV Manager, un client WebDAV ultra-léger en JS. Évalué à 0. Dernière modification le 14 octobre 2022 à 14:00.
Ah oui oui, mais il parlait de récupérer des fichiers.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Websocket
Posté par barmic 🦦 . En réponse à la dépêche WebDAV Manager, un client WebDAV ultra-léger en JS. Évalué à 0.
Je comprends pas. HTTP n'a pas besoin de webdav pour télécharger des fichiers.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Quelques améliorations d'UI/UX
Posté par barmic 🦦 . En réponse à la dépêche WebDAV Manager, un client WebDAV ultra-léger en JS. Évalué à 4.
Si je peux faire une suggestion, les fichiers semblent trié par ordre alphabétique, je pense que par date et par taille peut aussi être utile quand tu veux faire de la place dans ton dossier.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Websocket
Posté par barmic 🦦 . En réponse à la dépêche WebDAV Manager, un client WebDAV ultra-léger en JS. Évalué à 4.
Il parle du protocole au dessus de websocket qui serais ad hoc. C'est propriétaire au sens pas issue d'une normalisation, mais dédié à un logiciel.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Websocket
Posté par barmic 🦦 . En réponse à la dépêche WebDAV Manager, un client WebDAV ultra-léger en JS. Évalué à 2.
Plus avec HTTP/2 puis HTTP/3
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll