Quand le bureau KDE et toutes ses applications seront portés sur Windows
(on s'en rapproche pour ceux qui suivent, les applications deviennent de
plus en plus stables), celui-ci envahira Windows car, contrairement à
Linux qui possède des dizaines de bureaux, il sera l'unique alternative
au bureau Windows : KDE apporterait un souffle nouveau à Windows, en
tous cas plus que le bureau de Seven.
Du coup, l'utilisateur lambda (qui est l'utilisateur très largement
majoritaire) ne verra plus la différence entre un Windows et un linux
(ou un OpenSolaris ou un BSD) qui tournera derrière et au bout du
compte, il préférera naturellement se tourner vers l'OS qui lui coûte le
moins cher.
Michel Talon, dans le message <hhom78$2u9q$, a écrit :
En d'autres termes les "développeurs Debian" se croient plus malins que les auteurs originaux des softs
Ce qui, en général, s'avère parfaitement justifié.
YBM
Michel Talon a écrit :
JKB wrote:
de ce qui peut se passer dans la phase de compilation). En d'autres termes, les ports, ce sont des logiciels fournis tels quels aux quelques scripts de compilation et de gestion des dépendances.
De l'autre côté, debian fournit des paquets bien plus suivis en terme de sécurité.
En d'autres termes les "développeurs Debian" se croient plus malins que les auteurs originaux des softs
Ils ont presque toujours raison.
et se permettent quelques fantaisies du genre de la célèbre manipulation de ssh.
Tss, sophiste.
Michel Talon a écrit :
JKB <knatschke@koenigsberg.fr> wrote:
de ce qui peut se passer dans la phase de compilation). En d'autres
termes, les ports, ce sont des logiciels fournis tels quels aux
quelques scripts de compilation et de gestion des dépendances.
De l'autre côté, debian fournit des paquets bien plus suivis en
terme de sécurité.
En d'autres termes les "développeurs Debian" se croient plus malins
que les auteurs originaux des softs
Ils ont presque toujours raison.
et se permettent quelques fantaisies
du genre de la célèbre manipulation de ssh.
de ce qui peut se passer dans la phase de compilation). En d'autres termes, les ports, ce sont des logiciels fournis tels quels aux quelques scripts de compilation et de gestion des dépendances.
De l'autre côté, debian fournit des paquets bien plus suivis en terme de sécurité.
En d'autres termes les "développeurs Debian" se croient plus malins que les auteurs originaux des softs
Ils ont presque toujours raison.
et se permettent quelques fantaisies du genre de la célèbre manipulation de ssh.
Tss, sophiste.
Stephane TOUGARD
Riquer Vincent a perdu son temps a nous dire:
J'ai un peu de mal à considérer mon portable, dont la garantie a expiré en juin dernier, comme "obsolète depuis des années". Garantie 3 ans...
Il y a moins de 5GB d'espace disque sur ton portable ? tu t'es fait avoir.
Utiliser Debian stable pour du desktop, à part pour un usage basique, ce n'est pas possible. Mais la testing est suffisamment fiable pour cet usage.
Merci de le reconnaitre. Ceci dit, je ne suis pas sur que le dcraw de la testing soit plus avance que celui de la stable. -- http://unices.over-blog.com/ Un Francais en Chine
Riquer Vincent a perdu son temps a nous dire:
J'ai un peu de mal à considérer mon portable, dont la garantie a expiré
en juin dernier, comme "obsolète depuis des années". Garantie 3 ans...
Il y a moins de 5GB d'espace disque sur ton portable ? tu t'es fait
avoir.
Utiliser Debian stable pour du desktop, à part pour un usage basique, ce
n'est pas possible. Mais la testing est suffisamment fiable pour cet usage.
Merci de le reconnaitre. Ceci dit, je ne suis pas sur que le dcraw de la
testing soit plus avance que celui de la stable.
--
http://unices.over-blog.com/ Un Francais en Chine
J'ai un peu de mal à considérer mon portable, dont la garantie a expiré en juin dernier, comme "obsolète depuis des années". Garantie 3 ans...
Il y a moins de 5GB d'espace disque sur ton portable ? tu t'es fait avoir.
Utiliser Debian stable pour du desktop, à part pour un usage basique, ce n'est pas possible. Mais la testing est suffisamment fiable pour cet usage.
Merci de le reconnaitre. Ceci dit, je ne suis pas sur que le dcraw de la testing soit plus avance que celui de la stable. -- http://unices.over-blog.com/ Un Francais en Chine
Stephane TOUGARD
Nicolas George a perdu son temps a nous dire:
Stephane TOUGARD parlait de Gimp. Que je sache, Gimp n'a pas de problème de support matériel.
Je parlais surtout de dcraw et d'ufraw. Et ca, comme support materiel, on fait difficilement mieux.
-- http://unices.over-blog.com/ Un Francais en Chine
Nicolas George a perdu son temps a nous dire:
Stephane TOUGARD parlait de Gimp. Que je sache, Gimp n'a pas de problème de
support matériel.
Je parlais surtout de dcraw et d'ufraw. Et ca, comme support materiel,
on fait difficilement mieux.
--
http://unices.over-blog.com/ Un Francais en Chine
Mais tu reproches à Debian stable d'être obsolète...
En tant que machine de base, oui, c'est exact.
Oui c'est un tout autre problème. La distribution n'est pas en cause.
C'est la config par defaut de la Debian. Un admin qui n'a pas l'experience se dira que si c'est Debian c'est que c'est bien sans se douter.
Un peu comme du Windows quoi.
Non, tu regrettes les mauvais choix des précédents administrateurs de ladite machine. Un spamd n'a rien à faire sur un MX frontal.
Non bien sur, dans un PME on va investir 3 serveurs pour monter un MX.
Un spamd peut avoir sa place sur un MX frontal, il s'agit simplement de bien le configurer.
-- http://unices.over-blog.com/ Un Francais en Chine
yl
In article , JKB writes:
[controverse : un admin sérieux n'installe(rait) pas linux sur autre chose qu'un PC.]
Je sais pas ce que W7 vient faire dans cette histoire. Ceci dit, il existe aussi des OS plus stables que Linux pour tourner sur ces architectures plus stables.
Ces OS plus stables ne tournent pas sur PC ???
Il parle certainement de Solaris/sparc dont certaines versions sont tellement stables qu'un bête /etc/init.d/networking restart fait paniquer le système (Solaris 8 sur 420R en configuration maximale mémoire, bug connu qu'on retrouve aussi sur les U80).
Arf.
Arrete moi si je me trompe : ça fait des années que Solaris tourne sur PC aussi, non ? Bon c'est open. C'est bien. Enfin je trouve (mais ça refuse de s'installer sur une ultrasparc s'il y a moins d'1 Go de RAM.)
Alors, si je veux etre sérieux, j'y met quoi sur mon u10 heing ?
Quant à OpenVMS, je ne l'ai jamais vu tourner sur PC (enfin, si, un bout à l'époque de Digital lorsque DEC voulait porter VMS sur i386).
On m'a fait cadeau d'un 386 Digital que je n'ai pas démarré parce que je procastine. Bonne idée d'y installer un VMS :))))
Bon et si j'ai bien compris le film, mettre autre chose qu'un VMS sur une station de travail VAX çaymal ?
Sinon je ne comprend pas trop pourquoi si c'est si pas bien de mettre un linux sur autre chose qu'un PC, c'est bien quand meme sur PC.
J'ai du rater un épisode parce que là ça fait pas raccord.
--
References:
In article <slrnhjvi1g.big.knatschke@rayleigh.systella.fr>,
JKB <knatschke@koenigsberg.fr> writes:
[controverse : un admin sérieux n'installe(rait) pas linux sur autre
chose qu'un PC.]
Je sais pas ce que W7 vient faire dans cette histoire. Ceci dit, il
existe aussi des OS plus stables que Linux pour tourner sur ces
architectures plus stables.
Ces OS plus stables ne tournent pas sur PC ???
Il parle certainement de Solaris/sparc dont certaines versions
sont tellement stables qu'un bête /etc/init.d/networking
restart fait paniquer le système (Solaris 8 sur 420R en
configuration maximale mémoire, bug connu qu'on retrouve
aussi sur les U80).
Arf.
Arrete moi si je me trompe : ça fait des années que Solaris tourne
sur PC aussi, non ? Bon c'est open. C'est bien. Enfin je trouve
(mais ça refuse de s'installer sur une ultrasparc s'il y a moins d'1
Go de RAM.)
Alors, si je veux etre sérieux, j'y met quoi sur mon u10 heing ?
Quant à
OpenVMS, je ne l'ai jamais vu tourner sur PC (enfin, si, un bout à
l'époque de Digital lorsque DEC voulait porter VMS sur i386).
On m'a fait cadeau d'un 386 Digital que je n'ai pas démarré parce que
je procastine. Bonne idée d'y installer un VMS :))))
Bon et si j'ai bien compris le film, mettre autre chose qu'un VMS sur
une station de travail VAX çaymal ?
Sinon je ne comprend pas trop pourquoi si c'est si pas bien de mettre
un linux sur autre chose qu'un PC, c'est bien quand meme sur PC.
J'ai du rater un épisode parce que là ça fait pas raccord.
[controverse : un admin sérieux n'installe(rait) pas linux sur autre chose qu'un PC.]
Je sais pas ce que W7 vient faire dans cette histoire. Ceci dit, il existe aussi des OS plus stables que Linux pour tourner sur ces architectures plus stables.
Ces OS plus stables ne tournent pas sur PC ???
Il parle certainement de Solaris/sparc dont certaines versions sont tellement stables qu'un bête /etc/init.d/networking restart fait paniquer le système (Solaris 8 sur 420R en configuration maximale mémoire, bug connu qu'on retrouve aussi sur les U80).
Arf.
Arrete moi si je me trompe : ça fait des années que Solaris tourne sur PC aussi, non ? Bon c'est open. C'est bien. Enfin je trouve (mais ça refuse de s'installer sur une ultrasparc s'il y a moins d'1 Go de RAM.)
Alors, si je veux etre sérieux, j'y met quoi sur mon u10 heing ?
Quant à OpenVMS, je ne l'ai jamais vu tourner sur PC (enfin, si, un bout à l'époque de Digital lorsque DEC voulait porter VMS sur i386).
On m'a fait cadeau d'un 386 Digital que je n'ai pas démarré parce que je procastine. Bonne idée d'y installer un VMS :))))
Bon et si j'ai bien compris le film, mettre autre chose qu'un VMS sur une station de travail VAX çaymal ?
Sinon je ne comprend pas trop pourquoi si c'est si pas bien de mettre un linux sur autre chose qu'un PC, c'est bien quand meme sur PC.
J'ai du rater un épisode parce que là ça fait pas raccord.
J'ai pas dit que c'était compliqué c'était juste la première fois que je configurais un serveur de mail. Ce qui a été compliqué c'est trouver la bonne section où mettre la règle. Mettre une socket IP au lieu d'une socket Unix est trivial oui. Bon, c'est exim4 où tout ce qui est trivial devient une épopée. Ceci dit je le réutiliserai parce que ce n'est pas non plus obscur comme administration. Le spamd collé au MX n'est pas la configuration par défaut de debian. Moi le daemon spamassassin tounait sur mon ordi de bureau ça ne le ralentissait pas meme quand je claquait la porte au nez à des vagues de spoums. Puis sur le serveur de mail lui meme et la il y avait un peu de lag (pentium avec 64Mo de RAM) mais ça passait quand meme.
C'est la carte ethernet du serveur qui a flanché. J'aimerai bien lire d'autres arguments que la surcharge éventuelle et le ralentissement hypothétique du serveur contre cette pratique qui évite le /dev/null (contraire aux RFC mail et/ou les bounces mal dirigés... un 400 sugffit à la fin du DATA ou bien on peut jouer au chat et à la souris avec le spammeur en mettant un faux greylisting, la possibilité de laisser le spamd gérer le vrai greylisting et d'utiliser des RBL pour scorer le message au lieu de le faire en tout ou rien, ce qui évite de jeter un message au ehlo alors que tout le subnet a été listé pour un spoum (c'est arrivé aux MX de free et de tous les autres FSI français, quelle que soit leur politique antispam)
Pour ça, une seule solution, utiliser milter-greylist et sendmail ou postfix.
Je ne demande pas comment se passer de spamd durant le ehlo (d'ailleurs spamassassin ou un autre antispoum mixte (rbl+ règle statistique pour scorage+ mots-clés+ quoi ?), mais bien pourquoi s'en passer ? Je n'y ai trouvé que des avantages. ça permet d'éliminer 99% de junk sans retarder le courrier légitime de 1 1/4h ou plus comme avec le greylisting avec sans faux positif et pas comme le blacklisting ou tu es à la merci d'un RPLDNS foireux (trop permissif, ou avec des MX légitimes listés) et si jamais ça arrive quand meme ils sont renseignés par la bannière 400 et comment me prévenir que ça bloque. OK ça prend des ressources. Faudrait faire payer les CPU par les spoummeurs.
Je donnais à manger à spamassassin les spams reçus sur mes autres adresses mail, pour l'apprentissage...
Avant le data je congédiais les proxy et les relais ouvert sur les base d'open-relay et les pièges à spammers triviaux, les violations de SPF. puis une fois le mail reçu il est envoyé au démon spamassassin qui le score (scores sur mots clés, relais listés, les autres cuisines de spamassassin. Spamassassin renvoie le score au MX et en fixant un seuil tu envoies la bannière correspondant à ce score pas spoum 250 OK mail delivered. spoum "400 service unavailable reason %(rapport spamassassin) contact postmaster if this is a mistake", avec l'adrese postmaster non filtrée
O% de faux positifs et 5% de faux négatifs. 25% en comptant ceux que je ne poubellisait qu'après le 250.
C'est exactement pour ça que ça a été écrit. L'installation pour sendmail est triviale. Pour postfix, c'est prévu, mais je ne connais pas.
Pour exim4 le greylisting est relativement simple à mettre en place aussi. Et un mécanisme facile à contourner pour un spoummeur. --
References:
In article <slrnhjvibi.big.knatschke@rayleigh.systella.fr>,
JKB <knatschke@koenigsberg.fr> writes:
J'ai pas dit que c'était compliqué c'était juste la première fois que je
configurais un serveur de mail. Ce qui a été compliqué c'est trouver la
bonne section où mettre la règle. Mettre une socket IP au lieu d'une
socket Unix est trivial oui. Bon, c'est exim4 où tout ce qui est
trivial devient une épopée. Ceci dit je le réutiliserai parce que ce
n'est pas non plus obscur comme administration. Le spamd collé
au MX n'est pas la configuration par défaut de debian. Moi le daemon
spamassassin tounait sur mon ordi de bureau ça ne le ralentissait pas
meme quand je claquait la porte au nez à des vagues de spoums. Puis sur
le serveur de mail lui meme et la il y avait un peu de lag (pentium
avec 64Mo de RAM) mais ça passait quand meme.
C'est la carte ethernet du serveur qui a flanché.
J'aimerai bien lire d'autres arguments que la surcharge éventuelle et
le ralentissement hypothétique du serveur contre cette pratique qui
évite le /dev/null (contraire aux RFC mail et/ou les bounces mal dirigés...
un 400 sugffit à la fin du DATA ou bien on peut jouer au chat et à la
souris avec le spammeur en mettant un faux greylisting, la possibilité
de laisser le spamd gérer le vrai greylisting et d'utiliser des RBL
pour scorer le message au lieu de le faire en tout ou rien, ce qui évite
de jeter un message au ehlo alors que tout le subnet a été listé pour
un spoum (c'est arrivé aux MX de free et de tous les autres FSI français,
quelle que soit leur politique antispam)
Pour ça, une seule solution, utiliser milter-greylist et sendmail
ou postfix.
Je ne demande pas comment se passer de spamd durant le ehlo (d'ailleurs
spamassassin ou un autre antispoum mixte (rbl+ règle statistique pour
scorage+ mots-clés+ quoi ?),
mais bien pourquoi s'en passer ?
Je n'y ai trouvé que des avantages.
ça permet d'éliminer 99% de junk sans retarder le courrier légitime
de 1 1/4h ou plus comme avec le greylisting avec sans faux positif
et pas comme le blacklisting ou tu es à la merci d'un RPLDNS foireux
(trop permissif, ou avec des MX légitimes listés) et si jamais ça arrive
quand meme ils sont renseignés par la bannière 400 et comment me prévenir
que ça bloque. OK ça prend des ressources. Faudrait faire payer les CPU par les
spoummeurs.
Je donnais à manger à spamassassin les spams reçus sur mes autres
adresses mail, pour l'apprentissage...
Avant le data je congédiais les proxy et les relais ouvert sur les
base d'open-relay et les pièges à spammers triviaux, les violations
de SPF. puis une fois le mail reçu il est envoyé au démon spamassassin
qui le score (scores sur mots clés, relais listés, les autres cuisines
de spamassassin. Spamassassin renvoie le score au MX et en fixant un
seuil tu envoies la bannière correspondant à ce score pas spoum 250 OK
mail delivered.
spoum "400 service unavailable reason %(rapport spamassassin) contact
postmaster if this is a mistake", avec l'adrese postmaster non filtrée
O% de faux positifs et 5% de faux négatifs. 25% en comptant ceux que je
ne poubellisait qu'après le 250.
C'est exactement pour ça que ça a été écrit.
L'installation pour sendmail est triviale. Pour postfix, c'est
prévu, mais je ne connais pas.
Pour exim4 le greylisting est relativement simple à mettre en place
aussi. Et un mécanisme facile à contourner pour un spoummeur.
--
J'ai pas dit que c'était compliqué c'était juste la première fois que je configurais un serveur de mail. Ce qui a été compliqué c'est trouver la bonne section où mettre la règle. Mettre une socket IP au lieu d'une socket Unix est trivial oui. Bon, c'est exim4 où tout ce qui est trivial devient une épopée. Ceci dit je le réutiliserai parce que ce n'est pas non plus obscur comme administration. Le spamd collé au MX n'est pas la configuration par défaut de debian. Moi le daemon spamassassin tounait sur mon ordi de bureau ça ne le ralentissait pas meme quand je claquait la porte au nez à des vagues de spoums. Puis sur le serveur de mail lui meme et la il y avait un peu de lag (pentium avec 64Mo de RAM) mais ça passait quand meme.
C'est la carte ethernet du serveur qui a flanché. J'aimerai bien lire d'autres arguments que la surcharge éventuelle et le ralentissement hypothétique du serveur contre cette pratique qui évite le /dev/null (contraire aux RFC mail et/ou les bounces mal dirigés... un 400 sugffit à la fin du DATA ou bien on peut jouer au chat et à la souris avec le spammeur en mettant un faux greylisting, la possibilité de laisser le spamd gérer le vrai greylisting et d'utiliser des RBL pour scorer le message au lieu de le faire en tout ou rien, ce qui évite de jeter un message au ehlo alors que tout le subnet a été listé pour un spoum (c'est arrivé aux MX de free et de tous les autres FSI français, quelle que soit leur politique antispam)
Pour ça, une seule solution, utiliser milter-greylist et sendmail ou postfix.
Je ne demande pas comment se passer de spamd durant le ehlo (d'ailleurs spamassassin ou un autre antispoum mixte (rbl+ règle statistique pour scorage+ mots-clés+ quoi ?), mais bien pourquoi s'en passer ? Je n'y ai trouvé que des avantages. ça permet d'éliminer 99% de junk sans retarder le courrier légitime de 1 1/4h ou plus comme avec le greylisting avec sans faux positif et pas comme le blacklisting ou tu es à la merci d'un RPLDNS foireux (trop permissif, ou avec des MX légitimes listés) et si jamais ça arrive quand meme ils sont renseignés par la bannière 400 et comment me prévenir que ça bloque. OK ça prend des ressources. Faudrait faire payer les CPU par les spoummeurs.
Je donnais à manger à spamassassin les spams reçus sur mes autres adresses mail, pour l'apprentissage...
Avant le data je congédiais les proxy et les relais ouvert sur les base d'open-relay et les pièges à spammers triviaux, les violations de SPF. puis une fois le mail reçu il est envoyé au démon spamassassin qui le score (scores sur mots clés, relais listés, les autres cuisines de spamassassin. Spamassassin renvoie le score au MX et en fixant un seuil tu envoies la bannière correspondant à ce score pas spoum 250 OK mail delivered. spoum "400 service unavailable reason %(rapport spamassassin) contact postmaster if this is a mistake", avec l'adrese postmaster non filtrée
O% de faux positifs et 5% de faux négatifs. 25% en comptant ceux que je ne poubellisait qu'après le 250.
C'est exactement pour ça que ça a été écrit. L'installation pour sendmail est triviale. Pour postfix, c'est prévu, mais je ne connais pas.
Pour exim4 le greylisting est relativement simple à mettre en place aussi. Et un mécanisme facile à contourner pour un spoummeur. --
References:
yl
In article , Stephane TOUGARD writes:
Yves Lambert a perdu son temps a nous dire:
Ta critique n'a absolument aucun lien avec la qualité de la distribution, donc.
Ma critique est constructive et n'est pas lie a un sentiment.
Par contre, j'ai exprime un sentiment contre certaines personnes, mais ca n'a rien a voir avec les qualites/defauts techniques de la Debian.
Pourtant c'est ce que tu as fait jusqu'à présent. Avec des arguments
Non, c'est pas ce que je fais. Mais c'est pas grave, depuis JKB, le proces d'intention est devenu affaire courante sur fcold.
Le fork n'est pas un processus normal de développement d'un logiciel libre ...
Qui t'a parle de fork ?
C'est d'ailleurs une des raison d'être de Debian : fournir un
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~ ~~
excellent creuset pour les autres.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On parle de dstributions là non ? Quand un LL fournit la base pour le développement d'un autre, respectivement une distibution lma base pour le développement d'une autre, le cereuset, il y a bien deux choses qui apparaissent, deux branches. Avec deux équipes de développements qui ^artent du meme code et le font évoluer chacun de son coté. Et comme on vit en bonne intelligence (ou pas) les améliorations de l'un peuvent profiter (ou pas) à l'autre et vice-versa. On est bien d'accord. non ?
Je parle de «creuset pour les autres» ou de fork; là ? En quoi le premier n'implique pas le second ?
C'est une raison d'etre de toutes les distributions, c'est une raison
Heureux de l'apprendre mais c'est toujours non. Ou alors explique ce que *tu* n'as pas compris dans la discussion que *tu* as initié à propos de debian qui avait permis l'émergence d'ubuntu etc.
Sans blaguer, tu n'as pas compris un seul de mes arguments.
Quels sont ils ? En quoi une des raison d'etre d'un logiciel libre (quel qu'il soit) est il de servir de base pour un autre logiciel libre ?????
T'as des problemes de lectures ?
Non.
elle en dit quoi ta maitresse ?
Pleins de choses qui ne te regarde pas. Voyeur. --
References:
In article <luu317-g7p1.ln1@gulliver.unices.org>,
Stephane TOUGARD <jkb@unices.org> writes:
Yves Lambert a perdu son temps a nous dire:
Ta critique n'a absolument aucun lien avec la qualité de la distribution,
donc.
Ma critique est constructive et n'est pas lie a un sentiment.
Par contre, j'ai exprime un sentiment contre certaines personnes, mais
ca n'a rien a voir avec les qualites/defauts techniques de la Debian.
Pourtant c'est ce que tu as fait jusqu'à présent. Avec des arguments
Non, c'est pas ce que je fais. Mais c'est pas grave, depuis JKB, le
proces d'intention est devenu affaire courante sur fcold.
Le fork n'est pas un processus normal de développement d'un logiciel
libre ...
Qui t'a parle de fork ?
C'est d'ailleurs une des raison d'être de Debian : fournir un
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~ ~~
excellent creuset pour les autres.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On parle de dstributions là non ? Quand un LL fournit la base pour le
développement d'un autre, respectivement une distibution lma base pour le développement
d'une autre, le cereuset, il y a bien deux choses qui apparaissent, deux
branches. Avec deux équipes de développements qui ^artent du meme code
et le font évoluer chacun de son coté. Et comme on vit en bonne
intelligence (ou pas) les améliorations de l'un peuvent profiter (ou
pas) à l'autre et vice-versa. On est bien d'accord. non ?
Je parle de «creuset pour les autres» ou de fork; là ? En quoi le
premier n'implique pas le second ?
C'est une raison d'etre de toutes les distributions, c'est une raison
Heureux de l'apprendre mais c'est toujours non. Ou alors explique ce
que *tu* n'as pas compris dans la discussion que *tu* as initié à propos
de debian qui avait permis l'émergence d'ubuntu etc.
Sans blaguer, tu n'as pas compris un seul de mes arguments.
Quels sont ils ? En quoi une des raison d'etre d'un logiciel libre
(quel qu'il soit) est il de servir de base pour un autre logiciel libre
?????
T'as des
problemes de lectures ?
Non.
elle en dit quoi ta maitresse ?
Pleins de choses qui ne te regarde pas. Voyeur.
--
Ta critique n'a absolument aucun lien avec la qualité de la distribution, donc.
Ma critique est constructive et n'est pas lie a un sentiment.
Par contre, j'ai exprime un sentiment contre certaines personnes, mais ca n'a rien a voir avec les qualites/defauts techniques de la Debian.
Pourtant c'est ce que tu as fait jusqu'à présent. Avec des arguments
Non, c'est pas ce que je fais. Mais c'est pas grave, depuis JKB, le proces d'intention est devenu affaire courante sur fcold.
Le fork n'est pas un processus normal de développement d'un logiciel libre ...
Qui t'a parle de fork ?
C'est d'ailleurs une des raison d'être de Debian : fournir un
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~ ~~
excellent creuset pour les autres.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On parle de dstributions là non ? Quand un LL fournit la base pour le développement d'un autre, respectivement une distibution lma base pour le développement d'une autre, le cereuset, il y a bien deux choses qui apparaissent, deux branches. Avec deux équipes de développements qui ^artent du meme code et le font évoluer chacun de son coté. Et comme on vit en bonne intelligence (ou pas) les améliorations de l'un peuvent profiter (ou pas) à l'autre et vice-versa. On est bien d'accord. non ?
Je parle de «creuset pour les autres» ou de fork; là ? En quoi le premier n'implique pas le second ?
C'est une raison d'etre de toutes les distributions, c'est une raison
Heureux de l'apprendre mais c'est toujours non. Ou alors explique ce que *tu* n'as pas compris dans la discussion que *tu* as initié à propos de debian qui avait permis l'émergence d'ubuntu etc.
Sans blaguer, tu n'as pas compris un seul de mes arguments.
Quels sont ils ? En quoi une des raison d'etre d'un logiciel libre (quel qu'il soit) est il de servir de base pour un autre logiciel libre ?????
T'as des problemes de lectures ?
Non.
elle en dit quoi ta maitresse ?
Pleins de choses qui ne te regarde pas. Voyeur. --
References:
yl
In article , Stephane TOUGARD writes:
Yves Lambert a perdu son temps a nous dire:
Ta critique n'a absolument aucun lien avec la qualité de la distribution, donc.
Ma critique est constructive
Peut etre.
et n'est pas lie a un sentiment.
Sans doute. Mais elle n'a aucun lien avec la qualité de la distribution.
Par contre, j'ai exprime un sentiment contre certaines personnes, mais ca n'a rien a voir avec les qualites/defauts techniques de la Debian.
Oui. Mais la critique que tu as exprimé ne porte pas sur la qualité de la distribution.
Pourtant c'est ce que tu as fait jusqu'à présent. Avec des arguments
Non, c'est pas ce que je fais. Mais c'est pas grave, depuis JKB, le proces d'intention est devenu affaire courante sur fcold.
Je ne te fais pas de procès d'intentiuon, je te fais juste remarquer que tu as changé d'angle de vue, comme ça, preque san s prévenir. C'est déroutant.
--
References:
In article <luu317-g7p1.ln1@gulliver.unices.org>,
Stephane TOUGARD <jkb@unices.org> writes:
Yves Lambert a perdu son temps a nous dire:
Ta critique n'a absolument aucun lien avec la qualité de la distribution,
donc.
Ma critique est constructive
Peut etre.
et n'est pas lie a un sentiment.
Sans doute. Mais elle n'a aucun lien avec la qualité de la distribution.
Par contre, j'ai exprime un sentiment contre certaines personnes, mais
ca n'a rien a voir avec les qualites/defauts techniques de la Debian.
Oui. Mais la critique que tu as exprimé ne porte pas sur la qualité de
la distribution.
Pourtant c'est ce que tu as fait jusqu'à présent. Avec des arguments
Non, c'est pas ce que je fais. Mais c'est pas grave, depuis JKB, le
proces d'intention est devenu affaire courante sur fcold.
Je ne te fais pas de procès d'intentiuon, je te fais juste remarquer que
tu as changé d'angle de vue, comme ça, preque san s prévenir. C'est
déroutant.
Ta critique n'a absolument aucun lien avec la qualité de la distribution, donc.
Ma critique est constructive
Peut etre.
et n'est pas lie a un sentiment.
Sans doute. Mais elle n'a aucun lien avec la qualité de la distribution.
Par contre, j'ai exprime un sentiment contre certaines personnes, mais ca n'a rien a voir avec les qualites/defauts techniques de la Debian.
Oui. Mais la critique que tu as exprimé ne porte pas sur la qualité de la distribution.
Pourtant c'est ce que tu as fait jusqu'à présent. Avec des arguments
Non, c'est pas ce que je fais. Mais c'est pas grave, depuis JKB, le proces d'intention est devenu affaire courante sur fcold.
Je ne te fais pas de procès d'intentiuon, je te fais juste remarquer que tu as changé d'angle de vue, comme ça, preque san s prévenir. C'est déroutant.
--
References:
Stephane TOUGARD
Riquer Vincent a perdu son temps a nous dire:
Couper le passage où je parle de datas de jeux te permet de dire ça. En remettant ce passage, ta réponse est juste à côté de la plaque.
Bien, sur un disque de 60Gb, tu n'as pas les 500Mb necessaires pour installer les *-dev et les *-doc qui vont bien.
Et je n'ai pas parlé de limitations dûes à l'espace disque sur l'ARM, juste de l'inutilité d'avoir ces données.
Oui bien sur, donc parce que tu as un ARM, il faut absolument que tous les packages de la Debian soient splites en petits bouts.
-- http://unices.over-blog.com/ Un Francais en Chine
Riquer Vincent a perdu son temps a nous dire:
Couper le passage où je parle de datas de jeux te permet de dire ça. En
remettant ce passage, ta réponse est juste à côté de la plaque.
Bien, sur un disque de 60Gb, tu n'as pas les 500Mb necessaires pour
installer les *-dev et les *-doc qui vont bien.
Et je n'ai pas parlé de limitations dûes à l'espace disque sur l'ARM,
juste de l'inutilité d'avoir ces données.
Oui bien sur, donc parce que tu as un ARM, il faut absolument que tous
les packages de la Debian soient splites en petits bouts.
--
http://unices.over-blog.com/ Un Francais en Chine
