bbo a écrit 220 commentaires

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)

Idéalement, il faudrait que orgroam soit compatible avec Zettlr

Idéalement, il faudrait surtout que tu passes sur emacs :-)

Avec mon œil de païen, les réponses que les utilisateurs d'emacs t'ont apporté dans tes 2 journaux semblent correspondre à ce que tu cherches.

Je crois qu'il est temps que tu acceptes l'inéluctable : il faut interfacer ton bepo avec l'OS de GNU ;-)

En parlant de cette migration, ton lien m'a fait chercher les raisons qui poussent FreeBSD à migrer de SVN à Git et j'ai trouvé ce billet d'un membre de la core team.

Au delà des classiques points forts (plus personne n'utilise SVN, énorme écosystème d'outils et de plateformes autour de Git, les développeurs connaissent Git alors qu'ils doivent apprendre SVN, facilité de collaboration), il expose quelques points faibles. Et, je n'aurai pas du tout imaginer que l'absence de client Git sous licence BSD-like puisse être un problème (je croyais qu'ils étaient ouverts à d'autres licences s'il n'y avait pas ce qu'il fallait en permissif). Je cite :

the BSDL git clients are much less mature than the GPL ones. Until recently, there was no C client that could be imported into the tree. While one might debate whether or not that's a good idea, there's a strong cultural heritage of having all you need in the base system that's hard to shrug off. OpenBSD recently wrote got which has an agreeable license (but a completely different command line interface, for good or ill). It has its issues, which aren't relevant here, but is maturing nicely. Even with the current restrictions, it is usable. There is an active port of got to FreeBSD due to the large number of OpenBSDisms that are baked in (some necessary, some gratuitous). The OpenBSD people are open to having a portable version of got, so this is encouraging.

J'ai donc appris l'existence de Got dont je n'avais jamais entendu parler ! "Ils sont fous ces BSDéistes" :-)

---

Enfin, j'ai esquissé un sourire en lisant :

Git also doesn't support dealing with all the merge conflicts it causes very well

Car je viens justement de relire un journal sur Pijul :-)

Je vois que le dépôt Github n'est qu'un miroir en lecture seule mais qu'il semble toléré d'y ouvrir des PR pour intégrer des patchs.

Comme ça m'a questionné, j'ai cherché à savoir s'il y avait un changement d'outil de revue dans le tuyau. Et donc, pour le moment, Phabricator reste leur outil pour les revues.

pour ceux qui ont loupé l'info la 1re fois du coup

Comme moi ^{^}

Oh ! Ça faisait longtemps que j'avais pas vu un thread hijack aussi fin et délicat ! :-P ;-)

J'en envoie une avant la fin du week-end et l'autre avant la nouvelle année. Merci des rappels et de me pousser à déconfiner ma motivation qui est restée coincée en avril !

Mais… Pourquoi t'as pas attendu vendredi ???!!! ;)

La JVM fut étudiée en 2001, mais jugée peu adaptée aux langages dynamiques (elle ne l’était d’ailleurs toujours pas en 2010, quid de 2020 ?).

C'est vieux 2001 :-) Mais en 2010, il y avait déjà Groovy (2003) et Clojure (2007). Je les cite mais je ne sais pas si on peut compter Jython (1997) et JRuby (2001) ?

Par contre, c'est vrai que Golo n'était pas encore prêt (2012) !

Je ne pense pas être en mesure de comprendre un article expliquant pourquoi les gens de Parrot ont estimé que la JVM n'était pas adaptée aux langages dynamiques (probablement un peu trop technique pour moi). Je vais donc me contenter d'exprimer mon étonnement. Et constater que tout le monde n'avait pas l'air d'accord avec eux à cette époque :-)

Rakudo est un compilateur pour Raku qui implémente la totalité du langage et peut cibler plusieurs différentes VM (la principale étant MoarVM).

La JVM est une des cibles, si j'ai bien lu Wikipédia :-)

Je vais taquiner un peu :-)

Peut-être aussi que la majorité des gens ne voit pas où est le souci avec Debian vis à vis du libre…

Ce n'est pas parce que la majorité le pense qu'une minorité ne peut pas avoir raison aussi

Je n'ai pas non plus la sensation que l'existence de Trisquel ou GNewSense est un rejet absolu de tout ce que Debian a pu réaliser (et réalise encore).

les parties non-libres optionnelles sont clairement identifiées comme telles dans le repo non-free

Et bien, justement, un des points qui chipote la FSF est justement que c'est pas toujours clair. Je cite :

De plus, certains des programmes libres qui font officiellement partie de Debian invitent l'utilisateur à installer des programmes non libres. En particulier, les versions de Firefox et Chrome fournies par Debian suggèrent des plugins non libres compatibles avec elles.

Factuellement, c'est vrai. Et y a des gens (peu, faut le reconnaître) que ça dérange. Et je trouve très bien qu'ils aillent disperser leur énergie à essayer de changer ça. S'ils y croient, pourquoi leur rabâcher en permanence qu'ils sont une goutte d'eau dans la mer ou qu'ils se trompent ou que leur énergie pourrait être mieux investie ailleurs ?

Il me semble que Debian ne distribue plus de binaires non-libre pour le noyau linux

Oui, depuis Debian Squeeze

La différence entre le noyau Debian et Linux-Libre est visiblement que le noyau Debian peut charger un firmware non libre. Pas Linux Libre.