fortran, linux

Nicolas George wrote:

Je n'insinue rien, je parle d'experience pour avoir gere des equipes
d'administrateurs systemes ou d'avoir repris des machines derrieres
certains d'entres eux pdt quelques annees.

Eh bien moi, je ne vais pas insinuer que si moi je regardais le résultats de
tes installations, je trouverais probablement que c'est fait en dépit du bon
sens.

Si tu fais des choses en depit du bon sens, ce n'est pas ta faute
puisque tu as installe le paquet par defaut avec tout ce qu'il contient,
que tu as suivi les procedures d'upgrade de Debian ...

Je suis paye a faire fonctionner des machines et tu sais quoi ? celles
qui fonctionnent le mieux ont ete entierement installees a la main. Par
contre, qu'est ce qu'on a comme emmerdes avec les Debian ou on a utilise
les packages standards.

Je doute que ce soit quelque chose dont tu aies à te vanter.

D'etre emmerdee avec des Debian en prod ? p*tain, cette distrib est
vraiment une saloperie, c'est bien en theorie, mais dans la pratique,
faut vraiment toucher a rien pour que ca fonctionne. Autant ca me gene
pas de recompiler le systeme sous FreeBSD parce que je suis sur que ca
va repartir, autant je me vois pas upgrader le noyau en remote sur une
Debian (je l'ai fait une fois, ca m'a suffit).

Nicolas George wrote:

Si tu fais des choses en depit du bon sens, ce n'est pas ta faute
puisque tu as installe le paquet par defaut avec tout ce qu'il contient,
que tu as suivi les procedures d'upgrade de Debian ...

Je parlais de l'installation à partir des sources.

Ah ben ca, j'en sais rien, tu bosses comme tu bosses, j'ai pas vu.

Maintenant, de maniere plus generale, l'erreur la plus courante des gens
qui bossent avec des paquets et qui un jour doivent installer a la main
sont :

- la rotation des logs qui n'est pas faite ou mal configuree
- la gestion des versions qui n'est pas faite
- la journalisation des options de configuration qui n'est pas maintenue

Mais ce sont les erreurs les plus courantes.

Oui. D'expérience, tous ceux qui se plaignent d'une distribution sérieuse en
termes aussi généraux (et pas spécifiquement pour tel paquet) sont des gens
qui ont la flemme de lire le peu de doc qui leur permettrait de faire les
choses de manière propre et fiable, et préfèrent bricoler leur solution
bâtarde et bancale.

Pourquoi irais-je m'emmerder a lire la doc d'une Debian, soit elle suit
un tant soit peu des procedures Unix standard, soit elle me pose plus
de problemes que de solutions. En ce sens, les FreeBSD ou la Slack sont
infiniment plus faciles a maintenir parce qu'ils ont des reactions plus
proches de ce qu'on attend d'un Unix et qu'on est pas oblige de faire
des trucs "crades" ou de se taper 30 pages de docs pour geek mal
reveilles pour les personaliser en fonction des besoins.

Stephane TOUGARD , dans le message
<slrnf8ms64.92k.stephane@server.propolys.com.sg>, a écrit :

Je n'insinue rien, je parle d'experience pour avoir gere des equipes
d'administrateurs systemes ou d'avoir repris des machines derrieres
certains d'entres eux pdt quelques annees.

Eh bien moi, je ne vais pas insinuer que si moi je regardais le résultats de
tes installations, je trouverais probablement que c'est fait en dépit du bon
sens.

Je suis paye a faire fonctionner des machines et tu sais quoi ? celles
qui fonctionnent le mieux ont ete entierement installees a la main. Par
contre, qu'est ce qu'on a comme emmerdes avec les Debian ou on a utilise
les packages standards.

Je doute que ce soit quelque chose dont tu aies à te vanter.

Stephane TOUGARD , dans le message
<slrnf8msmq.92k.stephane@server.propolys.com.sg>, a écrit :

Si tu fais des choses en depit du bon sens, ce n'est pas ta faute
puisque tu as installe le paquet par defaut avec tout ce qu'il contient,
que tu as suivi les procedures d'upgrade de Debian ...

Je parlais de l'installation à partir des sources.

Je doute que ce soit quelque chose dont tu aies à te vanter.
D'etre emmerdee avec des Debian en prod ?

Oui. D'expérience, tous ceux qui se plaignent d'une distribution sérieuse en
termes aussi généraux (et pas spécifiquement pour tel paquet) sont des gens
qui ont la flemme de lire le peu de doc qui leur permettrait de faire les
choses de manière propre et fiable, et préfèrent bricoler leur solution
bâtarde et bancale.

Stephane TOUGARD , dans le message
<slrnf8muav.97v.stephane@server.propolys.com.sg>, a écrit :

Pourquoi irais-je m'emmerder a lire la doc d'une Debian

Parce qu'utiliser des outils évolués fait, au total, gagner du temps.

soit elle suit
un tant soit peu des procedures Unix standard

La première des procédures sous Unix, c'est justement de lire la doc.

Nicolas George wrote:

Pourquoi irais-je m'emmerder a lire la doc d'une Debian
Parce qu'utiliser des outils évolués fait, au total, gagner du temps.

Je gere des Unix depuis au moins 10 ans, je gere des Debian depuis au
moins 7 ans. Au total, Debian m'a toujours fait perdre du temps parce
que :

- La procedure d'install n'incluaient pas quelques questions de bases
- La documentation est toujours assez particuliere et pas vraiment
standard (et plutot mal ecrite)
- Les upgrades des noyaux ont toujours poses des problemes sur des
configs hard un peu speciales
- Les softs ont toujours une plombe de retards sont souvent compiles
avec des options incompatibles avec mes besoins
- Certains softs sont compiles avec des options inutiles qui les rendent
lourds, peu performants ou avec des dependances bizarres
- Il manque toujours un package a la con a droite ou a gauche
- Elle reagit assez mal aux personalisations, a moins de creer des
packages dedies, ce qui rend les procedures d'installs incompatibles
avec les autres Unices.

A cote de ca,

- La procedure d'install d'un FreeBSD est complete, bien foutue,
comprend tous les points vitaux, proposent des options interessantes
et simples et peu memes etre relancee apres installation.
- La documentation d'un FreeBSD est simple, bien ecrite et complete.
- Les upgrades du systeme relevent de l'enfance de l'art, cvsup, make
world, reboot. Trois lignes a taper et jamais eu d'accident.
- Les ports sont globalement a jour.
- Il est simple de personaliser les options de compilation d'un port.
- Elle reagit bien aux personalisation et on peut melanger allegrement
les ports avec des softs compiles a la main.
- C'est un Unix historique ou tout se trouve a peu pres la ou on
l'attend.

C'est un exemple. FreeBSD est pas parfait non plus, mais pour des
serveurs il y a pas photo.

soit elle suit
un tant soit peu des procedures Unix standard
La première des procédures sous Unix, c'est justement de lire la doc.

Ca je suis d'accord, mais je bosse avec une dizaine d'Unix differents,
j'aime ne pas avoir a me la refaire a chaque fois.

Pour moi une Debian, c'est un systeme de base inupgradable sur le quel
j'installe mes programmes a la main en renoncant definitivement a
utiliser quoi que ce soit de particulier a cette distrib (un peu comme
un Solaris).

Et c'est pas faute d'avoir essaye, d'avoir lu les docs, d'avoir fait des
upgrades en live ... a chaque fois, ca a ete la merde et a chaque fois
que je vois un admin Debian qui installe des trucs personalises, c'est
ni fait ni a faire parce qu'il est gave de mauvaises habitudes.

Stephane TOUGARD , dans le message
<slrnf8n26m.9gc.stephane@server.propolys.com.sg>, a écrit :

C'est un exemple. FreeBSD est pas parfait non plus, mais pour des
serveurs il y a pas photo.

C'est un exemple, et ce n'est pas parfait, nous sommes d'accord. Et cet
exemple va dans mon sens : un système où le travail de préparation des
paquets a été fait est un gros gain de temps.

En revanche, je remarque particulièrement ceci dans ton discours :

Je gere des Unix depuis au moins 10 ans

- C'est un Unix historique ou tout se trouve a peu pres la ou on
l'attend.

Et c'est justement là que le bât blesse. Les méthodes historiques que tu
défends si fort, ce sont, justement, des méthodes historiques, des méthodes
d'il y a trente ans. Je ne fais pas l'erreur de penser que quelque chose de
vieux est forcément moins bon, mais il convient de regarder si la situation
n'a pas évolué depuis trente ans, ou même dix, ce qui justifierait que des
méthodes d'alors ne soient plus les meilleures actuellement. Or :

- Des nouveaux outils ont été développés, publiés et améliorés. Par
définition, ces outils n'existaient pas il y a trente ans, et dans le lot,
il y en a certainement qui sont bons.

- Le monde a évolué, et les besoins d'un système informatique aussi. Il y a
trente ans, un système pouvait largement se passer de cryptographie. De
nos jours, on ne trouvera pas beaucoup d'applications d'Unix où une
implémentation de TLS ne soit pas nécessaire. C'est encore plus vrai quand
on a des lusers, dont les envies font exploser la complexité. Cette
complexification justifie qu'une gestion qui pouvait se faire facilement à
la main demande de nos jours des outils automatisés.

- Les performances des systèmes évoluent, et les besoins des applications
aussi, donc l'optimal du point de vue de l'optimisation n'est plus le
même.

Bref, tout ceci justifie que gérer un Unix aujourd'hui comme on le gérait il
y a trente ans n'est pas la solution optimale en termes d'efficacité, loin
de là. Ensuite, savoir quel système adopter entre les bons systèmes
existants, c'est principalement une question de goût.

Stephane TOUGARD <stephane@unices.org> wrote:

exemple en ce moment ils passent à gcc-4.2.0 dans FreeBSD, et ils
trouvent des erreurs de l'optimiseur de gcc absolument splendides.

C'est pas un package, ca fait partie du systeme. Non ?

Oui, et ça a l'air de poser quelques soucis.

--

Michel TALON

Thierry B. wrote:

--{ GT a plopé ceci: }--

Curieuses réponses ...

Qui sont à l'endroit, elles...

Qu'est-ce qui n'est pas assez convivial ?
Latex ? Ce n'est pas son but.

LaTeX est _convivial_ car tu racontes ce que tu veux, et il
met ça tout propre, tout beau sans que tu ne te prennes la
tête avec quarantedouzemille clickoilles.

Fortran ?

Fortran est rigolo -> http://tontonth.free.fr/morefun.pdf

Joli. C'est normal le changement de taille de fonte page 18 ?

Nicolas George wrote:

- C'est un Unix historique ou tout se trouve a peu pres la ou on
l'attend.

- Des nouveaux outils ont été développés, publiés et améliorés. Par
définition, ces outils n'existaient pas il y a trente ans, et dans le lot,
il y en a certainement qui sont bons.

Tres certainement, mais d'experience, Debian ne rentre pas dans la
categorie des ameliorations.

- Le monde a évolué, et les besoins d'un système informatique aussi. Il y a
trente ans, un système pouvait largement se passer de cryptographie. De
nos jours, on ne trouvera pas beaucoup d'applications d'Unix où une
implémentation de TLS ne soit pas nécessaire. C'est encore plus vrai quand
on a des lusers, dont les envies font exploser la complexité. Cette
complexification justifie qu'une gestion qui pouvait se faire facilement à
la main demande de nos jours des outils automatisés.

Des 'lusers', je presumes "des utilisateurs Locaux" ?

Qui utilise Unix en utilisateur local maintenant ? quel interet ? a part
se fader des problemes de compatibilite de documents, de programmes
Windows qui tournent pas ... c'est un truc d'universitees ca. De toutes
facons, le seul utilisateur local des serveurs que je gere, c'est moi.

Mes machines, c'est des gateways SS7, des serveurs applicatifs SS7, des
serveurs de mails, des serveurs web ... mes clients ou les editeurs de
logiciels me disent : ca tourne sur Solaris, sur SuSE, sur FreeBSD, sur
RedHat ... et je discute meme pas.

Un vrai progres, ca serait des ports a la FreeBSD pour tout le monde
avec des fichiers de personalisations simples et efficaces et une
portabilite garantie sur une vingtaine d'Unix. Voila, ca serait ca le
progres pour la vraie vie de l'informatique en entreprise.

Alors ma solution, c'est un peu ca, mais limitee aux logiciels que
j'utilise et ca les petits gars de Debian, ils ont pas encore compris ou
il etait le vrai progres que les admins attendent dans la vraie vie. Ils
sont comme toi, ils parlent de 'lusers' en se masturbant les neurones,
mais les lusers, c'est 0.7% des utilisateurs mondiaux, c'est dire si ca
va vraiment pas loin et ca represente 1% de ma problematique (et encore,
je parle de serveur Samba, c'est dire le niveau de 'luser').

- Les performances des systèmes évoluent, et les besoins des applications
aussi, donc l'optimal du point de vue de l'optimisation n'est plus le
même.

En general, l'optimisation des performances n'est pas un besoin dans mon
metier.

Bref, tout ceci justifie que gérer un Unix aujourd'hui comme on le gérait il
y a trente ans n'est pas la solution optimale en termes d'efficacité, loin
de là. Ensuite, savoir quel système adopter entre les bons systèmes
existants, c'est principalement une question de goût.

Non, c'est principalement une question d'etre dans le metier ou pas, de
connaitre la pratique plutot que de l'imaginer en theorie, de rencontrer
les besoins et d'y repondre de la facon la plus efficace possible.