bbo a écrit 219 commentaires

Pour se protéger en attendant que ça soit correctement patché quelqu'un de plus compétent que moi m'a proposé d'ajouter le drapeau suivant sur les lignes de commande : -Dlog4j2.formatMsgNoLookups=true (je n'ai pas testé si ça avait un impact réel ou non).

Visiblement, c'est uniquement disponible sur log4j2 >= 2.10.0

À quoi correspondent les versions Q et R ? Les versions 10 et 11 ?

D'après Wikipédia, on a les versions suivantes :

• Android 7 = Nougat (août 2016)
• Android 8 = Oreo (août 2017)
• Android 9 = Pie (août 2018)
• Android 10 (septembre 2019) : nom de code Q en interne durant le développement
• Android 11 (septembre 2020): nom de code R en interne durant le développement
• Android 12 (octobre 2021)

La page anglophone indique que seules les versions 9 à 12 reçoivent encore des correctifs de sécurité.

ce serait bien de réécrire le site

Oui ! En Java/JEE !

Avec un billet qui rentre un peu plus dans les détails techniques de ce qui coince.

Tu me fais découvrir rqlite, merci :)

Merci PsychoFox de m'avoir aussi fait découvrir rqlite !

Ce qui est drôle c'est que j'ai par hasard découvert dqlite aujourd'hui. La FAQ indique les différences suivantes avec rqlite :

The main differences from rqlite are:
- Embeddable in any language that can interoperate with C
- Full support for transactions
- No need for statements to be deterministic (e.g. you can use time() )
- Frame-based replication instead of statement-based replication

Pour moi, cette semaine aura été celle des SQLite distribués !

Je n’ai pas d’exemple en tête mais ça existe.

Chez Gitlab où la version propriétaire se trouve dans le sous-dossier ee/.

Elastic l'avait fait aussi.

Normal, c'est parce que, comme les blagues, ça vole haut un hélicotè

Ce film serait devenu une référence sur LinuxFR si le clavier s'était complètement blo

Saloperie de cachou ! ;)

C'est tellement improbable.

Si je pousse le raisonnement basé sur ta remarque (je ne t'associe pas à ce raisonnement, c'est juste moi qui déroule) :

• si une charte "claire et précise" était possible, il n'y aurait aucun problème à automatiser la modération (un logiciel sait bien faire que la spec est "claire et précise"),
• vu que cette modération ne poserait pas de problème (car "claire" et appliquée "à la lettre"), on pourrait même l'appliquer à priori.

Cela ressemble beaucoup à ce que font "les plateformes" et ce que prône différents gouvernements. Ce que beaucoup appellent de la censure.

Autant, la charte pourrait être claire ("on ne s'insulte pas ici"), autant elle ne pourra jamais être précise. Vu que chaque intervention à modérer se fait dans un contexte, je ne vois pas comment on pourra se passer des modérateurs humains qui adaptent leur décision (c'est donc pas "appliqué à la lettre"). Ou alors, il faut que cette charte :

• interdise l'ironie, l'humour et la caricature (parce que sinon, y aura toujours quelqu'un pour taper les limites et frôler l'insulte)
• définisse une liste des sujets à ne pas aborder (au hasard, les sujets politiques ou sociétaux).

Là, c'est sûr que ça sera plus calme. Mais qu'est qu'on va s'ennuyer les vendredi :-)

---

A ce sujet, un épisode très intéressant de "Libre à vous" traite de la modération.

A la base, Linus ne voulait pas qu'on puisse se faire de l'argent sur son code (il admet que c'était une erreur de sa part, et cela n'a pas duré). Il voulait que les gens puisse prendre le code pour faire ce qu'ils voulaient mais (surtout) qu'ils doivent retourner les changements effectués. Et c'est pour cela qu'il a utilisé la GPL v2, car il a estimé que ça "faisait le job".

Dans cette interview, on peut lire :

The GPL ensures that nobody is ever going to take advantage of your code. It will remain free and nobody can take that away from you. I think that's a big deal for community management.

C'est aussi pour ça qu'il n'aime pas trop les licences permissives de type BSD (où tu n'es pas obligé de partager les changements) :

"Over the years, I've become convinced that the BSD license is great for code you don't care about"

Par contre cela auraient énormément bridé l'innovation et gêné l'émergence de bon nombre de start-up

Est-ce que des Google ou AWS auraient pu décoller s'il n'y avait eu que des OS propriétaires qui "protègent l'innovation" (la vraie ⸮) ?

Sinon, dans un monde sans Linux, est-ce que l'informatique en nuage se serait appelée informatique en armoire ? Remarquez, ça serait pratique car une armoire se met facilement on the edge.

Dans un monde sans Linux, on serait plus scalabilité verticale qu'horizontale je pense. Donc, est-ce que certaines boites (probablement américaines, certainement innovantes) disrupteraient le marché en installant carrément des conteneurs chez leurs clients ?

Quand on rédige un article, une paire de ciseaux apparait dans la marge. Ce n'est qu'une indication de la taille maximale recommandée

Oh mais je n'avais jamais fait gaffe !!! Merci pour cette info !

Je vais enfoncer une porte ouverte, mais je veux être sûr : mon commentaire sur le not Open Contribution n'est pas un soutien à ton commentaire initial :-)

Tu laisses entendre que la croyance religieuse est un critère de sélection pour contribuer à SQLite. C'est bien évidemment faux.

En faisant le sous-entendu que les contributeurs SQLite ne tolèrent pas les athées, tu diffuses une fausse info sur cette équipe. On peut le tourner dans tous les sens, mais cette petite remarque ne peut que nuire à ce projet (au mieux, rien n'a changé, au pire, des gens pensent que SQLite est développée par des intolérants).

Donc, comme ton affirmation en contient beaucoup d'ingrédients, je suppose que c'est pour ça que Philippe t'a dit que c'était du FUD.

Pour être un peu taquin, de toutes façons, vous ne pouvez pas être développeur SQLite… Tout court :-)

---

Plus sérieusement, le projet s'affirme Open-Source, not Open-Contribution et cela n'a rien à voir avec leur Code of Ethics :

In order to keep SQLite completely free and unencumbered by copyright, the project does not accept patches. If you would like to suggest a change and you include a patch as a proof-of-concept, that would be great. However, please do not be offended if we rewrite your patch from scratch.

Savais-tu que les changements climatiques diminuent la fermeté et l'acidité des pommes mais augmentent leur taux de sucres ?

Tiens, un peu comme Gentoo :

• 23 mai : annonce de la migration vers Libera
• 26 mai : des canaux encore sur Freenode ont été détournés.

Bref, Gentoo voulait migrer pour le 13 juin. Et bien, c'est fait depuis le 26 mai !

Dommage de ne jamais (l'article lié n'est pas plus disert) donner un seul exemple de ces "fonctionnalités les plus avancées" que LSP ne permettrait pas, surtout si on perd "énormément"..?

Jetbrains, par exemple, a toujours boudé LSP pour ses produits (même s'il existe des plugins)

Je cite cet article de 2018 autour de Rider (IDE .NET propriétaire) :

Re-using the Language Server Protocol (LSP), an idea we discarded. LSP is great and does many things, but it's also a lowest common denominator. Some refactorings in ReSharper are impossible to implement in LSP without bolting on many customizations. It's also unclear how LSP should handle languages like Razor, which typically mix C#/VB.NET and HTML, CSS, and JavaScript. There would have to be an LSP component for the separate languages, but also one for the combined languages. LSP would introduce many complexities and provide little benefit for our particular use case.

J'ai aussi trouvé cette discussion autour du support du LSP pour Kotlin dans Intellij (mais les remarques pertinentes s'arrêtent en 2018)

Comme la situation des IDE Jetbrains n'a pas changée, je suppose que les équipes de Jetbrains estiment que ces "problèmes" subsistent, indépendamment des évolutions favorables des Language/Debug Server Protocols.

Tu trouveras peut-être aussi cet article de fin 2020 intéressant. Quoiqu'on pense du LSP, je rejoins complètement une de ses remarques :

LSP did achieve a significant breakthrough — it made people care about implementing IDE backends

Tu as tout à fait raison sur le fait que cela ne correspond pas à l'attente que les gens ont.

Après, une autre chose qui me paraît sûre, c'est que le Disaster Recovery Plan étant pudiquement traduit "Plan de Reprise d'Activité (après incident)", cela n'aidait probablement pas à imaginer le pire. Un désastre, ce n'est pas perdre quelques disques ou une paire de VM.

Maintenant, on sait qu'un désastre, c'est perdre plusieurs centres de données (certes, géographiquement au même endroit) avec une partie des sauvegardes et n'avoir qu'un accès erratique à ta console d'administration. Tout ça en quelques instants et pour de nombreuses heures.

sa solution fonctionne très bien pour moi.

Top !

1000 mercis pour ces infos !!!

Ah ah, ça m'a fait penser : peut-on remercier 1000 fois 1 personne ou 1 fois 1000 personnes ?! :)

Blague à part,

Je suis 100 % d’accord avec le message de catweazel

Moi, le seul truc qui m'irrite c'est l'éternelle comparaison avec le(s) comportement(s) de Windows (ça marche aussi avec OSX).

Avec ce genre de raisonnement, le menu de Plasma est pourri car il me rappelle le menu "Démarrer" de Windows, Kontact c'est nul car ça me rappelle Outlook, je ne parle pas de Darktable tellement ça me fait penser à Lightroom, oh et puis VLC qui envoit des métadonnées c'est "so-Windows", etc etc

Comme "ça ressemble à Windows", il n'est même plus possible de discuter d'éléments techniques et/ou ergonomiques et/ou historiques.

Je comprends que ce comportement de mise à jour puisse irriter certains utilisateurs (cf ici même suite au changement chez Linux Mint). C'est même tout à fait légitime. Mais l'argument "ça ressemble à Windows", c'est vraiment pas au niveau. Cela affaibli même les autres (bons) arguments.

Discuter du meilleur moyen de laisser le choix, des workflows de chacun, des raisons qui ont poussé les développeurs à mettre ça en place (et, si possible, sans préjuger qu'ils cherchent à "nous", les utilisateurs, infantiliser/windowiser) me parait bien plus approprié. Et probablement plus pérenne.

Il y a plein de raisons légitimes à s'opposer à certaines fonctionnalités des OS proprio (tracking, etc). Mais si jamais une fonctionnalité "ressemble", c'est qu'on n'a pas assez creusé. Parce que, chez nous, c'est libre.

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 !