Disons qu'un outil shell est presque compréhensible à la lecture, cela ne présente donc pas énormément d'intérêt (dans notre cas uniquement naturellement)
Euh... ouais... sûr que vous faites ce que vous voulez, mais c'est pas un poil tordu de complexifier un outil, juste pour justifier sa documentation ? :|
Sans compter que comprendre le code du gestionnaire, ça présente quand même peu d'intérêt dans l'appréhension du fonctionnement d'un système Linux. Vous semblez considérer que bâtir un système, c'est le comprendre, et que plus on part de zéro, mieux c'est. De mon (certes petit) point de vue, tout cela est assez secondaire. Bâtir une LFS la truffe sur le bouquin, c'est à la porté de n'importe quel pinpin qui entend étrenner son costume de hacker, mais administrer et maintenir un tel système au quotidien, clairement pas. Bref, si vous manquez de ressources pour votre projet, il y a peut-être de meilleurs aspects dans lesquels investir celles dont vous disposez, non ? :)
J'ai du mal à saisir le rapport entre le langage et la documentation. En quoi un outil en shell ne pourrait-il pas être documenté comme il faut ?
De plus, la gestion des paquets, c'est àmha vraiment un boulot typique pour le shell : le gros œuvre (conditionnement et déploiement des fichiers) est souvent assuré par une commande unique (genre tar/cpio). Le reste c'est juste de la gestion de log et de la mise en place/exécution de fichiers annexes...
Je proposerais bien spkman/spkcpio, qui produisent et gèrent des paquets Slackware au format CPIO, et sont codés avec dash en essayant de coller au max. à POSIX :
Mais après avoir jeté un œil à spkg, il est loin d'en avoir toute les fonctionnalités. Pourtant, pour une "distro" (1) comme Saevia, il y aurait sûrement une bonne piste vers la simplicité : qui a besoin de gérer les dépendances, lorsqu'il a compilé tout le système lui-même ? le boulot du gestionnaire sur une telle distro se borne en gros à changer une pièce par une autre, non ?
Mes 2¢.
(1) À l'instar de Linux Froms Sratch, ça me paraît plus une méthode qu'une distribution.
Nous prions notre aimable clientèle de bien vouloir excuser cette monstruosité. Une enquête interne sera menée pour en comprendre les tenants et aboutissants, les responsabilité seront établies, et les coupables sanctionnés comme il se doit. Nous tenons à vous assurer que désormais tous les efforts possibles seront faits afin que jamais pareille chose ne se reproduise.
Cela étant, comme tout le monde aura corrigé de lui-même, il fallait bien évidemment lire :
while read line; do echo "$line"; done < /etc/fstab > ~/musiquededaubedrmisée.mp4
Oui, enfin MAC/DAC, en fait, on s'en moque. Dans ma traduction du modèle DRM en terme "UNIX", ce qui était important c'était que les DRM visaient le flux, mais à la relecture, ce n'est effectivement pas très clair, désolé.
Ce que je voulais dire, c'est que le système ne gère pas le contenu mais le conteneur, alors que c'est précisément le contraire qui intéresse les ayant-droits. Si je fais "cat /etc/fstab > ~/musiquededaubedrmisée.mp4", les ayant-droits s'en moquent, puisque le contenu n'est plus le leur. À l'inverse, tout le long le système aura veillé au grain : il aura vérifié que j'avais l'accès en lecture aux blocs référencés par "/etc/fstab", puis que je pouvais désallouer les blocs référencés par "~/musiquededaubedrmisée.mp4" et lui en réallouer d'autres. Le système gère où tu prétends lire/écrire et non ce que tu prétends lire/écrire, soit l'exact opposé de ce qu'essaient de faire les DRM. :)
Sauf qu'il me semble que le "Rights" de "Digital Rights Management" fait plus référence à un contexte légal qu'à un contexte d'administration système. C'est la possibilité pour les ayant-droits de forcer le respect de leurs droits, et donc de se prémunir de la contrefaçon, dans un cadre numérique.
On n'est d'autre part très loin du modèle UNIX présenté. Ce que veulent les ayants-droits, c'est un 740 copyrightowner:buyer, où les commandes qui ouvrent le fichier en lecture ne peuvent rediriger le flux obtenu vers un fichier buyer:buyer. Rien à voir avec l'administration système, qui vise à protéger tel fichier précis sur tel périphérique (grossièrement et pour faire court, une portion de disque dur), alors que ce que visent les DRM est une protection du *contenu* du fichier (c'est pour ça qu'àmha "Rigths" doit ici s'entendre comme "droits sur un œuvre de l'esprit", et non comme "droits dur les fichiers").
Enfin... ça reste tout de même principalement la créature de Pat.
J'ai également pensé un temps qu'il y avait une sorte de collégialité qui s'était instaurée à la tête du projet, mais la lecture de cette interview d'Eric Hameleers m'a laissé le sentiment que même les « Grands Slackeux » n'avaient pas vraiment prise sur le projet.
[^] # Re: Réponse globale
Posté par dr_home . En réponse au journal Projet Saevia - Recherche de contributeurs. Évalué à 9.
Euh... ouais... sûr que vous faites ce que vous voulez, mais c'est pas un poil tordu de complexifier un outil, juste pour justifier sa documentation ? :|
Sans compter que comprendre le code du gestionnaire, ça présente quand même peu d'intérêt dans l'appréhension du fonctionnement d'un système Linux. Vous semblez considérer que bâtir un système, c'est le comprendre, et que plus on part de zéro, mieux c'est. De mon (certes petit) point de vue, tout cela est assez secondaire. Bâtir une LFS la truffe sur le bouquin, c'est à la porté de n'importe quel pinpin qui entend étrenner son costume de hacker, mais administrer et maintenir un tel système au quotidien, clairement pas. Bref, si vous manquez de ressources pour votre projet, il y a peut-être de meilleurs aspects dans lesquels investir celles dont vous disposez, non ? :)
# Limite de documentation ?
Posté par dr_home . En réponse au journal Projet Saevia - Recherche de contributeurs. Évalué à 10.
J'ai du mal à saisir le rapport entre le langage et la documentation. En quoi un outil en shell ne pourrait-il pas être documenté comme il faut ?
De plus, la gestion des paquets, c'est àmha vraiment un boulot typique pour le shell : le gros œuvre (conditionnement et déploiement des fichiers) est souvent assuré par une commande unique (genre tar/cpio). Le reste c'est juste de la gestion de log et de la mise en place/exécution de fichiers annexes...
Je proposerais bien spkman/spkcpio, qui produisent et gèrent des paquets Slackware au format CPIO, et sont codés avec dash en essayant de coller au max. à POSIX :
http://requiescant.tuxfamily.org/spack/index.html
Mais après avoir jeté un œil à spkg, il est loin d'en avoir toute les fonctionnalités. Pourtant, pour une "distro" (1) comme Saevia, il y aurait sûrement une bonne piste vers la simplicité : qui a besoin de gérer les dépendances, lorsqu'il a compilé tout le système lui-même ? le boulot du gestionnaire sur une telle distro se borne en gros à changer une pièce par une autre, non ?
Mes 2¢.
(1) À l'instar de Linux Froms Sratch, ça me paraît plus une méthode qu'une distribution.
[^] # Re: Pas d'accord
Posté par dr_home . En réponse à la dépêche UltraViolet : et c'est reparti pour les DRM !. Évalué à 3.
Cela étant, comme tout le monde aura corrigé de lui-même, il fallait bien évidemment lire :
while read line; do echo "$line"; done < /etc/fstab > ~/musiquededaubedrmisée.mp4
[^] # Re: Pas d'accord
Posté par dr_home . En réponse à la dépêche UltraViolet : et c'est reparti pour les DRM !. Évalué à 2.
Ce que je voulais dire, c'est que le système ne gère pas le contenu mais le conteneur, alors que c'est précisément le contraire qui intéresse les ayant-droits. Si je fais "cat /etc/fstab > ~/musiquededaubedrmisée.mp4", les ayant-droits s'en moquent, puisque le contenu n'est plus le leur. À l'inverse, tout le long le système aura veillé au grain : il aura vérifié que j'avais l'accès en lecture aux blocs référencés par "/etc/fstab", puis que je pouvais désallouer les blocs référencés par "~/musiquededaubedrmisée.mp4" et lui en réallouer d'autres. Le système gère où tu prétends lire/écrire et non ce que tu prétends lire/écrire, soit l'exact opposé de ce qu'essaient de faire les DRM. :)
[^] # Re: Pas d'accord
Posté par dr_home . En réponse à la dépêche UltraViolet : et c'est reparti pour les DRM !. Évalué à 4.
On n'est d'autre part très loin du modèle UNIX présenté. Ce que veulent les ayants-droits, c'est un 740 copyrightowner:buyer, où les commandes qui ouvrent le fichier en lecture ne peuvent rediriger le flux obtenu vers un fichier buyer:buyer. Rien à voir avec l'administration système, qui vise à protéger tel fichier précis sur tel périphérique (grossièrement et pour faire court, une portion de disque dur), alors que ce que visent les DRM est une protection du *contenu* du fichier (c'est pour ça qu'àmha "Rigths" doit ici s'entendre comme "droits sur un œuvre de l'esprit", et non comme "droits dur les fichiers").
Mes 2¢ :)
[^] # Re: 2 poids, 2 mesures...
Posté par dr_home . En réponse à la dépêche Sortie de Slackware 13.1. Évalué à 2.
[^] # Re: 2 poids, 2 mesures...
Posté par dr_home . En réponse à la dépêche Sortie de Slackware 13.1. Évalué à 3.
J'ai également pensé un temps qu'il y avait une sorte de collégialité qui s'était instaurée à la tête du projet, mais la lecture de cette interview d'Eric Hameleers m'a laissé le sentiment que même les « Grands Slackeux » n'avaient pas vraiment prise sur le projet.