Moonz a écrit 3621 commentaires

J’aime comment tu balaies d’un revers de main la difficulté de faire correctement de la distribution de clé. Si le canal avec le dev est pas sécurisé, comment peut-il te communiquer de manière sécurisée :
- l’identité de ce tiers ?
- sa propre identité ? (non parce que si en tant qu’attaquant j’ai juste à dire « je m’appelle moonz et je suis l’auteur de git-webui » pour te convaincre de télécharger ma version vérolée de git-webui…)

Il te faut un tiers connu avant l’échange. Tu peux m’en donner un là maintenant qui soit :
- suffisamment connu pour avoir confiance dans son intégrité (pas dguihal.ru ou moonz.ro quoi…)
- ait des procédures suffisamment sûres pour que je ne puisse pas m’inscrire avant alberthier et me prétendre comme étant lui
?

(on pourrait appeler ça « PKI », l’utiliser pour sécuriser des transactions HTTP qu’on renommerait pour le coup « HTTPs »… mais je m’égare)

Et de fait on s’éloigne du sujet, qui est: en quoi un "curl … | bash" est significativement pire que le cas médian/moyen (qui ne choque personne) qui n’est pas un machin signé avec une clé publique communiquée off-channel mais un simple tar.gz avec au mieux une somme de contrôle (sur le même canal de distribution) ? Et de toute façon, pourquoi diable aurais-tu plus confiance en un git-webui correctement signé d’un git-webui non signé vu qu’à priori tu ne connais de toute façon son auteur ni d’eve ni d’adam ?

Si le développeur n’est pas dans ton WoT (comme c’est généralement le cas) c’est comme md5.

Et tu peux faire confiance que le md5 publié correspond bien au code de l’auteur parce que ? …

c'est aussi avoir une confiance complètement aveugle non seulement en toi, mais aussi en toute la chaine des fournisseurs entre ton PC et mon PC

À partir du moment où tu comptes télécharger et exécuter son programme tu es de facto dans cette situation, indépendamment que l’installation se fasse avec un script bash, un paquet deb préparé avec amour, une suite d’instructions dans un README ou un installeur en .msi à utiliser avec wine…

et qui reprend un laconique « vous verray ! » d'un populiste formé à l'école d'une bureaucratie mythomane qui a affamé son peuple pendant des décennies pour entretenir l'illusion de pouvoir faire la course à la puissance ?

Huh ?

Il n'y a pas d'outil équivalent sous Linux?

btrfs send pour btrfs. À ma (maigre) connaissance il n’y a pas d’équivalent pour ext*.

Les journaux sont supposés être une "création" personnelle, d'où le nom journal. Ils sont moins nombreux mais ils sont uniques.

{{référence nécessaire}}

et ils se font pas chier avec des packagings aussi complique

D’un autre côté quand on a pas de système de package avec gestion des dépendances c’est plus facile de gérer les mises à jour de l’arbre complet, effectivement.

Je savais pas que c’était possible de se suicider à l’hélium…

Pas besoin de télécharger le tarball des sources, ni de le dépaqueter avec arch?

Non, ça fait partie du PKGBUILD (l’équivalent du debian/rules), les sources sont listées dans une variable source, téléchargées et décompressées automatiquement lors de la création du paquet (avec vérification des checksums, support de sources git/svn/mercurial…)

Sans compter l’Afrique.

Tu n’as de toute façon pas une seule config pour toutes les versions de la distro vu que chez debian chaque version de la distro a une version upstream différente…

le principe de rétro-compatibilité, sont vraiment très importants.

Pourquoi ? C’est quoi l’intérêt de pouvoir construire un package d’il y a 10 ans sur une distrib d’aujourd’hui ? En quoi est-ce tellement plus important que d’avoir un système propre et clair aujourd’hui ?

Donc rien, c'est une fonctionnalité présente dans RPM, très bien. C'est le genre de truc que je m'attends à voir dans les outils d'empaquetage bien fournis, mais pas dans des trucs volontairement très simples, c'est tout.

Je connais pas les ports mais c’est possible avec les PKGBUILD, qu’on aura pourtant du mal à ne pas classer dans la catégorie « volontairement très simple »

Je ne vois pas du tout en quoi une ligne "OnFailure=script1.unit" dans ton script2.unit c’est de la maintenance en moins relativement à écrire "script1.sh || script2.sh" dans un master.sh.

Les deux me semblent équivalents en fait.

Ça veut pas dire que c’est une mauvaise idée d’utiliser ainsi les fonctionnalités de systemd si tu l’utilises à la base pour d’autres raisons (templating, par défaut dans la distrib), c’est juste que ça me semble loin d’être une raison suffisante convaincante pour passer à systemd, ni un avantage énorme de ce dernier.

Comprend pas pourquoi tu aurais besoin d’un système spécial pour ça.

Tu fais tes scripts simples faisant une chose et une seule, puis un script maître pour chapeauter le tout.

Et le libéral te dira que ce que j’ai dit c’est aussi une simplification à outrance de sa pensée, et le libriste pareil, etc.

Au cas où ça t’aurait échappé, le but de mon post n’était pas de faire un résumé monoligne de deux-trois idéologies, c’était une simple illustration.

Ça commence à me sortir par les trous de nez cette manie de dériver sur une discussion sur la crasse sous l’ongle du doigt quand on pointe la lune…

à quel moment prend on acte qu'ils travaillent contre nous ?

À partir du moment où ils te désarment et te prennent ton argent ? :)

Le problème, c'est que face à une vérité complexe et pas toujours satisfaisante et une explication simpliste, c'est toujours l'explication simpliste qui l'emporte.

Et parfois la pensée simpliste est plus satisfaisante (héliocentrisme vs géocentrisme, au pif) que la réalité complexe qu’on veut à tout prix faire rentrer dans un système idéologique (et tout le monde a une idéologie)

Pour un socialiste, la pensée libérale est simpliste (« c’est vraiment trop simpliste de dire qu’il suffit de laisser les gens faire ce qu’ils veulent pour arriver à une situation optimale »). Il faut interdire la diffusion des idées libérales ?

Pour un libéral, la pensée socialiste est simpliste (« c’est vraiment trop simpliste de dire qu’il suffit d’arroser les pauvres d’argent pour mettre fin à la pauvreté »). Il faut interdire la diffusion des idées socialistes ?

Pour certains (même ici), la pensée libriste est simpliste (« c’est vraiment trop simpliste de dire qu’il suffit d’ouvrir le code pour avoir plein de gens pour trouver les bugs/failles »). Il faut d’urgence fermer LinuxFR ?

et alors ?

Des innovations moins rapides dans le domaine médical, c’est des morts hein…

Et on pourrait aussi mettre en place la version via GPG

Je connaissais DANE mais ça ça me dit rien du tout. Tu te réfères à quoi ?

Remplace "le tuer" par "tuer son pote".

Aux dernières nouvelles, la France soutenait (au moins diplomatiquement) l’Ukraine.

Vu qu’il existe déjà des SPOF, c’est pas grave d’en ajouter à tours de bras ?

Comment ils font pour que le navigateur ne hurle pas ?

Donc non clairement, ce n'est pas le workflow prévu par git.

J’ai dit Gi*s*t, pas Git.

Et sur le reste de ton message tu surinterprètes. Le truc que je dis être accepté (pifométriquement) par 99% des utilisateurs Git, c’est que le boulot se fait sur des branches fonctionnalités séparées et non pas directement sur master. Pour le reste, rebase vs merge, une branche par hotfix ou une unique branche hotfix, je sais bien qu’il y a autant d’opinions (tout aussi valables les unes que les autres) que de personnes, et non je dis pas que le workflow Github est LE workflow Git, d’autant plus que celui que j’ai mis en place au boulot en diffère substantiellement :)

Ce que je dis (et où je suis en profond désaccord), c’est que je trouve le workflow Github particulièrement adapté à ce qui m’intéresse pour comment j’aborde mes contributions aux logiciels libres : des petits patchs sur des projets, pas de grosses contributions qui demandent de grosses discussions, des tests/synchronisations fréquents, etc.

Le seul point qui a l’air de te chagriner c’est la multiplication des clones. Je ne vois pas du tout le problème : sauf très rares exceptions, le mainteneur c’est la racine de l’arbre. C’est une règle assez simple et claire je trouve.

D’un autre côté, la solution mailing list, ça veut dire :
- devoir s’inscrire à une mailing list (et les 3/4 des processus d’inscriptions aux ML sont ignoblement pénibles). Ça inclut choisir un mot de passe (genre je n’ai pas assez de mots de passe à gérer avec les 57 bugzilla et les 473 autres sites qui demandent une inscription…), et le risque (loin d’être négligeable puisque au final tout mail que tu envoies sur une ML se retrouvera broadacsté à des centaines voire des milliers d’inconnus) que le dit mail se retrouve dans la nature et devienne un nid à spams.
- faire chier 200 personnes qui n’en ont rien à faire de ton petit bug avec un message
- puis, pendant 2 mois, te faire spammer ta boîte mail avec des messages dont tu n’as que faire jusqu’à ce que tu aies le courage de suivre la procédure kafkaïenne de la mailing list pour te désincrire (et ce jusqu’au prochain bug)

Alors oui, si tu es un contributeur régulier les ML c’est cool. Oui, si le patch est important (grosse fonctionnalité) pouvoir en discuter en public c’est cool.

Pour des patchs d’une dizaine de lignes je préfère 100 fois deux clics sur une interface web

Avec ton exemple, je suis en effet totalement dans le flou

Mon exemple est un peu particulier dans le sens ou l’upstream a été obligé (DCMA notice) d’arrêter son dépôt, et qu’il peut donc difficilement désigner explicitement un repreneur sans se faire taper sur les doigts (et sans que ce repreneur lui-même aie le même problème).

Mais il illustre un autre avantage (mineur je le reconnais) de cette incitation au fork : même si un jour le dev initial décide (sur un coup de tête, problème légal,…) de tout supprimer, le code est toujours là. Avantage que n’auront pas les petits projets sur des trucs genre sourceforge.