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.
C'est à dire un serveur smtp utilisé en réception, c'est bien ça ?
Je ne connaissais pas cet adage et je l'ai eu fait, pire, le spamd tournait sur une autre machine et communiquait en TCP avec le MX avec un fallback en cas de non réponse du démon - OK je n'avais pas beaucoup de charge - mais je n'y ai vu que des avantages. ça n'est pas du tout la configuration/défaut de debian et il a famllu que j'intuite bien le trruxc pour que ça fonctionne et ça fonctionnait. 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)
--
References:
In article <dl3417-ak8.ln1@sd-2862.dedibox.fr>,
Riquer Vincent <vincent@riquer.fr> writes:
Un spamd n'a rien à faire sur un MX frontal.
C'est à dire un serveur smtp utilisé en réception, c'est bien ça ?
Je ne connaissais pas cet adage et je l'ai eu fait, pire, le spamd
tournait sur une autre machine et communiquait en TCP avec le MX avec
un fallback en cas de non réponse du démon - OK je n'avais pas
beaucoup de charge - mais je n'y ai vu que des avantages.
ça n'est pas du tout la configuration/défaut de debian et il a famllu
que j'intuite bien le trruxc pour que ça fonctionne et ça fonctionnait.
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)
C'est à dire un serveur smtp utilisé en réception, c'est bien ça ?
Je ne connaissais pas cet adage et je l'ai eu fait, pire, le spamd tournait sur une autre machine et communiquait en TCP avec le MX avec un fallback en cas de non réponse du démon - OK je n'avais pas beaucoup de charge - mais je n'y ai vu que des avantages. ça n'est pas du tout la configuration/défaut de debian et il a famllu que j'intuite bien le trruxc pour que ça fonctionne et ça fonctionnait. 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)
--
References:
JKB
Le 02-01-2010, ? propos de Re: KDE tuera Windows, Riquer Vincent ?crivait dans fr.comp.os.linux.debats :
Patrice Karatchentzeff a écrit :
Riquer Vincent a écrit :
Stephane TOUGARD a écrit :
[...]
Gimp en 2.4.7 (contre la 2.6) dcraw 8.86 (contre la 8.98, la difference est enorme) ufraw 0.13 (contre la 0.16)
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.
Bof... quand la distribution de la mort qui tue deux ans auparavant avaient tous ces logiciels dans la *même* version, on ne l'utilisait pas pour faire du desktop ?
Si, très bien. Par contre, avec l'âge d'un OS apparraissent des problèmes de support des nouveaux matériels. Sur un serveur on s'en fout, mais sur un desktop, tu préfères que ton imprimante fonctionne « toute seule ». L'imprimante n'est qu'un exemple, inutile de me répondre que certaines marques sont bien supportées etc :)
http://packages.debian.org/source/lenny-backports/linux-2.6 C'est à l'heure où j'écris un 2.6.30. Ce qui est bien pour une distribution obsolète et le support des matériels récents.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 02-01-2010, ? propos de
Re: KDE tuera Windows,
Riquer Vincent ?crivait dans fr.comp.os.linux.debats :
Patrice Karatchentzeff a écrit :
Riquer Vincent <vincent@riquer.fr> a écrit :
Stephane TOUGARD a écrit :
[...]
Gimp en 2.4.7 (contre la 2.6) dcraw 8.86 (contre la 8.98, la
difference est enorme) ufraw 0.13 (contre la 0.16)
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.
Bof... quand la distribution de la mort qui tue deux ans auparavant
avaient tous ces logiciels dans la *même* version, on ne l'utilisait
pas pour faire du desktop ?
Si, très bien. Par contre, avec l'âge d'un OS apparraissent des
problèmes de support des nouveaux matériels. Sur un serveur on s'en
fout, mais sur un desktop, tu préfères que ton imprimante fonctionne «
toute seule ».
L'imprimante n'est qu'un exemple, inutile de me répondre que certaines
marques sont bien supportées etc :)
http://packages.debian.org/source/lenny-backports/linux-2.6
C'est à l'heure où j'écris un 2.6.30. Ce qui est bien pour une
distribution obsolète et le support des matériels récents.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 02-01-2010, ? propos de Re: KDE tuera Windows, Riquer Vincent ?crivait dans fr.comp.os.linux.debats :
Patrice Karatchentzeff a écrit :
Riquer Vincent a écrit :
Stephane TOUGARD a écrit :
[...]
Gimp en 2.4.7 (contre la 2.6) dcraw 8.86 (contre la 8.98, la difference est enorme) ufraw 0.13 (contre la 0.16)
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.
Bof... quand la distribution de la mort qui tue deux ans auparavant avaient tous ces logiciels dans la *même* version, on ne l'utilisait pas pour faire du desktop ?
Si, très bien. Par contre, avec l'âge d'un OS apparraissent des problèmes de support des nouveaux matériels. Sur un serveur on s'en fout, mais sur un desktop, tu préfères que ton imprimante fonctionne « toute seule ». L'imprimante n'est qu'un exemple, inutile de me répondre que certaines marques sont bien supportées etc :)
http://packages.debian.org/source/lenny-backports/linux-2.6 C'est à l'heure où j'écris un 2.6.30. Ce qui est bien pour une distribution obsolète et le support des matériels récents.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
JKB
Le 02-01-2010, ? propos de Re: KDE tuera Windows, Yves Lambert ?crivait dans fr.comp.os.linux.debats :
In article , Stephane TOUGARD writes:
Yves Lambert a perdu son temps a nous dire:
Il n'y a pas qu'IBM PC dans la vie. Il parait meme qu'il existe des architectures plus stables y compris chez IBM. Seulement on ne peut pas y mettre windows 7 dessus.
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). 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).
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 02-01-2010, ? propos de
Re: KDE tuera Windows,
Yves Lambert ?crivait dans fr.comp.os.linux.debats :
In article <euq317-jg31.ln1@gulliver.unices.org>,
Stephane TOUGARD <jkb@unices.org> writes:
Yves Lambert a perdu son temps a nous dire:
Il n'y a pas qu'IBM PC dans la vie. Il parait meme qu'il existe des
architectures plus stables y compris chez IBM. Seulement on ne peut
pas y mettre windows 7 dessus.
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). 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).
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 02-01-2010, ? propos de Re: KDE tuera Windows, Yves Lambert ?crivait dans fr.comp.os.linux.debats :
In article , Stephane TOUGARD writes:
Yves Lambert a perdu son temps a nous dire:
Il n'y a pas qu'IBM PC dans la vie. Il parait meme qu'il existe des architectures plus stables y compris chez IBM. Seulement on ne peut pas y mettre windows 7 dessus.
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). 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).
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
JKB
Le 02-01-2010, ? propos de Re: KDE tuera Windows, Yves Lambert ?crivait dans fr.comp.os.linux.debats :
In article , Riquer Vincent writes:
Un spamd n'a rien à faire sur un MX frontal.
C'est à dire un serveur smtp utilisé en réception, c'est bien ça ?
Je ne connaissais pas cet adage et je l'ai eu fait, pire, le spamd tournait sur une autre machine et communiquait en TCP avec le MX avec un fallback en cas de non réponse du démon - OK je n'avais pas beaucoup de charge - mais je n'y ai vu que des avantages. ça n'est pas du tout la configuration/défaut de debian et il a famllu que j'intuite bien le trruxc pour que ça fonctionne et ça fonctionnait.
Pardon ? Je ne sais pas avec quel MX tu jouais, mais en tout cas, avec sendmail, c'est trivial. Le milter se branche dans sendmail et attaque spamd sur une socket réseau comme il attaquerait sa socket locale.
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. 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.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 02-01-2010, ? propos de
Re: KDE tuera Windows,
Yves Lambert ?crivait dans fr.comp.os.linux.debats :
In article <dl3417-ak8.ln1@sd-2862.dedibox.fr>,
Riquer Vincent <vincent@riquer.fr> writes:
Un spamd n'a rien à faire sur un MX frontal.
C'est à dire un serveur smtp utilisé en réception, c'est bien ça ?
Je ne connaissais pas cet adage et je l'ai eu fait, pire, le spamd
tournait sur une autre machine et communiquait en TCP avec le MX avec
un fallback en cas de non réponse du démon - OK je n'avais pas
beaucoup de charge - mais je n'y ai vu que des avantages.
ça n'est pas du tout la configuration/défaut de debian et il a famllu
que j'intuite bien le trruxc pour que ça fonctionne et ça fonctionnait.
Pardon ? Je ne sais pas avec quel MX tu jouais, mais en tout cas,
avec sendmail, c'est trivial. Le milter se branche dans sendmail et
attaque spamd sur une socket réseau comme il attaquerait sa socket
locale.
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. 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.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 02-01-2010, ? propos de Re: KDE tuera Windows, Yves Lambert ?crivait dans fr.comp.os.linux.debats :
In article , Riquer Vincent writes:
Un spamd n'a rien à faire sur un MX frontal.
C'est à dire un serveur smtp utilisé en réception, c'est bien ça ?
Je ne connaissais pas cet adage et je l'ai eu fait, pire, le spamd tournait sur une autre machine et communiquait en TCP avec le MX avec un fallback en cas de non réponse du démon - OK je n'avais pas beaucoup de charge - mais je n'y ai vu que des avantages. ça n'est pas du tout la configuration/défaut de debian et il a famllu que j'intuite bien le trruxc pour que ça fonctionne et ça fonctionnait.
Pardon ? Je ne sais pas avec quel MX tu jouais, mais en tout cas, avec sendmail, c'est trivial. Le milter se branche dans sendmail et attaque spamd sur une socket réseau comme il attaquerait sa socket locale.
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. 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.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Nicolas George
Riquer Vincent , dans le message , a écrit :
Si, très bien. Par contre, avec l'âge d'un OS apparraissent des problèmes de support des nouveaux matériels.
Stephane TOUGARD parlait de Gimp. Que je sache, Gimp n'a pas de problème de support matériel.
Riquer Vincent , dans le message <i4k417-v9m.ln1@sd-2862.dedibox.fr>, a
écrit :
Si, très bien. Par contre, avec l'âge d'un OS apparraissent des
problèmes de support des nouveaux matériels.
Stephane TOUGARD parlait de Gimp. Que je sache, Gimp n'a pas de problème de
support matériel.
Si, très bien. Par contre, avec l'âge d'un OS apparraissent des problèmes de support des nouveaux matériels.
Stephane TOUGARD parlait de Gimp. Que je sache, Gimp n'a pas de problème de support matériel.
Pierre P
Yves Lambert a écrit :
3. Que les blockbusters comme Firefox ou Open Office bénéficient d'un processus de validation S'il n'y aurait pas moyen de les intégrer différemment dans les distributions. Je n'ai pas d'idée précise, mais j'ai l'intuition qu'il y a quelque chose à faire, sans que ça soit harassant pour le mainteneur du paquetage qui se tape les versions instables (qui changent au rythme que tu (et tu ne dois pas etre le seul) souhaiterais mais ne sont pas full proof ;)
Peut-être que si le mainteneur fait parti du projet les mises à jour peuvent devenir automatiques en intégrant directement les dépôts ?
Yves Lambert a écrit :
3. Que les blockbusters comme Firefox ou Open Office bénéficient d'un
processus de validation
S'il n'y aurait pas moyen de les intégrer différemment dans les
distributions. Je n'ai pas d'idée précise, mais j'ai l'intuition
qu'il y a quelque chose à faire, sans que ça soit harassant pour le
mainteneur du paquetage qui se tape les versions instables (qui
changent au rythme que tu (et tu ne dois pas etre le seul)
souhaiterais mais ne sont pas full proof ;)
Peut-être que si le mainteneur fait parti du projet les mises à jour
peuvent devenir automatiques en intégrant directement les dépôts ?
3. Que les blockbusters comme Firefox ou Open Office bénéficient d'un processus de validation S'il n'y aurait pas moyen de les intégrer différemment dans les distributions. Je n'ai pas d'idée précise, mais j'ai l'intuition qu'il y a quelque chose à faire, sans que ça soit harassant pour le mainteneur du paquetage qui se tape les versions instables (qui changent au rythme que tu (et tu ne dois pas etre le seul) souhaiterais mais ne sont pas full proof ;)
Peut-être que si le mainteneur fait parti du projet les mises à jour peuvent devenir automatiques en intégrant directement les dépôts ?
Riquer Vincent
Yves Lambert a écrit :
In article , Riquer Vincent writes:
Un spamd n'a rien à faire sur un MX frontal.
C'est à dire un serveur smtp utilisé en réception, c'est bien ça ?
Je ne connaissais pas cet adage et je l'ai eu fait, pire, le spamd tournait sur une autre machine et communiquait en TCP avec le MX avec
Voilà, tu avais un MX en frontal qui communiquait avec une autre machine qui elle faisait tourner un spamd.
Yves Lambert a écrit :
In article <dl3417-ak8.ln1@sd-2862.dedibox.fr>,
Riquer Vincent <vincent@riquer.fr> writes:
Un spamd n'a rien à faire sur un MX frontal.
C'est à dire un serveur smtp utilisé en réception, c'est bien ça ?
Je ne connaissais pas cet adage et je l'ai eu fait, pire, le spamd
tournait sur une autre machine et communiquait en TCP avec le MX avec
Voilà, tu avais un MX en frontal qui communiquait avec une autre machine
qui elle faisait tourner un spamd.
Si, très bien. Par contre, avec l'âge d'un OS apparraissent des problèmes de support des nouveaux matériels.
Stephane TOUGARD parlait de Gimp. Que je sache, Gimp n'a pas de problème de support matériel.
Vu la pirouette de Monsieur Tougard avec son histoire de Canon D70, je suis curieux de savoir ce qui lui manque dans Gimp.
Je n'utilises pas gimp, je me contente de mettre les photos à l'endroit, pour les logiciels qui ne savant pas exploiter l'orientation EXIF.
Riquer Vincent
JKB a écrit :
http://packages.debian.org/source/lenny-backports/linux-2.6 C'est à l'heure où j'écris un 2.6.30. Ce qui est bien pour une distribution obsolète et le support des matériels récents.
Ouais, backports, c'est pas non plus super pratique. Il me semble qu'on est obligé de faire du pinning pour chaque paquet. Et tout n'est pas disponible dans backports. D'ailleurs, les imprimantes, c'est CUPS, pas le kernel (ok ça doit y être aussi) :)
Par contre, tu n'as pas le serveur X dans backports.
JKB a écrit :
http://packages.debian.org/source/lenny-backports/linux-2.6
C'est à l'heure où j'écris un 2.6.30. Ce qui est bien pour une
distribution obsolète et le support des matériels récents.
Ouais, backports, c'est pas non plus super pratique. Il me semble qu'on
est obligé de faire du pinning pour chaque paquet. Et tout n'est pas
disponible dans backports. D'ailleurs, les imprimantes, c'est CUPS, pas
le kernel (ok ça doit y être aussi) :)
Par contre, tu n'as pas le serveur X dans backports.
http://packages.debian.org/source/lenny-backports/linux-2.6 C'est à l'heure où j'écris un 2.6.30. Ce qui est bien pour une distribution obsolète et le support des matériels récents.
Ouais, backports, c'est pas non plus super pratique. Il me semble qu'on est obligé de faire du pinning pour chaque paquet. Et tout n'est pas disponible dans backports. D'ailleurs, les imprimantes, c'est CUPS, pas le kernel (ok ça doit y être aussi) :)
Par contre, tu n'as pas le serveur X dans backports.
talon
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 et se permettent quelques fantaisies du genre de la célèbre manipulation de ssh.
--
Michel TALON
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 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 et se permettent quelques fantaisies du genre de la célèbre manipulation de ssh.
