Christophe a écrit 682 commentaires

Google Groups va continuer à exister pour son autre fonctionnalité principale, les listes de diffusion.

Seule la passerelle NNTP va être retirée.

Personnellement je fais les choses différemment:

• Pour les blancs en neige, pareil, ainsi que pour le sucre et le sel. Attention au sel, il faut vraiment en mettre très peu, ça se sent tout de suite
• Faire fondre le chocolat et le beurre, puis lorsqu'il aura un peu refroidi ajouter les jaunes d'oeuf et mélanger
• Incorporer, petit à petit, les blancs en neige dans le chocolat, en remuant trèèèès doucement. Le but est de garder l'air capturé dans les blancs en neige, et ainsi avoir une mousse moins compacte.
• Soit laisser dans le saladier, soir verser dans des verrines. Laisser reposer au frigo quelques heures.

j'aimerais juste voir le bilan carbone global

Oui, je crois que c'est là que le bât blesse, car si j'ai bien compris personne ne sait trop si la capture de CO2 est efficace ou pas vraiment…

Depuis quand un "complotiste" va "étudier les complots" ?

Pas sûr que les deux phénomènes aient un rapport: si le CO2 est déjà piégé dans le basalte, il y restera, au fond de l'océan. L'eau ne va pas forcément capturer le CO2 piégé dans le basalte.

C'est un peu frustrant du coup: tout l’intérêt de cette énigme repose sur les données d’entrée, qu'on n'a pas ici.
Ou alors j'ai encore raté un truc.

Manifestement, la problématique des données privées n'intéresse pas vraiment les gens. Chrome écrase tout le reste, se sentant pousser des ailes avec l'arrivée du Manifest V3 taillé sur mesure pour les finances de Google.

Je pense que si Firefox arrête le support de Manifest V2, c'est mort pour eux: nos plugins de protection seront aussi inutiles sur Chrome que sur Firefox.

… et pour F-droid ?

Le programme peut maintenant choisir d'utiliser

Finalement ce sont juste deux approches différentes: soit on laisse le programme choisir, soit on laisse l'utilisateur choisir. Et en voyant ce qui a poussé l'auteur à implémenter sa propre solution, je pense qu'il a pris la seconde approche en toute connaissance de cause, pour ne pas s'enfermer sur telle ou telle techno.

Alors oui, ça introduit de la complexité dans un fichier de configuration, et l'intégration avec le système est moins bonne. Mais au moins, le programme "supporte" dès aujourd'hui «nftables, iptables ou autre», pas besoin d'attendre la version 2025.

Et rien n'empêche l'auteur d'ajouter ces raccourcis plus tard à Reaction; pour moi, c'est la bonne approche pour une première version du programme.

Alors désolé, mais là je suis perdu. J'ai l'impression que petitboot est finalement un bootloader intermédiaire, avec un joli menu, lancé par u-boot. Comme un systemd-boot, au final, avec quelques fonctionnalités en plus.

Donc la chaîne de boot serait:

SPL -> U-boot -> petitboot -> noyau de la distribution Linux installée

Avec U-boot et petitboot installés sur la eMMC de la carte odroid. Le grand changement ici étant que U-boot et petitboot viennent préinstallés sur la carte; ça me fait fortement penser aussi à Tow-Boot pour Pine64.

Cependant je ne vois pas comment le linux de la distribution pourrait se passer de la DTB spécifique à la carte odroid sur laquelle on démarre. Ou alors, le bénéfice c'est que cette DTB est donnée par petitboot ? Auquel cas il faudrait "juste" avoir un noyau plus ou moins générique, avec tous les drivers ARM possibles.

l’usage de SSD limités en cycle d’écriture

Même si cela existe effectivement, il faut bien garder en tête les ordres de grandeur dont on parle.

Prenons comme exemple un SSD de 1To: on trouve, assez classiquement, des limites de l'ordre de 600TB (en donnée constructeur).

Il faut bien voir que ce nombre est très grand: même en écrivant l'équivalent de 50Go chaque jour sur le disque, on aurait une durée de vie de l'ordre de 30 ans !

Pour moi le ramdisk est effectivement utile pour sa vitesse, et ce côté volatile. Mais pas pour "sauver" le SSD.

Personnellement, j'utilise l'extension Firefox CleanURL

Ca juste marche, en ce qui concerne les résultats Google. Même si, bien sûr, il doit rester pas mal de tracking sur le reste de la page…

Il fait justement des comparaison « à froid » et « à chaud », donc sans cache et avec cache. Dans les deux cas, gitstatusd est bien meilleur.

On notera la rationalisation des appels systèmes, le choix de syscalls plus performants, un libgit2 patché… bref c'est un travail intéressant, dont une partie mériterait sans doute d'être fusionnée dans git lui-même.

La poule aux oeufs d'or a été découverte avec Whatsapp: si le login est le numéro de téléphone, alors il n'y a même pas besoin de créer un compte, la découverte de contacts devient (trop?) triviale et facilite énormément l'implantation de l'app chez les gens.

Je pense que c'est le point décisif qui a permis à Whatsapp de décoller aussi rapidement. D'ailleurs ce principe a ensuite été copié par nombre d'autres applis…

Cela semble expliqué sur le wiki de NixOS: https://nixos.wiki/wiki/Appimage

Du coup, on est d'accord que le problème ce n'est pas le "mobile", en fait.

Ils leur filent un Nokia 110 à 30€, et comment ça l'enfant peut appeler en cas de pépin, problème réglé…

https://linuxfr.org/users/akauffmann/journaux/edition-francaise-du-livre-ada-zangemann

Je suis assez d'acoord sur l'impression générale.

Je pense que la sensation « d'ensemble mieux fini que KDE » vient du côté très sobre, voire rigide, de GNOME. L'expérience par défaut ne met pas l'accent sur les divers plugins et gadgets, et propose quelque chose d'assez minimaliste, mais "léché".

Et puis certains (ne citons personne) promeuvent l'usage de discussion instantanée via l'email, ce qui ne va pas arranger le quota !

Je lis à la source :

Contributors to these new repositories will now need to agree to a standard Apache CLA

Donc, non, aucune garantie spéciale (sauf si j'ai raté un truc dans le CLA Apache), c'est un CLA "classique" où Element peut faire ce qui lui chante.

attention à la confiance aveugle dans la techno :P

Ça fait déjà plusieurs fois que je remarque cet argument dans une discussion sur les choix de mot de passe… et je le trouve peu pertinent.

On est en train de comparer des mots de passes choisis par des humains (venant donc avec les biais et faiblesses associés, et sont stockés dans un fichier tout bête du navigateur), avec un logiciel conçu pour sécuriser ça (moins de biais, moins prévisible, stockage plus sécurisé à priori).

Keepass, c'est un fichier chiffré. L'emplacement du fichier peut être n'importe où. Les logins stockés sur un Firefox, c'est un pauvre json dans le profil, n'ayant même pas de mot de passe maître par défaut…

Alors OK il y a des CVE et des bugs dans Keepass, mais même avec ça le gain en sécurité est incontestable.

Et je viens de tomber, en fouillant un peu dans le nouveau KDE Plasma, sur cette nouvelle: les activités seront probablement bientôt abandonnées !

Il semble que les planètes s'alignent pour ramener un fond d'écran par bureau…

Au cas-où, les Activités permettent l'utilisation de fonds d'écran différents (1 par activité donc)…mais ça veut dire qu'il n'y a pas de Cube…

Oui, c'est la réponse classique donnée dans ce rapport de bug. Mais travailler avec les activités est différent et oblige à se passer d'autres fonctionnalités sympa liées aux bureaux virtuels…
Au final, Nate Graham indique que si on veut voir cette fonctionnalité, il faut que quelqu'un si colle. Et qui sait, c'est peut-être plus facile via ce nouveau système « d'addons » pour kwin/KDE. Rendez-vous dans 10 ans ?

Mais personnellement, j'ai trouvé la solution il y a des années: j'utilise XFCE.

C'est sympa de revoir ce fameux cube ! Mais je suis assez d'accord avec le tout premier commentaire sur Phoronix: à quand le retour du fond d'écran différent par bureau ?

Si les devs KDE ont le temps de réimplémenter le cube rigolo, ils auront le temps de réimplémenter cette fonctionnalité utile, non ? Bon désolé pour ce post râleur, je suis juste un peu frustré :)

En lisant plus avant les réponses, c'est plus compliqué, on retrouve ce comportement dans les doc du w3c…