bbo a écrit 204 commentaires

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.

Fonctionnalité inclue directement avec Firefox

C'est tellement bien caché (accessible depuis le menu Affichage > Style de la page ; avec la barre de menu cachée dans le comportement par défaut de Firefox…) que je n'avais jamais remarqué cette fonctionnalité !

Limite, il faudrait une extension pour avoir une sélection rapide possible quand des CSS alternatives sont disponibles !

Quoiqu'il en soit, un très grand merci pour la découverte de ces CSS alternatives !

Quand on parle d'IoT, je reconnais que je suis un peu perdu car cela me semble toujours couvrir un panel très vaste de "trucs" (d'où le "Things" je suppose ^^) qui semblent cools en quelques phrases. Mais, à la fin, je ne comprends pas vraiment de quoi on parle quand même.

En tant que profane du Edge/IoT/Embarqué, je m'excuse donc par avance si mes questions vous paraissent complètement débiles. Que "ceux qui savent" ne s'étranglent pas et saisissent plutôt cette opportunité pour m'expliquer de manière à ce que je raconte moins de bêtises à l'avenir ;)

• Qu'est-ce qu'on développe comme applications sur "Ubuntu Core for IoT" ? Quelles sont les contraintes les plus fortes ?
• Je croyais que l'IoT, c'était les ampoules connectées. Mais cela ne semble pas la cible d'Ubuntu Core (mais j'ai peut-être raté le paragraphe qui explique que je peux installer Ubuntu Core sur mon frigo). Alors, comment Ubuntu Core fait quand même de l'IoT ?
• Quels langages et outils (build, CI, etc) sont utilisés sur les projets IoT ?
• Comment les équipes de développements travaillent (Agilité, etc) ? Et quels sont les profils habituels des gens qui composent ces équipes ?
• Qui utilise (vraiment) Ubuntu Core ? J'avais l'impression que dans l'embarqué, c'est plus courant de se construire sa "distribution" avec juste ce qu'il faut

D'avance merci à celui ou celle ou ceux qui éclaireront ma laterne ;)

"L'étiquetteur fou" :) Merci beaucoup !

Non, tu ne te trompes pas ^. Je me suis fais la même réflexion que toi !

Surtout que la communication de Signal ne parle pas de décentralisation (ce qui n'est pas étonnant). J'espère que Goffi ne s'étranglera pas devant cette confusion de l'auteur ;)

Merci beaucoup Benoît. Et merci pour le rangement ;)

Salut !

Ils se sont aussi déjà montrés hostiles envers de implémentations alternatives

Cette phrase m'a fait tiquer et j'ai donc été lire le ticket Github ayant entraîné l'arrêt de LibreSignal.

Pour ma part, j'ai surtout trouvé qu'il clarifie la différence entre le code, la marque et le service Signal. Pour ne citer qu'une toute petite partie de la conversation :

If people want to use our source code to develop their own products, that's fine, so long as it's done under the terms of the license. That's the deal we're making with everyone, and I agree that it allows for possible collaboration. However, we are not running a service for other people's products, and we are not letting other people use our name in their products. Those things aren't part of the deal.

Que des gens trouvent ça hostile, ok. Mais d'autre trouveront ça normal. Mozilla ne le contredirait probablement pas sur la marque, par exemple.

Je profite qu'on ne soit pas vendredi pour poser sérieusement la question : 1 mois après, où en es-tu de ton adoption/adaptation ?

Si la migration est faite, as-tu observé une mutation génétique de tes poils de barbe ou es-tu resté normal (pour ce qu'un utilisateur d'i3 sur GNU/Linux puisse avoir de normal) ?

Roh ! C'est même pas écrit en Rust !

:)

Je vais répondre en 2 temps

openSUSE/CentOS

La base de Leap est une reconstruction des RPM de SLE (Linux, systemd, GCC ou GNOME par exemples). En plus, la communauté fournis des paquets supplémentaires (Plasma ou Xfce par exemples). Je n'ai pas la proportion de paquets venant de SLE/fournis par la communauté. Ca serait une donnée intéressante !

C'est toujours un peu glissant de comparer des distributions car le diable se cache dans les détails. Mais je dirai que Leap se rapproche plus d'un ensemble CentOS+EPEL (si on compare avec le monde Red Hat).

Dans les différences subjectives (attention, on est vendredi et c'est Noël) :

• YaST : certains ne l'utilise pas mais d'autres aiment la centralisation de la configuration à un seul endroit (les goûts, les couleurs, tout ça)
• une Leap sentira plus le frais que le combo CentOS/EPEL,
• le caméléon c'est plus sympa que le chapeau (mais je suis un ami des bêtes)

Il y a, plus sérieusement, une grosse différence organisationnelle :

• les paquets Leap venant de SLE sont maintenus par les ingénieurs de SUSE (là où le rebuild de CentOS n'était, sur le papier, pas le problème des ingénieurs Red Hat)
• SLE est tirée de Tumbleweed (openSUSE en publication continue). Leap est reconstruit à partir de SLE et tire ses paquets communautaires de Tumbleweed. Les paquets communautaires de Leap peuvent être reconstruits pour SLE et rendu disponible dans le Package Hub (qui est comparable au dépôt Universe d'Ubuntu). C'est donc le même projet qui est upstream et downstream (là où, il y a le projet Fedora et le projet CentOS).

Il y a eu une conséquence importante de cet engagement de SUSE directement dans Leap : plutôt que de continuer à maintenir 2 constructions avec les problèmes que cela peut poser au niveau de la maintenance (différence d'environnement, etc), SUSE a proposé que Leap s'appuie directement sur les binaires de SLE. Il s'agit du projet Jump qui sera mis en œuvre pour Leap 15.3 en 2021.

openSUSE/SUSE

Il n'y a aucun support offert par SUSE sur Leap. Il faut migrer. Et je ne sais pas comment ça se passe si tu utilises des paquets communautaires qui ne sont pas dans le Package Hub

Le cycle de vie de Leap et de SLE n'est pas comparable car, une fois qu'une nouvelle version majeure de SLE arrive, Leap passe sur cette base alors que SUSE continuera de sortir des Service Packs sur les 2 versions (Leap 42.x n'est plus supportée par la openSUSE alors que SLE 12, sa base, continue de voir des Service Packs sortir)