Cette espace vous permet de voir toutes les Messages réalisées par ce membre. Vous ne pouvez voir que les Messages réalisées dans les espaces auxquels vous avez accès.
Pour voir la différence, j'ai testé flatpak vs snap vs natif sur firefox sous ubuntu 18.04. On pourrait s'imaginer que snap soit avantagé par rapport à flatpak dans de telles conditions.
A la fin on peut aussi voir le temps d'ouverture de chromium en natif vs snap (pas dispo en flatpak...). Et on peut bien voir le temps de lancement largement plus lent. Temps franchement bien perceptible à froid...
De l'ordre de 1 à 2s. Un temps clairement remarquable.
Pour une machine avec disque dur, pas trop pu voir la différence, mais oui je pense que ça doit rester proportionnel, ça doit rester visible.
Après perso toutes mes machines sont full ssd maintenant. Et ce temps est perceptiblement plus long que ça soit sur: i5 6300u i5 4300 Ryzen 2600
J'attends de voir par curiosité ce que ça va donner avec chromium en snap comparé à du deb... Juste par curiosité. Sinon sur internet tu peux voir pas mal de vidéo de comparatif de temps d'ouverture entre snap et installé de base c'est assez flagrant les différences de temps.
EDIT: je viens d'installer chromium dans la ubuntu mate 20.04 beta en vm. Le temps de fou que ça a pris à s'installer.... Le temps de lancement me parait aussi très important. Mais difficile à comparer comme ça... Je vais voir si je peux avoir firefox en snap pour comparer entre l'install de base et le paquet snap...
EDIT2: je viens de faire le test entre firefox dans les dépôts, et firefox snap. Avec la même chose, le même thème, la même page d'accueil, la même extension (ublock) La différence de temps d'ouverture à froid est juste flagrante...
Snap/flatpak sont une bonnes choses quand ils sont utilisés avec parcimonie. En gros pour certains outils peu utilisés ou qu'on veut de récent ça peut être bien. Perso j'utilise des paquet snap pour yakyak (pour hangout) ou pour riot-web.
Mais il y a quand même 2 gros défauts: - la taille de paquets peuvent franchement être conséquente... ALors ok on a de la place (en fait oui et non parce que certaines machines ont toujours 256go de ssd. Et les ssd de 1To restent quand même cher même si plus abordables). Exemple : 2.6go l'émulateur gba en flatpack...
- le temps d'ouverture de l'application spap/flatpack et ce même sur des pcs récents. Si c'est pour une application particulière on peut accepter mais pour une application utilisée couramment comme un navigateur web c'est une plaie! LE temps d'ouverture est perceptible, même sur un ryzen 2600...
-l'intégration avec le bureau et le thème pause parfois problème. Idem pour la langue du bureau mal prise en compte.
- les performances à l'utilisation sont bien souvent inférieures. qu'un paquet natif.
- un deamon snap tourne en arrière plan et son empreinte mémoire n'est pas négligeable. Assez souvent c'est entre 200 et 300mo de plus en mémoire une fois avoir activé snap...
Donc en gros, pour moi ça peut servir quand on veut un truc particulier sur une base assez ancienne, genre si on a une debian stable, ou une LTS en fin de vie, pour avoir un logiciel particulier à jour, c'est une solution acceptable. Exemple j'ai sweethome3d (donc du java etc) en snap, ça ça ne me dérange pas.
Mais pour un logiciel qu'on utilise en continu je trouve ça trop contraignant. Par exemple pour ubuntu LTS 20.04, chromium ne doit plus être fourni comme paquet, mais justement uniquement en snap. Et c'est tout le problème... C'est justement ce qui me fait quitter la distribution, aucune envie de voir une telle perte de perf et un temps d'ouverture si long pour quelque chose que j'utilise tous les jours...
Bref c'est vraiment du cas par cas et pour des points exceptionnels je trouve.
Installation sous gnome à partir de la même iso. Puis maj sans soucis. Comme prévu plus de soucis de dépendance.
les dernières majs ont amélioré le support en vm d'ailleurs. (interface graphique plus fluide).
Par contre l'empreinte mémoire est plus importante que manjaro. Je n'ai pas fait gaffe si snap était actif de base ou pas ce qui pourrait expliquer la grosse différence.
Merci pour l'info. ça a parfaitement fonctionné pour la console.
Pour l'updage je fais bien évidemment zypper dup. Et même à ce jour les dépendances sont toujours pété pour cinnamon.
Donc clairement pas un bureau utilisable sous tumbleweed. IL faut donc que je fasse une réinstall sous gnome3 pour voir si j'arrive à en faire ce que je veux.
Oui je pense que sur leap ça doit être ok, enfin j'ose espérer. (sinon là aussi quel serait l'intéret de proposer un environnement non maintenu sur une version freeze... )
Merci pour l'info, je vais recommencer avec gnome pour voir. Mais du coup j'ai du mal à comprendre le concept de proposer d'autres bureaux s'ils ne sont pas maintenus au final.
Bonjour, comme demandé j'ai créé un topic qui va bien.
Sinon pour opensuse perso je faisais l'upgrade à partir du dvd avant, ça ne fonctionne plus maintenant? Il n'y avait rien de particulier à faire depuis le dvd, juste faire "upgrade". Rien de bien compliqué pour un utilisateur donc.
Tentative de mise à jour à l'instant. Et vlam pb de dépendance par rapport à cinnamon.
Pour l'instant pas embalé par cette rolling release. :/ Je me doute qu'en restant sur gnome ça serait peut-être moins galère sur ce point là vu que là ça semble propre à cinnamon.
Me voilà de retour (non pas pour vous jouer un mauvais tour...) pour essayer un peu OpenSuse. Testant un peu pas mal de distrib, je me suis donc mis à tester OpenSuse tumbleweed en VM.
Pour l'installation j'ai pas mal galéré au niveau du partitionnement. Mon but c'était de chiffrer le "/" comme je l'ai toujours fait. Normalement je mets dans un conteneur LVM mais ça n'a pas fonctionner.
Au final voilà ce que j'ai fais: -Partition de démarrage de bios de 8m - /boot de 1go en FAT - / en brfs chiffré de 50go - Swap de 8go
Une fois installé tout s'est bien passé. Le mot de passe demandé était bien en azerty.
Récemment j'ai donc fais l'upgrade d'openSuse via la fameuse commande zypper dup. L'upgrade est bien passée mais, maintenant au boot, après grub, pour déchiffrer la partition /, le mot de passe doit être saisi en QWERTY.
J'ai regardé dans yast dans la conf du bootloader, je ne vois rien qui précise ça. Tout le reste est bien toujours en FR dans l'interface, seul le mdp au chargement est passé en qwerty.
Auriez vous une idée du pourquoi?
En comparaison j'ai testé sur une manjaro que j'ai installé il y a quelque temps en vm, je n'ai pas ce soucis là, je suis toujours en FR au niveau du boot avec une installation très proche (pas de brfs mais bon le reste est identique).
