Daniel J. Bernstein a une manie tenace : il aime bien protéger ses applis en utilisant juste la propriété intellectuelle, sans licence libre, mais en fournissant les sources, au détail près qu'il est interdit de les redistribuer modifiées, tout comme il est interdit de distribuer des binaires modifiés.
Bon, ça n'empêche pas de distribuer des paquets source contenant son code intact, les patches qui vont bien, et de compiler tout ça à la volée pour les installer... mais on sent qu'il aime garder le contrôle...
En outre, il a une vue très particulière de la manière de gérer un système : les démons, par exemple, ne sont pas gérés par des scripts dans /etc/init (linkés dans les runlevels) - il a son propre machin, daemontools... pareil pour l'arborescence, il a ses propres manies, pas du tout à-la-UNIX, comme on l'entend traditionnellement... Alors, il a le droit, hein... sauf que ça complique la tâche d'intégration dans les systèmes qui ne pensent pas (et ne veulent pas le faire - rien de mal à ça) comme lui... et comme ce n'est pas libre, ça complique encore d'autant. Heureusement, voyant que ses softs sont finalement "peu" utilisés (hors par ses "groupies"), il finit par les sortir en "domaine public"... mais longtemps après leur parution initiale.
Je pense notamment à djbdns (je connais très peu qmail) : bonne pratique de séparer le DNS autoritaire du DNS récursif, en deux démons distincts (pratique d'ailleurs reprise plus tard par PowerDNS, ou MaraDNS, notamment... quoique pour celui là, si quelqu'un sait comment permettre à un DNS autoritaire de, à la fois, ne pas activer le cache sur celui-ci, et se référer quand même à un récursif pour ce qu'il ne connaît pas, ça m'intéresse ; il m'a pris la tête une bonne partie du weekend, et j'ai abandonné, le cache s'activant systématiquement sur l'autoritaire pour peu qu'on lui dise d'aller voir un récursif au besoin - dommage, c'est le seul truc qui m'embête avec lui, mais c'est rédhibitoire, pour moi), comme ça, on est sûr d'éviter les empoisonnements de cache pour les noms locaux, puisqu'il n'y en a pas, de cache, sur le daemon qui s'en occupe.
Il y a aussi de la très bonne idée, en avance sur son temps, avec la "randomisation" des ports sources, ce qui fait que djbdns, et ceux qui l'ont imité depuis longtemps (PowerDNS, MaraDNS, par exemple... encore) n'ont pas été impactés par la "nouvelle" "faille" DNS du printemps dernier...
Oui... mais en pratique, sa fronde comportementale n'a pas contribué à démocratiser son appli : au contraire, Bind est toujours ultra-dominant...
Personnellement, je trouve que la satisfaction de l'ego de DJB, qui veut, m'est avis, trop contrôler (packaging, source, ...), est nuisible. Si djbdns avait été sorti sous une licence libre dès le début, en permettant aux gens de l'adapter à la manière de faire UNIX, s'ils en avaient envie, pour mieux l'intégrer dans les _distributions_ (qui ont des manies, elles aussi), Bind serait probablement enterré depuis un moment... Hélas...
Arriver avec de nouvelles idées est une très bonne chose ; hélas, tous les avantages peuvent être réduits à peau de chagrin pour cause d'un ego, m'est avis, mal placé... c'est dommage. Certes, tu pourras m'objecter que l'ego des communauté est à prendre en compte aussi, à ce moment-là : moui... mais les distros et leurs utilisateurs ne veulent pas dénaturer les DJBeries, mais simplement les intégrer à leur sauce, en étant libres de faire comme elles l'entendent : ni plus, ni moins. Face aux démarches entreprises par DJB pour empêcher ça, ce sont deux visions de "seul contre tous" qui s'opposent ; malheureusement, une seule des deux est libre.
> Eh, peut être que ca contenterait aussi des constructeurs susceptibles de mettre leurs pilotes sous licence libre mais qui sont freinés à l'heure d'aujourd'hui par la piètre qualité technique de l'API des drivers du kernel
Admettons... sauf qu'un code sous licence libre n'est pas forcément maintenable, sans documentation... Exemple : nv, le driver pour les GPU du caméléon - libre, pour sûr - obsfuqué et impossible à maintenir par la communauté, pour sûr...
Et dans ce cas, si la société se fait racheter, ou arrête de jouer avec nous, qu'est ce qu'on fait du driver ? Simple, à la première modification d'API (inéluctable, tout autant qu'on puisse la retarder) : on se le met sur l'oreille...
Des drivers libres, c'est bien : mais infiniment moins que des spécifications (une doc client est amplement suffisante : pas besoin des plans de conception, ni de la liste des jours et heures auxquelles le personnel de la boîte est allé prendre un café). Avec des spécifications, même si le fabricant abandonne, on a de quoi se retourner. Alors, avec un driver libre en plus, c'est encore mieux - mais les deux ne sont clairement pas sur un pied d'égalité, eu regard aux avantages qu'ils peuvent nous procurer.
[^] # Re: Faire payer... Ou proposer ce que les gens demandent.
Posté par Aefron . En réponse au journal Linux et le grand public il faut en finir avec la gratuité.. Évalué à 4.
Daniel J. Bernstein a une manie tenace : il aime bien protéger ses applis en utilisant juste la propriété intellectuelle, sans licence libre, mais en fournissant les sources, au détail près qu'il est interdit de les redistribuer modifiées, tout comme il est interdit de distribuer des binaires modifiés.
Bon, ça n'empêche pas de distribuer des paquets source contenant son code intact, les patches qui vont bien, et de compiler tout ça à la volée pour les installer... mais on sent qu'il aime garder le contrôle...
En outre, il a une vue très particulière de la manière de gérer un système : les démons, par exemple, ne sont pas gérés par des scripts dans /etc/init (linkés dans les runlevels) - il a son propre machin, daemontools... pareil pour l'arborescence, il a ses propres manies, pas du tout à-la-UNIX, comme on l'entend traditionnellement... Alors, il a le droit, hein... sauf que ça complique la tâche d'intégration dans les systèmes qui ne pensent pas (et ne veulent pas le faire - rien de mal à ça) comme lui... et comme ce n'est pas libre, ça complique encore d'autant. Heureusement, voyant que ses softs sont finalement "peu" utilisés (hors par ses "groupies"), il finit par les sortir en "domaine public"... mais longtemps après leur parution initiale.
Je pense notamment à djbdns (je connais très peu qmail) : bonne pratique de séparer le DNS autoritaire du DNS récursif, en deux démons distincts (pratique d'ailleurs reprise plus tard par PowerDNS, ou MaraDNS, notamment... quoique pour celui là, si quelqu'un sait comment permettre à un DNS autoritaire de, à la fois, ne pas activer le cache sur celui-ci, et se référer quand même à un récursif pour ce qu'il ne connaît pas, ça m'intéresse ; il m'a pris la tête une bonne partie du weekend, et j'ai abandonné, le cache s'activant systématiquement sur l'autoritaire pour peu qu'on lui dise d'aller voir un récursif au besoin - dommage, c'est le seul truc qui m'embête avec lui, mais c'est rédhibitoire, pour moi), comme ça, on est sûr d'éviter les empoisonnements de cache pour les noms locaux, puisqu'il n'y en a pas, de cache, sur le daemon qui s'en occupe.
Il y a aussi de la très bonne idée, en avance sur son temps, avec la "randomisation" des ports sources, ce qui fait que djbdns, et ceux qui l'ont imité depuis longtemps (PowerDNS, MaraDNS, par exemple... encore) n'ont pas été impactés par la "nouvelle" "faille" DNS du printemps dernier...
Oui... mais en pratique, sa fronde comportementale n'a pas contribué à démocratiser son appli : au contraire, Bind est toujours ultra-dominant...
Personnellement, je trouve que la satisfaction de l'ego de DJB, qui veut, m'est avis, trop contrôler (packaging, source, ...), est nuisible. Si djbdns avait été sorti sous une licence libre dès le début, en permettant aux gens de l'adapter à la manière de faire UNIX, s'ils en avaient envie, pour mieux l'intégrer dans les _distributions_ (qui ont des manies, elles aussi), Bind serait probablement enterré depuis un moment... Hélas...
Arriver avec de nouvelles idées est une très bonne chose ; hélas, tous les avantages peuvent être réduits à peau de chagrin pour cause d'un ego, m'est avis, mal placé... c'est dommage. Certes, tu pourras m'objecter que l'ego des communauté est à prendre en compte aussi, à ce moment-là : moui... mais les distros et leurs utilisateurs ne veulent pas dénaturer les DJBeries, mais simplement les intégrer à leur sauce, en étant libres de faire comme elles l'entendent : ni plus, ni moins. Face aux démarches entreprises par DJB pour empêcher ça, ce sont deux visions de "seul contre tous" qui s'opposent ; malheureusement, une seule des deux est libre.
> Eh, peut être que ca contenterait aussi des constructeurs susceptibles de mettre leurs pilotes sous licence libre mais qui sont freinés à l'heure d'aujourd'hui par la piètre qualité technique de l'API des drivers du kernel
Admettons... sauf qu'un code sous licence libre n'est pas forcément maintenable, sans documentation... Exemple : nv, le driver pour les GPU du caméléon - libre, pour sûr - obsfuqué et impossible à maintenir par la communauté, pour sûr...
Et dans ce cas, si la société se fait racheter, ou arrête de jouer avec nous, qu'est ce qu'on fait du driver ? Simple, à la première modification d'API (inéluctable, tout autant qu'on puisse la retarder) : on se le met sur l'oreille...
Des drivers libres, c'est bien : mais infiniment moins que des spécifications (une doc client est amplement suffisante : pas besoin des plans de conception, ni de la liste des jours et heures auxquelles le personnel de la boîte est allé prendre un café). Avec des spécifications, même si le fabricant abandonne, on a de quoi se retourner. Alors, avec un driver libre en plus, c'est encore mieux - mais les deux ne sont clairement pas sur un pied d'égalité, eu regard aux avantages qu'ils peuvent nous procurer.