| Les deux révisions précédentesRévision précédente | |
| issue122:mon_opinion [2017/07/08 16:52] – andre_domenech | issue122:mon_opinion [2017/07/09 08:27] (Version actuelle) – d52fr |
|---|
| Snappy vous permet d'installer une application stable, complètement et automatiquement mise à jour, sur n'importe quelle distribution qui le prend en charge : notamment, à ce jour, Ubuntu, Fedora, Arch, Debian, open SUSE et Gentoo. Les applications Snappy peuvent même être installées à partir du Centre de logiciels graphique, si le centre le prend en charge. | Snappy vous permet d'installer une application stable, complètement et automatiquement mise à jour, sur n'importe quelle distribution qui le prend en charge : notamment, à ce jour, Ubuntu, Fedora, Arch, Debian, open SUSE et Gentoo. Les applications Snappy peuvent même être installées à partir du Centre de logiciels graphique, si le centre le prend en charge. |
| |
| Pourquoi l'installation d'une application stable, complètement et automatiquement mise à jour, sur Linux n'est-elle pas possible ? Eh bien, c'est un grand problème sur l'ordinateur de bureau Linux actuel. Il y a, apparemment, un dilemme sans issue entre avoir des applications stables et avoir des applications à jour. Ceci est dû à la nature du système de dépendances partagées du bureau Linux. Si vos dépendances sont toujours entièrement à jour, ce qui est le cas d'une distribution à publication continue, vous pourriez finir par casser des applications un peu plus vieilles qui n'ont pas été mises à jour en amont pour qu'elles fonctionnent avec les nouvelles dépendances. Cela signifie que les utilisateurs rencontrent des bogues importants qu'il faut traiter, ce qu'ils n'auraient jamais dû avoir à faire. C'est impossible de tester pour cela comme il faut, car, afin de pouvoir sortir les mises à jour aussi rapidement que possible, la période de test est très courte, ce qui signifie moins de temps pour se rendre compte des bogues et moins de temps pour faire des correctifs. Ça peut vous sembler possible, mais la réalité montre le contraire. Si vous insistez auprès de gens qui prétendent que des distributions comme Arch, Antergos et Manjaro sont stables, vous trouverez qu'ils sont en fait obligés de faire des tâches diverses de gestion et configuration de paquets, des tâches auxquelles un utilisateur final lambda ne devrait pas être confronté. Qui plus est, des mises à jour des dépendances sur ces distributions en publication continue peuvent casser des fonctionnalités importantes du bureau qui ne devraient jamais être cassées, et pas seulement des applications. Antergos a cassé LightDM pendant au moins quelques heures (et sans doute davantage, si c'était entre le survenu entre le bogue et le moment où les développeurs ont sorti un billet de blog le concernant). Si des millions d'individus étaient en train d'utiliser le système d'exploitation Antergos, le résultat en aurait été de très très nombreux utilisateurs malheureux. | Pourquoi l'installation d'une application stable, complètement et automatiquement mise à jour, sur Linux n'est-elle pas possible ? Eh bien, c'est un grand problème sur l'ordinateur de bureau Linux actuel. Il y a, apparemment, un dilemme sans issue entre avoir des applications stables et avoir des applications à jour. Ceci est dû à la nature du système de dépendances partagées du bureau Linux. Si vos dépendances sont toujours entièrement à jour, ce qui est le cas d'une distribution à publication continue, vous pourriez finir par casser des applications un peu plus vieilles qui n'ont pas été mises à jour en amont pour qu'elles fonctionnent avec les nouvelles dépendances. Cela signifie que les utilisateurs rencontrent des bogues importants qu'il faut traiter, ce qu'ils n'auraient jamais dû avoir à faire. C'est impossible de tester pour cela comme il faut, car, afin de pouvoir sortir les mises à jour aussi rapidement que possible, la période de test est très courte, ce qui signifie moins de temps pour se rendre compte des bogues et moins de temps pour faire des correctifs. Ça peut vous sembler possible, mais la réalité montre le contraire. Si vous insistez auprès de gens qui prétendent que des distributions comme Arch, Antergos et Manjaro sont stables, vous trouverez qu'ils sont en fait obligés de faire des tâches diverses de gestion et configuration de paquets, des tâches auxquelles un utilisateur final lambda ne devrait pas être confronté. Qui plus est, des mises à jour des dépendances sur ces distributions en publication continue peuvent casser des fonctionnalités importantes du bureau qui ne devraient jamais être cassées, et pas seulement des applications. Antergos a cassé LightDM pendant au moins quelques heures (et sans doute davantage, si c'était survenu entre le bogue et le moment où les développeurs ont sorti un billet de blog le concernant). Si des millions d'individus étaient en train d'utiliser le système d'exploitation Antergos, le résultat en aurait été de très très nombreux utilisateurs malheureux. |
| |
| ===== 2 ===== | ===== 2 ===== |
| There’s another big advantage of snappy that makes it worth using: background updates happen without a prompt, like in ChromeOS, so there is less user interaction and users can just get on with using their operating system. Could this mean that an update breaks the app without the user’s permission? Perhaps, but this is less likely because there’s few shared dependencies and updates can be rolled back if necessary. Perhaps this seems insecure? But the applications are confined, they don’t have access to your whole system (they can if they need to – if they use classic confinement, but these snaps are manually reviewed before entering the snappy store), so this is not really a problem. Indeed, the confinement of snaps is itself another reason why snappy is great. They’re confined Android-style, they have access to only certain parts of the system, not the entire filesystem like with Linux applications packaged traditionally. Programs that really need to access the filesystem, like code editors, can do so, this is called Classic confinement, but the vast majority of snappy applications are confined properly.** | There’s another big advantage of snappy that makes it worth using: background updates happen without a prompt, like in ChromeOS, so there is less user interaction and users can just get on with using their operating system. Could this mean that an update breaks the app without the user’s permission? Perhaps, but this is less likely because there’s few shared dependencies and updates can be rolled back if necessary. Perhaps this seems insecure? But the applications are confined, they don’t have access to your whole system (they can if they need to – if they use classic confinement, but these snaps are manually reviewed before entering the snappy store), so this is not really a problem. Indeed, the confinement of snaps is itself another reason why snappy is great. They’re confined Android-style, they have access to only certain parts of the system, not the entire filesystem like with Linux applications packaged traditionally. Programs that really need to access the filesystem, like code editors, can do so, this is called Classic confinement, but the vast majority of snappy applications are confined properly.** |
| |
| C'est à ce stade que les gens se plaignent de la taille du fichier. Il est vrai que la taille du fichier augmente, parce qu'il y a de multiples copies de la même bibliothèque utilisées sur le système d'exploitation. C'est sans doute cela le seul inconvénient de Snappy, mais il y a plusieurs raisons pour lesquelles ce problème n'est pas aussi important qu'il peut paraître. Tout d'abord, avec les mises à jour delta (uniquement les changements), une fois qu'un snap est installé, l'ordinateur ne télécharge qu'une petite quantité de données pour mettre le snap à jour. Deuxièmement, la taille du fichier d'un snap individuel peut être réduite en enlevant les fonctionnalités inutiles des dépendances, comme Peek fait avec ffmpeg et imagemagick. Troisièmement, de nos jours, les ordinateurs de bureau ou portables ont généralement beaucoup d'espace disque et la grande taille d'un fichier n'est pas souvent un problème. Enfin, il y a un précédent pour cette façon de gérer les paquets : Android, par exemple, a de nombreux fichiers Jar en double et même macOS et Windows, dans une moindre mesure. | C'est à ce stade que les gens se plaignent de la taille du fichier. Il est vrai que la taille du fichier augmente, parce qu'il y a de multiples copies de la même bibliothèque utilisées sur le système d'exploitation. C'est sans doute cela le seul inconvénient de Snappy, mais il y a plusieurs raisons pour lesquelles ce problème n'est pas aussi important qu'il peut paraître. Tout d'abord, avec les mises à jour delta (uniquement les changements), une fois qu'un snap est installé, l'ordinateur ne télécharge qu'une petite quantité de données pour mettre le snap à jour. Deuxièmement, la taille du fichier d'un snap individuel peut être réduite en enlevant les fonctionnalités inutiles des dépendances, comme Peek fait avec ffmpeg et imagemagick. Troisièmement, de nos jours, les ordinateurs de bureau ou portables ont généralement beaucoup d'espace disque et la grande taille d'un fichier n'est souvent pas un problème. Enfin, il y a un précédent pour cette façon de gérer les paquets : Android, par exemple, a de nombreux fichiers Jar en double et même macOS et Windows, dans une moindre mesure. |
| | |
| | Cela vaut la peine d'utiliser snappy à cause d'un autre grand avantage : les mises à jour en arrière-plan ont lieu sans une invite, comme sous Chrome OS, et il y a donc moins d'interaction utilisateurs et les utilisateurs peuvent tout simplement continuer à utiliser leur système. Serait-il possible de casser une app avec une mise à jour faite sans la permission de l'utilisateur ? Peut-être, mais c'est moins probable parce qu'il n'y a que très peu de dépendances partagées et vous pouvez désinstaller les mises à jour au besoin. Le côté sécurité vous inquiète ? Mais les applications sont confinées et ne peuvent pas accéder à votre système entier (elles peuvent le faire au besoin, si elles utilisent le confinement classique, mais ces snaps-là sont évalué manuellement avant d'arriver dans le snappy store) ; ainsi, ce n'est pas vraiment un problème. En effet, le confinement des snaps contribue lui-même à la magnificence de snappy. Ils sont confinés comme dans Android et ne peuvent accéder qu'à certaines parties du système, pas à tout le système de fichiers, comme les applications Linux empaquetées de façon traditionnelle. Les programmes qui ont vraiment besoin d'accéder au système de fichiers, comme les éditeurs de code, peuvent le faire - cela s'appelle le Confinement classique -, mais la grande majorité des applications snappy sont confinés comme il faut. |
| |
| Cela vaut la peine d'utiliser snappy à cause d'un autre grand avantage : les mises à jour en arrière-plan ont lieu sans une invite, comme sous Chrome OS, et il y a donc moins d'interaction utilisateurs, les utilisateurs peuvent tout simplement continuer à utiliser leur système. Serait-il possible de casser une app avec une mise à jour faite sans la permission de l'utilisateur ? Peut-être, mais c'est moins probable parce qu'il n'y a que très peu de dépendances partagées et vous pouvez désinstaller les mises à jour au besoin. Le côté sécurité vous inquiète ? Mais les applications sont confinées et ne peuvent pas accéder à votre système entier (elles peuvent le faire au besoin, si elles utilisent le confinement classique, mais ces snaps-là sont évalué manuellement avant d'arriver dans le snappy store) ; ainsi, ce n'est pas vraiment un problème. En effet, le confinement des snaps contribue lui-même à la magnificence de snappy. Ils sont confinés comme dans Android et ne peuvent accéder qu'à certaines parties du système, pas à tout le système de fichiers, comme les applications Linux empaquetées de façon traditionnelle. Les programmes qui ont vraiment besoin d'accéder au système de fichiers, comme les éditeurs de code, peuvent le faire - cela s'appelle le Confinement classique -, mais la grande majorité des applications snappy sont confinés comme il faut. | |
| ===== 4 ===== | ===== 4 ===== |
| |
