bbo a écrit 263 commentaires

Stallman considers himself afflicted, to some degree, by autism

A mon avis, tu n'as probablement pas choisi la meilleure citation pour illustrer les propos d'anaseto. Parce que ça ressemble à un certificat SSL auto-signé ou à une attestation de sortie ;-)

Comme je n'ai pas lu ce bouquin, je ne sais pas si les autres mentions dont tu parles sont plus modérées ou sourcées. Quoiqu'il en soit, Stallman a visiblement dit que cette remarque était exagérée. L'article dit également :

But Stallman did acknowledge that he has "a few of the characteristics" and that he "might have what some people call a 'shadow' version of it."

Là encore, ok. Je veux bien le croire. Mais ça serait plus facile à accepter avec, par exemple, un avis médical.

et qu’il se tape la maintenance du code C.

Ou qu'il porte en BTR ?

Ok je --> []

Merci pour ton regard intéressant. Cela ne m'étonne pas vraiment qu'il ait un côté My way or the Highway.

Je ne le suis que de loin en loin et c'est vrai qu'il est assez radical (voir de plus en plus avec le temps ?). Par contre, j'avoue que je ne savais pas qu'il avait arrêté de contribuer à Alpine.

Dans un language plus « simple », chaque projet doit aussi ré-inventé la roue quand il faut faire quelque chose qui n'est pas prévu de base. Au final chaque projet a ses propres conventions qu'il faut ré-apprendre.

Donc cela veut dire que si tu veux qu'un langage "simple" perce, il te faut une grosse communauté qui fera des libs et frameworks qui seront considérés comme "standards".

Vu son billet, il ne cherche pas la comparaison avec rust mais juste avec le C. Après, il me semble inutile de faire la liste de ce que rust ou go ont déjà car :

• Ce nouveau langage reste quand même très flou jusqu'à présent :)
• C'est un furieux du minimalisme qui n'aime pas rust (je pense que la blague du nom est plutôt liée à ça qu'à une envie de concurrencer rust… c'est "better" dans la vision d'une partie des utilisateurs de source hut). Donc, les arguments que rust possède déjà les fonctionnalités qu'il veut, et bien je crois qu'il s'en fout :)
• Il a déjà plusieurs projets en Go et il a l'air d'aimer

En passant, merci pour tes réactions (et aux autres aussi hein ^). Je ne suis pas trop branché langage systèmes/"simples" et vous m'aidez à me faire mon éducation ;)

La comparaison avec Zig a été levée (mais pas en aussi détaillée que toi ⁾ sur la mailing list.

Morceau choisi :

May I ask how your new systems programming language differs from Zig?

It's much simpler, and does not provide any metaprogramming facilities
(such as comptime). Unlike Zig, BTR does not use LLVM.

Zig takes about 30 minutes to compile and run its test suite, not
including the time required to build LLVM, whereas BTR takes about 5
seconds to build qbe[0], its compiler, and its stdlib, and run the
compiler and stdlib test suites.

Après ce futur langage reste très mystérieux. Faudra voir dans 1 an :)

si c'est depuis dans un bureau graphique, c'est window() ;

Même s'il fonctionne sous Wayland ?

Il faudrait un terme plus clair pour désigner la fonction qui donne du travail aux autres. Peut être master?

Vu que c'est la porte d'entrée du programme, je pense que je l’appellerais door dans mon futur fork de ce futur langage.

Et surtout, c'est exactement ce qu'on attend en général de toi en entreprise

Absolument. Savoir naviguer dans un océan de legacy est une vraie compétence.

il y a un joli « drama » autour de ça

Et ça continue !

Le mainteneur pour FreeBSD (Kyle Evans, membre de la Core Team si j'ai bien compris) a jeté l'éponge !

Visiblement, il n'a pas trop apprécié le mode de communication de Jason Donenfeld.

Tu as très probablement raison.

Ça sera un grand moment quand Lennart intègrera Git dans systemd. Maintenant, je peux sortir !

On passe d'un truc qui a du sens à un truc qui n'en a pas → tout le monde en à rien à foutre.
On passe d'un truc qui n'en a pas à un truc qui n'en a pas → c'est offensant.

Je trouve que "main" a un peu plus de sens que "master" :

• J'ai quelques dépôts avec une seule et unique branche (genre, mes dotfiles) : "main" est plus explicite que "master"
• Dans un github-flow en livraison continue, "main" est aussi plus explicite que "master"

Cependant, "main" reste pas clair pour plein de projets :

• Je suis éditeur d'un logiciel on-premise ou je suis une distro GNU/Linux, "main" ne sera pas nécessairement hyper explicite (et encore). Des trucs comme "develop", "current", "next" seraient probablement plus explicites. Et avec des branches de maintenance nommées "stable/x.y" ou "maintenance-x-y", on verrait quand même bien à quoi servent les branches du dépôt.
• Je fournis un SaaS sans livraison continue, je trouve que des branches "dev", "staging", "prod" (si j'ai 3 plateformes) sont beaucoup plus explicites que les "develop", "release/x.y", "master" appliquées dogmatiquement "car c'est le git-flow" (mais qu'on a du mal à appliquer vraiment, entre autre parce que "git c'est compliqué").

Un projet qui doit mettre dans le README ou le CONTRIBUTING que "la master, c'est ce qu'on déploie donc il ne faut pas la casser" a peut-être un problème de nom ¹. Pourquoi ne pas nommer la branche "production" ou "shippable" ?

Là où je veux en venir c'est que nommer les choses, c'est compliqué (et les développeurs le savent bien). Comme on ne crée pas un dépôt Git tous les jours, j'aurai tout à fait toléré d'être forcé de définir le nom de ma branche principale (oh oh !) à l'initialisation de mon dépôt. Ainsi, plus de polémique sur le nom par défaut (car il n'y a plus !) et, ça me fera juste réfléchir 2 fois à la création d'un dépôt (mkdir think, cd think, git init again).

Franchement, je t'ai plussé car :

1. Tout à fait dans le thème d'un vendredi
2. J'ai bien rigolé, même si c'est beauf
3. T'étais à +41… Je ne pouvais pas laisser passer l'occasion d'aider une moule à voler à +42

… J'étais tombé sur Water CSS qui semble avoir quelques fonctionnalités de plus. Notamment le mode sombre/clair et des jolies icônes sur les adresses !

L'auteur a écrit carrément un nouveau billet pour répondre à des arguments qui font écho à ce qui a été discuté ici : Why not rely on app developer to handle security?.

Il y a des arguments qui ont déjà été donnés ici mais, si je me risque au TL;DR (de l'article, pas de mon avis hein :) ):

• En tant qu'utilisateur, il y a moins de tiers à qui faire confiance quand c'est la distro qui gère
• En tant qu'utilisateur, tu auras les correctifs plus vite car il n'y aura pas à attendre tous les projets amonts
• Meilleur bus factor. Les distributions couramment utilisées ont plus de volontaires que la grande majorité des projets logiciels qui sont plutôt petits, voir même maintenus par une seule personne (qui est une situation courante)
• Embarquer les bibliothèques pour connaître l'état et "garantir" le bon fonctionnement du logiciel posera toujours la question du nombre de cas testés (que se passe-t-il si les locale sont configurées différemment de la CI, que se passe-t-il si la plateforme n'est pas du x86, etc) et, paradoxalement, cela génère plus de travail puisque chaque projet aura du boulot.
• la distribution se retrouve toujours à devoir patcher un moment ou un autre (si le mainteneur est en vacances, ne répond pas vite, ne veut pas faire une version, etc). Donc, on est quand même obligé de faire confiance à la distribution (cf point 1)

Mais le soucis, c'est quand il y a un problème de sécurité :)

Pourtant, on n'est pas encore vendredi. N'aurions-nous pas à faire à une moule précoce ?

Ça devient un peu LOURD la rust propaganda :(

Voilà un avis qui pourrait donc t'intéresser ;) Avis que j'ai trouvé intéressant car discutant aussi du packaging et des architectures supportées.

Pour te mettre l'eau à la bouche, je cite :

The Rust cargo cult needs to pause and re-evaluate.

(oui, je sais, mettre cette phrase hors contexte est digne d'un vendredi)

Dolphin fait effectivement partie des KDE Applications qui sortent tous le 4 mois (avril, août et décembre)

La 20.12 avait quelques petites améliorations sur Dolphin.

Ça pourrait être utilisé ici par exemple.

Vu tous les styles proposés, c'est clair que ça sera cool pour essayer à la volée !

Par contre je ne suis pas sûr que ça s'intègre au mode sombre/claire (le truc qui permet de dire à l'OS ce qu'on préfère et que ce soit répercuté jusque dans les sites web).

Je pense que tu as raison et que cela ne s'intègre effectivement pas avec le thème sombre/clair qui marche maintenant par une media query répondant au doux nom de prefers-color-scheme (donc, pur CSS).

Alors que le chargement des alternate se ferait probablement par une goutte de JS qui positionnerait brutalement l'alternate sélectionnée en feuille par défaut (directement en modifiant le DOM je veux dire).

au delà de la vanne, je suis sûr que économiquement parlant ça se tient.

Si Pole Emploi fait une OPA sur Air France, on pourra faire les calculs !

Je n'ai rien trouvé à ce sujet dans le menu sandwich. J'ai fait des recherches juste parce qu'André affirmait que c'était supporté par défaut et que je me demandais ce que ça pouvait bien faire.

Au final, c'est sur le MDN ¹ que j'ai trouvé l'info :

Firefox lets the user select the stylesheet using the View > Page Style submenu. Internet Explorer also supports this feature (beginning with IE 8), also accessed from View > Page Style. Chrome requires an extension to use the feature (as of version 48). The web page can also provide its own user interface to let the user switch styles.

Je reconnais n'avoir pas cherché des heures non plus mais, aucune mention du menu sandwich. Désolé.

Du coup, j'ai regardé un peu le code (après tout, c'est ouvert ), et j'ai vite compris comment générer ma propre licence. Je suis tranquille pour 30 ans :p

J'ai peut-être mal interprété et, dans ce cas, je te pris de bien vouloir me corriger.

Dans le cas où j'ai bien saisi ce que tu écris, et au risque de faire le casse-pied :

• le code de la version EE est "ouvert" mais propriétaire quand même
• contrairement à ce que tu avances dans un autre commentaire, ce que tu fais n'est pas une "feinte" de la licence . Juste une violation.

Je comprends tout à fait la contrainte budgétaire que leur modèle de facturation par utilisateur peut poser (surtout dans ton cas où tu devrais payer un siège pour chaque utilisateur qui s'inscrit pour juste ouvrir un bug ce qui n'est pas financièrement tenable).

Mais que tu postes sans rougir que c'est facile de défoncer leur génération de clef pour envoyer se faire foutre la licence, ça me parait un poil abusé sur un site où on discute/débat régulièrement des licences et de leur respect. La prochaine fois qu'une grosse boite se fait épingler pour non respect de la GPL, on lui dira qu'il n'y a pas de problème à avoir feinter la licence ?

le seul truc chiant c'est que c'est le kernel UEK qui est par défaut

Je ne suis pas assez versé dans les arcanes du noyau alors, je vais poser ma question bête : quelles sont les différences majeures avec le kernel Red Hat ? As-tu eu des problèmes particuliers qui te font fuir ce noyau vendu comme "incassable" ?

Quel public touchez vous lorsque vous parlez sur Mastodon ?

Le même public qui a mis en place la campagne (la boucle est bouclée).

Après, reconnaissons qu'il est largement plus facile de convaincre des gens déjà convaincus.