Reprise du message précédent :

 
Est-ce qu'installer des rpms sur une distribution atomique n'en enlève pas une bonne partie de l'intérêt ? Tu te retrouves dans un état hybride.

Etant donné que Firefox est un RPM également, sans codec, il peut être difficile de visualiser du contenu sur les sites en proposant.

 
Je comprends bien, je me pose juste des questions sur le cas d'usage de ces distributions immuables. J'ai d'ailleurs du mal à cerner le réel public visé, pour certains c'est Mme Michu qui va ainsi éviter de risquer la stabilité du système avec de fausses manips, pour d’autre c'est au contraire un public technique.
 
De toute manière si on ne tripatouille pas le système et qu'on installe quasiment tout via des flatpacks , le risque d'avoir des mauvaises surprises lors de mises à jours ou des montées de versions est vraiment très limité.

mjules tu peux me filer le topic si tu veux

On vote?  
   

non

enfin reprned si tu veux, c'était pour suivre le mouement avec l'update du titre

Non, je vote pour toi  

 
De toute façon, le système conserve toujours deux images en mémoire. Il est possible de revenir en arrière en cas de problème. Concernant la montée de version, j'ai fait la migration 43 > 44 sans souci étant donné que le système de base est minimaliste.

Je me suis lancé, Kinoite 44 installée. Pour l'instant tout se passe bien.
 
Concernant Firefox, la version de base installée ne coimprend pas certains codecs, mais je ne note pour l'instant aucune vidéo réfractaire à être lue. Youtube semble OK. Dans quel contexte peut-on rencontrer ce genre de vidéo ?

Premier problème génant : j'ai un switch HDMI pour utiliser avec le même écran plusieurs PC. Si l'écran n'est pas switché sur le PC avec Kinoite avant le démarrage, lorsque je le fait je me retoruve avec un écran noir et le pointeur de la souris    Obligé de passer en VT et de  rebooter. Je suppose que c'est la même chose avec un boot moniteur éteint.
 
Vous avez la même chose ?

Je viens de passer au kernel 7.0.4 depuis la branche 6.x !

 
Ça a un intérêt dans le monde de l’entreprise quand tu as des postes avec des agents qui ne peuvent plus faire foirer leur poste vu que des que tu redémarres, tout est remis en place.
Pour quelqu’un qui fait bcp de choses avec son PC à la maison et qui aime bidouiller installer ou désinstaller des trucs, ça n’a aucun intérêt.

 
Je suis toujours en phase de test, je veux voir ce que ça donne sur la longueur, mais c'est la conclusion a laquelle je vais arriver je pense.
 
Le principe est génial mais c'est trop contraignant pour un usage standard. Ça impose trop de mises en place de contournements ou de renoncements pour être intéressant au final.

Amha l'intérêt de ces distribs atomiques, c'est la garantie de ne pas se faire baiser par un rootkit. Que ce soit un poste en entreprise ou personnel.
 
Edit: et qu'on soit admin ou pas  

Bah, vu que les mitigations pour Copy Fail ne seront pas propagées dans la 6.19.x [EOL], c'était un move obligatoire pour F43 et F44  

Des webcams dans mon cas.

 
Depuis mon message, je suis effectivement tombé sur des vidéos qui n'étaient pas lisibles. J'ai donc installé la version Flathub de Firefox avec override de la version présente dans l'image de base. La position stricte de Fedora sur les drivers et les codecs est plus impactante sur les déclinaisons atomiques.

YouTube utilise depuis longtemps le codec VP9 dans son format WebM, ce n’est donc pas le site le plus concluant pour faire un test, puisque le VP9 est un format ouvert. De plus, Firefox embarque nativement un codec h.264 fourni par Cisco dans ses plug-ins.
 
Peut-être que ce qui va coincer sera la lecture de fichiers MP3 (typiquement les podcasts audio et les flux tels les webradios ; car les codecs ne concernent pas que la vidéo, mais aussi l’audio), même si les brevets liés à ce format ont tous expiré début 2017 (et n’avaient de toute façon aucune valeur en Europe, les brevets logiciels n’y étant pas reconnus).

Bonjour, petit problème mêlant Dolphin, Samba et Selinux (Fedora 43 KDE, noyau 7.0.10-101.fc43.x86_64)
 
En bref il semble que Dolphin conserve l'étiquette de contexte SElinux du répertoire A source lorsqu'on copie un fichier vers un autre répertoire B.
 
ls dans le Répertoire source A :

 
ls dans le dossier B partagé :

 
En l'occurence le répertoire A est un dossier générique et le répertoire B est un partage SAMBA sur lequel j'avais appliqué les étiquettes idoines :

 
Dans mon cas le Répertoire source A est étiquetté "unlabeled_t" mais si le répertoire source est dans $HOME (étiquetté "user_home_t" ) par exemple, c'est le même problème
 
C'est le comportement attendu ?

Pourquoi le terminal Gnome s'appelle ptyxis et pas gnome-terminal ?

Choix de Fedora et Ubuntu, qui ont préféré un terminal capable de gérer nativement des conteneurs (typiquement ceux de Toolbox) à celui fourni par Gnome (qui avait de toute façon basculé sur KGX en 2021 avec Gnome 42, car conçu d’emblée en GTK4/Libadwaita, alors que gnome-terminal était resté en GTK3).

Non mais moi ça me va le ptyxis, il est bien je trouve. C'est juste sa commande qui est moisie, d'où c'est ptyxis et surtout pourquoi il faut --new-window pour l'ouvrir...

 
Je reviens là dessus, mais avec un /etc ouvert en écriture comme c'est le cas sur toutes les distros atomiques hors Nixos, les arguments sur le côté incassable ou la sécurité sont moins pertinents il m semble. Ca rajoute à ma perplexité face au modèle atomique.

Vraiment pas mal ce que fait Universal Blue, des Fedora versions atomiques avec des images qui contiennent déjà tout ce qu’il faut niveau codecs / pilotes, et la capacité à se créer facilement des images custom (pas encore testé).
J’ai essayé Aurora (Plasma) et là je suis sur Bluefin : c’est opérationnel out of the box, les MAJ sont réalisées en tâche de fond pour l’image, pas de layering.
   
 
C’est des anciens d’Ubuntu qui sont aux manettes.

Fedora c'est plutot à jour ? Bien que sur les forum on lit que c'est très à jour j'ai l'impression que sur certains packages ca peut être à la traine vis à vis d'une Arch par exemple. Exemple : FFMPEG 9.0 sorti il y a 3 jours maintenant , et invisible que ce soit sur rpmfusion ou bohdi. Mais autres exemples : mesa par exemple...
https://archlinux.org/packages/extra/x86_64/ffmpeg/

Fedora n’est pas une vraie rolling release comme Arch : certains paquets restent dans une version donnée jusqu’à la prochaine version de Fedora, surtout quand ça pourrait casser la compatibilité avec d’autres (cas de FFMpeg, qui est au cœur de tous les logiciels de traitement multimédia ; ou de Mesa, aussi).

Arch aussi peut parfois garder quelque temps certains paquets dans une version ancienne sur son canal Stable, pour la même raison : compatibilité cassée avec des dépendances qui doivent aussi être mises à jour en même temps, mais ne sont pas encore toutes prêtes ; ou nécessité de recompiler tous les paquets liés à une dépendance commune, quand celle-ci a une nouvelle version (coucou, Python, Protobuf et GlibC !)…

Et c’est sans parler du fait qu’étant en août, certains mainteneurs sont partis en vacances et ne pourront donc s’occuper de mettre à jour les paquets dont ils sont responsables qu’à leur retour (on a aussi ça, sur Arch, où ces mainteneurs n’ont pas de suppléants pour prendre la relève en attendant).