bbo a écrit 200 commentaires

Plausible, alternative à Google Analytics légère et respectueuse de la vie privée (et citée ici pas plus tard qu'aujourd'hui !), a aussi fait ce choix fin 2020 de passer d'une licence permissive (MIT dans leur cas) à l'AGPL.

Le modèle est un peu différent :

• Pas de support gratuit sur la version pour auto-hébergement
• Il y a un lag entre la version cloud et la version auto-hébergée. L'annonce indique que la version auto-hébergé aura 2 versions par an, mais début 2021, c'est plutôt tous les 4 mois. A voir à l'usage, c'est récent. Après, c'est juste la distribution du binaire, le code de la version cloud est sur Github (AGPL oblige).

Heureusement que la FSF résiste en essayant de proposer des licences qui protègent vraiment l'utilisateur final et pas les intermédiaires.

Cela dit, je suis impatient de connaître la position officielle de la FSF sur la SSPL.

Faudrait que la FSF, qui affiche ne pas aimer le non libre, se penche sur le sujet (pas nouveau, MySQL le fait depuis des lustres)

Oui, mais que ça soit MySQL ou Grafana, ce n'est pas la licence qui leur permet de faire ça, mais leur CLA. Je doute donc que la FSF en dise grand chose.

Par ailleurs, il y a beaucoup de monde que fait signer des CLA. Je suppose donc que l'idée/l'envie de contribuer à un projet sous CLA est plus une question de confiance avec l'entité qui tient le copyright (ou a qui est donné le droit de faire une version propriétaire de ta contribution).

mais on sent quand même bien que le but est de vendre leur version non libre

J'ai surtout trouvé qu'ils cherchent à vendre de l'abonnement SaaS (mais qui est non libre, je te rejoins).

Je rajouterai même que (sans troll) la dictature c'est pas forcément le meilleur système.

;)

J'ai beaucoup plus de respect pour Ian Murdock qui a crée Debian (qui est toujours là), que pour des dictateurs, même bienveillants, qui seraient incapables de bâtir quelque chose qui va leur survivre.

Ce qui rendra une distribution stable, c'est de ne rien mettre à jour du tout :)

Si ce qui t'intéresse, c'est la stabilité générale (au sens tu sais ce qui marche et ce qui ne marche pas) et que, donc, tu t'en fous d'avoir un bureau et des applications à jour, regarde en priorité Kubuntu 20.04. Pas de changement pour encore 2 ans (Kubuntu LTS est supporté 3 ans). En plus, c'est la même base que Neon donc tu ne seras pas dépaysé.

Si changer de base ne te fait pas peur, openSUSE Leap c'est pas mal sans trop bouger. Les goûts et les couleurs font que ça pourrait te plaire.

Si ce qui t'intéresse, c'est la stabilité de la base (car tu t'en fous de la "base" tant que ton matériel est reconnu) mais quand même avoir des applications à jour et bien dans ce cas, regarde en priorité l'édition utilisateur de Neon car c'est exactement ce qui est proposé. Tu ne seras pas dépaysé et tu n'auras pas à réinstaller. Juste à appliquer la procédure indiquée par le projet.

Si tu as choisi de changer de base, sache qu'openSUSE propose des dépôts complémentaires pour avoir tout KDE à jour sur Leap

Bons tests et bon courage ; choisir, c'est toujours pénible !

sauf la dernière lubie de Discover : demander le reboot pour faire certaines maj, ce qui m’oblige à utiliser Apper

Tu seras donc ravi d'apprendre que les mises à jour hors-ligne (actives sur l'édition Utilisateur de Neon que depuis le 1er avril) seront activables/désactivables par l'utilisateur à partir de Plasma 5.22, dont la sortie prévue début juin.

En attendant, il semblerait que tu puisses les désactiver via :

kwriteconfig5 --file discoverrc --group Software --key UseOfflineUpdates --type bool false

Systemd ne fera pas traitement de texte, pas serveur web, pas gestionnaire de base de données, etc.

Exact, pour cela il y a Emacs ! Emacs fait même le "etc."

;)

NoGNU : Not Only GNU

J'ai des idées de noms :

• GNG (GNG’s Not GNU) mais va le prononcer !
• YAGNU (Yet Another GNU)

:)

Je sais que ça peut choquer/surprendre de ne pas attendre qu'une fonctionnalité soit complète pour la fusionner, mais avoir des incréments les plus petits possibles aident vraiment (je trouve) pour un tas de raisons.

Je suis d'accord avec ce que tu dis. Mais cela peut impliquer un changement culturel. Car, il y a un moment où tu auras du mal à n'avoir qu'une partie de fonctionnalité sans feature flag. Et ça ne passe pas dans la culture de certaines équipes/entreprises.

• agit sur le fait que le site ne pouvait se permettre de diffuser cette idéologie,
• affirmé que la liberté d'expression n'oblige pas le site à accepter de publier n'importe quoi,
• confirmé que les règles du site s'appliquaient,

En effet, une belle illustration de :

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