Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Nouveautés dans Focal

[supprimé]

Non mais, arrêtez de prendre les gens pour des cons... tout ce que vous me proposez je l'ai déjà fait dès les premiers désagréments.
J'ai 3 configs matérielles
- Intel core i3-2350m Linux Manjaro 12Go de RAM HDD -> Connexion Filaire
- Intel core i5-7200u Windows 10 et Linux Ubuntu 8Go de Ram SSD -> Wifi AC
- Tablette Android Samsung Galaxy A6 2Go -> Wifi N
Sur les 3 je fais entre 65Mbps et 600 Mbps connexion fibre.
Je n'ai pas besoin de faire de la 4K, ça plante aléatoirement même en 360p !
Sur les 3 configs matérielles je fais du Firefox et du Chrome/Chromium pour les mêmes choses. C'est curieux mais depuis Firefox 68, ça déconne partout avec Firefox aléatoirement sur les vidéos, et pas avec Chrome et Chromium. Ce qui est encore plus curieux, c'est quand je reviens à Firefox 67.0.4 et moins, il n'y a plus aucun lag aléatoire nulle part sur mes 3 configs matérielles.

[supprimé]

Tu as le même problème sur la version 70 de Firefox ?
Sinon essaye la nightly.

[supprimé]

Je viens de basculer en Firefox 70 sur mes installs en Intel 64 bits avec un coup de réparation de Firefox et tiens oh surprise, je viens de me rendre compte que cet idiot avait réactivé l'accélération matérielle de lui même ! :rolleyes:
France info est en live sur un PC, je verrais si l'onglet plante.
Il semble qu'effectivement que la gestion de l'accélération matérielle depuis FF68 soit moins bonne.

GammaDraconis

Absolument pas, arrète de prendre ton cas pour une généralité !
L'accélération matérielle fonctionne parfaitement !

Je viens de faire le test à l'instant en laissant tourner une vidéo en résolution 4K et en plein écran pendant 3H de suite de 16H45 jusqu'a 19H45, celle-ci : https://www.youtube.com/watch?v=lM02vNMRRB0
et aucun soucis à signaler ni aucun bug ni ralentissement.

Firefox 70 par défaut (donc évidemment avec l'accélération matérielle qu'il faut biensûr laissé coché sur n'importe quel pc avec un cpu multicoeur).
J'ai juste l'extension ublock origin d'installé sinon aucune autre extension.
(Attention, si tu as pleins d'extension activé, cela peux ralentir ton navigateur).

Bref tout ça pour dire qu'il n'y aucun soucis de performance sous Firefox.

[supprimé]

Bah tant mieux pour toi, mais le système lui même sait gérer le multi-cœur et alloue à sa convenance les threads.
Toujours est-il qu'en version 67.0.4 avec ces options activées je n'avais aucun lag/bug/freeze et ce quelque soient les conditions matérielles. Ensuite, en désactivant toutes les options d'accélération matérielle, les proces ne chauffent plus à blanc mais j'ai un rendu équivalent.

Christophe C

Tiens, le responsable du bureau (gnome) Ubuntu quitte son poste. Il est remplacé par l'actuel leader d'Ubuntu MATE (Martin Wimpress).

https://www.omgubuntu.co.uk/2019/10/canonical-has-a-new-ubuntu-desktop-director

Je trouve que l'évolution de gnome, surtout dans sa variante Ubuntu, était assez convaincante (même si le contrôle qualité me semble toujours insuffisant). Un leader nouveau-mais-pas-trop c'est une idée intéressante. Ubuntu MATE est assez réussit.

frenchy82

Dans les mauvaises nouvelles il sembles que les dev reflechissent ou du moins n’écartent pas l'idée d'intégrer libreoffice dans sa version snap par défaut dans Ubuntu apres corrections des bugs.
Vu les résultats que j'ai avec chromium, ce n'est pas réjouissant du tout

GammaDraconis

Oui frenchy82, ce que je lis sur le forum anglais (discourse.ubuntu.com) est un peu inquiétant.
Pourtant ce n'est pas faute d'insister mais apparemment ils ne veulent rien savoir, ils ont vraiment l'intention de passer au snap massivement par défaut.

Apparemment, d'après ce que j'ai compris, il n'y a pas de retour en arrière possible, ils veulent vraiment tout miser sur les snaps. La 20.04 devraient être un peu épargné mais je crains qu'au fil des années ils s’engouffrent dans leur snap.

Quand on voit qu'un logiciel aussi basique, facile et léger que la calculatrice de Gnome met plusieurs secondes à se lancer au 1er démarrage de session en snap (problème qui dure depuis le début et qu'ils ne sont jamais arrivé à résoudre), imaginez les applications plus lourde comme LibreOffice...

En faite ils veulent pas admettre que leur technologie ne convient pas, si vous leur dite que c'est lent, ils vont vous dire "aidez nous à corriger", ils ne comprennent pas que ce qu'on veux c'est pas des snaps mais les paquets debian, du moins pour les logiciels de base et ceux facile à installer.

ça ne veux pas dire qu'ils doivent définitivement abandonner les snaps (bien que certains pensent clairement cela) mais ça doit rester juste une alternative comme flatpak.

En parlant de Flatpak, les performances sont meilleur que Snap je trouve, il est juste dommage qu'il y ai plus d'appli en Snap qu'en Flatpak au catalogue alors que Flatpak est meilleur et plus apprécié par la communauté linux.

Cela dit, même des logiciels en Flatpak ne doivent pas être intégré par défaut, ça doit rester une alternative. Fedora l'a bien compris : ils n'imposent aucun Flatpak, tout comme Mint.

Roschan

Que ce soit snap ou flatpak, dans le cas de LibreOffice est-ce que ça n'empêcherait pas d'éditer des documents sur les périphériques externes ?

lykhead

GammaDraconis a écrit...

Cela dit, même des logiciels en Flatpak ne doivent pas être intégré par défaut, ça doit rester une alternative. Fedora l'a bien compris : ils n'imposent aucun Flatpak, tout comme Mint.

alors ceux qui sont intéresser par le sujet tester fedora silverblue et endless OS (debian based)
l'avantage c'est juste que l'on risque moins de bousillé son OS quoi que rpm-ostree et eostree fonctionnent comme dnf et apt si on sait joué avec les sources.list

flatpack et rapide j'ai une difference de 1sec au premier lancement entre 1 paquet rpm et 1 paquet flatpack.

le gros point noir sa oblige a passer sur des disque ssd de très grosse capacité et par l'uefi (oui je ne sais pourquoi mais c'est plus rapide en partition gpt que sous partition dos) et les traductions pas toujours inclusent

je pense que si vraiment Canonical veut pousser les SNAP qu'il le fasse avec la version 20.10 mais pas sur une LTS

lykhead

Roschan a écritQue ce soit snap ou flatpak, dans le cas de LibreOffice est-ce que ça n'empêcherait pas d'éditer des documents sur les périphériques externes ?

ben le flatpack ou le snap se servent de xdg pour savoir ou sont stocker les documents
on peut donné les autorisation par la logithèque
après a voir quel seront les autorisation attribué par défaut

GammaDraconis

Il y a aussi les histoires de droit mais ça a la limite cela peux se modifier, pour moi ce n'est pas ça le plus gros problème mais c'est surtout la lenteur de démarrage :
on est en 2019 avec des SSD ultra-rapide (le miens monte à 3600 Mo/s), on veux des applis ultra rapide à se lancer et c'est le cas avec les paquets Debian.
Si le paquet universel est lent alors c'est une grosse régression qui n'est pas acceptable.

Le 2ème problème des paquets universels et qu'ils prennent beaucoup + de place, certes les espaces de stockage sont beaucoup plus important aujourd'hui mais cet espace supplémentaire cumulé avec tous les logiciels prendrai énormément de place pour un résultat au final mauvais puisque ce n'est même pas performant.

Le principe d'isolation peut être intéressant pour certains logiciels risqués mais l'appliquer de façon systématique à tous les logiciels qu'on utilise est absurde (et pourtant c'est leur objectif).

Les débutants qui n'y connaissent rien ne vont pas chercher longtemps : si leur appli leur parait lente sous Ubuntu alors que c'est rapide ailleurs, ils changeront de distribution.

Roschan

lykhead a écrit
Roschan a écritQue ce soit snap ou flatpak, dans le cas de LibreOffice est-ce que ça n'empêcherait pas d'éditer des documents sur les périphériques externes ?
ben le flatpack ou le snap se servent de xdg pour savoir ou sont stocker les documents
on peut donné les autorisation par la logithèque
après a voir quel seront les autorisation attribué par défaut

"xdg" c'est juste le préfixe pour les standards freedesktop, qui sont plusieurs centaines. Ce qu'une appli peut utiliser c'est le "xdg-document-portal", mais ça atteint très vite ses propres limitations, même avec des applications basiques. La logithèque (ou, plus logiquement, les paramètres système) peuvent parfois modifier les permissions, mais ça ne fait pas disparaître les limitations des implémentations.

lykhead

Roschan a écrit
lykhead a écrit
Roschan a écritQue ce soit snap ou flatpak, dans le cas de LibreOffice est-ce que ça n'empêcherait pas d'éditer des documents sur les périphériques externes ?
ben le flatpack ou le snap se servent de xdg pour savoir ou sont stocker les documents
on peut donné les autorisation par la logithèque
après a voir quel seront les autorisation attribué par défaut
"xdg" c'est juste le préfixe pour les standards freedesktop, qui sont plusieurs centaines. Ce qu'une appli peut utiliser c'est le "xdg-document-portal", mais ça atteint très vite ses propres limitations, même avec des applications basiques. La logithèque (ou, plus logiquement, les paramètres système) peuvent parfois modifier les permissions, mais ça ne fait pas disparaître les limitations des implémentations.

en gros libreoffice n'en ouvrira pas plus que gnome-documents de base
il aura juste accès au répertoire documents de l'utilisateur.

Roschan

Non.

La limitation de GNOME Documents est qu'il récupère une liste de documents via Tracker, ça n'a rien à voir avec Flatpak ni avec les portails freedesktop. Sauf correctif dont je n'aurais pas entendu parler, les fonctionnalités qui pourraient ne pas marcher seraient :

moi, tout à l'heure, mais encore fallait-il me lire a écritéditer des documents sur les périphériques externes

Ainsi que le sous-menu des fichiers récemment utilisés, les extensions ou les thèmes. Vu le micmac que c'est pour lancer une macro, je ne serais pas étonné que ça casse aussi.

[supprimé]

Article intéressant sur les performances de Gnome-Shell : https://discourse.ubuntu.com/t/boosting-the-real-time-performance-of-gnome-shell-3-34-in-ubuntu-19-10/13095

Pour ceux qui ont la flemme de tout lire, ça se résume à ça au niveau des améliorations qui ont été faite et qui seront encore à faire à l'avenir :

17.10 : Gnome Shell arrive dans Ubuntu
18.04LTS : Améliorations mineures du rendement
18.10 : Améliorations mineures des performances
19.04 : Améliorations mineures du rendement
19.10 : Améliorations majeures des performances
20.04LTS : Objectif : Haute performance sur des machines rapides/modernes
20.10 : Objectif : Haute performance sur les machines lentes/anciennes

[supprimé]

Boarf, si Snap continue à être lent, le résultat sera toujours de la part des utilisateurs lambda : "Ubuntu est trop lent !"

JLK

GammaDraconis a écritLes débutants qui n'y connaissent rien ne vont pas chercher longtemps : si leur appli leur parait lente sous Ubuntu alors que c'est rapide ailleurs, ils changeront de distribution.

Ou ils reviendront sur des OS propriétaires. :mad:

TheSun a écritArticle intéressant sur les performances de Gnome-Shell : https://discourse.ubuntu.com/t/boosting-the-real-time-performance-of-gnome-shell-3-34-in-ubuntu-19-10/13095

Pour ceux qui ont la flemme de tout lire, ça se résume à ça au niveau des améliorations qui ont été faite et qui seront encore à faire à l'avenir :

17.10 : Gnome Shell arrive dans Ubuntu
18.04LTS : Améliorations mineures du rendement
18.10 : Améliorations mineures des performances
19.04 : Améliorations mineures du rendement
19.10 : Améliorations majeures des performances
20.04LTS : Objectif : Haute performance sur des machines rapides/modernes
20.10 : Objectif : Haute performance sur les machines lentes/anciennes

Ils feraient mieux d'inverser les objectifs de la 20.04 LTS et de la 20.10 pour limiter l'obsolescence ~~programmée~~ injustifiée. :/ :rolleyes:

Roschan

Sauter une marche pour revenir en arrière donc ?

JLK

Roschan a écritSauter une marche pour revenir en arrière donc ?

Non pour aller devant.

« Page précédente Page suivante »