Firefox 46 intègre finalement le support de GTK3 sous Linux

Firefox 46 intègre finalement le support de GTK3 sous Linux

Couper les fils avec X11

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

26/04/2016 3 minutes
76

Firefox 46 intègre finalement le support de GTK3 sous Linux

Le déploiement de Firefox 46 a commencé, mais pas pour tout le monde. Avant tout la nouvelle mouture signe enfin l’arrivée de GTK3 sous Linux. Elle améliore aussi la sécurité pour la compilation JIT du JavaScript ainsi que les performances de WebRTC.

Firefox 46 intègre donc enfin le support de GTK3 pour la version Linux. Cela faisait plusieurs mois que Mozilla travaillait sur ce point, la prise en charge faisant des allers et retours selon les versions. Cet ajout permet de réduire la dépendance au vieillissant serveur d’affichage X11, une compatibilité renforcée avec le HiDPI ainsi et surtout une meilleure intégration avec les thèmes.

Une sécurité renforcée pour le JavaScript

Le nouveau navigateur permet également d’améliorer la sécurité de la compilation JavaScript en Just-In Time. L’idée est d’influer sur le code RWX (read-write-execute) qui entraine parfois un risque. Il représente initialement une exception à des règles fixées par le système d’exploitation, tout particulièrement le stockage de données dans une zone mémoire où elles peuvent être exécutées (lues), mais pas écrites.

Pour remédier à ce problème, Mozilla emploie un mécanisme nommé W^X. Sa fonction est d’interdire au JavaScript d’écrire dans les zones de la mémoire contenant du code JIT. Cette modification se fera au détriment d’une très légère baisse des performances, estimée selon l’éditeur dans une fourchette de 1 à 4 %. Par ailleurs, les créateurs de certaines extensions sont invités à tester la compatibilité de leur code face à ce mécanisme.

Pour le reste, Firefox 46 améliore les performances et la fiabilité des connexions WebRTC, et permet d’utiliser le Content Decryption Module pour les contenus H.264 et AAC quand c’est possible. Les développeurs auront à disposition quelques ajouts également, comme le profilage des pauses dans les allocations et le ramasse-miettes, ou encore le lancement du mode responsive dans le Style Editor.

Précisons que cette nouvelle mouture renforce l'accent sur la signature des extensions, mais qu'elle ne la rend pas encore obligatoire. Cette importante bascule est prévue pour Firefox 47, les développeurs étant appelés à se dépêcher s'ils n'ont pas commencé à travailler sur ce point.

Pour récupérer le navigateur, il suffira de cliquer sur l'un des liens suivants :

La version Android charge les pages en cache sans connexion

La version Android comporte de son côté une bonne liste d’améliorations. Elle permet d’indiquer dans les notifications relatives aux onglets en arrière-plan les adresses précises. Elle est également compatible avec le nouveau système de permissions d’Android 6.0 et demandera ces dernières à l’exécution, non à l’installation.

Firefox 46 peut également afficher les pages mises en cache quand le smartphone ou la tablette n’a pas de connexion, un ajout que beaucoup devraient apprécier. La page d’accueil a de son côté été révisée pour être plus claire, et l’historique comme les favoris ont été ajoutés au menu. Enfin, les Top Sites intègrent par défaut les sites les plus populaires, mais ils peuvent être supprimés et remplacés par d’autres.

Attention, Firefox 46 se débarrasse du support d’Android Honeycomb (versions 3.X). Un arrêt de support qui ne devrait concerner qu’un nombre minime d’utilisateurs.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Une sécurité renforcée pour le JavaScript

La version Android charge les pages en cache sans connexion

Commentaires (76)




Firefox 46 peut également afficher les pages mises en cache quand le smartphone ou la tablette n’a pas de connexion, un ajout que beaucoup devraient apprécier.





C’est pas trop tôt !!




Cet ajout permet de réduire la dépendance au vieillissant serveur d’affichage X11, une compatibilité renforcée avec le HiDPI ainsi et surtout une meilleure intégration avec les thèmes.

Ça veut dire que les thèmes seront enfin affichés correctement sur un environnement GTK3 (Gnome-Shell, Unity, Cinnamon, etc) ? Si c’est ça, champagne !&nbsp;<img data-src=" />


Ouais c’est tout à fait ça <img data-src=" />


J’ai un soucis avec le cache de Firefox sous Android, quand je visite par exemple la version mobile de NextInpact que j’actualise, je n’ai pas toujours les derniers articles, comme si le cache n’était pas invalidé. Du coup, je dois fermer Firefox et le rouvrir pour avoir la page actualisée.


Après ça, plus aucune application en GTK2 sur mon installation <img data-src=" />




Firefox 46 peut également afficher les pages mises en cache quand le

smartphone ou la tablette n’a pas de connexion, un ajout que beaucoup

devraient apprécier.





&nbsp;Pas trop tôt. Ce rechargement quand on revient sur la page après un bon moment, c’est franchement lourd (surtout si on a perdu la connexion depuis, ça tente de recharger puis ça échoue sans laisser l’ancien contenu). J’ai hâte d’avoir la màj.


Youpi GTK3 <img data-src=" />


Ah ben c’est déja mieux

&nbsp;

Performance &gt; Chrome

Interface = Chrome

API Graphique &gt;&gt;&gt;&gt;&gt; Chrome

h264 = Chrome

Extensions &gt; Chrome



Firefox refait son retard, il lui manque plus que

&nbsp;





  • Installation dans AppData comme un goret&nbsp;

  • Aspirer les données utilisateurs en donnant une ID unique a chaque installation&nbsp;

  • Créer un service FirefoxUpdater.exe qu’on ne peut désinstaller&nbsp;

  • S’incruster sur les machines par tous les moyens possibles, y compris en ayant recours a une installation forcée par le biais d’Avast&nbsp;

  • Implémenter des drafts HTML5 non finalisés pour assurer une incompatibilité maximale&nbsp;





    Plus que quelques efforts et Firefox sera enfin au niveau de Chrome !


#sarcasm


Je crois que ça l’était depuis au moins la 44 sous Archlinux. Il suffit d’aller sur « about:buildconfig » et voir si l’argument –enable-default-toolkit=cairo-gtk3 est présent.








RRMX a écrit :



Créer un service FirefoxUpdater.exe qu’on ne peut désinstaller&nbsp;



Ils on déjà un service d’update sous Windows, mais il est désinstallable.









RRMX a écrit :



Installation dans AppData comme un goret&nbsp;



Si si, c’est bon depuis longtemps. Personnellement je trouve ça bien, ça évite de donner des droits d’administrateur à tous les utilisateurs pour pouvoir bénéficier des mises à jour. Vu la merde que c’est à déployer en masse, c’est un pis-aller.



Ouai, c’est le cas chez moi.

Par contre, le support des widgets GTK3 est assez approximative : pas d’animations, quelques “blocages” sur les états CSS des widgets, etc (genre l’ombre sous le bouton reste alors qu’il n’est plus en focus).


L’install dans AppData est une très bonne pratique, tu n’impacte que toi-même.








psn00ps a écrit :



L’install dans AppData est une très bonne pratique, tu n’impacte que toi-même.





N’exagérons rien, disons que c’est une rustine convenable à la gestion catastrophique des droits sur NT.



Ce que psn00ps dit, c’est que ça permet d’installer Firefox pour soi, sans avoir les droits admin/sans impacter les autres utilisateurs.



C’est une critique acceptable de Linux (hélas) : On ne peut pas installer un logiciel “pour soi” sans avoir les droits admin, ni le mettre à jour.








psn00ps a écrit :



L’install dans AppData est une très bonne pratique, tu n’impacte que toi-même.





Je preferai que le profile de l’utilisateur, y compris appdata donc soit en noexec personnellement… ca éviterait la plus part des saloperies comme les ransomwares.







lincruste_2_la vengeance a écrit :



N’exagérons rien, disons que c’est une rustine convenable à la gestion catastrophique des droits sur NT.







C’est vrai que c’est pas top… c’est presque du tout ou rien : admins ou utilisateurs du domaine… après tu peux jouer avec les GPO pour affiner les droits mais tu te manges vite un mal de crane <img data-src=" />



En activant les ACL avancés et en jouant avec sudo/elevation de privilège on doit pouvoir y arriver <img data-src=" />


Tu veux dire, en permettant aux utilisateurs de jouer avec le système ? On perd l’avantage de la sûreté des permissions POSIX ;)


Non, il ne faudrait pas qu’il puisse s’élever jusqu’au root tout de même :)


Tu as raison, c’est une question de ce qu’on veut laisser à l’utilisateur.

Mais je ne vois pas&nbsp; ce qui s’oppose à la création d’un profil noexec.


Les droits existent, il faut s’en servir.


J’vois pas trop alors. Enfin si, tu peux à la limite donner les droits root au binaire apt-get / pacman, avec les droits SUID / GUID. Mais c’est risqué <img data-src=" />








lincruste_2_la vengeance a écrit :



Si si, c’est bon depuis longtemps. Personnellement je trouve ça bien, ça évite de donner des droits d’administrateur à tous les utilisateurs pour pouvoir bénéficier des mises à jour. Vu la merde que c’est à déployer en masse, c’est un pis-aller.





&nbsp; Ça peut en effet se faire depuis toujours, et c’est un bonne chose. Mais ça n’est pas le comportement par défaut, et ça aussi c’est une bonne chose. Normalement le service de maintenance Mozilla permet justement de faire les mises à jour sans avoir besoin des droits d’admin.







Salamandar a écrit :



C’est une critique acceptable de Linux (hélas) : On ne peut pas installer un logiciel “pour soi” sans avoir les droits admin, ni le mettre à jour.





Ce n’est pas la démarche habituelle, mais on peut tout a fait installer des applications en tant qu’utilisateur sous Linux. Personnellement mon $HOME contient un répertoire Apps avec plein de logiciels utilisateur dedans, notamment la version Nightly de Firefox.









Salamandar a écrit :



Ce que psn00ps dit, c’est que ça permet d’installer Firefox pour soi, sans avoir les droits admin/sans impacter les autres utilisateurs.



C’est une critique acceptable de Linux (hélas) : On ne peut pas installer un logiciel “pour soi” sans avoir les droits admin, ni le mettre à jour.





Rien ne t’empeche de l’installer dans ton /home ?



C’est faisable certes, mais pas les paquets précompilés qui contiennent des références à /usr/lib et /usr/share.

Et ce n’est pas la façon de faire habituelle, ce n’est pas user-friendly de le faire :)

Après, ya les paquets xdg-apps/snappy(beurk)/Appimage qui commencent à arriver et qui changeront peut-être ça. Mais on pert un peu de l’“essence” de la gestion des paquets et des librairies partagées sous Linux qui est clairement un avantage !








Salamandar a écrit :



J’vois pas trop alors. Enfin si, tu peux à la limite donner les droits root au binaire apt-get / pacman, avec les droits SUID / GUID. Mais c’est risqué <img data-src=" />





Il faut un gestionnaire de paquets adapté effectivement.









psn00ps a écrit :



Tu as raison, c’est une question de ce qu’on veut laisser à l’utilisateur.

Mais je ne vois pas  ce qui s’oppose à la création d’un profil noexec.





Sous windows ? C’est pas trivial il me semble non ?



Justement c’est pour moi un des gros problème de Linux, on est obligé (ou fortement encouragé) à recourir aux droits administrateur pour énormément de choses pour lesquelles on ne devrait pas avoir à le faire.



Quant au système de dépendances c’est pour moi un des points clés qui empêchent un développement grand public de Linux. S’il n’y avait qu’un seul Linux pourquoi pas, mais multiplier l’effort de packaging sur chaque distribution est vraiment une idiotie.


C’est étonnant que personne n’a encore pondu de chroot ou de docker.








Uther a écrit :



Justement c’est pour moi un des gros problème de Linux, on est obligé (ou fortement encouragé) à recourir aux droits administrateur pour énormément de choses pour lesquelles on ne devrait pas avoir à le faire.





Tu peux toujours te logger avec le compte root en interface graphique si tu penses que la sécurité est une erreur.









Uther a écrit :



Justement c’est pour moi un des gros problème de Linux, on est obligé (ou fortement encouragé) à recourir aux droits administrateur pour énormément de choses pour lesquelles on ne devrait pas avoir à le faire.



Quant au système de dépendances c’est pour moi un des points clés qui empêchent un développement grand public de Linux. S’il n’y avait qu’un seul Linux pourquoi pas, mais multiplier l’effort de packaging sur chaque distribution est vraiment une idiotie.





Le système de dépendance n’oblige à rien. Chrome n’est pas packagé sur Fedora, mais il y est tout à fait installable via un rpm.









lysbleu a écrit :



Le système de dépendance n’oblige à rien. Chrome n’est pas packagé sur Fedora, mais il y est tout à fait installable via un rpm.





Sauf que tu perds dans ce cas un des grands avantages des gestionnaires de paquets pour le grand public, à savoir une logithèque centralisée où tu peux presque tout trouver, et la gestion très simple des mises à jour.



Quant à la résolution des dépendances, c’est plutôt un problème de user avancé que de Michu sur une distrib user-friendly.



C’est ce que je disais : la nécessité des droits root est une critique acceptable de Linux, dans le sens où c’est un vrai problème.

Après ça a de vrais avantages, mais peu pour un ordinateur personnel (avec un seul utilisateur). D’où l’existence de sudo.



Pour les librairies et les dépendances, je suis à moitié d’accord avec toi.

En effet, ça impose un travail d’intégration à chaque distrib.

Mais si le développeur est clair sur les besoin de son logiciel (simple liste des dépendances + système de build transparent (c’est déjà le cas) + “comment dire au système de build les chemins vers les libs et include” (c’est peut-être là qu’il faut un peu de boulot, mais pas tant que ça si tu utilises les systèmes de build classiques (autotools, cmake, etc))), le seul travail à faire est du côté du mainteneur de la distrib, et ce n’est pas compliqué.

Exemple, j’ai écrit quelques PKGBUILDs pour ArchLinux, dans le pire des cas j’ai pris 20 minutes à écrire le paquet + tout vérifier.


Google a créé des repos pour ses paquets.

Chrome y est présent.


Le packaging bénéficie du partage des sources.

A part quelques spécificités, les dépendances sont les mêmes.


Jvois pas le problème, je le fais quand ma session est en carafe ou quand je veux bidouiller ma partition home <img data-src=" />

&nbsp;Mais bon, je sais ce que je fais (enfin plus ou moins), et je sais ce que je risque :p








ActionFighter a écrit :



Sauf que tu perds dans ce cas un des grands avantages des gestionnaires de paquets pour le grand public, à savoir une logithèque centralisée où tu peux presque tout trouver, et la gestion très simple des mises à jour.



Quant à la résolution des dépendances, c’est plutôt un problème de user avancé que de Michu sur une distrib user-friendly.





Certes, c’est pour ça que la plupart des logiciels sont packagés. Parce que les 20 minutes nécessaires pour écrire un fichier de spec rpm en valent la peine. Mais personne n’oblige les développeurs (alors dans les faits, ce n’est pas forcément le développeur le mainteneur du logiciel) à “multiplier l’effort de packaging sur chaque distribution”, car apparemment ce serait une “idiotie”. Ils peuvent tout à faire reproduire la façon de faire de Windows si c’est mieux, donc ce n’est pas un frein à “un développement grand public de Linux” comme le dit @Uther.





psn00ps a écrit :



Google a créé des repos pour ses paquets.

Chrome y est présent.





Ah, j’ai juste vu qu’ils proposaient un rpm sur leur site, je ne savais pas !









Salamandar a écrit :



Jvois pas le problème, je le fais quand ma session est en carafe ou quand je veux bidouiller ma partition home <img data-src=" />

 Mais bon, je sais ce que je fais (enfin plus ou moins), et je sais ce que je risque :p





<img data-src=" />



En interface graphique ?



Dans ce cas, perso, je passe en root mais en shell ou par chroot sur un live USB, ça suffit largement. Parce qu’autoriser une session graphique en root c’est quand même moyen <img data-src=" />



Après, si tu sais ce que tu fais et que tu es le seul user sur ton pc, pourquoi pas.







lysbleu a écrit :



Certes, c’est pour ça que la plupart des logiciels sont packagés. Parce que les 20 minutes nécessaires pour écrire un fichier de spec rpm en valent la peine. Mais personne n’oblige les développeurs (alors dans les faits, ce n’est pas forcément le développeur le mainteneur du logiciel) à “multiplier l’effort de packaging sur chaque distribution”, car apparemment ce serait une “idiotie”. Ils peuvent tout à faire reproduire la façon de faire de Windows si c’est mieux, donc ce n’est pas un frein à “un développement grand public de Linux” comme le dit @Uther.





C’est vrai que c’est mieux de pouvoir conserver des dépendances pas à jour, c’est plus pratique <img data-src=" />



+1

Et oui le développeur fait rarement du packaging, à part pour des raisons de tests.

&nbsp;Et si le packaging du logiciel est trop compliqué, c’est certainement qu’il est mal développé (gros yeux vers QtiPlot, bordel…).

C’est pour ça que quand je vois des projets qui embarquent leurs dépendances dans leur code source, je pète un câble. Oui ça fait un peu de boulot en plus pour vérifier que ça tourne avec la nouvelle version de la lib, mais tout le monde en profitera. Et le fait qu’il y ait une floppée de distributions n’y change rien. Tu vis dans un écosystème avec plein de projets, plein de librairies, faut faire avec.








ActionFighter a écrit :



<img data-src=" />



En interface graphique ?



Dans ce cas, perso, je passe en root mais en shell ou par chroot sur un live USB, ça suffit largement. Parce qu’autoriser une session graphique en root c’est quand même moyen <img data-src=" />



Après, si tu sais ce que tu fais et que tu es le seul user sur ton pc, pourquoi pas.





Patapé patapé <img data-src=" />

Je reste en shell tant que je peux, mais j’aime pas redimensionner mes partitions en pas-graphique. Donc je lance cinnamon et GParted.

En vrai, c’est mon manque de connaissances sur certains points qui me poussent à startx en root ^^ mais je m’y connais suffisamment pour pas risquer mon système.



Ca m’est déjà arrivé de lancer X en root, mais pas le DE quand même <img data-src=" />

Juste Xterm et l’app dont j’ai besoin en root à ce moment là.


Une “bonne pratique” qui va à l’encontre des spécifications de MS qui pour une fois vont dans le bon sens<img data-src=" />

&nbsp;Appdata c’est fait pour les données, pas les programmes.



Ya pas un concept similaire chez le manchot?<img data-src=" />

&nbsp;

Par contre, j’ai beau chercher où j’avais lut cela sur le site de Microsoft, je ne trouve plus l’article.

Cela concernait la validation des programmes pour qu’il soient “Windows 7 ready”..



Ensuite, je vais le redire mais les seuls programmes qui viennent se coller dans Appdata, je le répète car j’en vois tout les week-ends, ce sont majoritairement des malwares, justement pour contourner la sécurité de Windows.

<img data-src=" /> (J’ai juste vu f.lux et chrome…..)



Firefox c’est pas beaucoup plus propre, il installe un service sous le compte système <img data-src=" />



On aime ou on aime pas la protection de Program files, si on est une boite sérieuse (Google/Mozilla) il faut faire avec et pas la contourner.



&nbsp;Après, le sujet des MAj est délicat….Vaut mieux laisser quelqu’un pas à jour (monsieur n’est pas admin) ou faire des trucs pas très propres en termes de fonctionnement?

&nbsp;








Salamandar a écrit :



Patapé patapé <img data-src=" />

Je reste en shell tant que je peux, mais j’aime pas redimensionner mes partitions en pas-graphique. Donc je lance cinnamon et GParted.

En vrai, c’est mon manque de connaissances sur certains points qui me poussent à startx en root ^^ mais je m’y connais suffisamment pour pas risquer mon système.





Avec un live usb, tu peux lancer une appli de partitionnement en graphique et faire du chroot si besoin <img data-src=" />









RaoulC a écrit :



U



Firefox c’est pas beaucoup plus propre, il installe un service sous le compte système <img data-src=" />







Euh, c’est plutôt courant çà…



J’aime vivre dangereusement <img data-src=" />

Et “killall -u salamandar && umount /home” est plus rapide que de lancer un live usb ;)








psn00ps a écrit :



L’install dans AppData est une très bonne pratique, tu n’impacte que toi-même.







<img data-src=" /> Dans un environnement réseau, où AppData est redirigé vers un partage, voir débarquer 3.000 Google Chrome, 2.500 Firefox, avec tous leurs plugins et autres historiques + caches de navigation… <img data-src=" />

Et pi faut le sauvegarder, le AppData… <img data-src=" />

Et enfin, l’utilisateur blinde son quota, sans le savoir, et hop ! Appel au service info pour le débloquer…

Merci Google, merci Mozilla ! <img data-src=" />









RaoulC a écrit :



Ya pas un concept similaire chez le manchot?<img data-src=" />



&nbsp;Comme dossier pour mettre les préférences des logiciels ?

En fait dès qu’un nom de fichier commence par un point “.”, il est caché par les explorateurs de fichiers.

Donc en fait, dans ton dossier utilisateur tu as plein de dossiers

“.mozilla, .cache, .steam, .thunderbird, .gnupg”. Et tu as le dossier .config, où les logiciels peuvent aussi stocker des préférences.

Tu as aussi le dossier .local, mais j’ai jamais compris son intérêt par rapport à .config.



Les ClickOnce générés par Visual Studio s’installent à cet endroit. C’est normal.


Dans un environnement réseau, on surveille et on réglemente ces pratiques.








psn00ps a écrit :



Dans un environnement réseau, on surveille et on réglemente ces pratiques.







<img data-src=" /> Gros flicage de données personnelles… <img data-src=" />



A ma connaissance, c’est le seul à le faire, non ?


Toi, tu ne connais pas OCS et équivalents.








Gilbert_Gosseyn a écrit :



A ma connaissance, c’est le seul à le faire, non ?





Je ne sais pas, je n’utilise que Firefox et un peu Opera Mini…









Gilbert_Gosseyn a écrit :



Toi, tu ne connais pas OCS et équivalents.





J’ai jamais regardé s’il était possible de déployer Firefox via OCS, et surtout en désactivant l’auto update de Firefox (sinon bonjour la consommation de bp)…









Salamandar a écrit :



Comme dossier pour mettre les préférences des logiciels ?

En fait dès qu’un nom de fichier commence par un point “.”, il est caché par les explorateurs de fichiers.

Donc en fait, dans ton dossier utilisateur tu as plein de dossiers

“.mozilla, .cache, .steam, .thunderbird, .gnupg”. Et tu as le dossier .config, où les logiciels peuvent aussi stocker des préférences.

Tu as aussi le dossier .local, mais j’ai jamais compris son intérêt par rapport à .config.







Le dossier .local va avec .config et .cache. Tous les trois, ils permettent d’éviter de transformer ton HOME en poubelle géante avec trois millions de dossier .quelquechose : les données utilisateurs dans .local/share, la configuration des logiciels dans .config, et les données temporaires ou pouvant être facilement recrées / retéléchargées dans .cache.









CryoGen a écrit :



J’ai jamais regardé s’il était possible de déployer Firefox via OCS, et surtout en désactivant l’auto update de Firefox (sinon bonjour la consommation de bp)…







<img data-src=" />

Tu peux gérer de la config Firefox en plaçant un fichier, p.ex. firefox.cfg, à la racine de Firefox, dans lequel tu donnes tes directives de conf :

pour désactiver les updates auto :

lockPref(“app.update.enabled”, false);



Pref = l’utilisateur peut changer les paramètres préconfigurés

lockPref = l’utilisateur ne peut PAS changer les paramètres préconfigurés



Pour que ça marche, il faut rajouter <img data-src=" /> un fichier all.js dans defaults/pref qui contient les 2 lignes suivantes :

pref(“general.config.obscure_value”, 0);

pref(‘general.config.filename’, ‘firefox.cfg’);



<img data-src=" />





edit : PS :

de la même manière, tu peux rerouter Firefox vers un proxy, avec impossibilité pour l’utilisateur de le changer, forcer une page d’accueil, régler la taille du cache etc etc. <img data-src=" />









Gilbert_Gosseyn a écrit :



Toi, tu ne connais pas OCS et équivalents.





OCS en particulier non, je bosse avec (je devrais dire malgré) LanDesk. Pourquoi ?



Il exist Junest (https://github.com/fsquillace/junest ) qui est un gestionnaire de paquet qui utilise la base ArchLinux mais s’installe dans ton home.

Donc ça permet d’avoir tous les paquets de Arch et pacman / yaourt, mais dans son dossier perso.


Hum, c’est à creuser, merci <img data-src=" />








sephirostoy a écrit :



J’ai un soucis avec le cache de Firefox sous Android, quand je visite par exemple la version mobile de NextInpact que j’actualise, je n’ai pas toujours les derniers articles, comme si le cache n’était pas invalidé. Du coup, je dois fermer Firefox et le rouvrir pour avoir la page actualisée.





J’ai remarqué le même souci, en revanche je ne ferme pas le navigateur. Je ferme simplement l’onglet et je l’ouvre de nouveau puis je vois bien les nouveaux articles. &nbsp;J’utilise la version Nightly (48.0a1 en ce moment) sur Android 4.1.2 et c’est encore le cas.









ActionFighter a écrit :



Tu peux toujours te logger avec le compte root en interface graphique si tu penses que la sécurité est une erreur.





&nbsp;Justement, c’est tout le contraire que je préconise. Avec un système de droits bien conçu l’utilisation du root devrait être totalement exceptionnelle. Or il y a clairement trop de tache qui nécessitent les droit root dans l’utilisation desktop d’une distribution GNU/Linux classique, ce qui affaiblit la sécurité.

&nbsp;





lysbleu a écrit :



Le système de dépendance n’oblige à rien. Chrome n’est pas packagé sur Fedora, mais il y est tout à fait installable via un rpm.





Un rpm sur Fedora, plus un deb pour Debian, qui sera peut être ou peut-être pas compatible avec Ubuntu, et je ne parle même pas des distribution plus rares ou des problèmes si on veut plusieurs versions d’un même logiciel. Un développeur ne peut pas gérer toutes les distributions.



Certes tant que l’on reste dans les paquets officiels de sa distribution tout va bien, mais une distribution ne peut pas non plus maintenir a jour le packaging de tous les logiciels existants.







&nbsp;





Uther a écrit :

Un rpm sur Fedora, plus un deb pour Debian, qui sera peut être ou peut-être pas compatible avec Ubuntu, et je ne parle même pas des distribution plus rares ou des problèmes si on veut plusieurs versions d’un même logiciel. Un développeur ne peut pas gérer toutes les distributions.



Certes tant que l’on reste dans les paquets officiels de sa distribution tout va bien, mais une distribution ne peut pas non plus maintenir a jour le packaging de tous les logiciels existants. &nbsp;

&nbsp;Justement, un développeur ne se soucie à peu près jamais de la destribution et du packaging de son logiciel. Tu fais ton code, dans ton Readme tu dis “faites ./configure && make pour compiler avec comme argument le chemin vers le dossier de librairies et le dossier de données (souvent /usr/share/le_logiciel)” et basta.

&nbsp;

Après, c’est bien gentil de dire que “ya plein de distros c’est chiant” mais au fond, elles sont organisées pareil. /usr/bin, /etc pour la config, /usr/share pour les données. Et avec autotools, make install te fait direct l’arborescence de ton logiciel.

Du coup, la création de paquets revient quasi uniquement (d’expérience) à rattraper les erreurs des développeurs.



La seule incompatibilité entre Ubuntu et Debian (comme tu l’as noté) n’est pas due aux paquets eux-mêmes. Elle est due aux imbéciles de maintencurs d’Ubuntu qui ont cru intelligent de prendre le même format de paquets, à peu près les mêmes bases de données, mais EN CHANGEANT LE NOM DES PAQUETS DE LIBRAIRIES. Du coup un paquet Debian ne retrouve plus ses petits. Bon et aussi au fait que Apt-Get, c’est en carton pas solide.








saladiste a écrit :



Gtk2 ou 3, FF reste meilleur que les bouses signées M$, qui au XXIe siècle ne sait toujours pas produire de code portable.





En même temps, si MicroMou faisait du code portable , ça se saurait trés vite&nbsp;&nbsp; …&nbsp;&nbsp; en ont-ils la volonté ?&nbsp;&nbsp; <img data-src=" />









Salamandar a écrit :



Après, c’est bien gentil de dire que “ya plein de distros c’est chiant” mais au fond, elles sont organisées pareil. /usr/bin, /etc pour la config, /usr/share pour les données. Et avec autotools, make install te fait direct l’arborescence de ton logiciel.

Du coup, la création de paquets revient quasi uniquement (d’expérience) à rattraper les erreurs des développeurs.





Certes, c’est pas une tache compliquée pour une distribution de faire un paquet, mais c’est impossible de demander à une distribution de faire tous les paquets de tous les logiciels imaginables et surtout de tous les maintenir.

&nbsp;Et inversement demander a un logiciel de gérer toutes les distributions n’est pas non plus tenable, surtout pour un petit projet. Et la recompilation, ok pour moi. Mais on ne peux pas demander a un utilisateur lambda de faire ça.



Le système de tout intégrer&nbsp; dans la distribution était parfait quand l’écosystème Linux était restreint. Mais maintenant j’ai vraiment l’impression que ça l’empêche de prendre son essor.&nbsp;









doom_Oo7 a écrit :



Il exist Junest (https://github.com/fsquillace/junest ) qui est un gestionnaire de paquet qui utilise la base ArchLinux mais s’installe dans ton home.

Donc ça permet d’avoir tous les paquets de Arch et pacman / yaourt, mais dans son dossier perso.





Merci pour la découverte, je ne connaissais pas.



Après, le besoin reste tout de même particulier. Je me vois mal conseiller ça pour le grand public qui souhaiterai s’affranchir des droits root <img data-src=" />







Uther a écrit :



Justement, c’est tout le contraire que je préconise. Avec un système de droits bien conçu l’utilisation du root devrait être totalement exceptionnelle. Or il y a clairement trop de tache qui nécessitent les droit root dans l’utilisation desktop d’une distribution GNU/Linux classique, ce qui affaiblit la sécurité.





Ok, je l’avais pas compris dans ce sens <img data-src=" />



Personnellement, je n’ai pas l’impression d’avoir besoin de droits d’admin pour des tâches courantes hors installation/mise à jour.



Il faut précompiler ton paquet, mais oui ça peut se faire. Même en multi-site (sur les sites “externes”, il te faut juste un relais avec un simple Apache et rien d’autre).


Comment on passe de x86 à x64 ?


Il te suffit de désinstaller la version 32 et d’installer ensuite la version 64. Ton profil devrait être gardé et utilisé lors du lancement.


&nbsp;







psn00ps a écrit :



Les ClickOnce générés par Visual Studio s’installent à cet endroit. C’est normal.





Je sais. D’ailleurs j’avais déjà trouvé cela bizarre à l’époque où l’on me l’avait fait remarquer dans les commentaires , ici même. Quand on édite des “guidelines” , si c’est pour se torcher avec….<img data-src=" />

&nbsp;

Après, j’ai certainement lut un truc de travers <img data-src=" />









CryoGen a écrit :



Euh, c’est plutôt courant çà…





Un service système pour faire des maj, courant?

A part Flash et Firefox, qui le fait?



Ce n’est pas possible de faire la maj en élévant un processus, avec une alerte UAC qui va bien?

J’imagine que l’objectif c’est d’avoir le navigateur le plus à jour possible contre les failles…. D’ou la maj via cette bidouille.

&nbsp;



Salamandar a écrit :



&nbsp;Comme dossier pour mettre les préférences des logiciels ?

En fait dès qu’un nom de fichier commence par un point “.”, il est caché par les explorateurs de fichiers.

Donc en fait, dans ton dossier utilisateur tu as plein de dossiers

“.mozilla, .cache, .steam, .thunderbird, .gnupg”. Et tu as le dossier .config, où les logiciels peuvent aussi stocker des préférences.

Tu as aussi le dossier .local, mais j’ai jamais compris son intérêt par rapport à .config.&nbsp;





Merci pour ces précisions <img data-src=" />









RaoulC a écrit :



Un service système pour faire des maj, courant?

A part Flash et Firefox, qui le fait?



Ce n’est pas possible de faire la maj en élévant un processus, avec une alerte UAC qui va bien?

J’imagine que l’objectif c’est d’avoir le navigateur le plus à jour possible contre les failles…. D’ou la maj via cette bidouille.

 

Merci pour ces précisions <img data-src=" />







Les antivirus le font. Certains clients VPN et logiciels d’entreprises (déploiements automatisés, pas d’action utilisateur).

En cherchant sur mon pc tout de suite : Google (Google Updater Service, et il y en a plusieurs en plus !!) , Windows Update (bon évidemment…) , Steam (je viens de le découvir), Skype (!!),…