| Les deux révisions précédentesRévision précédenteProchaine révision | Révision précédente |
| issue122:mon_opinion [2017/07/07 15:15] – [4] auntiee | issue122:mon_opinion [2017/07/09 08:27] (Version actuelle) – d52fr |
|---|
| Why is installing an automatically and fully updated, properly stable application on Linux not currently possible? Well this is a big problem on the current Linux desktop. There’s an apparently unresolvable dilemma between having stable applications and having up-to-date applications. This arises due to the nature of the Linux desktop’s shared dependency system. If you have fully up-to-date dependencies all the time—i.e., a rolling-release distribution model—you may find that you end up breaking slightly older applications that haven’t been updated upstream to work with the newer dependencies. This means that users are faced with significant bugs which they should never have had to deal with. It’s impossible to test properly for these occasions because, in order to get the updates out as fast as possible, the testing period is very short—which means less time to catch the bugs, and less time to make patches to fix them. You may think that this is possible, but reality has shown that it is not. On pressing those who claim that distributions like Arch, Antergos and Manjaro are stable, you find that actually they have to do various package management and configuration tasks, which an ordinary end-user should not have to do. Further, updates to dependencies on these rolling distributions can break key features of the desktop which should never be broken, not just applications. Antergos broke LightDM for at least a few hours (possibly more if it was a while between when the bug occurred and when the developers filed a blog post on it). If millions were using the Antergos operating system, this would have resulted in a great many unhappy users.** | Why is installing an automatically and fully updated, properly stable application on Linux not currently possible? Well this is a big problem on the current Linux desktop. There’s an apparently unresolvable dilemma between having stable applications and having up-to-date applications. This arises due to the nature of the Linux desktop’s shared dependency system. If you have fully up-to-date dependencies all the time—i.e., a rolling-release distribution model—you may find that you end up breaking slightly older applications that haven’t been updated upstream to work with the newer dependencies. This means that users are faced with significant bugs which they should never have had to deal with. It’s impossible to test properly for these occasions because, in order to get the updates out as fast as possible, the testing period is very short—which means less time to catch the bugs, and less time to make patches to fix them. You may think that this is possible, but reality has shown that it is not. On pressing those who claim that distributions like Arch, Antergos and Manjaro are stable, you find that actually they have to do various package management and configuration tasks, which an ordinary end-user should not have to do. Further, updates to dependencies on these rolling distributions can break key features of the desktop which should never be broken, not just applications. Antergos broke LightDM for at least a few hours (possibly more if it was a while between when the bug occurred and when the developers filed a blog post on it). If millions were using the Antergos operating system, this would have resulted in a great many unhappy users.** |
| |
| 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é à 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 vieux 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 du 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 ===== |
| So how do we get properly up-to-date applications that work without these dependency-related bugs? Well, you allow the developer to bundle the dependency versions that they expect! This means that an update to a dependency does not result in users being left with a broken application; the developer of the application can update the dependencies and their application, ensuring that it still works correctly, in their own time. Snappy adopts this approach. There are still a few shared dependencies like libc, but much less than there were previously.** | So how do we get properly up-to-date applications that work without these dependency-related bugs? Well, you allow the developer to bundle the dependency versions that they expect! This means that an update to a dependency does not result in users being left with a broken application; the developer of the application can update the dependencies and their application, ensuring that it still works correctly, in their own time. Snappy adopts this approach. There are still a few shared dependencies like libc, but much less than there were previously.** |
| |
| Le modèle d'une distribution en publication continue n'est apparemment pas la solution. Quant aux distributions basées sur des versions, elles ont le problème inverse. Elles peuvent être incapable d'installer une application récente, parce qu'elles font confiance et s'attendent à avoir des dépendances récentes qui ne font pas encore partie de la distribution - et elles rencontrent des problèmes ainsi. Si vous mettez à jour la dépendance, vous risquez d'introduire des bogues dans d'autres programmes qui ont la même dépendance et c'est pourquoi les PPA (archives personnelles de paquets) sur Ubuntu, par exemple, peuvent être très risquées et pourquoi les paquets ne sont pas toujours complètement à jour par défaut en premier lieu. | Le modèle d'une distribution en publication continue n'est apparemment pas la solution. Quant aux distributions basées sur des versions, elles ont le problème inverse. Elles peuvent être incapables d'installer une application récente, parce qu'elles font confiance et s'attendent à avoir des dépendances récentes qui ne font pas encore partie de la distribution - et elles rencontrent des problèmes ainsi. Si vous mettez à jour la dépendance, vous risquez d'introduire des bogues dans d'autres programmes qui ont la même dépendance et c'est pourquoi les PPA (archives personnelles de paquets) sur Ubuntu, par exemple, peuvent être très risquées et pourquoi les paquets ne sont pas toujours complètement à jour par défaut en premier lieu. |
| |
| Alors, comment obtenir des applications, mises à jour comme il faut, qui fonctionnent sans les bogues associés aux dépendances ? Eh bien, vous permettez au développeur d'inclure les versions des dépendances attendues ! Cela signifie qu'une dépendance mise à jour ne laisse pas l'utilisateur face à une application cassée ; le développeur de l'application peut, quand il veut, mettre à jour les dépendances et leur application en s'assurant que tout fonctionne très bien. Snappy adopte cette approche. Quelques dépendances partagées restent, notamment libc, mais beaucoup moins que précédemment. | Alors, comment obtenir des applications, mises à jour comme il faut, qui fonctionnent sans les bogues associés aux dépendances ? Eh bien, vous permettez au développeur d'inclure les versions des dépendances attendues ! Cela signifie qu'une dépendance mise à jour ne laisse pas l'utilisateur face à une application cassée ; le développeur de l'application peut, quand il veut, mettre à jour les dépendances et leur application en s'assurant que tout fonctionne très bien. Snappy adopte cette approche. Quelques dépendances partagées restent, notamment libc, mais beaucoup moins que précédemment. |
| 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 à de multiples copies de la même bibliothèque utilisée 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 soit 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 ===== |
| |
| This is our opportunity to solve an old problem with the Linux desktop and drastically improve the usability of that desktop for ordinary computer users. Let’s grasp that opportunity.** | This is our opportunity to solve an old problem with the Linux desktop and drastically improve the usability of that desktop for ordinary computer users. Let’s grasp that opportunity.** |
| |
| Snappy faciliterait les mises à jour normale des applications sur Linux Desktop pour l'utilisateur final et continuera à améliorer l'expérience du bureau de l'utilisateur final au fur et à mesure de la continuation du développement du format. Mais snappy est également excellent pour des développeurs qui écrivent des applications pour Linux Desktop. Ils ne doivent écrire qu'un fichier déclaratif snapcraft.yaml pour faire un snap de leur application et saisir que deux ou trois commandes (ou même faire deux clics) pour qu'il soit publié sur le snappy store et, donc, publié sur chaque installation de Linux avec snappy, sans empaqueteur intermédiaire. Malgré la possibilité d'omettre l'empaqueteur intermédiaire, des gens, comme moi, qui ne sont pas des programmeurs, peuvent s'impliquer en aidant les développeurs en amont en créant des fichiers snapcraft.yaml qu'ils peuvent adopter. Il suffit de suivre le tutoriel de snapcraft (le nom de l'outil qui crée des snaps),, le terminer (20 minutes), puis, si cela vous tente, aller faire d'autres tutoriels snapcraft (comme pour Python et des sites Web), trouver un programme qui n'a pas encore été « snappé » et snapper, puis envoyer le snapcraft.yaml fonctionnel au développeur pour qu'il puisse lui-même l'utiliser. Si vous rencontrez des problèmes en chemin, vous pouvez lire la documentation de snapcraft et vous pouvez poser des questions à la communauté amicale de snapcraft sur les forums Rocket Chat et Stack Overflox. | Snappy facilite les mises à jour normale des applications sur Linux Desktop pour l'utilisateur final et continuera à améliorer l'expérience du bureau de l'utilisateur final au fur et à mesure de la continuation du développement du format. Mais snappy est également excellent pour des développeurs qui écrivent des applications pour Linux Desktop. Ils ne doivent écrire qu'un fichier déclaratif snapcraft.yaml pour faire un snap de leur application et ne saisir que deux ou trois commandes (ou même faire deux clics) pour qu'il soit publié sur le snappy store et, donc, publié sur chaque installation de Linux avec snappy, sans empaqueteur intermédiaire. Malgré la possibilité d'omettre l'empaqueteur intermédiaire, des gens, comme moi, qui ne sont pas des programmeurs, peuvent s'impliquer en aidant les développeurs en amont en créant des fichiers snapcraft.yaml qu'ils peuvent adopter. Il suffit de suivre le tutoriel de snapcraft (le nom de l'outil qui crée des snaps), le terminer (20 minutes), puis, si cela vous tente, aller faire d'autres tutoriels snapcraft (comme pour Python et des sites Web), trouver un programme qui n'a pas encore été « snappé » et snapper, puis envoyer le snapcraft.yaml fonctionnel au développeur pour qu'il puisse lui-même l'utiliser. Si vous rencontrez des problèmes en chemin, vous pouvez lire la documentation de snapcraft et vous pouvez poser des questions à la communauté amicale de snapcraft sur les forums Rocket Chat et Stack Overflox. |
| |
| C'est l'occasion de résoudre un vieux problème sur le Linux desktop et d'améliorer considérablement la facilité d'utilisation de ce bureau pour les utilisateurs ordinaires d'ordinateurs. Saisissons cette pportunité ! | C'est l'occasion de résoudre un vieux problème sur le Linux desktop et d'améliorer considérablement la facilité d'utilisation de ce bureau pour les utilisateurs ordinaires d'ordinateurs. Saisissons cette opportunité ! |
| |
