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.
testing et unstable en fonction de ses besoins. Le besoin pour un serveur de prod n'est pas celui d'une machine de bureau (d'ailleurs, je n'ai même pas de carte graphique sur mes serveurs). Mes serveurs
Oui enfin on parlait de desktop...
On est d'accord : sur un desktop, testing ou unstable.
JKB a écrit :
testing et unstable en fonction de ses besoins. Le besoin pour un
serveur de prod n'est pas celui d'une machine de bureau (d'ailleurs,
je n'ai même pas de carte graphique sur mes serveurs). Mes serveurs
Oui enfin on parlait de desktop...
On est d'accord : sur un desktop, testing ou unstable.
testing et unstable en fonction de ses besoins. Le besoin pour un serveur de prod n'est pas celui d'une machine de bureau (d'ailleurs, je n'ai même pas de carte graphique sur mes serveurs). Mes serveurs
Oui enfin on parlait de desktop...
On est d'accord : sur un desktop, testing ou unstable.
Hugolino
Le 03-01-2010, Yves Lambert a écrit :
YBM writes:
<...> >> et se permettent quelques fantaisies >> du genre de la célèbre manipulation de ssh. > > Tss, sophiste.
Je n'ai pas entendu causer de ça. Qu'est-ce que c'est ?
Tu as passé la dernière décennie au fond d'une grotte d'Afghanistan et tu viens d'être libéré ?
Une amorce de serrage en 2T sur une décélération prolongée, moi j'appelle ça un défaut de lubrification.
Une décélératrion prolongée sur un 2T, moi j'appelle ça de la connerie. Hugo (né il y a 1 441 984 909 secondes)
Stéphane CARPENTIER
Yves Lambert wrote:
In article <4b3feff2$0$23332$, YBM writes:
En d'autres termes les "développeurs Debian" se croient plus malins que les auteurs originaux des softs
Ils ont presque toujours raison.
Tout dépend où se situe le «presque». C'est pas très sympa pour les développeur ça
Il y a une différence entre développer un soft pour qu'il réponde à un besoin et le faire tourner dans un environnement. Les développeurs de debian ne se croient pas plus malins que les développeurs des softs originaux pour ce qui est de son fonctionnement normal. Par contre, ils ont presque toujours raison pour son intégration dans l'environnement debian.
Ce n'est pas insultant pour les développeurs originaux, c'est reconnaître qu'ils ne font pas le même métier.
Yves Lambert wrote:
In article <4b3feff2$0$23332$426a34cc@news.free.fr>,
YBM <ybmess@nooos.fr.invalid> writes:
En d'autres termes les "développeurs Debian" se croient plus malins
que les auteurs originaux des softs
Ils ont presque toujours raison.
Tout dépend où se situe le «presque». C'est pas très sympa pour les
développeur ça
Il y a une différence entre développer un soft pour qu'il réponde à un
besoin et le faire tourner dans un environnement. Les développeurs de
debian ne se croient pas plus malins que les développeurs des softs
originaux pour ce qui est de son fonctionnement normal. Par contre, ils
ont presque toujours raison pour son intégration dans l'environnement
debian.
Ce n'est pas insultant pour les développeurs originaux, c'est
reconnaître qu'ils ne font pas le même métier.
En d'autres termes les "développeurs Debian" se croient plus malins que les auteurs originaux des softs
Ils ont presque toujours raison.
Tout dépend où se situe le «presque». C'est pas très sympa pour les développeur ça
Il y a une différence entre développer un soft pour qu'il réponde à un besoin et le faire tourner dans un environnement. Les développeurs de debian ne se croient pas plus malins que les développeurs des softs originaux pour ce qui est de son fonctionnement normal. Par contre, ils ont presque toujours raison pour son intégration dans l'environnement debian.
Ce n'est pas insultant pour les développeurs originaux, c'est reconnaître qu'ils ne font pas le même métier.
Stéphane CARPENTIER
Hugolino wrote:
Le 03-01-2010, Yves Lambert a écrit :
YBM writes:
<...>
et se permettent quelques fantaisies du genre de la célèbre manipulation de ssh.
Tss, sophiste.
Je n'ai pas entendu causer de ça. Qu'est-ce que c'est ?
Tu as passé la dernière décennie au fond d'une grotte d'Afghanistan et tu viens d'être libéré ?
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.
Utiliser exim pour un serveur privé (comprendre une station de travail qui a besoin d'un serveur de mail pour que certains daemons puissent envoyer un courrier à l'administrateur en cas de problème), pourquoi pas. L'utiliser sur un vrai serveur de mail est une bêtise tant le truc est troué.
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.
Ta prose est illisible...
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 03-01-2010, ? propos de
Re: KDE tuera Windows,
Yves Lambert ?crivait dans fr.comp.os.linux.debats :
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.
Utiliser exim pour un serveur privé (comprendre une station de
travail qui a besoin d'un serveur de mail pour que certains daemons
puissent envoyer un courrier à l'administrateur en cas de problème),
pourquoi pas. L'utiliser sur un vrai serveur de mail est une bêtise
tant le truc est troué.
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.
Ta prose est illisible...
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.
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.
Utiliser exim pour un serveur privé (comprendre une station de travail qui a besoin d'un serveur de mail pour que certains daemons puissent envoyer un courrier à l'administrateur en cas de problème), pourquoi pas. L'utiliser sur un vrai serveur de mail est une bêtise tant le truc est troué.
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.
Ta prose est illisible...
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 03-01-2010, ? propos de Re: KDE tuera Windows, Patrice Karatchentzeff ?crivait dans fr.comp.os.linux.debats :
Stephane TOUGARD a écrit :
Patrice Karatchentzeff a perdu son temps a nous dire:
C'est quoi des distributions classiques ?
(et encore, je ne relève pas qu'une distribution est une distribution Linux)
Solaris,
N'existe plus en entreprise, sauf grand groupe et encore...
Ça dépend essentiellement du matériel. Personnellement, j'en croise pas mal.
Free/Net/OpenBSD
Tellement marginale que cela existe sans doute encore moins que Solaris...
Slackware
Jamais vu dans une seule entreprise...
Et pour cause ;-)
SuSE
Représente sans doute encore moins d'exemplaire que Solaris...
Là, c'est faux. Tous les produits Novell (iFolder et autres) ne tournent correctement _que_ sur SuSE. Compiler un produit Novell même open source sur une autre distribution relève du masochisme tellement c'est pensé pour forcer à l'utilisation de SuSE. Quiconque a essayé de compiler simias+ifolder+mono me comprendra...
... ce ne sont pas les exemples qui manquent.
Ben si : aligne stp. Des Debian et des RedHat se comptent par paquet de mille et j'ai travaillé dans des dizaines de boîtes, de la microélectronique aux télécom...
Ça m'intéresse aussi. Et je rajouterais qu'on croise de RedHat sur des machines qui ont un logiciels officiellement supporté sur RedHat et pas sur autre chose. Parce que dans l'immense majorité des cas, lorsqu'un administrateur a le choix, il ne prend pas RedHat par défaut.
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 03-01-2010, ? propos de
Re: KDE tuera Windows,
Patrice Karatchentzeff ?crivait dans fr.comp.os.linux.debats :
Stephane TOUGARD <jkb@unices.org> a écrit :
Patrice Karatchentzeff a perdu son temps a nous dire:
C'est quoi des distributions classiques ?
(et encore, je ne relève pas qu'une distribution est une distribution
Linux)
Solaris,
N'existe plus en entreprise, sauf grand groupe et encore...
Ça dépend essentiellement du matériel. Personnellement, j'en croise
pas mal.
Free/Net/OpenBSD
Tellement marginale que cela existe sans doute encore moins que
Solaris...
Slackware
Jamais vu dans une seule entreprise...
Et pour cause ;-)
SuSE
Représente sans doute encore moins d'exemplaire que Solaris...
Là, c'est faux. Tous les produits Novell (iFolder et autres) ne
tournent correctement _que_ sur SuSE. Compiler un produit Novell
même open source sur une autre distribution relève du masochisme
tellement c'est pensé pour forcer à l'utilisation de SuSE. Quiconque
a essayé de compiler simias+ifolder+mono me comprendra...
... ce ne sont pas les exemples qui manquent.
Ben si : aligne stp. Des Debian et des RedHat se comptent par paquet
de mille et j'ai travaillé dans des dizaines de boîtes, de la
microélectronique aux télécom...
Ça m'intéresse aussi. Et je rajouterais qu'on croise de RedHat sur
des machines qui ont un logiciels officiellement supporté sur RedHat
et pas sur autre chose. Parce que dans l'immense majorité des cas,
lorsqu'un administrateur a le choix, il ne prend pas RedHat par
défaut.
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 03-01-2010, ? propos de Re: KDE tuera Windows, Patrice Karatchentzeff ?crivait dans fr.comp.os.linux.debats :
Stephane TOUGARD a écrit :
Patrice Karatchentzeff a perdu son temps a nous dire:
C'est quoi des distributions classiques ?
(et encore, je ne relève pas qu'une distribution est une distribution Linux)
Solaris,
N'existe plus en entreprise, sauf grand groupe et encore...
Ça dépend essentiellement du matériel. Personnellement, j'en croise pas mal.
Free/Net/OpenBSD
Tellement marginale que cela existe sans doute encore moins que Solaris...
Slackware
Jamais vu dans une seule entreprise...
Et pour cause ;-)
SuSE
Représente sans doute encore moins d'exemplaire que Solaris...
Là, c'est faux. Tous les produits Novell (iFolder et autres) ne tournent correctement _que_ sur SuSE. Compiler un produit Novell même open source sur une autre distribution relève du masochisme tellement c'est pensé pour forcer à l'utilisation de SuSE. Quiconque a essayé de compiler simias+ifolder+mono me comprendra...
... ce ne sont pas les exemples qui manquent.
Ben si : aligne stp. Des Debian et des RedHat se comptent par paquet de mille et j'ai travaillé dans des dizaines de boîtes, de la microélectronique aux télécom...
Ça m'intéresse aussi. Et je rajouterais qu'on croise de RedHat sur des machines qui ont un logiciels officiellement supporté sur RedHat et pas sur autre chose. Parce que dans l'immense majorité des cas, lorsqu'un administrateur a le choix, il ne prend pas RedHat par défaut.
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 03-01-2010, ? propos de Re: KDE tuera Windows, Yves Lambert ?crivait dans fr.comp.os.linux.debats :
In article , JKB writes:
Le 02-01-2010, ? propos de Re: KDE tuera Windows, Patrick Lamaizière ?crivait dans fr.comp.os.linux.debats :
Patrice Karatchentzeff :
Un Unix est un OS de developpement philosophiquement parlant. Meme si on ne fait pas de developpement (je ne fais pas de C), on peut toujours faire des ./configure && make && make install parce qu'on a besoin d'un soft qui n'est pas package (ou pas comme il faut).
MDR. Sur un serveur de prod par exemple ?
Ou l'art et la manière d'ouvrir grandes ouvertes les portes de la machine au premier script kiddy venu.
Sur les BSD il y a une chaine de compilation fonctionnelle dans la base et ça m'a pas l'air plus troué que Linux.
Euh... J'ai des FreeBSD et des NetBSD comme machines de test. Ta chaîne de compilation n'est utilisable que si tu vires les alertes de sécurités des ports (sinon, tu as toujours un ou deux trucs et je suis gentil qui refusent de s'installer parce que troués).
Ben ouais. C'est là qu'il faut voir s'il n'y a pas une version où le bug est corrigée et qui n'est pas dans les ports, et l'y faire entrer, (c'est complexe, mais faisable) ou alors voir coment on peut se passer du "truc" en question ou selon si l'alerte de sécurité est grave ou pas.
Par ailleurs, il est écrit noir sur blanc dans la doc des BSD que les équipes de développement ne sont pas responsables de la sécurité des logiciels dans les ports (comprendre de l'utilisation de l'outil et 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é.
Rien n'empeche d'appliquer les patches debian au paquet, si patches debian il y a. Il y a une procédure pour appliquer des patches persos qui est bien documentée et facile sur NetBSD.
J'ai plusieurs programmes qui ne _fonctionnent_ pas sur NetBSD en raison de bugs spécifiques (sigpending()). Sous FreeBSD, j'ai trouvé un bug dans sig_info. Sous OpenBSD, il traîne un sombre problème dans sigaltstack(). Les logiciels des ports ont été patchés pour fonctionner malgré ces problèmes (en tout cas, mon NetBSD/sparc32 et mon FreeBSD/i386 téléchargent les sources puis les patchent). Il ne me viendrait pas à l'idée d'utiliser autre chose que les logiciels des ports car le fonctionnement de ceux-ci ont été validés.
Je me contrefiche de la sécurité de ces machines de test car elles ne sont pas directement sur le grand ternet (adresses non routables et derrière des firewall sérieux). Les frontales sont toutes sous debian avec les patches de sécurité.
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 03-01-2010, ? propos de
Re: KDE tuera Windows,
Yves Lambert ?crivait dans fr.comp.os.linux.debats :
In article <slrnhjut3q.big.knatschke@rayleigh.systella.fr>,
JKB <knatschke@koenigsberg.fr> writes:
Le 02-01-2010, ? propos de
Re: KDE tuera Windows,
Patrick Lamaizière ?crivait dans fr.comp.os.linux.debats :
Patrice Karatchentzeff :
Un Unix est un OS de developpement philosophiquement parlant. Meme
si on ne fait pas de developpement (je ne fais pas de C), on peut
toujours faire des ./configure && make && make install parce qu'on a
besoin d'un soft qui n'est pas package (ou pas comme il faut).
MDR. Sur un serveur de prod par exemple ?
Ou l'art et la manière d'ouvrir grandes ouvertes les portes de la
machine au premier script kiddy venu.
Sur les BSD il y a une chaine de compilation fonctionnelle dans la base
et ça m'a pas l'air plus troué que Linux.
Euh... J'ai des FreeBSD et des NetBSD comme machines de test. Ta
chaîne de compilation n'est utilisable que si tu vires les alertes
de sécurités des ports (sinon, tu as toujours un ou deux trucs et je
suis gentil qui refusent de s'installer parce que troués).
Ben ouais. C'est là qu'il faut voir s'il n'y a pas une version où le bug
est corrigée et qui n'est pas dans les ports, et l'y faire
entrer, (c'est complexe, mais faisable) ou alors voir coment on peut se
passer du "truc" en question ou selon si l'alerte de sécurité est grave
ou pas.
Par
ailleurs, il est écrit noir sur blanc dans la doc des BSD que les
équipes de développement ne sont pas responsables de la sécurité des
logiciels dans les ports (comprendre de l'utilisation de l'outil et
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é.
Rien n'empeche d'appliquer les patches debian au paquet, si patches
debian il y a. Il y a une procédure pour appliquer des patches persos
qui est bien documentée et facile sur NetBSD.
J'ai plusieurs programmes qui ne _fonctionnent_ pas sur NetBSD en
raison de bugs spécifiques (sigpending()). Sous FreeBSD, j'ai trouvé
un bug dans sig_info. Sous OpenBSD, il traîne un sombre problème
dans sigaltstack(). Les logiciels des ports ont été patchés pour
fonctionner malgré ces problèmes (en tout cas, mon NetBSD/sparc32 et
mon FreeBSD/i386 téléchargent les sources puis les patchent). Il ne
me viendrait pas à l'idée d'utiliser autre chose que les logiciels
des ports car le fonctionnement de ceux-ci ont été validés.
Je me contrefiche de la sécurité de ces machines de test car elles
ne sont pas directement sur le grand ternet (adresses non routables
et derrière des firewall sérieux). Les frontales sont toutes sous
debian avec les patches de sécurité.
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 03-01-2010, ? propos de Re: KDE tuera Windows, Yves Lambert ?crivait dans fr.comp.os.linux.debats :
In article , JKB writes:
Le 02-01-2010, ? propos de Re: KDE tuera Windows, Patrick Lamaizière ?crivait dans fr.comp.os.linux.debats :
Patrice Karatchentzeff :
Un Unix est un OS de developpement philosophiquement parlant. Meme si on ne fait pas de developpement (je ne fais pas de C), on peut toujours faire des ./configure && make && make install parce qu'on a besoin d'un soft qui n'est pas package (ou pas comme il faut).
MDR. Sur un serveur de prod par exemple ?
Ou l'art et la manière d'ouvrir grandes ouvertes les portes de la machine au premier script kiddy venu.
Sur les BSD il y a une chaine de compilation fonctionnelle dans la base et ça m'a pas l'air plus troué que Linux.
Euh... J'ai des FreeBSD et des NetBSD comme machines de test. Ta chaîne de compilation n'est utilisable que si tu vires les alertes de sécurités des ports (sinon, tu as toujours un ou deux trucs et je suis gentil qui refusent de s'installer parce que troués).
Ben ouais. C'est là qu'il faut voir s'il n'y a pas une version où le bug est corrigée et qui n'est pas dans les ports, et l'y faire entrer, (c'est complexe, mais faisable) ou alors voir coment on peut se passer du "truc" en question ou selon si l'alerte de sécurité est grave ou pas.
Par ailleurs, il est écrit noir sur blanc dans la doc des BSD que les équipes de développement ne sont pas responsables de la sécurité des logiciels dans les ports (comprendre de l'utilisation de l'outil et 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é.
Rien n'empeche d'appliquer les patches debian au paquet, si patches debian il y a. Il y a une procédure pour appliquer des patches persos qui est bien documentée et facile sur NetBSD.
J'ai plusieurs programmes qui ne _fonctionnent_ pas sur NetBSD en raison de bugs spécifiques (sigpending()). Sous FreeBSD, j'ai trouvé un bug dans sig_info. Sous OpenBSD, il traîne un sombre problème dans sigaltstack(). Les logiciels des ports ont été patchés pour fonctionner malgré ces problèmes (en tout cas, mon NetBSD/sparc32 et mon FreeBSD/i386 téléchargent les sources puis les patchent). Il ne me viendrait pas à l'idée d'utiliser autre chose que les logiciels des ports car le fonctionnement de ceux-ci ont été validés.
Je me contrefiche de la sécurité de ces machines de test car elles ne sont pas directement sur le grand ternet (adresses non routables et derrière des firewall sérieux). Les frontales sont toutes sous debian avec les patches de sécurité.
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
Michel Talon, dans le message <hhq0np$asm$, a écrit :
Cette assertion est parfaitement ridicule,
C'est ce que j'ai hélas trop souvent constaté. J'ai pas mal fouillé dans les sources de divers trucs, et ça fait parfois très peur.
du même tonneau que celle qui consiste à dire qu'un prof de math de lycée est plus compétent qu'un grand mathématicien pour exposer au mieux un sujet.
Ça dépend pour exposer quel sujet à quel public.
Michel Talon, dans le message <hhq0np$asm$1@asmodee.lpthe.jussieu.fr>, a
écrit :
Cette assertion est parfaitement ridicule,
C'est ce que j'ai hélas trop souvent constaté. J'ai pas mal fouillé dans les
sources de divers trucs, et ça fait parfois très peur.
du même tonneau que celle
qui consiste à dire qu'un prof de math de lycée est plus compétent
qu'un grand mathématicien pour exposer au mieux un sujet.
