Pourquoi les snap-packages existent-ils? Y a-t-il un besoin réel?
Hypothèses
Honnêtement, je ne connais pas grand chose aux paquets instantanés - mais ceci n’a aucune pertinence pour cette question - voir ci-dessous. Je suppose que le système est très différent de celui existant.
Le changement a-t-il un sens?
Y a-t-il un besoin réel, assez fort? C'est-à-dire - existe-t-il un nouveau cas d'utilisation suffisamment important pour développer un nouveau format - et l'infrastructure associée?
N’est-il pas possible de modifier la méthode actuelle pour couvrir également les nouveaux cas d’utilisation?
Ou est-ce que je manque le point?
Il est possible que ce que je vois soit principalement du marketing - de nouveaux noms et une présentation pour un changement technique minimal, afin de donner à tout organisme le risque de le croire "nouveau et meilleur" et de l'utiliser effectivement. En outre, il se peut que les nouveaux packages reposent tellement sur le format existant qu'il s'agisse principalement d'un changement de présentation pour l'utilisateur. Cela pourrait être une bonne solution, bien sûr. Dans ce cas, cette question n'aurait pas beaucoup de pertinence.
Ensuite, j'espère que c'est encore assez utile pour répondre aux aspects secondaires. Faites-moi simplement savoir si la question n'est pas utile ou déroutante pour les nouveaux utilisateurs, je suis ravie de la supprimer.
Alors, pourquoi existent-ils?
Contexte
Ma première réaction a été "Cela n'a aucun sens!"
Cela ressemble à une situation où, sur le site de physique, quelqu'un a demandé, malheureux, pourquoi personne ne discute de ses brillantes nouvelles idées en réponse. Cela ressemblait beaucoup à des idées de pot-de-vin; Si loin de la connaissance physique réelle qu'il était difficile de trouver un point de départ même. J'ai écrit une réponse qui ne touchait pas ses idées avec un seul mot, mais j'expliquais pourquoi on ne discutait simplement pas en supposant des idées de pots de fous - pas le premier cas de cela. La réponse était en train de frapper le point, je pense.
Si mes hypothèses étaient correctes, cette affaire est similaire.
Mais alors, peut-être pas - voyons.
Oui, il y a un réel besoin.
Il y avait un réel besoin pour quelque chose comme ça depuis la première fois qu'un logiciel dépendait d'un autre.
Soyons clairs:
La gestion des dépendances est difficile .
Il y a une raison pour laquelle elle s'appelle dépendance enfer . Les systèmes d'empaquetage tels que RPM et Debian ont été créés dans le but d'éviter la dépendance. Cependant, quelqu'un doit payer le coût:
- Sous Windows, où les programmes regroupent leurs dépendances, l'utilisateur doit prendre en charge les mises à niveau (et tout problème de sécurité dû à leur absence). Si je souhaite que la version X veuille quelque chose pour mon application, c'est simple: je la fournis avec mon application. Maintenant, comment gérer les mises à jour?
- Sur la plupart des distributions Linux (après Debian ou Red Hat), où un programme peut dépendre d'un logiciel du référentiel, un programme du référentiel doit dépendre du logiciel du référentiel. Si je veux la version X de quelque chose pour mon application et que la distribution fournit X, c'est simple: j'en dépend. Et si la distribution ne le fait pas? Ensuite: ???
- L'ajout de plusieurs versions à la distribution augmente la charge du mainteneur
- Perdre la possibilité d'utiliser la version de choix des dépendances augmente la charge du développeur
- Perdre la capacité d'utiliser la version de choix des applications frustrent l'utilisateur
Il y a une perte considérable de liberté dans l'une ou l'autre méthode.
Et c’est là que les instantanés entrent en jeu: ils permettent au développeur d’inclure la version X et au système d’emballage de gérer les mises à jour. Qui paie le coût? L'utilisateur:
- en demandant plus d'espace.
- en les exposant à un risque dû à un développeur imprudent, ils ne reconstruisent pas leurs instantanés lorsqu'une dépendance est corrigée.
Quels sont les avantages, en échange?
- Mis à part la sécurité via les mises à jour (qui, franchement, ne préoccupent pas assez les gens), l'utilisateur ne doit pas s'inquiéter des dépendances avec des instantanés. La Parole perd surtout son sens.
- Outre les mises à jour de sécurité, le développeur de logiciels n'a pas à s'inquiéter de demander aux utilisateurs d'installer les dépendances appropriées.
Une fonctionnalité particulière des captures instantanées qui pourrait être utile est la possibilité de choisir un canal pour les développeurs qui fournissent plusieurs canaux, tel que release , candidat , maître , etc.
Par exemple, en cliquant sur le bouton Canal pour nextcloud , la boîte de dialogue ci-dessous apparaît.
Les autres points forts de vente sont l’isolation, l’immutabilité et le sandboxing, contrôlés par un contexte de politique de sécurité , qui permet de définir des autorisations par application, également appelées 'plugs' pour, par exemple:
- emplacements de lecture/écriture
- accès au stockage amovible
- pays où la sélection est sur liste blanche/liste noire
- l'accès au réseau
- appareil photo, imprimante, joystick, localisation GPS
- les paramètres du système
- ... liste complète des interfaces de capture
Cette approche imite dans une certaine mesure les offres groupées d’applications MacOS et le sandboxing d’applications Android avec autorisations et fournisseurs/destinataires de contenu.
Maintenant, imaginez que vous deviez exécuter une douzaine d’applications, chacune avec sa propre version de certaines bibliothèques, sa propre version du moteur d’exécution Python/Ruby/NodeJS et vous ne voudriez pas vous heurter à une dépendance, déranger ou polluer vos bibliothèques système, vos modules système Python/Node/Perl/Ruby, etc.