Sommaire
- Des accords entre Google et les développeurs
- Des APIs et des logiciels libres et gratuits
- De la bascule à venir du 15 mars 2021
- De l'avenir de Chromium sous Slackware
Remarque : les développements traités dans ce fichier s'appuient sur l'article d'AlienBob How to 'un-google' your Chromium browser experience et en reprennent certains éléments.
Un peu de contexte. Chromium est un logiciel libre développé depuis 2008 par le Chromium project, équipe dirigée et financée par Google. L'idée de l'entreprise était de proposer un navigateur simple, efficace et surtout permettant une intégration maîtrisée avec les produits que propose la société. S'attaquant aux mastodontes de l'époque, le choix de développement a été celui de l'ouverture via la BSD-3-Clause License et profiter ainsi d'une vaste communauté mondiale pouvant apporter son aide, tout en ouvrant la possibilité d'adoption du navigateur par des tierces parties. S'appuyant sur les possibilités offertes par la licence, Google peut ensuite utiliser les sources de Chromium, y ajouter différentes portions de codes fermés et propriétaires, et diffuser le tout sous forme binaire à l'utilisateur final : Google Chrome.
Parmi les différences entre Google Chrome et Chromium, on peut retrouver les mises à jour automatiques, des modules vidéo et audio propriétaires, ou encore des mécanismes de suivi (optionnels ou non). Google Chrome intègre aussi la fameuse technologie controversée de DRM Widevine utilisée notamment par Amazon Prime Video, Netflix ou encore Spotify pour ces contenus en premium. Mais surtout Google Chrome permet un accès aux services de la société Google via des interfaces de programmation (API) accessibles par système de clefs.
Des accords entre Google et les développeurs
Ce dernier point est important. En effet l'intégration de ces APIs par clefs uniquement accessibles via Google Chrome pouvait gêner les développeurs extérieur à Google de deux façons. La première est que ces développeurs, qui contribuaient librement et (souvent) gratuitement au code de Chromium, voulaient pouvoir non seulement compiler les sources mais, pour eux aussi et leurs utilisateurs, avoir accès aisément aux APIs proposées par Google depuis Chromium. Par ailleurs, en terme de promotion, le système d'accès par clefs aux APIs réservé à Google pouvait freiner le développement d'applications tierces ou embarquées pour ce navigateur.
Prenons un exemple simple, juste pour comprendre. Je suis développeur indépendant et je souhaite créer un petit jeu pour Chrome. Je prévois que mon jeu puisse notamment sauvegarder les scores et les parties en cours en les synchronisant avec le compte Google du joueur. En tant que développeur, pour faire interagir mon programme avec le produit Google Sync (qui s'occupe justement des services de synchronisation de fichiers), il me faut nécessairement passer par l'API que propose ce service.
Évidemment un service a un coût. Un utilisateur lambda de Google Chrome va payer le coût de ces services avec toutes ses données personnelles. Mais dans le cas de Chromium ou d'applications Google Chrome ou Chromium tierces, c'est moins évident. Partant de là Google a décidé de passer des accords avec certaines tierces parties pour les autoriser à avoir un accès aux APIs des différents services de la firme. C'était aussi, bien sûr, une jolie manière d'amplifier l'intérêt que pouvait susciter Google Chrome et Chromium auprès des entreprises et des développeurs du monde entier, mais aussi du grand public en proposant un environnement plus riche. Pour ce dernier cas, on peut penser par exemple à Rovio et son Angry Birds intégré par extension dans Chrome qui a aidé à faire une bonne publicité pour Chrome à une certaine époque, tout en ramenant des joueurs monétisables vers l'entreprise productrice du jeu.
Google a donc commencé à proposer à certains développeurs des clefs personnelles donnant accès à ces APIs et qui sont intégrées au moment de la compilation des binaires. De sorte qu'à chaque fois qu'une personne utilise le programme, il utilise forcément la clef du développeur, et le compteur lié audit développeur incrémente de un. Et ce qu'il faut comprendre c'est que Google passait des accords avec ces développeurs pour un certain nombre d'accès gratuit à ces APIs. Autrement dit, au-delà d'un certain seuil, l'accès à l'API par ces clefs est coupé et le développeur doit passer à la caisse.
Reprenons mon exemple. Mon jeu intègre des publicités qui me permettent de monétiser mon travail. En passant un accord avec Google pour avoir accès à leurs APIs je leur explique ma situation financière encore précaire. Après négociation, ils acceptent de me donner deux mille accès gratuits pour les trois premiers mois. Au deux mille et unième accès, Google coupe les autorisations de ma clef, mes joueurs ne peuvent plus accéder à leurs scores et à leurs parties enregistrées (autrement dit le jeu est tronqué) ; je dois passer à la caisse.
Il s'agit ici d'un cas où l'accès aux APIs génère un revenu pour le développeur. On comprend donc que Google, à un moment donné, demande une partie des bénéfices du développeur pour l'utilisation de ses services (qui ont un coût pour l'entreprise, rappelons-le).
Des APIs et des logiciels libres et gratuits
Mais qu'en est-il des développeurs utilisant les APIs de Google mais dont le travail ne génère absolument aucun revenu. Si vous êtes sous une distribution GNU/Linux, c'est un cas qui vous concerne. En effet, les packageurs créant des binaires de Chromium pour leur communauté, s'ils veulent que les utilisateurs aient accès à, mettons, Google Sync pour synchroniser leurs mots de passe et leurs signets, doivent demander à Google des clefs officielles aux APIs, clefs qui leur sont liées personnellement.
Par exemple, individuellement, sous Slackware j'utilise principalement Mozilla Firefox. Cependant, il se trouve que, parfois, j'ai besoin d'utiliser Chromium. Ce programme n'est pas proposé par défaut sous Slackware, et il nous faut donc compter sur la communauté. Une personne bien connue pour nous est Eric 'AlienBob' Hameleers qui propose justement depuis des années un paquet tout prêt pour Slackware. Et si l'on regarde attentivement son dépôt pour Chromium, on voit parfaitement dans le script les appels aux différentes clefs pour les APIs Google de même que les clefs elles-mêmes.
C'est ainsi que chaque fois que j'ouvre Chromium sur ma Slackware le programme contacte les serveurs de Google avec la clef d'AlienBob, incrémentant son compte d'accès de un, et m'autorisant, si je le veux, à utiliser les différents APIs de cette entreprise en toute transparence. C'est très pratique pour moi, et pour tant d'autres utilisateurs de Slackware et de ses dérivées. Mais, au bout d'un moment, forcément, le quota d'accès gratuit offert par Google à AlienBob est dépassé et il doit passer à la caisse. Il faut noter, chose importante, que ces seuils ont été significativement augmentés pour les packageurs de distributions GNU/Linux au fur et à mesure du temps, ce qui évitait de trop payer si le paquet devenait vraiment trop populaire. Mais il arrive toujours un moment où il faut passer à la caisse. Et, apparemment, la facture peut être particulièrement salée.
Sauf qu'il y a plusieurs mois, différents cadres chez Google ont décidé que tout cela, et bien c'était terminé.
De la bascule à venir du 15 mars 2021
Dans un article très récent, AlienBob est notamment revenu sur son ressenti eu égard au fait qu'il doive payer après un certain nombre d'accès via ses clefs. Ainsi qu'il le dit, pour Slackware cela ne le gène pas. Cela fait parti de l'effort qu'il souhaite apporter à la communauté. Et si donner à Slackware un Chromium lié aux APIs de Google permet de continuer à faire briller cette distribution auprès des utilisateurs actuels ainsi que de potentiels à venir, c'est un coût qu'il entend prendre en charge. Surtout que, rappelle-t-il, il reçoit des dons de la communauté pour le travail qu'il fourni, dons qu'il utilise pour payer une partie des infrastructures qu'il gère pour le bien de Slackware — y compris la facture à Google.
L'une des questions qu'il soulève par contre est celle des dérivées de Slackware, dont certaines sont très utilisées. On pense notamment à une des versions de Puppy Linux, ou encore à Slint. Il se trouve que les packageurs de ces distributions reprennent les excellents builds d'AlienBob, y compris Chromium. Et, dès lors, utilisant ses clefs, ces utilisateurs d'autres distributions incrémentent de façon non négligeable son compteur d'accès aux APIs. On sent bien ici la guerre de chapelles entre les packageurs de différentes communautés et je renvoie simplement au début de l'article d'AlienBob ainsi qu'aux commentaires (où interviennent justement lesdits packageurs) pour se faire une idée plus précise de la situation présente.
Seulement cette situation, si elle était prise dans une sorte de status quo ces dernières années, va grandement changer dès le 15 mars prochain. En effet à partir de cette date Google a décidé de bloquer les accès à une grande partie des APIs de toutes les versions de Chromium qui ne sont pas issues de Google. Et cela dépasse en réalité le cadre du simple navigateur de bureau car vont être impactés aussi tout ce qui regarde l'embarqué et ChromiumOS.
Une grande partie donc mais pas tout. Restera accessible notamment le fameux safe browsing, service qui identifie des sites frauduleux ou dangereux et en informe l'utilisateur. Dans les choses à noter par contre, sera bloqué l'accès à Google Sync — il ne sera donc plus possible de synchroniser via Chromium ses mots de passe, signets, etc., par ce service. Enfin, et surtout, les possibilités d'accès gratuits vont être tout bonnement supprimées. Car en effet, et comme dit, certains services restant accessibles, l'une des clefs reste valide pour ces cas là. Mais le développeur qui proposera un tel accès sera facturé dès la première connexion.
C'est là je crois le premier nœud de l'article d'AlienBob qui, s'il accepte de prendre en charge les connexions des utilisateurs de la communauté pour laquelle il se dévoue, refuse catégoriquement de payer pour des utilisateurs auxquels il n'est lié en aucune manière, et qui n'ont, par ailleurs, même aucune conscience que quelqu'un d'une autre distribution va payer pour eux.
En parallèle, il faut aussi noter une chose importante qui est que la discussion dépasse en réalité les différentes distributions libres et ouvertes qui proposent une version Chromium non tronquée des services de Google. En effet, depuis quelques années énormément de constructeurs utilisent des systèmes embarqués basés sur Chromium, systèmes qui ne sont donc pas officiellement issus de Google et qui vont être coupés d'une grande partie des services de Google. On pense notamment aux télévisions connectées. S'il est clair que de très grands groupes ont probablement déjà négocié des accès privilégiés, d'autres sociétés vont se retrouver avec des clients mécontents qui ne comprendront pas d'où vient le problème. On peut d'ailleurs lire l'une des discussions sur ce sujet ici pour se rendre compte de la catastrophe pour ces entreprises.
De l'avenir de Chromium sous Slackware
C'est la deuxième grande question abordée par AlienBob. Car même en acceptant de payer pour les quelques services qui resteront, il prend acte de la situation perdante pour l'utilisateur de Chromium, pour la communauté Slackware en général et pour lui-même. En effet, une bonne hygiène numérique implique d'avoir installé des extensions tierces qui remplissent le rôle de safe browsing. En somme AlienBob se retrouve dans une situation où nous devrions payer alors que l'un des services phares, à savoir celui de la synchronisation, n'est plus accessible. Il faut dire que l'usage de la synchronisation de mots de passe, des signets et autres, entre différents terminaux s'est largement répandue ces dernières années et, puisque l'accès à Google Sync ne sera bientôt plus possible, son parti pris est de se débarrasser complètement des liens avec Google et de se focaliser sur un navigateur Chromium respectueux de la vie privée de ses utilisateurs. Et pour ceux qui ne peuvent se passer des services Google, il reste toujours la possibilité d'installer les binaires de Chrome proposées par Google.
AlienBob a ainsi entamé un travail vers la production d'un paquet Chromium dégooglisé, complètement coupé de tous les liens avec les services proposés par Google — ce qui donne le paquet chromium-ungoogled. Pour arriver à cela il utilise différents patchs et scripts issus notamment de projets comme ungoogled-chromium, d'inox patchset ou de la version Debian de Chromium. À terme, note-il, ce paquet viendra définitivement remplacer le paquet Chromium qu'il a produit jusque-là avec ses clefs.
Évidemment, au niveau de l'utilisateur final, cela demande quelques adaptations. Puisque cette version n'offre plus le safe browsing, il faut donc en passer par des extensions comme uBlock Origin ou uMatrix que l'on installera soit manuellement ou soit via le Chromium Web Store après avoir installé celui-ci manuellement. De la même manière, il faudra troquer Google Sync pour KeePassXC et xBrowserSync.
En dernier point, voici la procédure à suivre pour installer manuellement des extensions sous Chromium. Il suffit de se rendre sur chrome://extensions/ et d'activer en haut à droite le mode développeur. On récupère ensuite une extension (disons uBlock Origin, en cliquant en l'occurrence sur Ajouter à Chromium). Si l'extension Chromium Web Store n'est pas installée, cela va se matérialiser par le téléchargement d'un fichier .crx. Après avoir décompressé le contenu de ce fichier dans un dossier, il suffira depuis l'onglet extensions de Chromium de cliquer sur Load unpacked puis d'indiquer le chemin vers le dossier. Sans la présence du Store, les mises à jour devront être faîtes manuellement en suivant la même procédure (idéalement après avoir supprimé de Chromium l'ancienne version).
Notez aussi que l'option d'effacement des cookies et des données des sites lorsque l'on quitte Chromium est activée par défaut (voir chrome://settings/cookies). Il faudra la désactiver si l'on souhaite garder les informations de connexion aux sites d'une session à l'autre à moins d'utiliser des choses comme KeePassXC.
# En conclusion
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 10.
Il est temps de revenir sur Firefox ;-)
[^] # Re: En conclusion
Posté par HL . Évalué à 1. Dernière modification le 08 mars 2021 à 22:31.
Ce n'est pas aussi simple. La version de Firefox fournie dans la version stable de la distribution (14.2) est la 68.12esr. Plusieurs sites ne fonctionnent pas avec.
(Ceci dit c'est vrai, la 15.0 alpha 1 est sortie récemment est propose la version beaucoup plus récente 78.8.0esr et la prochaine version stable a l'air proche, mais tout le monde n'a pas encore fait le pas.)
[^] # Re: En conclusion
Posté par Psychofox (Mastodon) . Évalué à 5.
Mais pourquoi utiliser l'ESR?
[^] # Re: En conclusion
Posté par paulez (site web personnel) . Évalué à 7.
Parce que c'est beaucoup de boulot de maintenir Firefox non ESR. Il y a des mises à jour très régulièrement, qui requièrent un compilateur et Rust à jour. Donc souvent il faut mettre à jour LLVM, Clang, et Rust, donc pas forcément possible pour une distribution stabilisée.
[^] # Re: En conclusion
Posté par HL . Évalué à 2.
C'est le paquet officiel de la distribution. J'avoue que je ne sais pas ce que vaut l'installation d'un Firefox plus récent sur une 14.2 niveau stabilité.
[^] # Re: En conclusion
Posté par Yth (Mastodon) . Évalué à 8. Dernière modification le 09 mars 2021 à 11:16.
Les binaires fournis par mozilla fonctionnent très bien sous une slackware 14.2, j'écris sur un FF 86.0 là.
Mais c'est alors décorrélé de la distrib, mon autre FF est installé dans un répertoire, et il gère les mises à jour en interne.
[^] # Re: En conclusion
Posté par ff9097 . Évalué à 2.
Sinon Firefox est disponible officiellement sur Flathub
[^] # Re: En conclusion
Posté par Yth (Mastodon) . Évalué à 8. Dernière modification le 09 mars 2021 à 18:59.
Pour le coup je ne suis pas très sûr que ça soit plus simple avec flathub.
Le binaire Firefox officiel, tu détares, et tu te fais ton lien pour lancer Firefox, après tu touches plus, la mise à jour est gérée par firefox dans son répertoire où tu l'as dézippé, tu ne retélécharges plus jamais rien à la main, tu ne fais plus rien d'autre que d'accepter les mises à jours et redémarrages qui vont avec.
[^] # Re: En conclusion
Posté par ff9097 . Évalué à 3.
Justement je ne veux pas avoir à décider où je dézippe, ni devoir écrire moi même le .desktop
Flatpak existe justement pour ce besoin avec la partie bac a sable et permissions en bonus.
[^] # Re: En conclusion
Posté par barmic 🦦 . Évalué à -1.
La mise à jour n'est pas automatique et tu ne peux pas télécharger vers et depuis le dossier que tu souhaite de ta machine, pratique.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: En conclusion
Posté par Anonyme . Évalué à 3.
Bien sûr que si, pour ces deux points.
[^] # Re: En conclusion
Posté par barmic 🦦 . Évalué à 0.
Je dois mettre à jour manuellement mes flatpak perso. Je n'ai pas essayé Firefox je te l'accord. S'il by-pass flatpak pour se mettre à jour tout seul (bon je ne suis pas sûr que ce ne soit pas du travestissement du concept), il ne mettra pas à jour ses layers (qu'il faut tout de même mettre à jour).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: En conclusion
Posté par ff9097 . Évalué à 1.
Gnome software le permet après le boot.
[^] # Re: En conclusion
Posté par claudex . Évalué à 3.
Qu'est-ce que tu appelle manuellement ? C'est un système de packaging comme des deb ou rpm. Tu as flatpak update pour mettre à jour en CLI et c'est intégré dans les gestionnaire graphique de mise à jour des bureaux (en tout cas avec KDE et Gnome).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: En conclusion
Posté par barmic 🦦 . Évalué à 1.
Tu dois régulièrement faire :
Quand tu dézip firefox tu n'a rien à faire, l'arrêter de temps en temps c'est le mettre à jour.
Donc oui c'est comme apt, yum, urpmi, pkgsrc et autre nix, mais c'est pas comme le firefox de base.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: En conclusion
Posté par Psychofox (Mastodon) . Évalué à 2.
Non dans les distribs qui utilisent gnome-software c'est fait automatiquement donc ça revient au même.
[^] # Re: En conclusion
Posté par ff9097 . Évalué à 1.
Ton dezip firefox, c'est pas quelque chose que tu peux généraliser à tout. Après si ça te convient…
[^] # Re: En conclusion
Posté par Yth (Mastodon) . Évalué à 2.
Pour le coup, on parle d'un cas très particulier, et aussi d'un logiciel avec une place assez unique parmi tous les autres.
J'ai commencé à utiliser les binaires officiels pour la version développeurs.
Difficile à packager efficacement dans une distrib, plus simple de laisser Firefox gérer ses propres mises à jour.
[^] # Re: En conclusion
Posté par zurvan . Évalué à 10.
je n'aimais déjà pas beaucoup google et chrom(ium), pour pleins de raisons différentes, et toute cette histoire me conforte dans ma détestation de leurs méthodes pour tout englober dans leurs tentacules, et pour continuer à éviter leurs services le plus possible.
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: En conclusion
Posté par barmic 🦦 . Évalué à 5.
Tu vois moi ça me questionne aussi sur mon usage de firefox. J'utilise un compte firefox pour la gestion de mes mots de passe, mes extensions et l'envoi de page d'un navigateur à un autre.
Je serais bien content de payer Mozilla pour se compte, mais ça n'est pas mis en place. Je peux très bien me passer de la synchronisation des extensions et de l'envoi d'onglet, mais la gestion de mes mots de passe ça va être plus embêtant (et c'est particulièrement confortable d'utiliser la gestion par firefox).
Pour la pérennité de mon usage il faudra que je regarde pour me rendre indépendant de Mozilla (plus exactement d'un service gratuit donc non pérenne).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: En conclusion
Posté par zurvan . Évalué à 6.
moi je n'ai pas envie de payer mozilla ni google pour cela. Mes données sont à moi, et je veux les gérer moi-même !
J'héberge d'ailleurs celles-ci via yunohost et le plugin de firefox sync :
https://yunohost.org/en/app_ffsync
et d'ailleurs ça me dérange de devoir m'authentifier via mozilla pour cela, je préférerais être 100% indépendant de services tiers.
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: En conclusion
Posté par Tarnyko (site web personnel) . Évalué à 4.
Intéressant FFsync ; je vais comparer avec le xBrowserSync de l'article (ça pourrait évt. t'aider à te débarrasser du fil à la patte).
[^] # Re: En conclusion
Posté par Zenitram (site web personnel) . Évalué à 4.
Ou pas.
Ici, Google essaye de monétiser. Le problème de Mozilla est que ses utilisateurs ont bien du mal à payer quoi que ce soit, du coup Mozilla dépend à 90%… De Google. Ce même Google qui pense que le navigateur qui a beaucoup plus de part de marché que Firefox n'est pas assez rentable.
Tu vois venir le problème j'imagine… Celui du long terme. Mozilla a viré sans ménagement du monde, Firefox va-t-il évoluer? Et si les gens préfèrent Chromium même sur du libre et même en devant degooliser, pourquoi pas se poser d'abord la question de pourquoi c'est préféré par rapport à Firefox avant de conclure que Firefox est une solution? Ne surtout pas se poser les questions qui ne plaisent pas…
Mais "bizarrement", le monde des distros Linux (et autres) n'a pas trouvé la volonté/financement de juste refaire la partie synchro qui est payante (pour faire 36 distros ça y va, pour coder un truc commun il y a tout de suite moins de monde, triste).
Finalement, on peut se demander si pour les distros Linux (et autres) il ne serait pas plus rentable de se mettre ensemble pour développer la partie synchro (pas le plus compliqué, surtout comparé à un moteur web), et il sera toujours possible de forker si Google décide de ne plus faire en libre le moteur.
Bref, ta conclusion est très orientée, loin d'être objective, et il y a des alternatives pour compenser le problème.
[^] # Re: En conclusion
Posté par xcomcmdr . Évalué à 3.
Moi je paierai bien pour l'offre VPN de Mozilla. Franchement c'est LE truc qui m'intéresse.
Mais c'est que pour les USA.
Mozilla ont l'art de se tirer dans le pied.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: En conclusion
Posté par Zenitram (site web personnel) . Évalué à 6. Dernière modification le 09 mars 2021 à 09:34.
De ce que j'ai compris (exemple, en attendant de trouver une source plus fiable), Mozilla VPN est du rebranding de https://mullvad.net.
C'est bien de chercher à rendre bankable sa marque (il faut bien se nourrir), mais que ce soit LE truc qui t’intéresse m'interroge : en quoi est-ce intéressant par rapport à prendre direct la source technique du VPN? que tu puisses pour le même prix que le VPN seul avoir le VPN + file la thune de l'apporteur d'affaire à Mozilla? Est-ce qu'un Chromium avec le développement de la partie synchro payé par une offre similaire te conviendrait autant?
Pas négatif (ça serait pas idiot comme façon de payer), juste je cherche à comprendre si j'ai loupé un truc intéressant.
Mais sinon, oui, être si lent dans le déploiement est vraiment se tirer une balle dans le pied (un peu avant on avait aussi que le VPN était que pour Windows et Mac, maintenant corrigé mais quelle communication ratée que d'exclure sa base de fans…)
[^] # Re: En conclusion
Posté par xcomcmdr . Évalué à 4.
Ça fait longtemps qu'un VPN m'intéressait (pas pour la sécurité, car ça n'a rien à voir), et un VPN estampillé Mozilla avait l'avantage de m'intéresser "par principe de confiance" envers Mozilla, et pour les soutenir tout en me rendant service.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: En conclusion
Posté par xcomcmdr . Évalué à 5. Dernière modification le 09 mars 2021 à 09:58.
Alors tout ce qui est Chrome/Chromium non.
Le rendu des pages et l'UI de tout ce qui est dérivé Chromium m'horripile.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: En conclusion
Posté par Anonyme . Évalué à 6.
Leur site le dit explicitement :
[^] # Re: En conclusion
Posté par Sylvestre Ledru (site web personnel) . Évalué à 1.
Ca devrait arriver bientôt en Europe. Mozilla se tire pas de le pied, c'est juste compliqué de déployer un service comme un VPN (compta, facturation, etc) …
[^] # Re: En conclusion
Posté par Zenitram (site web personnel) . Évalué à 1.
Vraiment, faut comprendre, c'est compliqué… sérieux, il y a des centaines de fournisseurs de VPN, la plupart avec bien moins de thune que Mozilla, et il y a même la source technique de Mozilla qui fait déjà ça. Trouvez une autre excuse bidon moins visible…
Et pour Linux pas dispo au début, c'est quoi comme excuse bidon pour cacher la non priorité? Que du technique la…
Ce n'est pas en prenant les gens pour des cons incapables de voir ailleurs que Mozilla redorera son blason.
[^] # Re: En conclusion
Posté par Xanatos . Évalué à 1.
Vraiment ?
[^] # Re: En conclusion
Posté par Yth (Mastodon) . Évalué à 9.
Ah ben oui, un moteur de rendu web, en 2021, c'est l'un des bouts de code les plus complexes qui tournent sur ton ordinateur…
À côté de ça, une synchro de données, même si c'est pas simple, c'est un autre ordre de grandeur.
[^] # Re: En conclusion
Posté par Xanatos . Évalué à 1.
Ironie.
Je citais ce passage tel que je l'ai compris : navigateur web plus facile à développer que solution de sync.
Affirmation avec laquelle je ne suis pas d'accord.
Je rejoins le commentaire de freem ci-dessous + W3C + sécurité + UI + réseau + vie privée + performance + cloisonnement + etc.
Le web très compliqué d'aujourd'hui ne laisse pas de répit, d'autres se sont cassé les dents: Presto, Trident, Webkit pour les moteurs de rendu, pour les navigateurs, ce n'est pas un cimetière mais depuis 2015 c'est le gouffre.
Pour le fun/déprime essayez d'aller sur une plateforme de paiement en ligne/banque avec Midori ou ceux qui sont dans le 1%.
[^] # Re: En conclusion
Posté par Zenitram (site web personnel) . Évalué à 4.
J'ai écrit (et Yth a compris) l'inverse : c'est bien la partie synchro qui n'est pas compliquée, et tout le commentaire tourne autour de ça.
Je ne l'ai donc pas comprise, 2x.
[^] # Re: En conclusion
Posté par Xanatos . Évalué à 1.
Alors mea-culpa de ma part.
[^] # Re: En conclusion
Posté par freem . Évalué à 5.
Très probablement.
En l'occurrence, on parle de synchroniser les bases de données sous-jacentes, n'étant pas utilisateur, je ne sais pas si la connection se fait en permanence ou ponctuellement, mais même le cas du "en permanence", en pratique, tu ouvres une connection TCP/TLS, dès qu'un passe ou un truc est ajouté/supprimé, tu balances ton message au serveur, qui redonde sur les autres clients connectés.
Quand un client s'ouvre, il récupère son retard, quand un client se ferme, il vérifie (par acquis de conscience) que tout est OK.
Rien de bien sorcier à priori.
De l'autre côté, tu as l'UI. La, je me risquerais déjà pas à implémenter la gestion des onglets, des boîtes de dialogues et tout le toutim sans une bibliothèque (c'est ce qu'ils font d'ailleurs, gtk me semble?). Bon, on peut déléguer à une lib, mais il reste à faire une UI qui plaise et qui soit portable et qui s'intègre pas trop mal dans les OS supportés. Très, très difficile ça.
Et le pire, c'est le rendu des pages elles-mêmes. Tu dois interpréter/compiler 3 langages, dont l'un est "turing-complete". La complexité par rapport aux 2 autres éléments est nettement supérieure, sans même y ajouter de gestion des plugins et des hooks.
[^] # Re: En conclusion
Posté par Tarnyko (site web personnel) . Évalué à 7.
Chrom(ium) est moteur dans le monde du Web, pour des bonnes et mauvaises raisons, grâce à son intégration verticale. Le navigateur est state-of-the-art, sur des sujets qui sont souvent poussés au niveau du W3C par… Google lui-même.
Exemple : j'utilise un toolkit JS made in Google nommé Polymer. Dans ses 2 premières versions, il faisait appel à des innovations propres à Chromium (HTML Imports, Web Components v0), Firefox fonctionnant alors en mode "dégradé". Que va logiquement se dire le développeur ?
La force de frappe financière de sa société-mère joue un rôle indirect énorme dans son avance.
[^] # Re: En conclusion
Posté par Maclag . Évalué à 10.
Elle a été posée la question. Il y a déjà eu pas mal de débat quand le scandale du traitement des dirigeants a été replacé dans le contexte d'une chute dramatique des parts de marché et d'un licenciement de cette partie de l'équipe que tu mentionnes.
Avant d'accuser la communauté d'être radine, faudrait peut-être aussi voir si Mozilla envoie du rêve. Personnellement j'ai pas envie de faire un don à des dirigeants dont la stratégie semble être de se verser des salaires plus élevés en virant les dévs pour équilibrer le budget.
Et s'il faut qu'ils se ramassent la gueule lamentablement avant que les choses changent pour de bon, qu'ils se ramassent la gueule. Je serai là, avec mon portefeuille, quand ça reprendra un air de semblant de sérieux.
En fait, mon principal regret avec le recul, c'est que l'équipe virée n'ait pas monté une structure en parallèle pour continuer à travailler sur Firefox en faisant un appel aux dons. J'y aurais allègrement contribué. Si Mozilla est irrécupérable, qu'une autre structure reprenne Firefox, de gré (s'ils prennent leurs patches) ou de force (un fork).
https://www.xbrowsersync.org/
https://github.com/YunoHost-Apps/ffsync_ynh
Même si ce dernier a encore besoin d'aller s'identifier chez Mozilla.
Non, finalement on peut surtout se demander pourquoi se rendre toujours plus dépendants des bons vouloirs d'une grosse boite dont on sait qu'elle n'est pas notre pote.
Qu'est-ce qui empêchera Google un matin de décider que le serveur de sync exigera une signature fournie uniquement par la version proprio de Chrome?
Qu'est-ce qui les empêchera de décider que les prochaines fonctionnalités ne seront pas proprio?
Rien, et c'est pas comme si l'écosystème Android n'avait pas montré un tel chemin.
Faut arrêter avec les "ils n'oseront pas". C'est quoi les parts de marché de Chromium vs Chrome, et raisonnablement, s'ils tuaient Chromium, c'est quoi la part des utilisateurs qui diraient "bouh vilains méchants" avant d'installer Chrome (mais "à contre-cœur", bien entendu) ?
[^] # Re: En conclusion
Posté par Julien Wajsberg . Évalué à 2.
Les dons à Mozilla Fondation ne vont pas aux dirigeants de Mozilla Corp, ce sont deux structures disjointes.
[^] # Re: En conclusion
Posté par Maclag . Évalué à 10.
Oui, du coup c'est encore mieux: les dons à Mozilla ne servent pas à financer le développement de Firefox.
Ça fait encore plus rêver: si tu veux soutenir Firefox, tu peux envoyer de l'argent à Mozilla qui s'en servira à tout sauf soutenir Firefox.
[^] # Re: En conclusion
Posté par freem . Évalué à 3.
Perso, je me suis fait mordre une fois par opera, même si certes, je ne payais pas la synchro, mais depuis, c'est niet les trucs de synchro. À la rigueur, si j'en avais le contrôle, pourquoi pas, mais je préfère ne rien avoir plutôt qu'avoir un truc qui risque d'être viré aléatoirement sans que l'on ne puisse discuter la décision (de mémoire, j'avais reçu un mail comme quoi j'étais banni alors que je n'avais fait qu'essayer d'utiliser une des fonctionnalité, sans y arriver?).
Comme on dit, mieux vaut être seul que mal accompagné.
Et ça, ça vaut clairement autant pour la MoFo, la MoCorp, vivaldi (la boîte derrière) ou Alphabet.
Si un navigateur proposait, nativement un service de synchro qui soit configurable sans aller modifier à la main le about:config (que je considère l'équivalent de regedit, en moins bien foutu), j'y réfléchirais.
Je viens de regarder, ce n'est pas le cas de firefox: dans les préférences, il ne semble pas y avoir moyen de renseigner une URI de référence pour «sync».
Ben vois-tu, déjà je pense que tous les utilisateurs de vivaldi ou opera râleraient sévère. Ceux qui utilisent chromium sur Debian feraient la gueule, et je n'ai aucun doute que ça finirait à ce que Debian maintienne chromium. Probablement avec l'aide des devs de vivaldi et opera, ainsi que d'autres ici et la (otter browser, peut-être? Tiens, ça fait longtemps que j'ai vérifié ce qu'il vaut…).
Ça n'est certes pas au niveau des devs de Firefox, donc le résultat serait certainement à la ramasse comparé à Chrome, mais je pense que pas mal d'utilisateurs de ces solutions préféreraient largement ça. De ce que j'ai lu, il semble (basé sur le très sérieux indicateur pifométrique(tm), édité par la société très professionnelle MyFeelingCorp) que les utilisateurs de vivaldi me ressemblent sur un point: il préféraient utiliser un opera 12 non maintenu, plutôt que firefox ou chromium ou opera-blink, après tout.
[^] # Re: En conclusion
Posté par Anonyme . Évalué à 7.
C’est pas un problème d’utilisateur à mon avis. Je suis certains que s’ils poussaient un bandeau à l’ouverture de Firefox (comme le bandeau pour activer/désactiver la télémétrie) ou même un mail, pour récolter des dons (un peu comme Wikipedia), beaucoup de monde donnerait.
En attendant ils préfèrent envoyer du SPAM et se concentrer sur des trucs qui ne marcheront pas (Pocket, Mozilla VPN, etc.).
[^] # Re: En conclusion
Posté par Cᴬᴾᵀ Samavor . Évalué à 5.
Ou justement de passer à Chromium :)
Un truc qui m'a justement fait quitter Chromium c'était la synchro des mots de passes et favoris avec le Compte Google sans avertissements aucun (à l'époque, j'ai pas ressayé récemment).
Maintenant que ça coûte $$$ on va surement voir apparaitre un Chromium avec une gestion native et bien intégrée et sans plugin des signets et mots de passe en local, voir, soyons fous, avec le support Firefox Sync.
[^] # Re: En conclusion
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 5.
bah non puisque le développement de Chromium est dirigé par Google.
Il faudrait un fork de Chromium pour avoir les fonctions dont tu rêves. ( ou passer à Firefox, elles y sont déjà).
[^] # Re: En conclusion
Posté par Cᴬᴾᵀ Samavor . Évalué à 5.
Je pensais évidemment à la communauté, ces fonctionnalités vont bien manquer à quelques-uns.
Et je suis déjà sur Firefox, j'ai l'habitude d'être à rebours de la mode :
- Quand les sites n'étaient développés que pour IE5/6 j'étais sous Mozilla/Firefox.
- Quand les développeurs ont commencés à prendre en compte Gecko, je suis passé sur du Khtml.
- Maintenant que les dérivés de Khtml ont près de 90% des parts de marché et qu'on voit réapparaitre des sites qui fonctionnent mal sous Firefox, je suis repassé à ce dernier.
# xBrowserSync
Posté par Renaud Casenave-Péré . Évalué à 10.
Je n'utilise ni chromium ni slackware mais ce journal m'a fait découvrir xBrowserSync.
Alors merci.
[^] # Re: xBrowserSync
Posté par Tarnyko (site web personnel) . Évalué à 3.
Je tiens de tester xBrowserSync sous Android ; il s'y présente comme une application distincte, où cliquer sur les marque-pages ouvre le navigateur favori du mobile. Pas très pratique, donc.
Techniquement, on peut installer l'extension Firefox sur Fennec (à ne pas confondre avec l'appli nommée "Firefox", de nature différente), mais ça coince (bug).
Sommes-nous nombreux à installer Fennec sur Android ? En admettant le bug résolu, ça ferait une bonne motivation pour mettre Mozilla sur mobile (il n'y a qu'un Chrome-like compatible, et il est d'origine douteuse).
# Google Sync, mauvais feeling dès le départ
Posté par Tarnyko (site web personnel) . Évalué à 6. Dernière modification le 09 mars 2021 à 03:14.
Article passionnant, merci !
Je compile personnellement Chromium sans clés, et sous une forme extrêmement réduite (content_shell) où la plupart des traqueurs sont mécaniquement absents. J'ignorais cependant l'existence de l'effort ungoogled-chromium, je vais vérifier s'il y a des chemins de code qui me concernent.
Par contre, étais-je en minorité à avoir toujours été contre, ce truc d'envoyer ses données dans Google Sync ?
Je comprends l'intérêt pour un développeur d'applis Web commerciales (que je ne suis pas) d'enregistrer p.ex. la progression d'un jeu. Mais dans un contexte libre/gratuit, et si l'utilisateur tient tant que ça à jouer sur plusieurs devices, un transfert du profil ou ta solution XBrowserSync sont vraiment si hardcore à suggérer ?
Et question bonus, y-a-t-il des APIs ouachement utiles hors Google Sync ?
[^] # Re: Google Sync, mauvais feeling dès le départ
Posté par f6k (site web personnel) . Évalué à 4.
En un mot j'aurai tendance à dire oui. Pour la simple et bonne raison que les solutions proposées par Google représente une forme de sécurité, de stabilité et de simplicité pour de nombreux utilisateurs finaux qui peuvent déjà utiliser par ailleurs l'écosystème de Google (soit par choix personnel soit parce que c'est l'environnement mis en avant dans le cadre d'une institution/entreprise). Je pense que, à moins d'avoir une démarche pro-active en ce sens, c'est une des raisons (et peut-être la principale) qui fait que des solutions comme xBrowserSync sont moins courues. Sans parler du fait que, pour être vraiment certain que les données ne soient pas hébergés chez quelqu'un que l'on ne connait finalement pas (parce que oui, même l'api proposée par xbrowsersync.org n'a peut-être pas ce niveau de confiance), il faut installer sa propre instance (avec les connaissances et les problèmes de sécurité que cela génère).
Au niveau de l'utilisateur final, les APIs de synchronisation sont quand même celles qui sont pas mal mises en avant.
[^] # Re: Google Sync, mauvais feeling dès le départ
Posté par Tarnyko (site web personnel) . Évalué à 2.
Merci, ça répond bien à ma question. Le champ est donc 100% circonscrit :).
Tu me dis donc que c'est dur ; je veux bien te croire.
Ça ne me dérange en fait pas tant que ça de mettre des aspire-données à des utilisateurs… consentants.
Je vois plus l'impact sur le monde du libre/gratuit (un tel jeu se "vendant" moins). Mais là, je ne vois que s'entendre sur un plugin alternatif à fournir avec -ce qui implique déjà que l'impact sur ce petit monde fusse conséquent.
[^] # Re: Google Sync, mauvais feeling dès le départ
Posté par f6k (site web personnel) . Évalué à 0.
En un mot j'aurai tendance à dire oui. Pour la simple et bonne raison que les solutions proposées par Google représente une forme de sécurité, de stabilité et de simplicité pour de nombreux utilisateurs finaux qui peuvent déjà utiliser par ailleurs l'écosystème de Google (soit par choix personnel soit parce que c'est l'environnement mis en avant dans le cadre d'une institution/entreprise). Je pense que, à moins d'avoir une démarche pro-active en ce sens, c'est une des raisons (et peut-être la principale) qui fait que des solutions comme xBrowserSync sont moins courues. Sans parler du fait que, pour être vraiment certain que les données ne soient pas hébergés chez quelqu'un que l'on ne connait finalement pas (parce que oui, même l'api proposée par xbrowsersync.org n'a peut-être pas ce niveau de confiance), il faut installer sa propre instance (avec les connaissances et les problèmes de sécurité que cela génère).
Au niveau de l'utilisateur final, les APIs de synchronisation sont quand même celles qui sont pas mal mises en avant.
[^] # Re: Google Sync, mauvais feeling dès le départ
Posté par Psychofox (Mastodon) . Évalué à 9.
De toute façon que ce soit google-sync ou firefox-sync c'est bancale dès le départ. Que ce soit pour les mots de passes ou les favoris, c'est bien plus intéressant de les rendre indépendants du navigateur.
Et ça tombe bien on a les gestionnaires de mots de passes pour cela (et ils gèrent aussi très bien tes favoris car tous proposent un champ url).
[^] # Re: Google Sync, mauvais feeling dès le départ
Posté par Tarnyko (site web personnel) . Évalué à 3.
Exactement, ils veulent tous monétiser la fonctionnalité.
Alors qu'en fait c'est idéalement à une appli neutre et indépendante de gérer ce type de données sensibles.
# Précisions : gratuité et sécurité
Posté par MrLapinot (site web personnel) . Évalué à 10.
[Je travaille chez Google, mais je n’ai aucune information interne sur cette décision et ce qui suit est un commentaire personnel qui n'engage pas mon employeur.]
Ce n’est pas ce que dit l’article d’AlienBob.
L’accès à safe-browsing (et autres services qui nécessitent de contacter les serveurs de Google sans authentifier l’utilisateur) restera possible avec une API key et un certain quota d’utilisation gratuit. Par contre, les mainteneurs de distributions ont bénéficié jusqu’à présent d’une augmentation de ce quota, en raison du large nombre d’utilisateur. AlienBob n’est pas sûr pour l’instant de si ce quota élargi sera maintenu après le 15 mars, mais Google n’a pas prétendu qu’il sera restreint, et la communication envoyée ne concernait ni cette API, ni la question de la gratuité. Par ailleurs, AlienBob indique dans les commentaires de son propre article qu’il va finalement attendre de voir ce qu’il en est du quota et de l’usage en pratique avant de décider s’il force les distributions dérivées à obtenir leur propre API key. A priori, il devrait être possible aux mainteneurs de ces distributions de demander un quota élargi au besoin pour leur propre clé.
En revanche, l’accès à Cloud Sync (et autres APIs nécessitant un Client-ID, ie. accédant à des données personnelles de l’utilisateur) sera coupé purement et simplement. Google invoque des raisons de sécurité des données. On lit entre les lignes une volonté de changer les mécanismes de sécurité à moyen terme, pour une version qui ne serait sans doute plus compatible avec le modèle actuel, mais ils ne donnent pas plus de détails à part qu’il n’y a à leur connaissance pas eu d’incident de sécurité (donc que la faille, s’il y en une, n’a pas été exploitée en pratique). Là il n’est pas question de coût du tout, des intégrateurs de ChromiumOS ont demandé sur le thread chrome-packagers s’ils pouvaient payer pour continuer d’avoir accès, et la réponse a été clairement non. Ceux dans la pire situation ne sont pas les fabricants de SmartTV mais les vendeurs de portables sous ChromiumOS (à part pour les revendeurs officiels comme Acer et Samsung), parce que leurs utilisateurs ne pourront plus se connecter du tout à leur ordi !
Je trouve également très frustrant le manque de transparence sur ce changement brutal, mais s’il s’agit effectivement d’une faille potentielle mais pas exploitée, on peut comprendre la grande prudence à ne pas communiquer plus de détails.
[^] # Re: Précisions : gratuité et sécurité
Posté par f6k (site web personnel) . Évalué à 6.
En effet, c'est une erreur de ma part, merci de la correction. Au moment du premier jet de l'article, j'ai effectué quelques recherches sur cette question et j'ai sauté (trop) rapidement à la conclusion que le quota de gratuité serait lui aussi supprimé puisque le remaniement de tout cet écosystème semble pointer dans cette direction. Ainsi que tu le dis, il est clair qu'un nouveau modèle risque de voir le jour d'ici à l'année prochaine (pronostic personnel). Aussi je crois, personnellement, que cela va finir comme ça mais, pour le moment, et comme tu fais bien de l'expliquer, rien n'est certain sur ce point. Puis AlienBob est clairement revenu sur cet élément dans son commentaire du 5 mars sous son article (où il dit en substance wait and see) et j'ai manqué d'éditer mon article en conséquence.
En passant, rien à voir, mais question à tout le monde : n'est-il pas possible d'éditer mon journal afin d'apporter la correction et les précisions pointées par MrLapinot ?
Maintenant tu mets en avant un élément très intéressant à savoir les questions de sécurité, raison évoquée par Google à différents moments depuis plusieurs mois, que je n'aborde pas du tout pour des questions d'exhaustivité (au sens où je ne voulais pas m'étendre sur ce sujet ici et que je ne voulais pas non plus juste dire "ils disent que c'est une question de sécurité", argument que l'on ne peut pas juste évoquer seul comme cela tellement il a été galvaudé). Si mes souvenirs sont bons, c'est quelque chose qui est discuté (vis-à-vis des APIs je veux dire) depuis au moins début 2019 n'est-ce pas ? Par ailleurs, et dans ce même cadre, il aurait aussi été intéressant de parler de l'arrêt du support complet des Chrome apps d'ici à juin 2022 et de la volonté de Google de voir les développements de ces applications aller vers des Progressive Web App ; ce qui fait un lien de plus avec ta remarque sur Chromium0S. Mais là, à nouveau, je trouvais que je sortais trop du cadre et ne voulait pas alourdir mon propos. D'ailleurs, j'avais un paragraphe justement en prenant l'exemple de Samsung mais j'ai décidé de le supprimer histoire de ne pas ouvrir encore d'autres portes que je ne pourrais pas refermer. Enfin, j'ai personnellement beaucoup plu eu à lire sur la question des téléviseurs connectés (en lien notamment avec Samsung) mais il est indéniable que la coupure des accès aux APIs ainsi que l'arrêt du support des apps va poser d'énormes problèmes à beaucoup de monde.
[^] # Re: Précisions : gratuité et sécurité
Posté par Tarnyko (site web personnel) . Évalué à 2.
Non, il faut faire appel à un modérateur, ce que je mets en gras en espérant être vu ;).
[^] # Re: Précisions : gratuité et sécurité
Posté par _kaos_ . Évalué à 5.
Salut,
Attention, tu pourrais te faire pincer les doigts très forts !
:p
Matricule 23415
[^] # Re: Précisions : gratuité et sécurité
Posté par f6k (site web personnel) . Évalué à 1.
C'est noté merci ! Je serais beaucoup plus vigilant la prochaine fois :)
# uMatrix
Posté par E3Ms6vyX . Évalué à 5.
N'est plus activement développé, malheureusement.
https://github.com/uBlockOrigin/uMatrix-issues/issues/291#issuecomment-694988696
[^] # Re: uMatrix
Posté par Xanatos . Évalué à 2.
Merci pour l'info.
C'est fort dommage =/
# Le binaire Slackware marche partout
Posté par Tarnyko (site web personnel) . Évalué à 4. Dernière modification le 09 mars 2021 à 12:21.
J'allais du coup demander comment récupérer un chrome-ungoogled précompilé.
Mais en fait, vous savez le seul avantage de la méthode de compilation "île déserte" de Google ?
Son binaire marche quasi partout.
Je me suis contenté de récupérer le paquet Slackware, de l'extraire, touiller le script, eeeetttt…. hop !
[^] # Re: Le binaire Slackware marche partout
Posté par Nibel . Évalué à 3. Dernière modification le 09 mars 2021 à 14:08.
Autrement il y a un repo git (mais du coup faut compiler soi-même) :
https://github.com/Eloston/ungoogled-chromium
Un paquet est disponible dans AUR également pour les Archeux : ungoogled-chromium
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Le binaire Slackware marche partout
Posté par Tarnyko (site web personnel) . Évalué à 1. Dernière modification le 09 mars 2021 à 14:49.
Effectivement ; pour un utilisateur non informé, je précise que ça prend 3 à 6 heures, consomme 40 Go d'espace disque et 4-6 Go de RAM.
Maintenant je vais y rejeter un oeil pour le versionnage, merci d'avoir rappelé le lien.
Logiquement, il devrait marcher aussi (juste un format d'archive différent).
[^] # Re: Le binaire Slackware marche partout
Posté par Nibel . Évalué à 4. Dernière modification le 09 mars 2021 à 15:28.
Je n'avais pas fait attention que le lien de ce repo était dans le journal, mea culpa.
Précision : Sur AUR ce n'est pas un binaire qui est disponible, c'est seulement un MAKEPKG qui s'occupe de récupérer le repo git, les dépendances qui vont bien et qui lance la compilation.
En fouillant un peu, je viens de trouver que des binaires pré-compilés existent aussi :
https://ungoogled-software.github.io/ungoogled-chromium-binaries/
Peut-être que ça pourra t'intéresser ainsi que d'autres.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Le binaire Slackware marche partout
Posté par Tarnyko (site web personnel) . Évalué à 2. Dernière modification le 09 mars 2021 à 16:10.
La honte, le mec (moi) qui sait plus ce que c'est Arch !
Hé ben, l'utilisateur va se manger les heures de compil' dans ce cas…
Coiffé au poteau, un pote vient juste de m'envoyer là-bas ;).
Ce qui y manque par contre, c'est le binaire i586 (32-bit) de Slackware, mais faut que je le triture un peu pour voir sur quoi il tourne (faut sans doute du SSE au moins).
[^] # Re: Le binaire Slackware marche partout
Posté par Tarnyko (site web personnel) . Évalué à 2.
OK alors il tourne. Par contre j'ai des kernel panic sur un vieux noyau (3.10), sur un 3.16 il fonctionne mais alors l'erreur suivante se présente :
que l'on peut contourner de cette façon sous Debian:
Après j'ai aussi eu des crashes aléatoires liées à la version des bibliothèques NSPR/NSS, que j'ai dû upgrader plusieurs fois (3.28 n'a pas suffi, j'ai tâtonné).
Je pense que le fond du truc est que les distros i586 que j'ai à ma disposition sont toutes trop trop anciennes, ça marche probablement sur Slackware. En espérant que mes étapes servent.
[^] # Re: Le binaire Slackware marche partout
Posté par Yth (Mastodon) . Évalué à 5.
Ah oui, la Slackware i586 a les mêmes paquets que la version x86_64.
Donc un noyau récent, une glibc récente, etc.
Enfin, si on parle de la 14.2, ça a 5 ans, donc pas si récent, mais la current en i586 est la même que la version x86_64 (ou arm).
Donc côté libs et compatibilité, ça peut largement foirer sur une vieille version d'une autre distribution.
# MàJ conclusion : Tutoriel KeePassXC et xBrowserSync par AlienBob
Posté par f6k (site web personnel) . Évalué à 2.
Comme promis, AlienBob a sorti un long tutoriel expliquant la mise en place et l'utilisation de KeePassXC et xBrowserSync suite à l'utilisation d'un Chromium exempt des services de Google. Pour ceux que cela intéresse, on peut retrouver ces informations dans son article Sync and share your (Chromium and more) browser data among all your computers.
[^] # Re: MàJ conclusion : Tutoriel KeePassXC et xBrowserSync par AlienBob
Posté par Tarnyko (site web personnel) . Évalué à 1. Dernière modification le 16 mars 2021 à 15:20.
Très intéressant, merci !
J'avais essayé xBrowserSync, que je trouvais réussi mais l'intégration mobile Firefox (Android) pêchait à mon goût.
Je vois qu'il parle d'une version Google-Unchromium pour Android dont j'ignorais jusqu'à l'existence ! Si elle accepte l'extension ça pourrait faire le café, je teste ça.
[^] # Re: MàJ conclusion : Tutoriel KeePassXC et xBrowserSync par AlienBob
Posté par Anthony Jaguenaud . Évalué à 4.
Pour la gestion des mots de passe, j'ai découvert
bitwarden, installé sur un yunohost, fonctionne plutôt bien pour le moment.On peut ajouter les codes F2A, on le retrouve aussi bien sur ordiphone, que dans les navigateurs via des extensions.
Je suis toujours en phase d’évaluation, mais je suis très positif après 5 jours.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.