[…] dnf's API available for application via DBus calls […] This makes it easy to do packaging action from your application no matter what language it is written in, as long as there is DBus binding for it.
Euh .. un démon avec une api réseau juste pour ça ? Avec du dbus, policykit and co ? On ne marcherait pas sur la tête là ? Ou quelque chose m'échappe …
Ou les applications qui veulent offrir une interface au bon endroit. Par exemple, les plugins gimp qui sont sous formes de paquets, ou les codecs vidéos non disponibles de base et que tu voudrait installer à la demande car ç'est plus léger. Les firmwares/drivers de matériels en tout genre, comme les drivers d'imprimantes, via un popup quand tu branches l'imprimante.
Les alternatives sont "tout mettre sur le disque" comme sur Mac. Ou laisser les gens taper des commandes ou devoir changer de contexte comme avant.
Parce que bon, savoir que le driver pour un imprimante Acme InkShot 34FZE est dans le paquet "driver-acme-printer-2018", ça me semble non évident.
Il y a aussi une question de sécurité, on dit sans arrêt "faut réduire la surface utilisable". Surprise, avoir une installation facile à la demande, ça aide à ce niveau.
Peut-être entre les distributions RPM mais je n'y crois pas trop.
En effet, on a déjà PackageKit qui fait exactement ça : une abstraction pour que chaque gestionnaire de paquets puisse fournir son implémentation dédiée, un démon, une API DBus et une gestion de droits via Polkit… Mais l'intégration de PackageKit dans les distributions s'est fait dans la douleur et sur de (très) nombreuses années. Et je vois souvent des utilisateurs conseiller aux nouveaux de ne pas utiliser Discover (chez KDE) ou Software (chez GNOME)… C'est pour ça que je ne crois pas trop à un nouvel effort de standardisation entre les gestionnaires de paquets. Et d'ailleurs, PackageKit n'est plus sensé évoluer.
Du coup on lie les applis à un gestionnaire de paquet … ça me
paraît un peu douteuse comme approche.
Sinon, il y a packagekit, qui faisait exactement ça. Mais de toute façon, les applis vont être liés au nommage des paquets d'une façon ou d'une autre, et les efforts d'uniformisation avant d'avoir le code, ça ne marche pas.
Ensuite, il y a pas trop de choix. Soit tu fais un truc qui valide l'approche pour 1 gestionnaire de paquet avant d'essayer de convaincre le reste du monde (ce qui est fait en ce moment), soit tu fait un truc qui a pour vocation d'aller partout (et je pense que vu la violence des réactions sur systemd, personne ne va tenter ça), soit tu fais rien.
Si l'approche est bonne et apporte un plus pour la distribution, le code est libre, quelqu'un de motivé l'adapteras.
Puis pour ce qui est de réduire la surface d'attaque … un
demon qui tourne en permanence c peut-être pas une bonne idée.
Par rapport à un demon qui va se lancer à la demande ? Par rapport à ne pas avoir de demon, donc lancer un shell complet avec des droits étendus au lieu d'un logiciel qu'on peut confiner un peu plus ?
La surface d'attaque, elle va pas venir du fait que ça tourne tout le temps, mais des possibilités d'interactions. Et je pense que remplacer un shell root par un demon, c'est une bonne base pour permettre plus de sécurisation.
Sinon, il y a packagekit, qui faisait exactement ça. Mais de toute façon, les applis vont être liés au nommage des paquets d'une façon ou d'une autre, et les efforts d'uniformisation avant d'avoir le code, ça ne marche pas.
Si tu veux créer un tray icon qui indique les installations en cours, la disponibilité de mises à jour,… Tu n'en a pas besoin.
Je partage ton avis … j'ai un truc qui tourne sur Ubuntu pour contrôler la présence de mise à jour et il me prend parfois 100% de cpu. Certes aujourd'hui sur un pc avec 8 coeurs, je ne m'en rend plus trop compte, mais quand j'étais sur une config un peu plus limitée (2 ou 4 coeurs sans grosses perfs), là àça me posait problème (notamment en pleine visio - le PC quiu ramait à cause de ça).
Pendant ce temps là, dans le monde debian. apt-get à la vie à la mort !
Bof .. il semble par contre que sur Ubuntu, les SNAP remplacent de plus en plus les paquets apt. Suis assez mitigé sur ce point. les snaps ont un côté que je trouve pratique, par contre d'un autre côté, l'isolation des process et de la possibilité d'écrire sur les filesystems posent certains problèmes à certaines applis.
Du coup … je vais certainement retenter un freebsd sur mon laptop : s'il gère la mise en veille sur disque, je laisserai tomber Ubuntu, snap (et systemd à l'occasion ).
# MacroDNF ?
Posté par GnunuX (site web personnel) . Évalué à 4.
Zut microdnf était pratique parce qu'il était … micro. Très petit et avec très peu de dépendance. Pratique pour faire des conteneurs.
J'ai peur que ca devient "macrodnf" maintenant …
[^] # Re: MacroDNF ?
Posté par Glandos . Évalué à 5.
Faudra créer nanodnf, avant l'apparition de femtodnf.
[^] # Re: MacroDNF ?
Posté par bbo . Évalué à 4.
Pour pas que tu te fasses avoir le moment venu, je te conseille de créer les dépôts tout de suite car on a déjà PicoDNF et dnf-yocto !
[^] # Re: MacroDNF ?
Posté par bbo . Évalué à 5.
Ça sera intégré dans systemd avant ! (c'est bon, on est vendredi)
[^] # Re: MacroDNF ?
Posté par Psychofox (Mastodon) . Évalué à 4.
Où est-ce que tu as raté le without losing its small footprint ?
# Lorsque je lis l'article ...
Posté par totof2000 . Évalué à 6. Dernière modification le 15 avril 2022 à 14:02.
Mais quel est l'intéret d'avoir un daemon pour la gestion des packages?
[^] # Re: Lorsque je lis l'article ...
Posté par bbo . Évalué à 3.
Je ne sais pas si c'est lié, mais il y a un démon DNF chez Mageia.
Le README répond à ta question je pense :
[^] # Re: Lorsque je lis l'article ...
Posté par totof2000 . Évalué à 5.
Euh .. un démon avec une api réseau juste pour ça ? Avec du dbus, policykit and co ? On ne marcherait pas sur la tête là ? Ou quelque chose m'échappe …
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Lorsque je lis l'article ...
Posté par Psychofox (Mastodon) . Évalué à 4.
J'imagine que c'est pour que plusieurs applis puissent faire des requêtes en même temps.
[^] # Re: Lorsque je lis l'article ...
Posté par totof2000 . Évalué à 0.
C la ou ça me pise problème … Qurls applis auraient besoin de lancer des requêtes sur le gestionnaire de paquets ?
[^] # Re: Lorsque je lis l'article ...
Posté par Clément V . Évalué à 3.
Les mises à jour en arrière-plan et l'utilisateur qui veut installer des applications.
[^] # Re: Lorsque je lis l'article ...
Posté par Misc (site web personnel) . Évalué à 4.
Ou les applications qui veulent offrir une interface au bon endroit. Par exemple, les plugins gimp qui sont sous formes de paquets, ou les codecs vidéos non disponibles de base et que tu voudrait installer à la demande car ç'est plus léger. Les firmwares/drivers de matériels en tout genre, comme les drivers d'imprimantes, via un popup quand tu branches l'imprimante.
Les alternatives sont "tout mettre sur le disque" comme sur Mac. Ou laisser les gens taper des commandes ou devoir changer de contexte comme avant.
Parce que bon, savoir que le driver pour un imprimante Acme InkShot 34FZE est dans le paquet "driver-acme-printer-2018", ça me semble non évident.
Il y a aussi une question de sécurité, on dit sans arrêt "faut réduire la surface utilisable". Surprise, avoir une installation facile à la demande, ça aide à ce niveau.
[^] # Re: Lorsque je lis l'article ...
Posté par totof2000 . Évalué à 2.
Du coup on lie les applis à un gestionnaire de paquet … ça me paraît un peu douteuse comme approche.
Puis pour ce qui est de réduire la surface d'attaque … un demon qui tourne en permanence c peut-être pas une bonne idée.
[^] # Re: Lorsque je lis l'article ...
Posté par totof2000 . Évalué à 1. Dernière modification le 16 avril 2022 à 13:44.
Après, si DNF nouvelle génération est une surcouche d'abstraction vis a vis des autres gestionnaires de paquets, ça peut être une bonne idée.
[^] # Re: Lorsque je lis l'article ...
Posté par bbo . Évalué à 2.
Peut-être entre les distributions RPM mais je n'y crois pas trop.
En effet, on a déjà PackageKit qui fait exactement ça : une abstraction pour que chaque gestionnaire de paquets puisse fournir son implémentation dédiée, un démon, une API DBus et une gestion de droits via Polkit… Mais l'intégration de PackageKit dans les distributions s'est fait dans la douleur et sur de (très) nombreuses années. Et je vois souvent des utilisateurs conseiller aux nouveaux de ne pas utiliser Discover (chez KDE) ou Software (chez GNOME)… C'est pour ça que je ne crois pas trop à un nouvel effort de standardisation entre les gestionnaires de paquets. Et d'ailleurs, PackageKit n'est plus sensé évoluer.
[^] # Re: Lorsque je lis l'article ...
Posté par barmic 🦦 . Évalué à 3. Dernière modification le 16 avril 2022 à 17:59.
À une API de gestionnaire de paquet.
dbus peut très bien faire de l'activation à la requête.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Lorsque je lis l'article ...
Posté par Misc (site web personnel) . Évalué à 2.
Sinon, il y a packagekit, qui faisait exactement ça. Mais de toute façon, les applis vont être liés au nommage des paquets d'une façon ou d'une autre, et les efforts d'uniformisation avant d'avoir le code, ça ne marche pas.
Ensuite, il y a pas trop de choix. Soit tu fais un truc qui valide l'approche pour 1 gestionnaire de paquet avant d'essayer de convaincre le reste du monde (ce qui est fait en ce moment), soit tu fait un truc qui a pour vocation d'aller partout (et je pense que vu la violence des réactions sur systemd, personne ne va tenter ça), soit tu fais rien.
Si l'approche est bonne et apporte un plus pour la distribution, le code est libre, quelqu'un de motivé l'adapteras.
Par rapport à un demon qui va se lancer à la demande ? Par rapport à ne pas avoir de demon, donc lancer un shell complet avec des droits étendus au lieu d'un logiciel qu'on peut confiner un peu plus ?
La surface d'attaque, elle va pas venir du fait que ça tourne tout le temps, mais des possibilités d'interactions. Et je pense que remplacer un shell root par un demon, c'est une bonne base pour permettre plus de sécurisation.
[^] # Re: Lorsque je lis l'article ...
Posté par barmic 🦦 . Évalué à 3.
Si tu veux créer un tray icon qui indique les installations en cours, la disponibilité de mises à jour,… Tu n'en a pas besoin.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Un vrai frontend rpm pour fedora ?
Posté par David Demelier (site web personnel) . Évalué à 1.
J'espère que les performances seront enfin là, mais si c'est toujours codé en python probablement pas 🤷🏻♂️
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Un vrai frontend rpm pour fedora ?
Posté par totof2000 . Évalué à 1.
Je partage ton avis … j'ai un truc qui tourne sur Ubuntu pour contrôler la présence de mise à jour et il me prend parfois 100% de cpu. Certes aujourd'hui sur un pc avec 8 coeurs, je ne m'en rend plus trop compte, mais quand j'étais sur une config un peu plus limitée (2 ou 4 coeurs sans grosses perfs), là àça me posait problème (notamment en pleine visio - le PC quiu ramait à cause de ça).
# Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: re: DNF => MicroDNF
Posté par totof2000 . Évalué à 1.
Bof .. il semble par contre que sur Ubuntu, les SNAP remplacent de plus en plus les paquets apt. Suis assez mitigé sur ce point. les snaps ont un côté que je trouve pratique, par contre d'un autre côté, l'isolation des process et de la possibilité d'écrire sur les filesystems posent certains problèmes à certaines applis.
Du coup … je vais certainement retenter un freebsd sur mon laptop : s'il gère la mise en veille sur disque, je laisserai tomber Ubuntu, snap (et systemd à l'occasion ).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.