Pinaraf a écrit 3671 commentaires

C'est amusant ce choix d'écriture.
D'un côté on a diverses applications avec des dépendances, Python, Ruby, Mono… Et de l'autre on a une application qui dépend du JRE, et là, attention : on précise bien qu'il faut le JRE pour elle…

Y'a un ".dmg", ça marche plus sur MacOS ?
https://binary-factory.kde.org/view/MacOS/job/Kate_Release_macos/

Mais c'est bien normale, y'a pas deux souci. J'aime bien l'apprendage des choses sur linuxsaitfaire.

Peux tu me dire ce que tu pointes en particulier ?

J'avais perdu ça dans le message.
Je me suis infligé le documentaire une seconde fois pour trouver ce qui suit.

Montrer ainsi une corrélation est très dangereux.

À partir du moment où tu interroges des personnes largement décriées qui continuent de crier des contre-vérités basées sur des études scientifiques biaisées et amplement "débunkées", tu peux être dans deux cas :
- étudier les dérives de ce genre de personne, avec le bon contexte qui précise qu'elles ne parlent qu'avec des œillères bien particulières,
- propager leurs idées, que ce soit par soutien ou juste parce que ça sert ton contenu.

Ce documentaire est dans le deuxième cas. Et quand on me vend comme mise en bouche de la vidéo une image avec écrit en grand «Science», c'est une fumisterie dangereuse.

J'ai vu ce documentaire y'a quelques jours. Assez vite, pas mal d'éléments ont commencé à me perturber, notamment l'assimilation de la corrélation à une causalité sur certains éléments.
Du coup, un peu de recherche… hooo, dans le lot des gens interrogés, il y a des anti-vaccins notoires, notamment certains illuminés qui accusent les vaccins de provoquer l'autisme (Michel de Lorgeril).

Quand on se permet d'interroger ce genre de personne dans un documentaire, c'est qu'on a abandonné tout sérieux et toute rigueur.

Non, mais rien ne dit qu'il n'y en avait pas, et c'est le sens de ma blague.

Expérience personnelle : dans un taf précédent, on a demandé à des collègues de former des prestas dans le but explicite de délocaliser le travail en Inde (et donc de laisser partir les collègues français). Tu penses que les collègues étaient encore motivés ?

Une des blagues quand j'étais presta est qu'heureusement qu'on était là car les internes ne foutaient pas grand chose.

Les prestas sont arrivés parce que les internes étaient démotivés ?
Ou les internes étaient démotivés parce que les prestas sont arrivés ?

Vous avez 2H.

Ben non c'est une déviance du capitalisme francais parce que les choses ne sont pas identiques ailleurs.

Oui et non. Je ne sais pas pour les services infos dans le reste de l'Europe, mais mes potes de lycée devenus ingénieurs en méca, dont un dans l'automobile, sont largement témoins des déboires qui sont arrivés à leur domaine, et ce dans d'autres pays (Belgique, Allemagne).
De plus en plus les constructeurs automobiles vont sous-traiter des pans entiers de conception. Mais du coup, quand le constructeur A fait appel au sous-traitant X pour la conception d'un nouveau système d'essuie-glace à rayons laser, puis que plus tard B fait appel à X pour un systéme équivalent… on peut arriver à des situations ubuesques où la voiture de B sortira avant celle de A, sans qu'il n'y ait vol de propriété intellectuelle : c'est juste que les équipes de X ont passé du temps à essuyer les plâtres, et cette expérience n'était pas rattachée à l'entreprise A.

Autre facteur d'ailleurs : quand on a tout mis en place pour passer par une ESN… on peut faire jouer la sainte concurrence et passer d'une ESN en France à une ESN en Inde ou un autre pays à bas coût.

Si c'est ca, c'est con mais c'est fascinant.

Exactement. Je t'invite à l'encadrer cette phrase :)

Qui dans l'entreprise fait l'analyse que la seconde ligne compatble qui coute plus chère est nettement mieux?

Personne, puisque ce n'est pas le but.
Ça améliore par contre des indicateurs importants pour les investisseurs, importants pour la bourse.
Le recours aux ESN n'est au final qu'un signe de la déviance du capitalisme. On n'a jamais intégré dans la valeur d'une entreprise l'ancienneté (et donc l'expérience) de ses salariés. Ça n'existe pas.
Par contre, ce qui a été intégré, c'est le risque de devoir payer des indemnités de licenciement XXL aux salariés (XXL, qu'on s'entende bien, reste négligeable par rapport aux sous que se versent la plupart des dirigeants de ces boites).

Alors, je précise immédiatement : je déteste ces arguments.
Ceci dit, voici ce que j'ai pu observer/entendre, notamment dans mes activités de membre d'un CSE :

• «personne n'est irremplaçable», traduit par beaucoup de managers en «on peut prendre n'importe qui avec des contrats externes, pour faire n'importe quelle tâche assurée par quelqu'un en interne» (parce que c'est bien connu, l'expérience, ça ne compte que pour les managers et dirigeants)
• un externe, c'est quelqu'un qui ne compte pas dans les effectifs, qui n'a pas de représentant du personnel, pas de défense en cas de litige…
• en cas de coup dur, les externes disparaissent d'un claquement de doigt, les internes c'est plus compliqué,
• niveau comptable, c'est pas la même ligne du tout, et dans toute l’irrationalité d'un système comptable, vis-à-vis des investisseurs, il vaut mieux payer plus dans cette ligne que de payer plus dans la ligne salaires.

En fait tout se résume au mépris total de l'humain. C'est dans le nom d'ailleurs, «Gestion des Ressources Humaines», pas «Gestion du personnel». Tu es une ressource, pas une personne.

Tout dépend de la communauté existante et de son acceptabilité d'un tel changement.
Sur par exemple le noyau ou le projet PostgreSQL, 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).

D'ailleurs, dans les plaintes contre la migration de GNOME sur discourse, j'en ai vu une assez intéressante : il s'agissait des développeurs d'evolution… Et effectivement, c'est «amusant» de voir qu'on retire aux développeurs d'un logiciel un outil de communication qu'ils utilisaient avec leur logiciel.

Discourse fournit une API rest il me semble, donc si ça doit être possible: https://docs.discourse.org/openapi.json

J'adore ce genre de réponse. «y'a une api, c'est bon, tu peux coder ton client dans ton coin». Ça me fait penser à ceux qui me traitent de passéiste à vouloir garder XMPP pour qu'on continue à avoir nos clients desktops et pas des bousins en JavaScript, avec exactement le même argument de l'API.
La présence d'une API, si tant est qu'elle soit complète, n'est pas suffisant. Ne serait-ce que du point de vue du développeur d'un client : Si demain une fonctionnalité est ajoutée sur l'interface web mais absente de l'API, et qu'elle rend des éléments invisibles, comment faire ? Comment être notifié de l'arrivée de nouvelles APIs ? Et c'est pas un travail anodin, c'est long et fastidieux de faire un client pour ce genre d'usage.
Puis du point de vue d'un utilisateur qui explique qu'on lui retire son outil, «t'as qu'à t'en coder un», c'est une excellente idée ma foi…

Également, d'un point de vue philosophique, pourquoi est-ce-que je développerais un client pour un logiciel, certes libre, mais avec un protocole propriétaire à ce logiciel, et chapeauté par une entreprise dans un paradis fiscal ? Dans mon taf précédent, on subissait Slack, j'avais commencé à coder un client alternatif en Qt… Je l'ai utilisé un temps, mais j'en ai arrêté le développement, car au final rendre Slack utilisable, c'est améliorer cet outil, et c'est clairement pas à moi de le faire sur mon temps libre…

Je n'ai pas cherché mais il y a probablement déjà des interfaces pour terminaux.

J'ai cherché, je n'en ai pas trouvé. En tout cas pas dans les paquets Archlinux, ni les paquets Debian, ni sur Internet.

D'ailleurs, ça n'a pas été listé lors de la discussion du projet Debian sur une éventuelle utilisation de Discourse, cf https://lwn.net/Articles/817668/

Ben… oui… les jeunes que je croise au quotidien (une vingtaine d'années) n'utilisent pas le mail, donc le principe d'une ML et son usage leur sont complètement étrangers.

Donc, plutôt que de leur faire apprendre un outil indispensable plus tard (que je sache, il n'y a pas de discourse.gouv.fr, ni dans la plupart des entreprises), on abandonne ?

la barrière technique pour les nouveaux utilisateurs était trop élevée.

Vraiment ?
Il y a vraiment des personnes qui trouvent compliqué de s'inscrire et répondre sur une mailing list ? Et il est préférable, plutôt que de chercher à résoudre ce qui semble être un problème d'utilisabilité du mail, d'abandonner cet outil pour passer à des machins web ?
Y a-t-il des témoignages d'utilisateurs expliquant où se trouvent les difficultés ? Il ne suffit pas de dire «la barrière est élevée» pour que ce soit vrai, encore faut-il que ce soit démontré…

pour tourner sur un Pi sans serveur graphique par exemple.

Un pi sans serveur graphique ne veut pas dire sans GUI. Par exemple eglfs marche très bien…

L'autre bonne raison (dont je n'ai pas parlé, j'aurais dû) de ne pas vouloir tout faire en Qt, mais le cantonner vraimement à l'UI, c'est qu'un utilisateur pourrait avoir envie de lancer le soft en mode headless, pour juste lire son patch sur une machine pas forcément très performante, sans s'encombrer du poids de l'interface. Pour une session live par exemple. Du coup l'approche synthèse en C au plus bas niveau possible semble plus pertinente. Après je ne sais pas trop ce qui est possible de faire en pur Qt à ce niveau. Faut que je me renseigne serieusement.

Ça dépend, est-ce un problème que les libQtGui.so et autres soient installés ? Si c'est pas un problème, tu peux faire tourner une appli Qt sans lancer les composants d'interface graphique (voire avoir la flemme et utiliser un petit QT_QPA_PLATFORM=offscreen pour ne pas dépendre de X11/Wayland/eglfs)

Je lis «thread» et «Python» dans la même phrase, je m'inquiète.
Que vont faire les threads en question ?
Il ne faut jamais perdre de vue qu'en Python, il n'y a qu'un seul thread qui exécute du code Python par interpréteur. C'est le fameux GIL.
Mais donc, si on est sur des threads qui ne feront pas de tâche intensive en CPU… quel devient leur intérêt par rapport à un modèle plus événementiel ? Et si c'est des tâches intensives en CPU, alors ça part dans du multi-processus Python…

Mon avis, c'est que sa réponse améliore la blague…

Les avis, c'est comme les trous du cul : chacun le sien.

Non, les avis sont à partager pour éclairer chacun.

Je te laisse donc imaginer l'éclairage…

Tu crois que toutes les distros envoient un mail au développeur de chaque bout de code, librairie, petit utilitaire avant de fournir un paquet? Tu crois que c'est une méthode de fonctionnement valable? Moi je serais le dev de la lib trucumuche, ça me gaverait de recevoir 50 emails de ce genre.

Bonjour sophisme.
Comparer une lib ou un petit utilitaire à un chantier de reverse engineering produisant un ensemble de patchs au noyau, y compris un nouveau pilote DRM en Rust, et une autre pelletée de code dans Mesa et ailleurs…

Là, ce que fait la distro, c'est juste tenter de tirer la couverture à soi tout en prenant le risque de discréditer le travail des développeurs en mettant dans les mains de personnes pas du tout prêtes du code complètement expérimental.
Donc non, le problème ne sera pas seulement entre manjaro et ses utilisateurs.

La critique serait qu'ils utilisent un noyau instable dans leur version dite stable, c'est ça ?

La critique, c'est qu'ils utilisent un noyau hautement expérimental, dont le développement est incessant, et envoient ça aux utilisateurs sans avoir demandé aux développeurs de la série de patchs du noyau ce qu'ils en pensaient ou l'état général de la chose. En l'occurence, les patchs pour les SoC Apple M1 et M2. C'est ultra expérimental, j'ai cru lire que ça pouvait détruire les hauts-parleurs selon les réglages… on est bien bien bien au delà de "instable".
Du coup les développeurs des patchs ne sont pas contents parce qu'on ne leur a pas demandé leur avis, aucun canal n'a été mis en place.
Une distribution ne devrait pas venir prendre du code en développement (surtout à ce niveau là) sans discuter, c'est la moindre des politesses.

Sous le post ci-dessus plusieurs personnes se plaignent de la version Pinephone de la distribution et maintenant cette critique de l'équipe ARM.
Vous avez un avis éclairé sur cette distribution et l'objectif de l'équipe ?

Les avis, c'est comme les trous du cul : chacun le sien.

Mais sur mon pinephone, j'ai eu plusieurs problèmes directement liés à des choix côté manjaro. Le plus récent date de ce matin : contraintes incorrectes sur les versions des paquets, du coup mon système a cessé de fonctionner suite à une désynchro partielle des miroirs (le miroir FR/EU n'avait pas la bonne version de qt5-wayland-client).
Dans le lot des soucis liés à la distrib, le principal autre a été des fichiers de conf incorrects pour l'audio (alors que les confs correctes tournaient depuis des mois). Ça donne vraiment pas l'impression d'une distribution sérieuse, j'envisage de changer (mais y'a un port de Sculpt OS qui a été annoncé, ça m'intéresse bien donc j'hésite)

Avant de bannir un processeur, peut-être peut-on le faire tourner plus longtemps en idle (voire l'éteindre hein, on sait jamais)… Genre je ne pense pas que le site de lemonde doive consommer 2% de CPU en consultation… Du coup j'utilise noscript et ublock