bbo a écrit 218 commentaires

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

… 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).