ya de quoi se demander si tout le monde a réussi à installer Debian :D (Ubuntu étant un ancien mot africain signifiant « je n'ai pas réussi à installer Debian »).
Bref, ouais les SNAP spa la joie… dommage de ne pas libérer le service (en AGPL spa compliqué…) outre que c'est encore du NIH vu que flatpak est clairement plus pratique.
c'est encore du NIH vu que flatpak est clairement plus pratique.
Snap et Flatpak sont deux technologies similaires, mais qui répondent à des problèmes différents.
Ubuntu est (du moins en terme de financement) une distribution pour serveurs, et la version bureau sert à là fois de vitrine et de banc d’essai pour améliorer la version serveur.
Si Canonical n’adopte pas Flatpak au lieu de Snap, c’est que c’est complètement inadapté à une utilisation sur serveur, vu que ça ne supporte que les applications graphiques. Flatpak ne peux pas empaqueter un daemon, un noyau ou un outil en ligne de commande, Snap si.
Posté par Misc (site web personnel) .
Évalué à 8 (+5/-0).
Dernière modification le 20 juillet 2026 à 21:53.
Mais en même temps, en étant les seuls à adopter snap, écosystème autour me semble assez limité. Je comprends le point de vue de Canonical de vouloir essayer de se distinguer de la concurrence et de fournir des choses en plus (en l’occurrence, snap), mais ça me semble non adapté pour les usages serveurs vu que c'est un endroit ou les utilisateurs veulent quelque chose de standard avant tout (en l’occurrence, Docker et le format OCI, et tout écosystème à coté).
Pour moi, Canonical tente d'adapter les mécanismes de la vente sur le desktop pour particulier (à savoir se distinguer via une feature exclusive) aux serveurs, et ça n'as pas l'air de marcher.
Après je ne dis pas que c’est une stratégie gagnante, seulement que les remarques récurrentes (pas uniquement sur LinuxFR) du style "ils devraient utiliser Flatpak, qui est mieux que Snap" ne comprennent pas ce que Canonical vise avec Snap.
Posté par BAud (site web personnel) .
Évalué à 3 (+1/-0).
Dernière modification le 20 juillet 2026 à 22:48.
les remarques récurrentes (pas uniquement sur LinuxFR) du style "ils devraient utiliser Flatpak, qui est mieux que Snap" ne comprennent pas ce que Canonical vise avec Snap.
Peut-être bien qu'ils l'expliquent mal ;-) (tu aurais une URL qui en parle plus longuement ?) et à quand un serveur snap déployable facilement en entreprise si c'est si bienTM avec une licence correcte si possible ?
Outre que la distinction Desktop / serveur a peu de sens sous Linux, hormis quelques optimisations noyau et système de fichier plutôt dédiés serveur, ce que je n'ai que peu vu mis en avant par Canonical…
Le backend est propriétaire. Cette raison est suffisante pour ne pas considérer Snap comme une solution généralisable dans le monde libre. En tout cas, tant que quelqu'un ne fait pas une implémentation libre indépendante et que le client snap n'a pas la possibilité de pointer vers d'autres fournisseurs (je suppose que c'est le cas - de toute façon il n'y a pas d'autres fournisseurs à priori !).
Mais Google/Apple vise pas les serveurs avec leur magasin d'application. Même Google te permet d'avoir des bouts de cloud chez toi via Anthos, ou Thales via S3NS.
J'entends bien les arguments sur SNAP et le flou par rapport à l'IA, mais il y a un autre argument qui me fait tiquer :
la lenteur des correctifs : TUXEDO pointe également du doigt des délais de déploiement parfois trop longs pour certaines mises à jour de sécurité critiques au sein des dépôts d’Ubuntu.
Combien paye TUXEDO pour avoir une distribution sécurisée rapidement ? Peut-être le font-ils, je ne sais pas, mais ils devraient peut-être verser un peu plus pour avoir ces mises à jour rapidement non ? Parfois j'entends certains râler pour les délais e correction de failles de sécurité sur des logiciels libres et dispo gratuitment, mais ces gens se plaignent alors qu'ils ne paient même pas, d'ou mon interrogation à propos de Tuxedo.
Canonical pourrait cibler du B2B spécifiquement pour les entreprises qui créent des dérivés d'Ubuntu.
Pour effectivement mieux maintenir les paquets de base, ceux que par exemple TUXEDO ne modifiait pas (l'article explique que TUXEDO ne modifiait que KDE, Qt, et certaines dépendances qui viennent avec).
Les équipes qui travaillent sur la sécurité chez Canonical sont clairement en sous capacité.
À mon travail, on paye des licences Ubuntu Pro (c'est pas hyper cher mais bon, on paye), et les correctifs sur les failles type copyfail, ptrace, etc… ont été très longues à livrer. Je parle de plusieurs semaines quand d'autres distribs ont livré les correctifs en quelques heures, ou moins de 2 jours.
Donc on a le service de livepatch du noyau, mais Canonical n'a pas livré de patch. On a les dépôts ESM pour avoir les mises à jour plus vite, mais pas de correctif dispo non plus.
Certes, il y a de l'assurance qualité, mais c'est beaucoup trop long et franchement pas transparent.
La dernière faille en date, Januscape, n'est pas corrigée alors que les distribs majeures sont au courant depuis longtemps (fin juin à priori)…
Chez Ubuntu (vous savez, cette entreprise montée par un milliardaire), le travail est annoncé comme en cours depuis le 9 juillet : CVE-2026-53359.
Chez Debian (vous savez, ce petit projet communautaire qui a un contrat social), le correctif a été livré le 5 juillet : DSA 6381-1.
# Eh ben
Posté par Luc-Skywalker . Évalué à 4 (+2/-0).
Je comprends leur point de vue (les SNAP, les incantations parfois obscures du boss …), mais ils adoptent une voie radicale et très ambitieuse.
Bonne chance à eux (déjà que c'est pas facile en raison de la crise des composants)
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: Eh ben
Posté par BAud (site web personnel) . Évalué à 8 (+6/-0).
en même temps quand tu vois que la section Ubuntu de LinuxFr.org est délaissée depuis juin 2025
https://linuxfr.org/sections/ubuntu
ya de quoi se demander si tout le monde a réussi à installer Debian :D (Ubuntu étant un ancien mot africain signifiant « je n'ai pas réussi à installer Debian »).
Bref, ouais les SNAP spa la joie… dommage de ne pas libérer le service (en AGPL spa compliqué…) outre que c'est encore du NIH vu que flatpak est clairement plus pratique.
[^] # Re: Eh ben
Posté par ChetManley . Évalué à 7 (+6/-0).
Snap et Flatpak sont deux technologies similaires, mais qui répondent à des problèmes différents.
Ubuntu est (du moins en terme de financement) une distribution pour serveurs, et la version bureau sert à là fois de vitrine et de banc d’essai pour améliorer la version serveur.
Si Canonical n’adopte pas Flatpak au lieu de Snap, c’est que c’est complètement inadapté à une utilisation sur serveur, vu que ça ne supporte que les applications graphiques. Flatpak ne peux pas empaqueter un daemon, un noyau ou un outil en ligne de commande, Snap si.
[^] # Re: Eh ben
Posté par Misc (site web personnel) . Évalué à 8 (+5/-0). Dernière modification le 20 juillet 2026 à 21:53.
Mais en même temps, en étant les seuls à adopter snap, écosystème autour me semble assez limité. Je comprends le point de vue de Canonical de vouloir essayer de se distinguer de la concurrence et de fournir des choses en plus (en l’occurrence, snap), mais ça me semble non adapté pour les usages serveurs vu que c'est un endroit ou les utilisateurs veulent quelque chose de standard avant tout (en l’occurrence, Docker et le format OCI, et tout écosystème à coté).
Pour moi, Canonical tente d'adapter les mécanismes de la vente sur le desktop pour particulier (à savoir se distinguer via une feature exclusive) aux serveurs, et ça n'as pas l'air de marcher.
[^] # Re: Eh ben
Posté par ChetManley . Évalué à 7 (+6/-0).
Après je ne dis pas que c’est une stratégie gagnante, seulement que les remarques récurrentes (pas uniquement sur LinuxFR) du style "ils devraient utiliser Flatpak, qui est mieux que Snap" ne comprennent pas ce que Canonical vise avec Snap.
[^] # Re: Eh ben
Posté par BAud (site web personnel) . Évalué à 3 (+1/-0). Dernière modification le 20 juillet 2026 à 22:48.
Peut-être bien qu'ils l'expliquent mal ;-) (tu aurais une URL qui en parle plus longuement ?) et à quand un serveur snap déployable facilement en entreprise si c'est si bienTM avec une licence correcte si possible ?
Outre que la distinction Desktop / serveur a peu de sens sous Linux, hormis quelques optimisations noyau et système de fichier plutôt dédiés serveur, ce que je n'ai que peu vu mis en avant par Canonical…
[^] # Re: Eh ben
Posté par Misc (site web personnel) . Évalué à 3 (+0/-0).
snapd est dispo, sous license GPL v3.
Et si la distinction a peu de sens, n'hésite pas à installer une linux mint avec ton serveur oracle :p
[^] # Re: Eh ben
Posté par raphj (site web personnel) . Évalué à 5 (+4/-1). Dernière modification le 21 juillet 2026 à 11:30.
snapd, c'est le daemon qui tourne côté utilisateurice.
Le backend est propriétaire. Cette raison est suffisante pour ne pas considérer Snap comme une solution généralisable dans le monde libre. En tout cas, tant que quelqu'un ne fait pas une implémentation libre indépendante et que le client snap n'a pas la possibilité de pointer vers d'autres fournisseurs (je suppose que c'est le cas - de toute façon il n'y a pas d'autres fournisseurs à priori !).
Ça correspond à l'anti-fonctionnalité Services de réseau non-libres de F-Droid.
[^] # Re: Eh ben
Posté par Misc (site web personnel) . Évalué à 3 (+0/-0).
Ah bah, j'imaginais même pas que quelqu'un se dise que ça serait une bonne idée que de ne pas permettre d'avoir son propre dépôt chez soi.
[^] # Re: Eh ben
Posté par raphj (site web personnel) . Évalué à 5 (+3/-0).
Google et Apple s'imaginent ce genre de choses… :-)
[^] # Re: Eh ben
Posté par Misc (site web personnel) . Évalué à 3 (+0/-0).
Mais Google/Apple vise pas les serveurs avec leur magasin d'application. Même Google te permet d'avoir des bouts de cloud chez toi via Anthos, ou Thales via S3NS.
[^] # Re: Eh ben
Posté par devnewton 🍺 (site web personnel) . Évalué à 5 (+2/-0).
J'en étais resté à :
Ça a évolué ?
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: Eh ben
Posté par raphj (site web personnel) . Évalué à 3 (+1/-0).
Pour Snap, non (https://launchpad.net/snapstore-server affiche toujours « Other/Proprietary (Canonical proprietary) »).
[^] # Re: Eh ben
Posté par ff9097 . Évalué à 3 (+1/-0).
snap c'est nul et privateur. flatpak c'est quand même un peu moins nul
# en même temps ....
Posté par totof2000 . Évalué à 3 (+3/-2).
J'entends bien les arguments sur SNAP et le flou par rapport à l'IA, mais il y a un autre argument qui me fait tiquer :
Combien paye TUXEDO pour avoir une distribution sécurisée rapidement ? Peut-être le font-ils, je ne sais pas, mais ils devraient peut-être verser un peu plus pour avoir ces mises à jour rapidement non ? Parfois j'entends certains râler pour les délais e correction de failles de sécurité sur des logiciels libres et dispo gratuitment, mais ces gens se plaignent alors qu'ils ne paient même pas, d'ou mon interrogation à propos de Tuxedo.
[^] # Re: en même temps ....
Posté par Sébastien Wilmet (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
Canonical pourrait cibler du B2B spécifiquement pour les entreprises qui créent des dérivés d'Ubuntu.
Pour effectivement mieux maintenir les paquets de base, ceux que par exemple TUXEDO ne modifiait pas (l'article explique que TUXEDO ne modifiait que KDE, Qt, et certaines dépendances qui viennent avec).
[^] # Re: en même temps ....
Posté par cg . Évalué à 8 (+6/-0).
Les équipes qui travaillent sur la sécurité chez Canonical sont clairement en sous capacité.
À mon travail, on paye des licences Ubuntu Pro (c'est pas hyper cher mais bon, on paye), et les correctifs sur les failles type copyfail, ptrace, etc… ont été très longues à livrer. Je parle de plusieurs semaines quand d'autres distribs ont livré les correctifs en quelques heures, ou moins de 2 jours.
Donc on a le service de livepatch du noyau, mais Canonical n'a pas livré de patch. On a les dépôts ESM pour avoir les mises à jour plus vite, mais pas de correctif dispo non plus.
Certes, il y a de l'assurance qualité, mais c'est beaucoup trop long et franchement pas transparent.
La dernière faille en date, Januscape, n'est pas corrigée alors que les distribs majeures sont au courant depuis longtemps (fin juin à priori)…
Chez Ubuntu (vous savez, cette entreprise montée par un milliardaire), le travail est annoncé comme en cours depuis le 9 juillet : CVE-2026-53359.
Chez Debian (vous savez, ce petit projet communautaire qui a un contrat social), le correctif a été livré le 5 juillet : DSA 6381-1.
Voir aussi cet article technique de blog1 de mon employeur, qui raconte comment plusieurs milliers de serveurs ont été patché très rapidement : https://blog.ovhcloud.com/fr/posts/cve-2026-53359-kvm-patching-lessons-learned/
qui fait aussi office de publicité et de communiqué de presse ↩
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.