Re: Organisation des sections Debian (Was: Site dedie a Debian autre que debian.org ?
Je n'ai pas l'intention de déclencher des descentes en flammes, d'autant que, comme je l'ai déjà noté, je ne suis *rien* pour le moment ni à Debian, ni au mouvement du logiciel libre, mais je veux simplement préciser certains points, car je ne pense pas que tout ce que nous ayons discuté, ou, plus particulièrement, ce que j'ai écrit précédemment contrevienne fondamentalement à la politique Debian, et j'y vois même des possibilités de simplification ( j'en conviens, pas pour celui qui va se taper l'algorithme, mais pour l'utilisateur ) qui ne peuvent qu'influer en faveur de Debian.
Le dimanche 13 juin 1999 à 09:16:39PM +0200, Stephane Bortzmeyer écrivit:
> Attention : pour que cette discussion ne tourne pas au café du commerce ("si
> j'étais au gouvernement..."), il faut prendre en compte tous les problèmes,
> pas seulement celui de l'utilisateur qui cherche un programme. Le découpage
> actuel en sections (les rubriques comme Math ou Text ou Web étant des
> sous-sections, dans la terminologie Debian) est avant tout conçu pour les
> éditeurs de CD-ROM ou les gestionnaires de miroirs FTP. Cela leur permet de
> déterminer rapidement ce qu'ils gardent ou pas, en fonction de leur place
> disque ou de leurs problèmes légaux (exemple : un éditeur de CD-ROM commercial
> peut exclure facilement tout ce qui est non-free). En leur facilitant la
> tâche, cela contribue à une bonne diffusion de Debian.
Je vais revenir un peu plus loin sur une formalisation de ma proposition, ce qui simplifiera la discussion, mais je note dès à présent que le problème est justement d'imposer à l'utilisateur "final" une organisation qui n'a d'intérêt que pour les fabricants de CDs, alors qu'on pourrait très bien mettre en oeuvre des moyens - précisés plus bas- qui permettraient d'appliquer des masques permettant, à la fois aux fabricants de ne prendre que ce qu'ils doivent/veulent prendre, et aux utilisateurs de se dépatouiller avec le tout.
>
> On Sunday 13 June 1999, at 19 h 29, the keyboard of Thierry Laronde
> <thierry.laronde@polynum.com> wrote:
>
> > où le trouver. Or le problème, en tout cas pour moi, c'est que quand je cherche
> > un programme, je sais grosso modo ce que je voudrais qu'il fît, mais que je ne
> > peux pas lancer une recherche générique sur l'*ensemble* des paquetages possibles,
>
> Cela existe depuis belle lurette : <http://www.debian.org/distrib/packages>.
> dpkg et apt sont effectivement conçus pour installer, pas pour chercher.
Il y a donc une bonne nouvelle : tout ce que je dis n'est pas crétin, puisque quelqu'un y a pensé avant moi :-) Par contre, qu'il existe un outil pour chercher ( voire même, un jour, en utilisant les identifiants, pour aider l'utilisateur à dégrossir les problèmes de configuration) cela me paraitrait utile.
> > Alexandre Vitrac ne sera peut-être toujours pas d'accord, mais je persiste
> > à dire que le tri par licence est un a priori idéologique
>
> Il s'agit d'un choix politique. On peut toujours essayer de le démoniser en
> parlant d'un "a priori idéologique" mais cest un choix politique délibéré et
> connu. Rappelons que ce "contrat social" <http://www.debian.org/social_contract
> est la base de Debian, base sans laquelle Debian n'existe pas.
>
Mon intention n'est pas de "démoniser". Je n'ai pas de problème avec l'esprit du contrat, j'en ai avec la réalisation, car l'enfer est pavé de bonnes intentions.
Ce qui me dérange aujourd'hui c'est de voir la section "main" crouler sous une avalanche d'assemblages de bits à l'intérêt douteux, parce que pour quelqu'un qui doit acheter des CDs, cela va augmenter le prix, et parce que cela noie l'objectif de Debian ( je cite §4 "We will be guided by the needs of our users and the free-software community. [..] To support these goals, we will provide an integrated system of high-quality, 100% free software, with no legal restrictions that would prevent these kinds of use.").
Ce qu'il faut souligner c'est : l'intérêt de l'UTILISATEUR et de la COMMUNAUTE DU LOGICIEL LIBRE qui est la PREMIERE DES PRIORITES : le dépeçage, dans l'intérêt des marchands de CDs, n'a donc pas à être imposé aux utilisateurs, surtout que l'on peut faire au mieux pour les deux. Deuxièmement, j'aimerais qu'on m'explique en quoi les programmes "100% free!" qui permettent de faire zing-zing-boom quand on ferme une fenêtre ont à voir avec "an integrated system of high-quality".
Par contre OK, il y a une chose qui m'avait nettement échappée, c'est que l'image de Debian, et le prosélytisme affiché en faveur du libre imposent d'avoir une distribution 100% libre ( je n'emploie pas prosélytisme en mauvaise part : on ne peut pas être révolutionnaire à moitié). Mais ça, cela devrait être non pas "main", une section parmi les autres, mais le coeur du système de haute-qualité, un athlète hyper-musclé, sans un gramme de graisse : LE coeur de Debian. Le reste c'est du plus, que ce soit libre mais sans intérêt, ou intéressant mais pas libre. Et si c'est non libre et sans intérêt, faut-il vraiment s'en soucier ?
Et pour gérer tout cela, on peut l'envisager ainsi :
Pour chaque programme/paquetage, il y aura deux clés :
clé administrative
identifiant
/*----------------------------------------------------------------*/
La clé administrative sera composée ainsi :
<champ_distribution><champ_valeur_du_programme>
<champ_distribution>:
<2bits_priorité><2bits_licence><1bit_politique>
<2bits_priorité>: # hérite de level priority mais je fais sauter extra
bit_de_poids_fort bit_de_poids_faible
bit_de_poids_fort : 0 => prioritaire
1 => non prioritaire
bit_de_poids_faible : idem, ce sont des subdivisions.
Exemple :
00 : required
01 : important
10 : standard
11 : optional
<2bits_licence>:
bit_de_poids_fort bit_de_poids_faible
bit_de_poids_fort : 0 => libre
1 => pas libre
bit_de_poids_faible : 0 => gratuit
1 => pas gratuit
Exemple :
00 : DFSG
01 : libre mais avec obligation de payer pour utilisation commerciale
10 : freeware
11 : logiciel commercial habituel
<1bit_politique>: 0 => pas de restriction à l'export
1 => restreint
REMARQUE : cela permettrait donc d'avoir une image globale de la distribution ( Cf mon message précédent), et il suffit d'appliquer le masque voulu pour obtenir les paquetages adéquats ( ça, c'est pour les fabricants de CDs).
/*--------------------------------------------------------------*/
<champ_valeur_du_programme>
un programme a donc deux "faces" :<ce qu'il est supposé faire><comment il est implémenté>
Le champ_valeur_du_programme hérite de cette caractéristique ( et du BTS):
<champ_valeur_du_programme>:
<1bit_fonction><2bits_implementation>
<1bit_fonction>:
0 => fait ce qu'il a à faire
1 => ne fait pas ce qu'il a à faire
Note : de manière heuristique, que le bit soit allumé peut signifier deux choses :
1°) Que le programme est mauvais : il peut fonctionner sans bogue, mais il ne rend pas les services qu'on en attend.
2°) Que le programme n'est pas suffisamment "élémentaire" dans une optique unixienne : il fait plusieurs choses que l'on avait plus ou moins distinguées, mais qu'il n'est pas possible de faire progresser de conserve dans un même programme.
<2bits_implementation>: bit_de_poids_fort bit_de_poids_faible
bit_de_poids_fort : 0 => pas de code cafardeux critique
1 => code cafardeux critique ( bogue sécurité par ex.)
bit_de_poids_faible : 0 => pas de bogue reporté par BTS
1 => bogue(s) reporté(s) par BTS
/*--------------------------------------------------------------*/
Bien et maintenant l'identifiant.
Stéphane Bortzmeyer l'a judicieusement et malicieusement souligné, c'est de la haute-voltige. Pourtant, je relève le gant, parce que j'ai déjà le début d'une idée ( Logique élémentaire - dans une optique Cantorienne distinguant les classes des ensembles, et donc dans une formalisation plus inspirée par von Neumann que par le système de Zermelo-Fraenkel, sachant que le problème est plus simple parce qu'il est plus limité).
Sur ce sujet, rendez-vous dans quelques mois (à la rentrée), non pas pour LA solution, mais pour le début du commencement d'une ébauche de formalisation.
Meilleures salutations.
--
/~~~~/-------------------------------------------------
( (__ Thierry LARONDE
D\_/^ _/ http;//www.polynum.com
Q \|/ thierry.laronde@polynum.com
M___^___________________________________________________
Reply to: