fortran, linux

Stephane TOUGARD , dans le message
<slrnf8pcr1.iet.stephane@server.propolys.com.sg>, a écrit :
<snip>

Ouais, t'es trop fort, tu fais tout parfaitement, et mieux que tout le
monde.

Tu m'excuseras, je n'y crois pas.

Michel Talon, dans le message <f6if9s$g87$1@asmodee.lpthe.jussieu.fr>, a
écrit :

Si dans Debian il y
a des consignes pour éclater les paquets, genre mettre ceci dans /etc,
celà dans /var, etc.

Ce que tu oublies de prendre en considération, c'est que ces consignes ne
sont pas sorties de nulle part, ni même du caprice d'un project leader
dérangé : il y a des raisons techniques à ces choix.

Nicolas George wrote:

Et l'inconvénient, c'est que tu ne peux pas monter /var en noexec, par
exemple.

Ca, a chaque fois, j'en dors pas la nuit.

Et c'est là qu'on doit se poser la question : qu'est-ce qui est plus grave :

1. devoir faire un peu de gymnastique mentale pour adapter ce qu'on lit dans
les docs à la situation présente, ou

2. devoir renoncer à une politique de sécurité ?

Tu dois en passer du temps a mettre en place tes politiques de securite
a deux balles.

Et certains programmes compilés comme ça vont mettre des données variables
sous leur $PREFIX (au revoir /usr/local monté en read-only), des données
dépendant de l'architecture dans $PREFIX/share/ (au revoir share partagé
entre différentes architectures), des données de configuration dans
$PREFIX/lib/ (au revoir le backup groupé de la configuration), etc.

Tu sais quoi, arrete de te masturber sur ta securite a deux balles, la
seule machine que je me suis fait attaquer etait une Debian installee
et upgradee dans les regles de l'art et selon la doc Debian (faut dire
que le serveur devait etre maudit, c'est egalement lui qu'a jamais voulu
repartir apres un upgrade du noyau ... toujours dans les regles de l'art
et le nez pendu a la doc Debian).

Quand un programme respecte bien les principes d'organisation des fichiers
dans l'arborescence, Debian n'y touche pas. Mais quand il y a une connerie,
ils préfèrent corriger cette connerie, quitte à ne plus coller parfaitement
aux docs.

Tres bien, apres, faut pas s'etonner du manque de succes de la Debian
dans le millieu industriel et par le fait qu'aucun editeur ne valide
quoi que ce soit dessus.

À titre personnel, tu ne le préfères pas. C'est ton droit. Mais tu pourrais
avoir la décence de le respecter.

C'est pas une question de respect ou de pas respect. C'est une question
de besoins dans la vraie vie, de comprendre pourquoi un admin systeme
qui a des clients prefere suivre les indications des mecs qu'on pondu
les logiciels plutot que celles des mecs qui pensent savoir mieux que
les autres comment les utiliser.

Je suis en train de t'expliquer pourquoi on trouve de la Debian dans des
petits serveurs web, mais qu'on le rencontre pas dans le monde des
telco, des gros serveurs, du logiciel proprio (parce que tout existe pas
dans le Libre) ... Je vais meme te dire pire, des hosting center qui
utilisaient la Debian avant sont en train de migrer sous Solaris 10,
sous RedHat ou sous FreeBSD maintenant. Ubuntu aussi commence a monter
(pas encore teste).

Apres, on trouve la Debian sur les PC de tous les mecs qui la
maintiennent. Ca fait deja pas mal de postes finalement (peut etre pas
0.7%, mais ca doit les remplir en bonne partie :D )

Stephane TOUGARD , dans le message
<slrnf8pi2t.jdc.stephane@server.propolys.com.sg>, a écrit :

Ben ce sont des raisons cons.

C'est toi qui le dis. Moi, ce que j'en ai lu, je trouve ça très raisonnable
au contraire. Qui a raison ?

C'est pas possible ? FreeBSD le fait tres bien avec un systeme de
package largement aussi performant.

Et FreeBSD n'offre pas certaines garanties de Debian, en particulier dans
l'organisation des paquets.

Quand les paquets upstream sont agencés n'importe comment (le comble du
ridicule revenant à djb qui met ses binaires dans /var, évidemment), il y a
forcément des inconvénients. À chacun de choisir ceux qui le gênent le
moins.

Stephane TOUGARD , dans le message
<slrnf8pikf.jh0.stephane@server.propolys.com.sg>, a écrit :

Oui, Qmail aussi met ses binaire dans /var

Euh, allô ? Qmail est un programme écrit par djb, c'est précisément de ça
que je parle.

et l'interet de les avoir la,
c'est que lorsque je prends un bouquin sur qmail, lorsque je lis une
doc, elle correspond a ce que je trouve. Bizarre non ?

Et l'inconvénient, c'est que tu ne peux pas monter /var en noexec, par
exemple.

Alors peut etre que le type qui a decide de les mettre la a fait une
connerie,

C'est le moins qu'on puisse dire.

mais il l'a fait et tout le monde l'a suivi et toutes les docs
se referent a ca. J'y peux rien, mais mes binaires de qmail iront dans
/var/qmail/bin

Et c'est là qu'on doit se poser la question : qu'est-ce qui est plus grave :

1. devoir faire un peu de gymnastique mentale pour adapter ce qu'on lit dans
les docs à la situation présente, ou

2. devoir renoncer à une politique de sécurité ?

Pour moi, il n'y a pas photo.

Pour les autres --prefix=/usr/local ca existe et la documentation
considere souvent que ca va la (plutot que dans /usr qui est reserve
pour le systeme en lui meme).

Et certains programmes compilés comme ça vont mettre des données variables
sous leur $PREFIX (au revoir /usr/local monté en read-only), des données
dépendant de l'architecture dans $PREFIX/share/ (au revoir share partagé
entre différentes architectures), des données de configuration dans
$PREFIX/lib/ (au revoir le backup groupé de la configuration), etc.

Quand un programme respecte bien les principes d'organisation des fichiers
dans l'arborescence, Debian n'y touche pas. Mais quand il y a une connerie,
ils préfèrent corriger cette connerie, quitte à ne plus coller parfaitement
aux docs.

À titre personnel, je préfère ce choix.

À titre personnel, tu ne le préfères pas. C'est ton droit. Mais tu pourrais
avoir la décence de le respecter.

Nicolas George wrote:

Hopital, charite ... tout ca

Tu calomnies. Mon discours est d'insister sur le fait que la meilleure
solution dépend des situations et des goûts, ce qui est l'opposé absolu de
ton discours intolérant.

Ton discourd consiste a pretendre qu'il y a un ideal et qu'on peut faire
autrement (ce qui revient a dire que tout autre solution que l'ideale
est forcement moins bonne).

Le mien consiste a dire que ton ideal est de la merde en barre.

Dans la forme, je parais plus intolerant. Dans le fond, nous exprimons
le meme genre de pensee.

izatis wrote:

Meuh non, t'es pas cuit. Si tu casse une debian, il te reste une slack.
C'est loin d'etre dramatique.

Ce qui ne manque jamais d'arriver au bout d'un moment.

Stephane TOUGARD , dans le message
<slrnf8pl0a.jqc.stephane@server.propolys.com.sg>, a écrit :
<snip>

Toujours le même discours : ce qui ne font pas comme toi sont des cons.

Nicolas George wrote:

Toujours le même discours : ce qui ne font pas comme toi sont des cons.

Hopital, charite ... tout ca

Le 05-07-2007, à propos de
Re: fortran, linux,
Stephane TOUGARD écrivait dans fr.comp.os.linux.debats :

Nicolas George wrote:

Et l'inconvénient, c'est que tu ne peux pas monter /var en noexec, par
exemple.

Ca, a chaque fois, j'en dors pas la nuit.

Et c'est là qu'on doit se poser la question : qu'est-ce qui est plus grave :

1. devoir faire un peu de gymnastique mentale pour adapter ce qu'on lit dans
les docs à la situation présente, ou

2. devoir renoncer à une politique de sécurité ?

Tu dois en passer du temps a mettre en place tes politiques de securite
a deux balles.

Je ne vois pas ce qui te permets d'en juger.

Et certains programmes compilés comme ça vont mettre des données variables
sous leur $PREFIX (au revoir /usr/local monté en read-only), des données
dépendant de l'architecture dans $PREFIX/share/ (au revoir share partagé
entre différentes architectures), des données de configuration dans
$PREFIX/lib/ (au revoir le backup groupé de la configuration), etc.

Tu sais quoi, arrete de te masturber sur ta securite a deux balles, la
seule machine que je me suis fait attaquer etait une Debian installee
et upgradee dans les regles de l'art et selon la doc Debian (faut dire
que le serveur devait etre maudit, c'est egalement lui qu'a jamais voulu
repartir apres un upgrade du noyau ... toujours dans les regles de l'art
et le nez pendu a la doc Debian).

Et comment s'est-elle fait attaquer ? Ça m'intéresse, parce depuis
que j'administre des machines, la seule qui ait réussi a se faire
pénétrer était une debian, mais l'intrus est venu grâce à un compte
utilisateur ftpuser dont l'utilisateur avait trouvé amusant de
mettre comme mot de passe ftpuser ! Et l'intrus n'a _jamais_ rien pu
faire pour augmenter ses droits et a jeté l'éponge.

Pourtant des machines frontales sur le grand ternet, j'en ai
quelques unes...

Quand un programme respecte bien les principes d'organisation des fichiers
dans l'arborescence, Debian n'y touche pas. Mais quand il y a une connerie,
ils préfèrent corriger cette connerie, quitte à ne plus coller parfaitement
aux docs.

Tres bien, apres, faut pas s'etonner du manque de succes de la Debian
dans le millieu industriel et par le fait qu'aucun editeur ne valide
quoi que ce soit dessus.

Et tu crois que c'est pour ça ?

À titre personnel, tu ne le préfères pas. C'est ton droit. Mais tu pourrais
avoir la décence de le respecter.

C'est pas une question de respect ou de pas respect. C'est une question
de besoins dans la vraie vie, de comprendre pourquoi un admin systeme
qui a des clients prefere suivre les indications des mecs qu'on pondu
les logiciels plutot que celles des mecs qui pensent savoir mieux que
les autres comment les utiliser.

Là, tu commences à m'amuser. Lorsque j'interviens chez un client,
j'aime bien savoir par défaut où se trouvent les softs. J'aime bien
aussi ne pas m'arracher les cheveux pour installer un mailman ou un
sql (au choix my ou pg) sur un Solaris 9 out of the box, parce que
le paquet de sunfreeware ne comporte pas les bonnes options de
compilation. J'aime bien aussi ne pas avoir des exécutables dans le
/var (pour un certain nombre de bonnes raisons dont certaines ont
déjà été évoquées ici). Jusqu'à présent, la façon de faire de debian
m'apparaît bien meilleure que la façon historique avec certains
exécutables dans /var, d'autres dans /etc, des troisièmes dans /opt
ou /usr/local.

Je suis en train de t'expliquer pourquoi on trouve de la Debian dans des
petits serveurs web, mais qu'on le rencontre pas dans le monde des
telco, des gros serveurs, du logiciel proprio (parce que tout existe pas
dans le Libre)...

J'ai du debian chez des clients qui bossent dans les telecoms (et
c'est du lourd, du cluster de T1000 avec baies de disques).

Je vais meme te dire pire, des hosting center qui
utilisaient la Debian avant sont en train de migrer sous Solaris 10,

Mouarf.

sous RedHat

Alors là, je m'incline !

ou sous FreeBSD maintenant.

Celle-là, je l'encadre, mais je ne rentrerais pas dans le troll.

Ubuntu aussi commence a monter
(pas encore teste).

1/ Que serait ubuntu sans debian ?
2/ ubuntu puise ses paquets dans debian/testing et debian/unstable,
ce qui est pour moi _incompatible_ avec une utilisation en serveur.

Apres, on trouve la Debian sur les PC de tous les mecs qui la
maintiennent. Ca fait deja pas mal de postes finalement (peut etre pas
0.7%, mais ca doit les remplir en bonne partie :D )

Il y a au moins un truc chez debian. Lorsqu'on prend une
Debian/stable avec les patches de sécurité, on a un système décent.
Aujourd'hui, j'ai testé à peu près toutes les grandes distributions
Linux, les xBSD et Solaris, et je n'ai pas encore trouvé mieux que
Debian (pour un tas de raisons). Maintenant, je changerai peut-être
d'avis dans l'avenir, mais il faudra pour cela qu'il y ait de
solides arguments. Et lorsque je vois aujourd'hui la stabilité de la
debian/testing, je me dis que ubuntu n'est pas un truc fiable.
Enfin, chacun voit midi à sa porte.

NetBSD est une bouse pas finie (sauf peut-être sur i386). Il faut
voir le truc tourner sur une sparc, c'est une assez bonne tranche de
rigolade au prix du CD de boot. Les FB CG14 sont reconnus comme des
CG8 (?) sur NetBSD 4.0, comme une émulation d'un truc bizarre sous
la version 3.1 du truc, les claviers sont mappés n'importe comment,
le noyau 3.1 n'est pas stable (il explose en vol de la même façon
que celui de Solaris 9, de là à dire qu'ils sont cousins...), le
serveur X est tellement buggué qu'il faut jouer à la tronçonneuse
pour ne pas avoir en même temps X et la console...

FreeBSD, bof... OpenBSD, aucune gestion SMP sur les architectures
qui m'intéressent.

Solaris : un truc infâme (et j'utilise Solaris depuis SunOS 1.4.x
qui ne s'appelait pas encore Solaris). Je pourrais écrire un bouquin
sur toutes les conneries de monsieur Sun (depuis le
/etc/init.d/networking restart -> Panic !) jusqu'au problèmes
beaucoup plus sournois de patches qui désactivent certains
composants matériels de la carte-mère plutôt que de corriger les
bugs. Sans parler de smpatch qui ne suit même pas ses fichiers de
configuration !

Redhat : j'ai maintenu des redhat jusqu'à ce qu'une mise à jour de
sécurité d'un serveur X avec RPM m'a foutu par terre un serveur que
je n'ai jamais pu redémarrer normalement. J'ai réinstallé par dessus
une debian, depuis, plus de problème.

Donc aujourd'hui, au moins par élimination, debian. Au moins pour sa
fiabilité, debian.

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.