ElVirolo a écrit 484 commentaires

Tout à fait, mais je pense que c'est un problème secondaire (voire, je l'imagine, pas un problème du tout pour les développeurs de Hare). Si le public de Hare se limite aux utilisateurs d'OS libres, cela ne pose pas nécessairement problème. Qui a dit qu'un logiciel/langage devait avoir la diffusion la plus large possible :) ?

un doigt levé à quiconque le demande ou souhaite fournir le support pour.

Tout d'abord, on n'en sait rien. Ensuite, même si c'était le cas, et alors ? Encore une fois, personne n'empêche quiconque de le faire - et une implémentation de Hare pour un système privateur aurait peut-être un succès fou, quoi que l'équipe de développement en pense.

Beaucoup de gens ne fournissent pas le support pour X ou Y système parce qu'ils n'ont ni les compétences, ni le matériel pour mais de là fermer la porte immédiatement c'est à mon sens inconcevable pour un langage.

Encore une fois, ils ne peuvent pas « fermer la porte », seulement ne pas effectuer ce travail eux-mêmes. Je ne vois pas ce que change le fait que nous ayons affaire à un langage de programmation. Ne pas développer d'implémentation pour un OS privateur est un choix de développement comme un autre. L'équipe de Hare ne doit rien à quiconque (encore moins aux OS privateurs, qui nous pourrissent déjà suffisamment la vie). Ils proposent un travail, dont on fait ce qu'on veut.

Avant je n'avais pas de mac et pour autant j'ai jamais dit sur un quelconque de mes projets « il ne sera jamais disponible pour macOS ». Un jour une personne m'a aidé à porter mon programme pour et j'étais ravi qu'il ai pu m'aider à le faire.

C'est tout à ton honneur. D'un autre côté, je comprends que lorsqu'on utilise et promeut le logiciel libre, on ne souhaite pas se donner l'(immense) peine d'assurer le support d'un OS privateur. C'est un logiciel libre : son auteur ne doit rien à personne, ses utilisateurs ne doivent rien à l'auteur, hormis le respect de la licence qu'il a choisie qui, en l'occurrence, n'empêche aucunement une implémentation tournant sur un OS propriétaire.

Cela ressemble à un procès d'intention. Encore une fois, aucun support des OS privateurs n'est prévu par l'équipe de développement. Et alors ?

Quand j'écris un programme, je n'ai aucune envie de m'assurer qu'il puisse être compilé sur un OS privateur. Étant donné que mes programmes sont libres, chacun peut se charger de ce travail s'il ou elle le souhaite. Qu'il s'agisse ici d'un langage de programmation (en aparté, quand cesserons-nous d'employer cet affreux anglicisme ?) ne change, à mon sens, rien à l'affaire, puisque le compilateur et le langage lui-même sont distincts.

Je vois mal des gens faire un portage downstream qui soit pas officialisé.

Pourquoi ? Par exemple, il y a des distributions/builds d'Emacs (et donc d'Emacs Lisp) non-officiels pour des OS privateurs. Pourtant, on ne peut pas considérer que l'équipe de développement (et surtout, son chef) accueillent particulièrement chaleureusement lesdits OS privateurs. Je ne vois pas pourquoi on ne pourrait pas faire la même chose pour Hare.

Le rapport est personnel : il a des molaires contre lui et ne loupe pas l'occasion de régler ses comptes par commentaires ici.

Oui, j'ai remarqué. Je vois pas trop l'intérêt, d'ailleurs, je crois qu'on commence à avoir compris (je trouve par ailleurs qu'il y a des choses critiquables chez Drew, m'enfin de là à en faire une maladie/obsession et à en faire profiter tout le monde à chaque fois, sans que le rapport avec le sujet en question soit particulièrement évident…).

Je ne poserai pas la question par rapport au fait que le système soit privateur mais juste au fait qu'on l'utilise et qu'on le connait.

Certes, mais de là à « mettre à la poubelle » un langage entier (sans en faire de commentaires techniques, ce que je trouverais d'ailleurs intéressant en tant que béotien) au motif qu'il n'existe pas d'implémentation officielle sur des OS privateurs alors que nous sommes sur un site traitant de Linux et des logiciels libres, il y a quelque chose qui me dépasse.

Drew - dont l'égo surdimensionné n'est plus à démontrer -

Si, si, il est toujours à démontrer (et quel est le rapport, par ailleurs ?) ;)

refuser de base des plateformes pour des opinions personnelles c'est probablement pas la bonne décision pour un langage

Ce sont des opinions politiques, et cela me paraît constituer une opinion tout à fait valable. Libre à chacun d'écrire une implémentation de Hare pour un système privateur, libre à lui de ne pas vouloir s'embêter avec cela.

Je n'ai pas bien compris depuis quand la qualité d'un langage était jugée à la capacité de son fondateur à en écrire une implémentation pour un système privateur (le langage n'est pas son implémentation), surtout quand ladite implémentation est tout à fait possible techniquement et juridiquement.

J'ai fait un comptage au doigt mouillé (j'espère que je ne me suis pas trompé, c'est vraiment à prendre avec des pincettes) :

Pour linux-lts :

$ git --no-pager log --pretty=reference --date-order -E --grep 'upgpkg' | awk '/[0-9]{4}-[0-9]{2}-[0-9]{2}\)$/ {print $NF}' | tr -d ')' | awk -F '-' 'BEGIN {OFS="-"}{print $1,$2}' | uniq -c | awk '{total += $1; count++} END {print total/count}'
4.79508


Pour linux (on compte le nombre de passages de [testing] à [core]):

$ git --no-pager log --pretty=reference --date-order -E --grep 'db-move' | awk '/[0-9]{4}-[0-9]{2}-[0-9]{2}\)$/ {print $NF}' | tr -d ')' | awk -F '-' 'BEGIN {OFS="-"}{print $1,$2}' | uniq -c | awk '{total += $1; count++} END {print total/count}'
6.24427


Chaque chiffre est une fréquence moyenne d'upgrade par mois.

Merci beaucoup pour ta réponse.

1) Pour la question du choix : je comprends, et j'approuve, mais je doute de sa pertinence en ce qui concerne les utilisateurs lambda. J'aime bien avoir le choix aussi (et manifestement, j'ai choisi systemd), mais je n'ai pas besoin d'avoir le choix du système d'init au sein de ma distribution. Celle-ci m'impose d'ailleurs d'utiliser le noyau Linux, qui est monolithique. Si je ne veux pas utiliser systemd, je n'utilise pas Arch Linux (c'est d'ailleurs ce que vous avez fait), mais ça n'a rien à voir avec systemd. Si je ne veux pas utiliser de noyau monolithique, j'utilise Hurd ou Helios (et je m'amuse bien…). Je comprends que les développeurs d'Arch Linux ne passent pas des mois à offrir le support pour plusieurs systèmes d'init (ou noyaux).

2) La question de la « philosophie Unix »

historiquement c'est Windows le gros truc monolithique, avec l'affichage qui est prioritaire sur le multi-tâches.

Le noyau Linux aussi est « monolithique » (certes, c'est très différent de l'exemple que tu donnes mais cela montre que l'argument est à géométrie variable, du moins c'est ce qu'il me semble).

3) La question du contrôle du développement par une grosse entreprise

Économiquement, c'est développé par une grosse boîte, rachetée par IBM. C'est pas un truc que "la communauté du libre" (j'entends par là : la communauté bénévole) va pouvoir reprendre et maintenir si IBM l'abandonne.

Peut-être que si :) Et si ce n'est pas le cas, on passera à autre chose, comme on l'a fait dix fois par le passé :) Que ça soit développé par une grosse boîte ne change à mon sens pas grand chose - ou alors quelque chose m'échappe. C'est un logiciel libre, on en fait ce qu'on veut. Si on n'y arrive pas, on fait autre chose, comme pour n'importe quel logiciel libre.

Pour le cas de Firefox, il existe, comme tu le sais, des forks ôtant les fonctionnalités qui gênent ou sont imposées. Pour moi aussi, utiliser des logiciels libre relève de la résistance au capitalisme de surveillance, mais j'ai du mal à voir le rapport avec systemd (ou même les grosses boîtes). La beauté et l'efficacité du libre résident justement dans sa neutralité axiologique. Ce qui compte, c'est la licence du code, pas d'où il vient. L'émancipation qu'il permet est mécanique, elle ne repose ni sur un jugement, ni sur des valeurs.

4) Sur la question du fait que la configuration soit plus aisée avec de petits programmes, mon intuition me fait pencher de ton côté (et souvent, c'est un usage que je préfère d'ailleurs). Mais je suis pas certain qu'un débutant ait besoin de configurer son système d'init tous les quatre matins. Moi-même, alors que je sais écrire un script d'init, recompiler un noyau, écrire des patches (alors que je ne suis pas programmeur, comme un utilisateur lambda), je n'ai quasiment jamais besoin de le faire.

J'ai la même expérience que toi. J'installe en général Linux Mint sur les PC de mes proches qui me demandent que je leur « installe Linux ». Je leur répète un nombre de fois incalculable qu'il leur faut installer les mises à jour, mais seule ma compagne le fait (certainement parce qu'elle a, la pauvre, probablement été encore plus que les autres exposée à mes consignes). De fait, c'est moi qui les installe tous les 36 du mois quand j'ai leur PC sous la main.

Je comprends en revanche qu'ils et elles n'installent pas les upgrades d'une version majeure à l'autre - c'est souvent peu aisé, ou peu évident à trouver dans la GUI.

Par ailleurs, j'adore Arch Linux et l'utilise sur toutes mes machines (portable, serveur, téléphone), mais, comme toi, j'ai du mal à saisir l'intérêt d'une rolling release pour des débutants.

En ce qui concerne systemd, sans vouloir réouvrir une flame war, je dois admettre que je ne comprends rien à toutes ces crispations.
Je suis un utilisateur avancé de GNU/Linux (utilisation quotidienne et intensive depuis plus de quinze ans) mais je reste, aussi, un utilisateur lambda au sens où, souvent, j'ai simplement besoin d'utiliser mon PC sans avoir à peaufiner ou tripatouiller cent mille choses. Du point de vue de l'utilisateur lambda, donc, je dois avouer que systemd, je m'en fiche éperdument. Tout ce dont j'ai besoin de savoir dans les cas où je ne suis pas en train d'écrire un service ou un timer (soit 99% du temps) se résume à systemctl [--user] [enable | start] [--now] service. C'est tout. Le reste n'a aucune incidence sur moi, et je m'en fiche. Tout ce que je sais, c'est que 1) C'est un logiciel libre 2) Ça marche. Et ça me suffit.

Quant au poncif de la « philosophie Unix », de la même façon, j'ai du mal à en saisir l'intérêt. Est-elle obligatoire tout le temps, partout ? Est-elle indispensable ? Je passe plus de la moitié de mon temps dans Emacs, qui est exactement le contraire de la « philosophie Unix » (certains diront que si en coupant les cheveux en quatre, cela dit). Et alors ? Je l'utilise précisément parce qu'il fait plein de choses de façon intégrée, et j'en suis très content. La philosophie truc ou bidule, je m'en fiche un peu, tant que le programme est libre et me convient.

Je suis conscient que j'ai certainement tort et serais ravi d'entendre des arguments rationnels et pragmatiques (c'est-à-dire illustrés de cas concrets et sans « bashing » a priori) sur la question.

Merci pour le journal, c'est un retour intéressant !

edit : pardon, je voulais répondre à zurvan.

Tout à fait ! Mais je comprends, notamment pour celles et ceux, habitant loin d'une boulangerie, qui font leur pain tous les jours, qu'on préfère s'en passer.

En aparté, j'utilise un plat en céramique circulaire muni d'un couvercle, ce qui permet de donner au pain une forme plus « naturelle ». Il ressemble à un pain de campagne qu'on trouve dans les boulangeries (et il est très croustillant).

À toutes fins utiles, il est également possible d'acheter du levain sec, notamment dans les boutiques bio. J'utilise de temps en temps cette recette, qui permet de se passer de pétrissage (et donc de machine à pain), et qui fait un excellent pain (meilleur, d'après moi, que celui des machines à pain) :

Pain sans pétrissage

Ingrédients

• 550g de farine T80 (ou un mélange de diverses farines comprenant au moins 300g de farine T65)
• 1 cuillère à soupe de sel fin
• 15 g de levain sec
• selon l'envie : graines, noix, épices, herbes, voire dés de fromage, tomates séchées, olives, etc.
• 450 à 480ml d'eau tiède à chaude.

Instructions

• Mélangez tous les ingrédients secs.
• Ajoutez l'eau, juste assez pour que l'ensemble des ingrédients soit humide.
• Couvrez avec une serviette éponge mouillée et laissez lever pendant 12h (minimum 8h, maximum 16h).
• Faites chauffer au four, à 220°C, un plat avec couvercle, vide et bien fariné.
• Quand le four est chaud, sortez le plat chaud du four et à l'aide d'une spatule, décollez la pâte des bords du saladier et versez-la directement dans le plat. Incisez le pain (facultatif). Recouvrez avec le couvercle encore chaud.
• Enfournez pour 1h.
• Après l'heure de cuisson, retirez le couvercle du plat et poursuivez la cuisson pendant 15 min, four éteint.
• Sortez le pain du plat immédiatement à sa sortie du four et laissez-le refroidir sur une grille.

Cette recette fonctionne certainement avec du levain vivant, mais il doit falloir adapter les quantités.

Bravo pour le journal !

Je viens de voir, par hasard, ce commentaire que Drew a laissé sur le Gitlab de PostmarketOS:

I don't think that HTML email is a great idea and I'm generally opposed to allowing it. However, I think it might make sense to allow it on some mailing lists (e.g. -discuss or -users) but not on others (e.g. -dev). Somewhat open to suggestions/patches on this theme.
On a vu moins tolérante et plus autoritaire, comme position… Je maintiens donc qu'il faut arrêter la fixation sur lui (ou sur le fantasme qu'on s'en fait).

D'après mon expérience, les courriels en HTML sont simplement rejetés par lists.sr.st. C'est son service, il en fait ce qu'il en veut, personne n'est « forcé » de ne pas utiliser d'HTML.

C'est un choix parmi d'autres. J'ai choisi d'utiliser Sourcehut entre autres pour cette raison. Il ne me viendrait pas à l'idée de lui reprocher de m'imposer de ne pas pouvoir utiliser de Javascript sur pages.sr.ht, par exemple. It's a feature, not a bug. Et libre à moi d'utiliser n'importe lequel des multiples autres services similaires.

Drew peut certes être grinçant, mais c'est un autre problème.

Il faut arrêter de suivre ce type qui s'auto proclame la voix de la sagesse en plus d'être une vraie drama queen.

Je ne vois pas ce qu'il y a de « drama queen » dans le lien que tu cites. Par ailleurs, c'est une « insulte » qui me paraît plus que problématique.

Drew a certes souvent des opinions arrêtées, et il n'a pas toujours été des plus diplomates (et, pour en avoir parlé avec lui, il en est conscient et a fait beaucoup d'efforts - insuffisants peut-être).

il les propage comme une véritable peste

C'est lui qui les « propage » ou ses utilisateurs qui décident de les adopter ?

Vu le nombre de commentaires acrimonieux, voire violents, à son égard que tu postes ici, il semble que que tu aies un dent particulière (personnelle, peut-être) contre lui, ce que je peux tout à fait comprendre. J'ai moi-même parfois eu du mal dans mes échanges avec lui.

Ce que je ne comprends pas, en revanche, c'est la propension de ses détracteurs à recourir à des méthodes similaires à celles qu'ils dénoncent chez lui. On ne pourrait pas juste discuter ses propositions froidement et rationnellement, sans agressivité, généralisations et attaques ad hominem ? Je peux comprendre que ses manières soient parfois problématiques, mais je ne vois pas l'intérêt de toujours ramener le fond à la forme (ce qui, ironiquement, est justement ce que cherche une « personne qui a besoin de beaucoup d'attention et le fait savoir »).

Ce n'est pas parce que c'est une personne qui a tous les défauts du monde qu'elle a nécessairement tort. Les deux choses sont tout à fait distinctes. Si à chaque fois qu'un de ses propos ou opinions est relayé, on a le droit à « de toute façon, c'est un sale type », on est bien avancés…

J'espère effectivement que c'est « simplement » une (très mauvaise) traduction automatique.

Par ailleurs, l'article est extrêmement mal écrit.

Rassure-moi, c'est une plaisanterie ?

Une entité qui a beaucoup de salariés, et d'autant plus s'ils sont bien payés, a besoin de réaliser des profits pour les rémunérer

J'aurais dû m'exprimer de façon plus précise. Je réagissais justement à cette question de « profit à tirer pour payer les salariés ». Ce qui sert à payer un salarié n'est pas du profit, c'est un coût de production. L'excédent ne « sert » pas à payer les salariés. D'ailleurs, en France, une association ne peut servir à enrichir un de ses membres ou salariés.

On peut considérer que les coût de production de telle ou telle association sont trop élevés, mais il ne s'agit pas de profit.

Je n'ai pas d'avis éclairé sur la question. Signal défend son modèle centralisé au motif que cela permet de mettre en place de nouvelles fonctionnalités plus vite, que cela supprime la nécessité de devoir fournir un support des clients tiers et que cela permet d'assurer un contrôle plus strict de la sécurité.

Matrix - que j'aime beaucoup et utilise par ailleurs - ne fournit, par exemple, à mon sens, pas une alternative sérieuse à Signal pour l'instant en ce qui concerne les conversations 1:1. La quantité de métadonnées perçues par les serveurs est sans commune mesure avec celles disponibles avec Signal. Par ailleurs, les clients laissent à désirer - pour l'instant. Je me vois mal conseiller Matrix à mes amis, alors qu'ils utilisent presque tous Signal.

Je comprends sur point de vue sur la centralisation, mais peut-être que la balance avantages/inconvénients relative aux questions de sécurité penche en sa faveur.

Pour la question du numéro de téléphone, je suis d'accord avec toi dans l'absolu, mais je pense que l'utilisation d'un numéro de téléphone a été un facteur majeur d'adoption massive de Signal et que c'est peut-être un compromis bénéfique, toutes choses égales par ailleurs.

Enfin, une carte SIM Lycamobile ne coûte que quelques euros, et elle n'a besoin d'être utilisée qu'une fois. J'imagine qu'il en va de même pour un numéro de VOIP - par ailleurs, je rappelle qu'à terme il ne sera plus obligatoire de fournir un numéro de téléphone.

Je suis un peu déçu, je m'attendais à une version féline de l'IP par transporteurs aviaires.

en plus on ne peut pas contrôler que côté serveurs ils ne décryptent pas tes messages

Je me trompe peut-être, mais a priori, tout l'enjeu est que, justement, cette vérification est inutile. Les messages sont chiffrés de bout en bout, sur le client, donc. Par ailleurs, du fait du système de ratchet, la clef de chiffrement change pour chaque message.

Si l'on ne fait pas confiance au chiffrement de bout en bout (pour quelle raison d'ailleurs ? Le client est libre et tu peux le compiler toi-même), alors ça s'applique aussi à Matrix. Je n'ai pas a priori davantage de raison de faire confiance à un système décentralisé qu'à un système centralisé.

Rappelons juste que le "non profit" est pour l'organisation, pas pour ceux qui la dirigent (coucou Mozilla),

Je ne comprends pas ton argument, ni la distinction « profit pour l'organisation » / « profit pour ses dirigeants ». Le profit est le profit, cela n'a aucun rapport avec la rémunération d'un salarié, aussi élevée soit-elle.

Dans un « nonprofit », les revenus dépassant le montant agrégé des coûts doit être réinvesti dans l'organisation, point. Qu'un dirigeant soit « bien payé » (qu'est-ce que cela veut dire, d'ailleurs ? quel est le seuil ?) n'a aucun rapport avec un quelconque profit.

Par ailleurs, je déplore le fait que la rémunération de la présidente de la fondation Mozilla soit aussi élevée, mais cela n'a aucun rapport avec une quelconque question de profit.

J'ai du mal à saisir le problème du numéro de téléphone utilisé comme identifiant. C'est un reproche que l'on fait souvent à Signal, mais il ne me semble qu'en partie fondé (en outre, Open Whisper travaille à une identification par nom d'utilisateur dans tous les cas).

Il est tout à fait possible d'utiliser une carte SIM anonyme/de VOIP, etc. Par ailleurs, Matrix expose bien plus de métadonnées que Signal qui, lui, les réduit à leur strict minimum.

Je ne vois pas absolument pas le rapport entre le fait que Signal soit libre et le fait qu'il n'autorise pas la fédération. L'ensemble du code de Signal, et de son serveur, est libre, point. Le modèle fédéré/centralisé n'a rien à voir avec cela. Libre à quiconque de monter un serveur Signal concurrent. On peut discuter de la pertinence de tel ou tel modèle, mais cela n'a strictement aucun rapport avec le fait que Signal soit libre ou non.

Je confirme que, dans mon cas, WoeUSB-ng a toujours très bien fonctionné.

Pas dans cet article en tout cas.

Si, c'est exactement ce qu'il fait dans cet article. S'il préfère les gestionnaires de paquets des distributions, ce n'est pas tant pour leur qualités intrinsèques (qui, comme tu le dis, ne pas tellement différentes de celles des autres systèmes) que pour, essentiellement, le système de contrôle (et de « contrôlabilité ») de la qualité des paquets, comme il le dit à la fin de l'article.

Soit on n'a pas lu le même article, soit je ne sais pas lire (ce qui est fort possible), soit c'est exactement ce qu'il dit.

Il ne parle pas tant de la nature de l'un ou l'autre des gestionnaire de paquets en tant que telle (système ou « overlay ») que des caractéristiques qui leur sont traditionnellement associées. D'où sa conclusion : « For my part, I’ll stick to the system package manager. But if you think that the overlay package manager can do it better: prove it. » (sous-entendu : mettez en place un système de contrôle/review/mainteneur du paquet indépendant du mainteneur du projet, voire des builds reproductibles, etc.).