De plus en plus nombreuses sont les entreprises, qui, ayant fait le
choix de migrer de NT à Linux, on passé sur Windows 2003.
Les problpmes prinicpaux sont:
- L'absence de support
- Le nombre de bug rencontrés
- Les fonctionnalités faibles, comme les outils de gestion des
utilisateurs ou des ressources
- Le choix de la bonne distribution (plus de 300 distros !)
Il est à noter que beaucoup de serveurs de base de données restent en
activité
Il s'agit surtout des services réseaux comme Active directory, DNS et
DHCP qui sont migrés.
En conclusion, quelle est la bonne stragégie ? Mettre
LC_NUMERIC=fr_FR
dans la configuration shell ?
Par ailleurs la dernière ligne de ton exemple me laisse perplexe. Si j'utilise "," comme séparateur de décimale dans la seconde expression, ça pose un problème :
Selon une page de manuel de SunOS trouvé en ligne, je suppose que le "," n'est utilisé que pour la conversion de chaîne en numérique (et inversement), _pas_ pour les nombres saisis sans guillemets (la page de gawk chez moi mentionne pas l'effet de LC_NUMERIC) :
LC_NUMERIC Determine the radix character used when interpreting numeric input, performing conversions between numeric and string values and formatting numeric output. Regardless of locale, the period character (the decimal-point character of the POSIX locale) is the decimal-point character recognized in processing awk programs (including assignments in command-line argu- ments).
C'est quand même assez pervers que les deux notations doivent être utilisées dans le même programme.
Le 26-07-2007, Nicolas George <nicolas$george@salle-s.org> a écrit :
SL , dans le message <slrnfah2uq.3ii.nospam@valla.limsi.fr>, a écrit :
J'ai essayé et rien à faire, ça me donne 0, promis juré craché :
quatramaran ~ $ awk --version | head -n 1
GNU Awk 3.1.5
En conclusion, quelle est la bonne stragégie ? Mettre
LC_NUMERIC=fr_FR
dans la configuration shell ?
Par ailleurs la dernière ligne de ton exemple me laisse perplexe. Si
j'utilise "," comme séparateur de décimale dans la seconde expression,
ça pose un problème :
Selon une page de manuel de SunOS trouvé en ligne, je suppose que le ","
n'est utilisé que pour la conversion de chaîne en numérique (et
inversement), _pas_ pour les nombres saisis sans guillemets (la page de
gawk chez moi mentionne pas l'effet de LC_NUMERIC) :
LC_NUMERIC
Determine the radix character used when interpreting numeric
input, performing conversions between numeric and string
values and formatting numeric output. Regardless of
locale, the period character (the decimal-point character of
the POSIX locale) is the decimal-point character recognized in
processing awk programs (including assignments in command-line
argu- ments).
C'est quand même assez pervers que les deux notations doivent être
utilisées dans le même programme.
En conclusion, quelle est la bonne stragégie ? Mettre
LC_NUMERIC=fr_FR
dans la configuration shell ?
Par ailleurs la dernière ligne de ton exemple me laisse perplexe. Si j'utilise "," comme séparateur de décimale dans la seconde expression, ça pose un problème :
Selon une page de manuel de SunOS trouvé en ligne, je suppose que le "," n'est utilisé que pour la conversion de chaîne en numérique (et inversement), _pas_ pour les nombres saisis sans guillemets (la page de gawk chez moi mentionne pas l'effet de LC_NUMERIC) :
LC_NUMERIC Determine the radix character used when interpreting numeric input, performing conversions between numeric and string values and formatting numeric output. Regardless of locale, the period character (the decimal-point character of the POSIX locale) is the decimal-point character recognized in processing awk programs (including assignments in command-line argu- ments).
C'est quand même assez pervers que les deux notations doivent être utilisées dans le même programme.
Nicolas George
SL , dans le message , a écrit :
~% echo $LC_NUMERIC
Les catégories de locales peuvent être réglées par différentes variables, tu n'en testes qu'une. Il faut utiliser la commande « locale » pour savoir tout exactement.
En conclusion, quelle est la bonne stragégie ?
La seule configuration viable d'un Unix vis-à-vis des locales, c'est d'avoir :
- LC_CTYPE qui décrit l'encodage du terminal ;
- LC_MESSAGES qui indique une langue autre que l'anglais si on tient vraiment à avoir des traductions obsolètes et approximatives ;
- tout le reste à C/POSIX.
Pour ça, il faut que $LANG sont indéfini (ou défini à C ou POSIX), que $LC_CTYPE soit défini, et que $LC_ALL soit indéfini.
Selon une page de manuel de SunOS trouvé en ligne, je suppose que le "," n'est utilisé que pour la conversion de chaîne en numérique (et inversement), _pas_ pour les nombres saisis sans guillemets (la page de gawk chez moi mentionne pas l'effet de LC_NUMERIC) :
Oui, c'est ça.
C'est quand même assez pervers que les deux notations doivent être utilisées dans le même programme.
Non, c'est tout à fait normal : le code du programme utilise la notation universelle avec le point, tandis que la version localisée est utilisée pour toutes les données venant de l'extérieur.
Dans l'absolu, le fait de devoir convertir en nombre une chaîne qui vient de l'intérieur du programme témoigne d'un défaut de conception. Ici, j'imagine que les chaînes viennent effectivement de l'extérieur dans le cas réel que tu cherchais à débugger.
Ceci dit, même si le comportement est globalement cohérent, utiliser les notations localisées pour les nombres est une très mauvaise idée, à cause de programmes non localisés, ou mal localisés (et ils sont fréquents).
SL , dans le message <slrnfah7na.3ii.nospam@valla.limsi.fr>, a écrit :
~% echo $LC_NUMERIC
Les catégories de locales peuvent être réglées par différentes variables, tu
n'en testes qu'une. Il faut utiliser la commande « locale » pour savoir tout
exactement.
En conclusion, quelle est la bonne stragégie ?
La seule configuration viable d'un Unix vis-à-vis des locales, c'est
d'avoir :
- LC_CTYPE qui décrit l'encodage du terminal ;
- LC_MESSAGES qui indique une langue autre que l'anglais si on tient
vraiment à avoir des traductions obsolètes et approximatives ;
- tout le reste à C/POSIX.
Pour ça, il faut que $LANG sont indéfini (ou défini à C ou POSIX), que
$LC_CTYPE soit défini, et que $LC_ALL soit indéfini.
Selon une page de manuel de SunOS trouvé en ligne, je suppose que le ","
n'est utilisé que pour la conversion de chaîne en numérique (et
inversement), _pas_ pour les nombres saisis sans guillemets (la page de
gawk chez moi mentionne pas l'effet de LC_NUMERIC) :
Oui, c'est ça.
C'est quand même assez pervers que les deux notations doivent être
utilisées dans le même programme.
Non, c'est tout à fait normal : le code du programme utilise la notation
universelle avec le point, tandis que la version localisée est utilisée pour
toutes les données venant de l'extérieur.
Dans l'absolu, le fait de devoir convertir en nombre une chaîne qui vient de
l'intérieur du programme témoigne d'un défaut de conception. Ici, j'imagine
que les chaînes viennent effectivement de l'extérieur dans le cas réel que
tu cherchais à débugger.
Ceci dit, même si le comportement est globalement cohérent, utiliser les
notations localisées pour les nombres est une très mauvaise idée, à cause de
programmes non localisés, ou mal localisés (et ils sont fréquents).
Les catégories de locales peuvent être réglées par différentes variables, tu n'en testes qu'une. Il faut utiliser la commande « locale » pour savoir tout exactement.
En conclusion, quelle est la bonne stragégie ?
La seule configuration viable d'un Unix vis-à-vis des locales, c'est d'avoir :
- LC_CTYPE qui décrit l'encodage du terminal ;
- LC_MESSAGES qui indique une langue autre que l'anglais si on tient vraiment à avoir des traductions obsolètes et approximatives ;
- tout le reste à C/POSIX.
Pour ça, il faut que $LANG sont indéfini (ou défini à C ou POSIX), que $LC_CTYPE soit défini, et que $LC_ALL soit indéfini.
Selon une page de manuel de SunOS trouvé en ligne, je suppose que le "," n'est utilisé que pour la conversion de chaîne en numérique (et inversement), _pas_ pour les nombres saisis sans guillemets (la page de gawk chez moi mentionne pas l'effet de LC_NUMERIC) :
Oui, c'est ça.
C'est quand même assez pervers que les deux notations doivent être utilisées dans le même programme.
Non, c'est tout à fait normal : le code du programme utilise la notation universelle avec le point, tandis que la version localisée est utilisée pour toutes les données venant de l'extérieur.
Dans l'absolu, le fait de devoir convertir en nombre une chaîne qui vient de l'intérieur du programme témoigne d'un défaut de conception. Ici, j'imagine que les chaînes viennent effectivement de l'extérieur dans le cas réel que tu cherchais à débugger.
Ceci dit, même si le comportement est globalement cohérent, utiliser les notations localisées pour les nombres est une très mauvaise idée, à cause de programmes non localisés, ou mal localisés (et ils sont fréquents).
Sam Hocevar
On Thu, 26 Jul 2007 13:38:00 +0000 (UTC), Nicolas George wrote:
La seule configuration viable d'un Unix vis-à-vis des locales, c'est d'avoir :
- LC_CTYPE qui décrit l'encodage du terminal ;
- LC_MESSAGES qui indique une langue autre que l'anglais si on tient vraiment à avoir des traductions obsolètes et approximatives ;
- tout le reste à C/POSIX.
Ça dépend quand même de ce que tu fais avec un Unix. Je ne veux pas d'un LC_TIME qui m'inverse le mois et le jour parce que 05/06/07 je ne sais jamais si c'est le 6 juillet 2005 ou le 7 juin 2005 ou le 5 juin 2007 (donc mon LC_TIME est à fr_FR), je veux que mes applis parlent en euros mais utilisent quand même "." comme caractère décimal (donc LC_MONETARY est à en_IE.UTF-8, j'ai choisi un pays anglophone de la zone euro), je ne veux pas que sort et autres traitent mes caractères UTF-8 comme si c'étaient plusieurs caractères 8 bits ou que "â" se trouve après "z" dans l'alphabet (donc mon LC_COLLATE est à en_GB.UTF-8).
En fait, je n'ai rien laissé à C, même LC_MESSAGES je l'ai mis à en_GB.UTF-8 pour avoir de jolis caractères pour les apostrophes, les guillemets ou les ellipses quand des gens prennent le temps de faire de belles transcriptions (et sinon, je me prends le message C standard, ce qui ne choque pas).
Après j'avoue que j'ai un alias cgrep='LANG=C grep' parce que s'il y a bien un truc qui rame, ce sont les moteurs d'expressions rationnelles manipulant de l'UTF-8.
On Thu, 26 Jul 2007 13:38:00 +0000 (UTC), Nicolas George wrote:
La seule configuration viable d'un Unix vis-à-vis des locales, c'est
d'avoir :
- LC_CTYPE qui décrit l'encodage du terminal ;
- LC_MESSAGES qui indique une langue autre que l'anglais si on tient
vraiment à avoir des traductions obsolètes et approximatives ;
- tout le reste à C/POSIX.
Ça dépend quand même de ce que tu fais avec un Unix. Je ne veux pas
d'un LC_TIME qui m'inverse le mois et le jour parce que 05/06/07 je ne
sais jamais si c'est le 6 juillet 2005 ou le 7 juin 2005 ou le 5 juin
2007 (donc mon LC_TIME est à fr_FR), je veux que mes applis parlent
en euros mais utilisent quand même "." comme caractère décimal (donc
LC_MONETARY est à en_IE.UTF-8, j'ai choisi un pays anglophone de la zone
euro), je ne veux pas que sort et autres traitent mes caractères UTF-8
comme si c'étaient plusieurs caractères 8 bits ou que "â" se trouve
après "z" dans l'alphabet (donc mon LC_COLLATE est à en_GB.UTF-8).
En fait, je n'ai rien laissé à C, même LC_MESSAGES je l'ai mis à
en_GB.UTF-8 pour avoir de jolis caractères pour les apostrophes, les
guillemets ou les ellipses quand des gens prennent le temps de faire de
belles transcriptions (et sinon, je me prends le message C standard, ce
qui ne choque pas).
Après j'avoue que j'ai un alias cgrep='LANG=C grep' parce que s'il y
a bien un truc qui rame, ce sont les moteurs d'expressions rationnelles
manipulant de l'UTF-8.
On Thu, 26 Jul 2007 13:38:00 +0000 (UTC), Nicolas George wrote:
La seule configuration viable d'un Unix vis-à-vis des locales, c'est d'avoir :
- LC_CTYPE qui décrit l'encodage du terminal ;
- LC_MESSAGES qui indique une langue autre que l'anglais si on tient vraiment à avoir des traductions obsolètes et approximatives ;
- tout le reste à C/POSIX.
Ça dépend quand même de ce que tu fais avec un Unix. Je ne veux pas d'un LC_TIME qui m'inverse le mois et le jour parce que 05/06/07 je ne sais jamais si c'est le 6 juillet 2005 ou le 7 juin 2005 ou le 5 juin 2007 (donc mon LC_TIME est à fr_FR), je veux que mes applis parlent en euros mais utilisent quand même "." comme caractère décimal (donc LC_MONETARY est à en_IE.UTF-8, j'ai choisi un pays anglophone de la zone euro), je ne veux pas que sort et autres traitent mes caractères UTF-8 comme si c'étaient plusieurs caractères 8 bits ou que "â" se trouve après "z" dans l'alphabet (donc mon LC_COLLATE est à en_GB.UTF-8).
En fait, je n'ai rien laissé à C, même LC_MESSAGES je l'ai mis à en_GB.UTF-8 pour avoir de jolis caractères pour les apostrophes, les guillemets ou les ellipses quand des gens prennent le temps de faire de belles transcriptions (et sinon, je me prends le message C standard, ce qui ne choque pas).
Après j'avoue que j'ai un alias cgrep='LANG=C grep' parce que s'il y a bien un truc qui rame, ce sont les moteurs d'expressions rationnelles manipulant de l'UTF-8.
Remplace « gawk » par « printf '%sn' », et tu verras quel est le code que tu exécutes effectivement, et donc pourquoi tu te plantes.
Ha oui, bien vu ! C'est effectivement plus lié a LC_NUMERIC qu'a une histoire de quotes.
Merci pour la correction.
-- Matthieu Clavier
SL
Le 26-07-2007, Nicolas George <nicolas$ a écrit :
C'est quand même assez pervers que les deux notations doivent être utilisées dans le même programme.
Non, c'est tout à fait normal : le code du programme utilise la notation universelle avec le point, tandis que la version localisée est utilisée pour toutes les données venant de l'extérieur.
Dans l'absolu, le fait de devoir convertir en nombre une chaîne qui vient de l'intérieur du programme témoigne d'un défaut de conception. Ici, j'imagine que les chaînes viennent effectivement de l'extérieur dans le cas réel que tu cherchais à débugger.
C'est vrai.
Le 26-07-2007, Nicolas George <nicolas$george@salle-s.org> a écrit :
C'est quand même assez pervers que les deux notations doivent être
utilisées dans le même programme.
Non, c'est tout à fait normal : le code du programme utilise la notation
universelle avec le point, tandis que la version localisée est utilisée pour
toutes les données venant de l'extérieur.
Dans l'absolu, le fait de devoir convertir en nombre une chaîne qui vient de
l'intérieur du programme témoigne d'un défaut de conception. Ici, j'imagine
que les chaînes viennent effectivement de l'extérieur dans le cas réel que
tu cherchais à débugger.
C'est quand même assez pervers que les deux notations doivent être utilisées dans le même programme.
Non, c'est tout à fait normal : le code du programme utilise la notation universelle avec le point, tandis que la version localisée est utilisée pour toutes les données venant de l'extérieur.
Dans l'absolu, le fait de devoir convertir en nombre une chaîne qui vient de l'intérieur du programme témoigne d'un défaut de conception. Ici, j'imagine que les chaînes viennent effectivement de l'extérieur dans le cas réel que tu cherchais à débugger.
C'est vrai.
Thierry B.
--{ SL a plopé ceci: }--
# aptitude list
qui me liste tous les paquets installés. Et ça me manque tellement qu'un jour, je vais m'y plonger, et voir si je ne peux pas la coder...
Ce qui rajoutera encore une façon de faire isolée, peu visible dans la doc, et incohérente avec l'ensemble...
Donc si je prends les sources Debian d'aptitude, que je me plonge dedans, que j'essaye de rajouter cette fonction qui me ferais bien plaisir, je suis peut-être isolé, mais pas vraiment incohérent avec le logiciel libre, non ?
Si ensuite je met ça au propre, avec le patch pour la doc, et que je propose ça à Debian, je suis un sale rebelle qui en veut au monde entier ? Décidément, je dois vieillir, je n'arrive plus à suivre la trollosphère :)
-- Dès Noël où un zéphyr haï me vêt de glaçons würmiens
--{ SL a plopé ceci: }--
# aptitude list
qui me liste tous les paquets installés. Et ça me manque
tellement qu'un jour, je vais m'y plonger, et voir si je ne
peux pas la coder...
Ce qui rajoutera encore une façon de faire isolée, peu visible dans la
doc, et incohérente avec l'ensemble...
Donc si je prends les sources Debian d'aptitude, que je me plonge
dedans, que j'essaye de rajouter cette fonction qui me ferais bien
plaisir, je suis peut-être isolé, mais pas vraiment incohérent
avec le logiciel libre, non ?
Si ensuite je met ça au propre, avec le patch pour la doc, et que
je propose ça à Debian, je suis un sale rebelle qui en veut au
monde entier ? Décidément, je dois vieillir, je n'arrive plus à
suivre la trollosphère :)
--
Dès Noël où un zéphyr haï me vêt de glaçons würmiens
qui me liste tous les paquets installés. Et ça me manque tellement qu'un jour, je vais m'y plonger, et voir si je ne peux pas la coder...
Ce qui rajoutera encore une façon de faire isolée, peu visible dans la doc, et incohérente avec l'ensemble...
Donc si je prends les sources Debian d'aptitude, que je me plonge dedans, que j'essaye de rajouter cette fonction qui me ferais bien plaisir, je suis peut-être isolé, mais pas vraiment incohérent avec le logiciel libre, non ?
Si ensuite je met ça au propre, avec le patch pour la doc, et que je propose ça à Debian, je suis un sale rebelle qui en veut au monde entier ? Décidément, je dois vieillir, je n'arrive plus à suivre la trollosphère :)
-- Dès Noël où un zéphyr haï me vêt de glaçons würmiens
Thierry B.
--{ Matthieu Clavier a plopé ceci: }--
gawk --version|head -n1
il manquait cela: GNU Awk 3.1.5
Une seconde, j'ai pensé que tu pratiquais la sécurité par
l'obscurité...
-- http://foo.bar.quux.over-blog.com/
--{ Matthieu Clavier a plopé ceci: }--
gawk --version|head -n1
il manquait cela:
GNU Awk 3.1.5
Une seconde, j'ai pensé que tu pratiquais la sécurité par
Une seconde, j'ai pensé que tu pratiquais la sécurité par
l'obscurité...
-- http://foo.bar.quux.over-blog.com/
izatis
Fabienne Ducroquet wrote:
Bonjour,
Prenons un exemple: aptitude. Je ne l'utilise qu'en ligne de commande, et j'aurais aimé avoir une option qui me permette de faire:
# aptitude list
qui me liste tous les paquets installés.
Pour avoir la liste des paquets installés avec aptitude c'est % aptitude search "~i" (pas besoin d'être en root) et c'est mieux que %dpkg -l car dpkg -l liste aussi les paquets supprimés mais pour lesquels il reste les fichiers de configuration, ce n'est pas le cas d'aptitude.
Bonjour, C'est vrai qu'avec dpkg, on est obligé de deleguer la recherche de motif a grep...
dpkg -l | egrep ^i
-- Izatis
Fabienne Ducroquet wrote:
Bonjour,
Prenons un
exemple: aptitude. Je ne l'utilise qu'en ligne de commande,
et j'aurais aimé avoir une option qui me permette de faire:
# aptitude list
qui me liste tous les paquets installés.
Pour avoir la liste des paquets installés avec aptitude c'est
% aptitude search "~i"
(pas besoin d'être en root) et c'est mieux que %dpkg -l car dpkg -l
liste aussi les paquets supprimés mais pour lesquels il reste les
fichiers de configuration, ce n'est pas le cas d'aptitude.
Bonjour,
C'est vrai qu'avec dpkg, on est obligé de deleguer la recherche de
motif a grep...
Prenons un exemple: aptitude. Je ne l'utilise qu'en ligne de commande, et j'aurais aimé avoir une option qui me permette de faire:
# aptitude list
qui me liste tous les paquets installés.
Pour avoir la liste des paquets installés avec aptitude c'est % aptitude search "~i" (pas besoin d'être en root) et c'est mieux que %dpkg -l car dpkg -l liste aussi les paquets supprimés mais pour lesquels il reste les fichiers de configuration, ce n'est pas le cas d'aptitude.
Bonjour, C'est vrai qu'avec dpkg, on est obligé de deleguer la recherche de motif a grep...
dpkg -l | egrep ^i
-- Izatis
nicolas vigier
On 2007-07-26, Thierry B. wrote:
--{ SL a plopé ceci: }--
# aptitude list
qui me liste tous les paquets installés. Et ça me manque tellement qu'un jour, je vais m'y plonger, et voir si je ne peux pas la coder...
Ce qui rajoutera encore une façon de faire isolée, peu visible dans la doc, et incohérente avec l'ensemble...
Donc si je prends les sources Debian d'aptitude, que je me plonge dedans, que j'essaye de rajouter cette fonction qui me ferais bien plaisir, je suis peut-être isolé, mais pas vraiment incohérent avec le logiciel libre, non ?
Aucun rapport avec logiciel libre ici, tu peux faire des trucs incoherents que ce soit libre ou pas.
Nicolas
On 2007-07-26, Thierry B. <tth@prout.stex> wrote:
--{ SL a plopé ceci: }--
# aptitude list
qui me liste tous les paquets installés. Et ça me manque
tellement qu'un jour, je vais m'y plonger, et voir si je ne
peux pas la coder...
Ce qui rajoutera encore une façon de faire isolée, peu visible dans la
doc, et incohérente avec l'ensemble...
Donc si je prends les sources Debian d'aptitude, que je me plonge
dedans, que j'essaye de rajouter cette fonction qui me ferais bien
plaisir, je suis peut-être isolé, mais pas vraiment incohérent
avec le logiciel libre, non ?
Aucun rapport avec logiciel libre ici, tu peux faire des trucs
incoherents que ce soit libre ou pas.
qui me liste tous les paquets installés. Et ça me manque tellement qu'un jour, je vais m'y plonger, et voir si je ne peux pas la coder...
Ce qui rajoutera encore une façon de faire isolée, peu visible dans la doc, et incohérente avec l'ensemble...
Donc si je prends les sources Debian d'aptitude, que je me plonge dedans, que j'essaye de rajouter cette fonction qui me ferais bien plaisir, je suis peut-être isolé, mais pas vraiment incohérent avec le logiciel libre, non ?
Aucun rapport avec logiciel libre ici, tu peux faire des trucs incoherents que ce soit libre ou pas.
Nicolas
Thierry B.
--{ nicolas vigier a plopé ceci: }--
Ce qui rajoutera encore une façon de faire isolée, peu visible dans la doc, et incohérente avec l'ensemble...
Donc si je prends les sources Debian d'aptitude, que je me plonge dedans, que j'essaye de rajouter cette fonction qui me ferais bien plaisir, je suis peut-être isolé, mais pas vraiment incohérent avec le logiciel libre, non ?
Aucun rapport avec logiciel libre ici, tu peux faire des trucs incoherents que ce soit libre ou pas.
Tu as oublié de citer le passage où je proposais de transmettre,
dans le cas où j'arrive à faire un truc propre, ma modification à l'équipe Debian.
Incohérence, quand tu nous tiens...
-- "Le touriste, maintenant, il voudrait internet au gite. Mais pourquoi il vient ici pour faire de l'internet ? C'est pas plus beau que des filles à poil, ici ?"
--{ nicolas vigier a plopé ceci: }--
Ce qui rajoutera encore une façon de faire isolée, peu visible dans la
doc, et incohérente avec l'ensemble...
Donc si je prends les sources Debian d'aptitude, que je me plonge
dedans, que j'essaye de rajouter cette fonction qui me ferais bien
plaisir, je suis peut-être isolé, mais pas vraiment incohérent
avec le logiciel libre, non ?
Aucun rapport avec logiciel libre ici, tu peux faire des trucs
incoherents que ce soit libre ou pas.
Tu as oublié de citer le passage où je proposais de transmettre,
dans le cas où j'arrive à faire un truc propre, ma modification
à l'équipe Debian.
Incohérence, quand tu nous tiens...
--
"Le touriste, maintenant, il voudrait internet au gite. Mais pourquoi il
vient ici pour faire de l'internet ? C'est pas plus beau que des filles
à poil, ici ?"
Ce qui rajoutera encore une façon de faire isolée, peu visible dans la doc, et incohérente avec l'ensemble...
Donc si je prends les sources Debian d'aptitude, que je me plonge dedans, que j'essaye de rajouter cette fonction qui me ferais bien plaisir, je suis peut-être isolé, mais pas vraiment incohérent avec le logiciel libre, non ?
Aucun rapport avec logiciel libre ici, tu peux faire des trucs incoherents que ce soit libre ou pas.
Tu as oublié de citer le passage où je proposais de transmettre,
dans le cas où j'arrive à faire un truc propre, ma modification à l'équipe Debian.
Incohérence, quand tu nous tiens...
-- "Le touriste, maintenant, il voudrait internet au gite. Mais pourquoi il vient ici pour faire de l'internet ? C'est pas plus beau que des filles à poil, ici ?"
