Juste un doigt de proselytisme. Il existe une licence libre (BSD) qui
se fonde sur des ideaux philosophiques differents de ceux de la GPL.
Oui, des idéaux de jemenfoutisme, de "oh bah qu'ils reprennent mon
code pour accroitre leur puissance commerciale afin de mieux
vérouiller l'informatique dans les brevets et du TCPA", très peu pour
moi, merci. Je ne comprends pas comment des auteurs de logiciel libre
peuvent trouver normal de laisser leur code se faire piller par des
gens qui déclarent officilement que le logiciel libre est un ennemi à
abattre.
Je pense qui si qu'un auteur de projet BSD sera content de se piller
lui-même plutôt que de ne pas pouvoir vendre son logiciel à cause de la
licence BSD.
sendmail.com a l'air de très bien y arriver.
De plus, la nature virale de la licence GPL pose aussi probleme: si
on commence a developper en integrant des bouts de code GPL, on place
d'office le developpement sous licence GPL... et on se coupe de certaines
personnes, qui auront un a priori tres negatif vis-a-vis de la GPL, et
de certaines possibilites de faire evoluer son code, vers certaines
pratiques commerciales par exemple.
ça me rappelle l'histoire d'un projet qui voulait passer de GPL en BSD
je crois ou quelque chose du genre (pour pouvoir le vendre) et tous les
co-auteurs devant donner leur accord, je crois qu'il y en a certains qui
ont bloqué. L'auteur initial devait être super content.
Sinon, à propos de la LGPL, n'est-elle pas boycottée cette licence
LGPL ? (par les GNUs)
Moi, je prefere que ca soit un choix assume, que la personne qui utilise
du code GPL sache bien dans quel engrenage elle met son doigt.
Il n'y a, helas ou heureusement, pas que le critere technique de la
qualite du code concerne a considerer.
Ce qui me paraît louche dans la GPL, c'est le :
<<
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
bref, le "later version".
Tiens, ca sent tres fort le Hurd, ca, comme habitude.
Oui, GNU/Hurd n'a pas de limites, par conception même, toute forme de
limites en est banni. Rendre la liberté aux utilisateurs, c'est aussi
éviter que l'utilisateur ne subisse des limites codées en dur dans les
applications, ni des limites techniques, comme l'impossibilité de
"monter" une image ISO sans être root, ou
le fait de devoir se
reloguer pour être rajouer à un groupe.
Depuis quand est-ce que ce problème est lié au fait que le noyau soit
micro-noyau ou pas.
Ce problème existe-t-il ailleurs que sous linux ?
Note :
Attention, ça va virer au débat politique.
Juste un doigt de proselytisme. Il existe une licence libre (BSD) qui
se fonde sur des ideaux philosophiques differents de ceux de la GPL.
Oui, des idéaux de jemenfoutisme, de "oh bah qu'ils reprennent mon
code pour accroitre leur puissance commerciale afin de mieux
vérouiller l'informatique dans les brevets et du TCPA", très peu pour
moi, merci. Je ne comprends pas comment des auteurs de logiciel libre
peuvent trouver normal de laisser leur code se faire piller par des
gens qui déclarent officilement que le logiciel libre est un ennemi à
abattre.
Je pense qui si qu'un auteur de projet BSD sera content de se piller
lui-même plutôt que de ne pas pouvoir vendre son logiciel à cause de la
licence BSD.
sendmail.com a l'air de très bien y arriver.
De plus, la nature virale de la licence GPL pose aussi probleme: si
on commence a developper en integrant des bouts de code GPL, on place
d'office le developpement sous licence GPL... et on se coupe de certaines
personnes, qui auront un a priori tres negatif vis-a-vis de la GPL, et
de certaines possibilites de faire evoluer son code, vers certaines
pratiques commerciales par exemple.
ça me rappelle l'histoire d'un projet qui voulait passer de GPL en BSD
je crois ou quelque chose du genre (pour pouvoir le vendre) et tous les
co-auteurs devant donner leur accord, je crois qu'il y en a certains qui
ont bloqué. L'auteur initial devait être super content.
Sinon, à propos de la LGPL, n'est-elle pas boycottée cette licence
LGPL ? (par les GNUs)
Moi, je prefere que ca soit un choix assume, que la personne qui utilise
du code GPL sache bien dans quel engrenage elle met son doigt.
Il n'y a, helas ou heureusement, pas que le critere technique de la
qualite du code concerne a considerer.
Ce qui me paraît louche dans la GPL, c'est le :
<<
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
bref, le "later version".
Tiens, ca sent tres fort le Hurd, ca, comme habitude.
Oui, GNU/Hurd n'a pas de limites, par conception même, toute forme de
limites en est banni. Rendre la liberté aux utilisateurs, c'est aussi
éviter que l'utilisateur ne subisse des limites codées en dur dans les
applications, ni des limites techniques, comme l'impossibilité de
"monter" une image ISO sans être root, ou
le fait de devoir se
reloguer pour être rajouer à un groupe.
Depuis quand est-ce que ce problème est lié au fait que le noyau soit
micro-noyau ou pas.
Ce problème existe-t-il ailleurs que sous linux ?
Note :
Attention, ça va virer au débat politique.
Juste un doigt de proselytisme. Il existe une licence libre (BSD) qui
se fonde sur des ideaux philosophiques differents de ceux de la GPL.
Oui, des idéaux de jemenfoutisme, de "oh bah qu'ils reprennent mon
code pour accroitre leur puissance commerciale afin de mieux
vérouiller l'informatique dans les brevets et du TCPA", très peu pour
moi, merci. Je ne comprends pas comment des auteurs de logiciel libre
peuvent trouver normal de laisser leur code se faire piller par des
gens qui déclarent officilement que le logiciel libre est un ennemi à
abattre.
Je pense qui si qu'un auteur de projet BSD sera content de se piller
lui-même plutôt que de ne pas pouvoir vendre son logiciel à cause de la
licence BSD.
sendmail.com a l'air de très bien y arriver.
De plus, la nature virale de la licence GPL pose aussi probleme: si
on commence a developper en integrant des bouts de code GPL, on place
d'office le developpement sous licence GPL... et on se coupe de certaines
personnes, qui auront un a priori tres negatif vis-a-vis de la GPL, et
de certaines possibilites de faire evoluer son code, vers certaines
pratiques commerciales par exemple.
ça me rappelle l'histoire d'un projet qui voulait passer de GPL en BSD
je crois ou quelque chose du genre (pour pouvoir le vendre) et tous les
co-auteurs devant donner leur accord, je crois qu'il y en a certains qui
ont bloqué. L'auteur initial devait être super content.
Sinon, à propos de la LGPL, n'est-elle pas boycottée cette licence
LGPL ? (par les GNUs)
Moi, je prefere que ca soit un choix assume, que la personne qui utilise
du code GPL sache bien dans quel engrenage elle met son doigt.
Il n'y a, helas ou heureusement, pas que le critere technique de la
qualite du code concerne a considerer.
Ce qui me paraît louche dans la GPL, c'est le :
<<
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
bref, le "later version".
Tiens, ca sent tres fort le Hurd, ca, comme habitude.
Oui, GNU/Hurd n'a pas de limites, par conception même, toute forme de
limites en est banni. Rendre la liberté aux utilisateurs, c'est aussi
éviter que l'utilisateur ne subisse des limites codées en dur dans les
applications, ni des limites techniques, comme l'impossibilité de
"monter" une image ISO sans être root, ou
le fait de devoir se
reloguer pour être rajouer à un groupe.
Depuis quand est-ce que ce problème est lié au fait que le noyau soit
micro-noyau ou pas.
Ce problème existe-t-il ailleurs que sous linux ?
Note :
Attention, ça va virer au débat politique.
Oui, des idéaux de jemenfoutisme, de "oh bah qu'ils reprennent mon
code pour accroitre leur puissance commerciale afin de mieux
vérouiller l'informatique dans les brevets et du TCPA", très peu pour
moi, merci. Je ne comprends pas comment des auteurs de logiciel libre
peuvent trouver normal de laisser leur code se faire piller par des
gens qui déclarent officilement que le logiciel libre est un ennemi à
abattre.
C'est pas parce que tu ne comprends rien a la motivation qui poussent
les gens a developper du logiciel BSD que tu es oblige de raconter
n'importe quoi jusqu'a la caricature.
[...]Non, en effet, il faut aussi un peu se préoccuper de problèmes
éthiques et défendre la liberté de son code.
Et, a ton avis, tu penses que c'est une demarche que nous n'avons pas ?
Nous sommes juste parvenus a d'autre conclusions que toi sur la marche
a suivre.
strlcpy et strlcat sûres ? mwarf, elles n'apportent quasiment rien de
plus que des strncpy et strncat, désolé, chez GNU on préfère éviter
les buffers statiques plutôt que de rajouter des fonctions pour les
gérer de manière un peu moins non-sûre.
Ca indique clairement que tu ne sais pas t'en servir, ou que tu as
trop suivi la propagande Ulrich Drepper...
On a strndup, asprintf, ... plutôt.
Enfin, comme toujours, chez BSD on préfère rajouter des ristounes
plutôt que de revoir la conception. On préfère faire des jails et
coder des "privilege separation" au niveau des applis, plutôt que
d'avoir une infrastructure qui permet de gagner et perdre
dynamiquement des jetons de sécurité, de faire tourner réellement
plusieurs piles TCP/IP n'ayant pas de privilèges... Moi je préfère
concevoir les choses proprement plutôt que de faire des bidouilles.
C'est une possibilite. Au fait, une version de Hurd qui serve a quelque
chose, c'est pour quand ?
En attendant, les rustines a la strlcpy/strlcat/snprintf ont evite plus
de trous que tout le code de Hurd reuni.
Accessoirement, le concept de privilege separation n'est absolument
pas une rustine, mais une technique raisonnable de
conception. C'est un peu complexe (voire tres dur) a retroffitter
sur du logiciel existant, mais ca marche tres bien en pratique.
Il est juste possible, la-encore, qu'on ait fait d'autres choix de
conception. Peut-etre que tout reecrire de fond en comble serait une
meilleure idee
(encore que je me souviens d'un trou dans la gestion des
capabilities sous linux qui avait bien jaser dans les chaumieres),
mais il n'empeche pas qu'on a des petites avancees constantes qui finissent
par faire de grandes choses.
Si tu regardes du cote de gcc, par exemple, tu y verras pas mal de code
de verifications supplementaires qui ont ete ecrites par des gens de BSD.
Mais bon, continue a faire du Hurd, hein...
Oui, des idéaux de jemenfoutisme, de "oh bah qu'ils reprennent mon
code pour accroitre leur puissance commerciale afin de mieux
vérouiller l'informatique dans les brevets et du TCPA", très peu pour
moi, merci. Je ne comprends pas comment des auteurs de logiciel libre
peuvent trouver normal de laisser leur code se faire piller par des
gens qui déclarent officilement que le logiciel libre est un ennemi à
abattre.
C'est pas parce que tu ne comprends rien a la motivation qui poussent
les gens a developper du logiciel BSD que tu es oblige de raconter
n'importe quoi jusqu'a la caricature.
[...]
Non, en effet, il faut aussi un peu se préoccuper de problèmes
éthiques et défendre la liberté de son code.
Et, a ton avis, tu penses que c'est une demarche que nous n'avons pas ?
Nous sommes juste parvenus a d'autre conclusions que toi sur la marche
a suivre.
strlcpy et strlcat sûres ? mwarf, elles n'apportent quasiment rien de
plus que des strncpy et strncat, désolé, chez GNU on préfère éviter
les buffers statiques plutôt que de rajouter des fonctions pour les
gérer de manière un peu moins non-sûre.
Ca indique clairement que tu ne sais pas t'en servir, ou que tu as
trop suivi la propagande Ulrich Drepper...
On a strndup, asprintf, ... plutôt.
Enfin, comme toujours, chez BSD on préfère rajouter des ristounes
plutôt que de revoir la conception. On préfère faire des jails et
coder des "privilege separation" au niveau des applis, plutôt que
d'avoir une infrastructure qui permet de gagner et perdre
dynamiquement des jetons de sécurité, de faire tourner réellement
plusieurs piles TCP/IP n'ayant pas de privilèges... Moi je préfère
concevoir les choses proprement plutôt que de faire des bidouilles.
C'est une possibilite. Au fait, une version de Hurd qui serve a quelque
chose, c'est pour quand ?
En attendant, les rustines a la strlcpy/strlcat/snprintf ont evite plus
de trous que tout le code de Hurd reuni.
Accessoirement, le concept de privilege separation n'est absolument
pas une rustine, mais une technique raisonnable de
conception. C'est un peu complexe (voire tres dur) a retroffitter
sur du logiciel existant, mais ca marche tres bien en pratique.
Il est juste possible, la-encore, qu'on ait fait d'autres choix de
conception. Peut-etre que tout reecrire de fond en comble serait une
meilleure idee
(encore que je me souviens d'un trou dans la gestion des
capabilities sous linux qui avait bien jaser dans les chaumieres),
mais il n'empeche pas qu'on a des petites avancees constantes qui finissent
par faire de grandes choses.
Si tu regardes du cote de gcc, par exemple, tu y verras pas mal de code
de verifications supplementaires qui ont ete ecrites par des gens de BSD.
Mais bon, continue a faire du Hurd, hein...
Oui, des idéaux de jemenfoutisme, de "oh bah qu'ils reprennent mon
code pour accroitre leur puissance commerciale afin de mieux
vérouiller l'informatique dans les brevets et du TCPA", très peu pour
moi, merci. Je ne comprends pas comment des auteurs de logiciel libre
peuvent trouver normal de laisser leur code se faire piller par des
gens qui déclarent officilement que le logiciel libre est un ennemi à
abattre.
C'est pas parce que tu ne comprends rien a la motivation qui poussent
les gens a developper du logiciel BSD que tu es oblige de raconter
n'importe quoi jusqu'a la caricature.
[...]Non, en effet, il faut aussi un peu se préoccuper de problèmes
éthiques et défendre la liberté de son code.
Et, a ton avis, tu penses que c'est une demarche que nous n'avons pas ?
Nous sommes juste parvenus a d'autre conclusions que toi sur la marche
a suivre.
strlcpy et strlcat sûres ? mwarf, elles n'apportent quasiment rien de
plus que des strncpy et strncat, désolé, chez GNU on préfère éviter
les buffers statiques plutôt que de rajouter des fonctions pour les
gérer de manière un peu moins non-sûre.
Ca indique clairement que tu ne sais pas t'en servir, ou que tu as
trop suivi la propagande Ulrich Drepper...
On a strndup, asprintf, ... plutôt.
Enfin, comme toujours, chez BSD on préfère rajouter des ristounes
plutôt que de revoir la conception. On préfère faire des jails et
coder des "privilege separation" au niveau des applis, plutôt que
d'avoir une infrastructure qui permet de gagner et perdre
dynamiquement des jetons de sécurité, de faire tourner réellement
plusieurs piles TCP/IP n'ayant pas de privilèges... Moi je préfère
concevoir les choses proprement plutôt que de faire des bidouilles.
C'est une possibilite. Au fait, une version de Hurd qui serve a quelque
chose, c'est pour quand ?
En attendant, les rustines a la strlcpy/strlcat/snprintf ont evite plus
de trous que tout le code de Hurd reuni.
Accessoirement, le concept de privilege separation n'est absolument
pas une rustine, mais une technique raisonnable de
conception. C'est un peu complexe (voire tres dur) a retroffitter
sur du logiciel existant, mais ca marche tres bien en pratique.
Il est juste possible, la-encore, qu'on ait fait d'autres choix de
conception. Peut-etre que tout reecrire de fond en comble serait une
meilleure idee
(encore que je me souviens d'un trou dans la gestion des
capabilities sous linux qui avait bien jaser dans les chaumieres),
mais il n'empeche pas qu'on a des petites avancees constantes qui finissent
par faire de grandes choses.
Si tu regardes du cote de gcc, par exemple, tu y verras pas mal de code
de verifications supplementaires qui ont ete ecrites par des gens de BSD.
Mais bon, continue a faire du Hurd, hein...
Non, un buffer dans la pile présente un danger, car nul n'est à
l'abris d'une erreur. Et un buffer de taille fixe est général une
limitation que l'utilisateur final subira.
Non, un buffer dans la pile présente un danger, car nul n'est à
l'abris d'une erreur. Et un buffer de taille fixe est général une
limitation que l'utilisateur final subira.
Non, un buffer dans la pile présente un danger, car nul n'est à
l'abris d'une erreur. Et un buffer de taille fixe est général une
limitation que l'utilisateur final subira.
Si tu n'es pas capable de réfléchir aux possibilités d'un design, et
de comprendre qu'un projet complexe, sur lequel peu de gens
contribuent, et qui a été suspendu pendant des années mettent un peu
de temps à se finaliser (surtout avec la révolution qu'il y a eu dans
le domaine des micro-noyaux entre le début du Hurd et le moment où le
projet a été relancé, j'entends par là ls µk de seconde génération
type L4)
Si tu n'es pas capable de réfléchir aux possibilités d'un design, et
de comprendre qu'un projet complexe, sur lequel peu de gens
contribuent, et qui a été suspendu pendant des années mettent un peu
de temps à se finaliser (surtout avec la révolution qu'il y a eu dans
le domaine des micro-noyaux entre le début du Hurd et le moment où le
projet a été relancé, j'entends par là ls µk de seconde génération
type L4)
Si tu n'es pas capable de réfléchir aux possibilités d'un design, et
de comprendre qu'un projet complexe, sur lequel peu de gens
contribuent, et qui a été suspendu pendant des années mettent un peu
de temps à se finaliser (surtout avec la révolution qu'il y a eu dans
le domaine des micro-noyaux entre le début du Hurd et le moment où le
projet a été relancé, j'entends par là ls µk de seconde génération
type L4)
In article ,
Gaël Le Mignot wrote:Non, un buffer dans la pile présente un danger, car nul n'est à
l'abris d'une erreur. Et un buffer de taille fixe est général une
limitation que l'utilisateur final subira.
Par opposition a un tampon ailleurs qui ne constitue pas un danger ?
Les tampons dans la pile comme les tampons dans le tas, en cas de
debordement, se transforment facilement en trou de securite.
In article <plopm3wu9ppkdj.fsf@drizzt.kilobug.org>,
Gaël Le Mignot <kilobug@freesurf.fr> wrote:
Non, un buffer dans la pile présente un danger, car nul n'est à
l'abris d'une erreur. Et un buffer de taille fixe est général une
limitation que l'utilisateur final subira.
Par opposition a un tampon ailleurs qui ne constitue pas un danger ?
Les tampons dans la pile comme les tampons dans le tas, en cas de
debordement, se transforment facilement en trou de securite.
In article ,
Gaël Le Mignot wrote:Non, un buffer dans la pile présente un danger, car nul n'est à
l'abris d'une erreur. Et un buffer de taille fixe est général une
limitation que l'utilisateur final subira.
Par opposition a un tampon ailleurs qui ne constitue pas un danger ?
Les tampons dans la pile comme les tampons dans le tas, en cas de
debordement, se transforment facilement en trou de securite.
In article ,
Gaël Le Mignot wrote:Si tu n'es pas capable de réfléchir aux possibilités d'un design, et
de comprendre qu'un projet complexe, sur lequel peu de gens
contribuent, et qui a été suspendu pendant des années mettent un peu
de temps à se finaliser (surtout avec la révolution qu'il y a eu dans
le domaine des micro-noyaux entre le début du Hurd et le moment où le
projet a été relancé, j'entends par là ls µk de seconde génération
type L4)
Deux choses:
- je ne pense pas que tu connais bien la taille d'OpenBSD, au niveau
equipe developpement. Ca n'est pas si gros que ca.
- ce que tu me decris, c'est le syndrome GNU que j'ai vecu pendant
des annees sur d'autres projets. Entre le `ben oui, ca n'avance plus, le
projet est gele,
J'appelerai bien ca le mirage GNU, tiens. Toujours courir apres les
dernieres nouveautes est une assez bonne facon de s'assurer qu'on ne
sortira jamais rien de concret.
In article <plopm3wu9ppkdj.fsf@drizzt.kilobug.org>,
Gaël Le Mignot <kilobug@freesurf.fr> wrote:
Si tu n'es pas capable de réfléchir aux possibilités d'un design, et
de comprendre qu'un projet complexe, sur lequel peu de gens
contribuent, et qui a été suspendu pendant des années mettent un peu
de temps à se finaliser (surtout avec la révolution qu'il y a eu dans
le domaine des micro-noyaux entre le début du Hurd et le moment où le
projet a été relancé, j'entends par là ls µk de seconde génération
type L4)
Deux choses:
- je ne pense pas que tu connais bien la taille d'OpenBSD, au niveau
equipe developpement. Ca n'est pas si gros que ca.
- ce que tu me decris, c'est le syndrome GNU que j'ai vecu pendant
des annees sur d'autres projets. Entre le `ben oui, ca n'avance plus, le
projet est gele,
J'appelerai bien ca le mirage GNU, tiens. Toujours courir apres les
dernieres nouveautes est une assez bonne facon de s'assurer qu'on ne
sortira jamais rien de concret.
In article ,
Gaël Le Mignot wrote:Si tu n'es pas capable de réfléchir aux possibilités d'un design, et
de comprendre qu'un projet complexe, sur lequel peu de gens
contribuent, et qui a été suspendu pendant des années mettent un peu
de temps à se finaliser (surtout avec la révolution qu'il y a eu dans
le domaine des micro-noyaux entre le début du Hurd et le moment où le
projet a été relancé, j'entends par là ls µk de seconde génération
type L4)
Deux choses:
- je ne pense pas que tu connais bien la taille d'OpenBSD, au niveau
equipe developpement. Ca n'est pas si gros que ca.
- ce que tu me decris, c'est le syndrome GNU que j'ai vecu pendant
des annees sur d'autres projets. Entre le `ben oui, ca n'avance plus, le
projet est gele,
J'appelerai bien ca le mirage GNU, tiens. Toujours courir apres les
dernieres nouveautes est une assez bonne facon de s'assurer qu'on ne
sortira jamais rien de concret.
| Emacs, gcc, gdb, des fileutils et coreutils très complets, bison,
| flex, info, The Gimp, Gnome, une libc, ... c'est sûr que GNU ne sort
| que peu de choses concrètes.
et tu crois que Marc n'a contribué à aucun de ses produits ?
| Emacs, gcc, gdb, des fileutils et coreutils très complets, bison,
| flex, info, The Gimp, Gnome, une libc, ... c'est sûr que GNU ne sort
| que peu de choses concrètes.
et tu crois que Marc n'a contribué à aucun de ses produits ?
| Emacs, gcc, gdb, des fileutils et coreutils très complets, bison,
| flex, info, The Gimp, Gnome, une libc, ... c'est sûr que GNU ne sort
| que peu de choses concrètes.
et tu crois que Marc n'a contribué à aucun de ses produits ?
| > J'appelerai bien ca le mirage GNU, tiens. Toujours courir apres les
| > dernieres nouveautes est une assez bonne facon de s'assurer qu'on ne
| > sortira jamais rien de concret.
|
| Emacs, gcc, gdb, des fileutils et coreutils très complets, bison,
| flex, info, The Gimp, Gnome, une libc, ... c'est sûr que GNU ne sort
| que peu de choses concrètes.
et tu crois que Marc n'a contribué à aucun de ses produits ?
| > J'appelerai bien ca le mirage GNU, tiens. Toujours courir apres les
| > dernieres nouveautes est une assez bonne facon de s'assurer qu'on ne
| > sortira jamais rien de concret.
|
| Emacs, gcc, gdb, des fileutils et coreutils très complets, bison,
| flex, info, The Gimp, Gnome, une libc, ... c'est sûr que GNU ne sort
| que peu de choses concrètes.
et tu crois que Marc n'a contribué à aucun de ses produits ?
| > J'appelerai bien ca le mirage GNU, tiens. Toujours courir apres les
| > dernieres nouveautes est une assez bonne facon de s'assurer qu'on ne
| > sortira jamais rien de concret.
|
| Emacs, gcc, gdb, des fileutils et coreutils très complets, bison,
| flex, info, The Gimp, Gnome, une libc, ... c'est sûr que GNU ne sort
| que peu de choses concrètes.
et tu crois que Marc n'a contribué à aucun de ses produits ?
