fortran, linux

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

Mais t'as le droit de t'exprimer

Très bien, alors allons-y.

Je lis que tu interviens sur des machines avec des systèmes d'exploitation
variés. J'en déduis que tu n'es en général pas l'administrateur système
attitré de ces machines, faute de quoi tu aurais installé ton système
favori, et il y aurait bien moins de variété.

Je lis aussi que tu fais sur ces machines des installations de logiciels à
ta manière, sans passer par le mécanisme propre à chaque système.

Et là, je me dis qu'il y a un problème : si le choix du système t'est
imposé, le choix de la manière dont il est géré ne t'appartient pas non
plus.

En d'autres termes, si j'ai un serveur sous RedHat / Debian / Solaris et que
je cherche un intervenant pour faire une installation dessus, je m'attends à
ce que cet intervenant fasse l'installation en respectant l'esprit, les
méthodes et l'organisation d'un Redhat / d'une Debian / d'un Solaris, et pas
comme il l'aurait fait sur une Slackware ou un FreeBSD.

En d'autres termes, je ne t'engagerais pas.

Évidemment, une fois que tu es venu mettre ton zoinx sur la machine et que
tu es le seul à comprendre comment ça fonctionne, tu peux dormir tranquille,
tu as un marché captif.

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

Nicolas George wrote:

Je lis que tu interviens sur des machines avec des systèmes d'exploitation
variés. J'en déduis que tu n'es en général pas l'administrateur système
attitré de ces machines, faute de quoi tu aurais installé ton système
favori, et il y aurait bien moins de variété.

AHAHAHAHAHA ... pardon.

Parce que tu t'imagines qu'on te laisse le choix, he he he, j'en rigole
encore tellement ta remarque est pleine de naivite.

Allez tiens, je te le donne en 1000, j'ai un client avec 5 serveurs :

- 2 Solaris,
- 1 Slackware
- 1 SuSE
- 1 FreeBSD

Et alors ? Moi aussi... Ce n'est pas une performance en tant que
telle.

J'ai decide de l'OS dans CHAQUE cas et j'en suis entierement
responsable. Mais tu sais quoi, il y a une raison pour chacun de ces
choix et la procedure d'exploitation est quasiment la mienne. A la fin,
j'ai meme le temps de troller ici.

Je lis aussi que tu fais sur ces machines des installations de logiciels à
ta manière, sans passer par le mécanisme propre à chaque système.

Je fais des installations propres aux procedures de ma societe, propres
aux logiciels que je dois gerer ou propres aux procedures des clients et
rarement en suivant les process propres aux systemes en eux memes. C'est
exact. Ce n'est pas un choix, c'est un fait.

Mais certaines distrib sont mieux foutues que d'autres :FreeBSD, SuSE
... et selon les process du moment, je vais suivre plus ou moins les
recommandations des distrib (SuSE est souvent utilise pour des softs
proprio, la en effet, on s'ecarte pas du chemin trace par l'editeur).

Et là, je me dis qu'il y a un problème : si le choix du système t'est
imposé, le choix de la manière dont il est géré ne t'appartient pas non
plus.

Ca depend du client, du logiciel, du cas, du besoin, de l'anteriorite,
des habitudes de travail, de l'historique ... parfois si, parfois non.

En d'autres termes, si j'ai un serveur sous RedHat / Debian / Solaris et que
je cherche un intervenant pour faire une installation dessus, je m'attends à
ce que cet intervenant fasse l'installation en respectant l'esprit, les
méthodes et l'organisation d'un Redhat / d'une Debian / d'un Solaris, et pas
comme il l'aurait fait sur une Slackware ou un FreeBSD.

Oui, mais t'es pas un client, t'as pas les moyens de te payer mes
services et t'as surtout pas les moyens d'acheter les logiciels que je
fais tourner la plupart du temps.

D'ailleurs, je suis les recommandations des logiciels que j'installe,
c'est a dire que si j'installe un Apache, tu vas sur le site d'Apache et
tu retrouves tes petits parce que ma conf est faite selon les options et
recommandations d'Apache (et non pas celle de Debian).

Je ne vois pas en quoi elles sont différentes. Passons...

C'est un exemple,
mais ca me parait plus logique de suivre les recommandation du logiciel
utilise que les delires de l'equipe de Debian qui va t'eclater ton
fichier de conf a la mitrailleuse.

? 'Modulaire'.eq.'éclater à la mitrailleuse' ?

En d'autres termes, je ne t'engagerais pas.

Ben non, puis t'as pas vraiment le choix en fait. Il faudrait deja tout
un tas de choses que tu es loin de pouvoir faire. Monter une boite par
exemple, avoir un poste qui te permette de prendre ce genre de decision,
avoir un marche qui justifie de me sous-traiter un chantier, etre en
Asie, avoir beaucoup de sous ...

Bref, tu vois, tout ce que j'ai deja fait et toi pas encore.

Il me semblait que tu avais été envoyé à Singapour par une boîte
française. C'est un peu différent de "monter une boîte", non ?

Évidemment, une fois que tu es venu mettre ton zoinx sur la machine et que
tu es le seul à comprendre comment ça fonctionne, tu peux dormir tranquille,
tu as un marché captif.

Bof, tu sais, si apt-get etait si bon, tout le monde l'utiliserait, hors
il se trouve qu'hormis sur des betes serveurs web, je ne le rencontre
jamais. Et meme la, la configuration par defaut des Apache est tellement
foireuse, compliquee et peu standard que la plupart du temps, ca depasse
meme pas un bete serveur PHP.

Bref, Debian, dans le millieu industriel, au mieux, c'est mignon.

Tu n'exagèrerais pas un petit peu, non ? Personnellement, je préfère
de loin avoir un truc qui gère un _minimum_ (même s'il y a des
ratés) les dépendances, et surtout qui soit _stable_. Le problème de
sous les softs à compiler sur des architectures pas trop courantes
(style linux/sparc64 pour ne citer qu'elle), ce sont les effets de
bord dans les compilos qui fait qu'un soft fonctionne _presque_
(tout étant dans le presque, mutex foireux qui met le processus en
état D, plantages aléatoires...). Je préfère pour cela une
debian/stable à toutes les autres (que j'ai testées). Par ailleurs,
les fichiers de conf ne sont pas compliqués (même ceux d'apache2) si
on y regarde bien.

--
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 wrote:

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.

Oui, Qmail aussi met ses binaire dans /var 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 ?

Alors peut etre que le type qui a decide de les mettre la a fait une
connerie, 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

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).

On 5 juil, 10:02, JKB <knatsc...@koenigsberg.fr> wrote:

g77 n'a jamais été un très bon compilateur Fortran (pas hyper fia ble, et
exécutables pas très rapides).

Prouve-le. g77 était déjà plus rapide que le compilo fourni t avec
HPUX 10.20 il y a dix ans. Maintenant, il n'était peut-être p as
aussi véloce que le DEC-Fortran, mais il a l'immense avantage d 'être
disponible quasiment partout.

Disponible partout certes, mais avec des qualités d'implémentation
très inégales suivant les plate-formes.

Mais surtout, g77 ignorait certaines extensions à la norme qui étaient
néanmoins devenues des standards de fait et disponibles sur les
compilos de tous les fabriquants de machines: l'exemple le plus
typique étant les "pointeurs Cray", qui étaient à l'époque la seule
façon simple de faire de l'allocation dynamique en Fortran.

Quant au Fortran 9x, à ma connaissance il n'existe pas de bon compila teur
libre. Pour un usage non commercial, le compilateur Intel est gratuit
toutefois (et il est d'un bon niveau).

Je n'ai pas encore eu de problèmes sérieux avec gfortran.
D'ailleurs, cela dépend des critères pour définir un _bon_
compilateur.

Le Fortran étant d'abord un langage de calcul scientifique, le critère
principal est une bonne optimisation du code (optimisation qui est
d'ailleurs devenue nettement plus complexe à réaliser pour les
compilos avec les syntaxes Fortran 90).

Deuxième critère: compiler sans problème les anciens codes, y compris
avec les extensions courantes aux normes précédentes.

gfortran ne me parait vraiment pas suffisamment mature (g95 non plus
d'ailleurs). Et je doute même qu'il le soit vraiment un jour. Les deux
boîtes que je connais ont retenu sous PC/Linux le compilo Intel pour
le Fortran, alors que gcc est utilisé sans problème pour C/C++

Tiens, pour voir, j'ai essayé de compiler avec gfortran le code sur
lequel je travaille actuellement. Ce code compile sans problème sous
IRIX, sous Solaris, et sous Linux avec ifort. gfortran échoue par
contre sur 2 fichiers (et je ne peux aller plus loin car les fichiers
suivants ont besoin des infos de modules des fichiers qui échouent):

[XXXXX] gmake
gfortran -c -DPC -O3 -I. GCTdep.F
gfortran -c -DPC -O3 -I. GCT_lapack.F
gfortran -c -DPC -O3 -I. somglis.f
gfortran -c -DPC -O3 -I. sort.f
gfortran -c -DPC -O3 -I. csttk-4.F90
csttk-4.F90: In function ?cst_wrtrace?:
csttk-4.F90:504: fatal error: gfc_todo: Not Implemented: Scalarization
of non-elemental intrinsic: __transfer1
compilation terminated.
make: *** [csttk-4.o] Error 1
[XXXXX] ifort -c csttk-4.F90
[XXXXX] gmake
gfortran -c -DPC -O3 -I. rkinds-1.f90
gfortran -c -DPC -O3 -I. util-2.f90
util-2.f90: In function ?locase?:
util-2.f90:251: internal compiler error: in gfc_finish_var_decl, at
fortran/trans-decl.c:416
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
make: *** [util-2.o] Error 1

Bref...

--
pehache

Le 05-07-2007, Thierry B. <tth@prout.stex> a écrit :

C'est globalement ce que je reproche a la Debian d'ailleurs, d'imposer
des grandes theories sans vraiment savoir ce qui peut/doit etre fait
dans la pratique.

Exemple: j'utilise "aptitude" pour installer/enlever des packages,
mais il faut utiliser "dpkg -l" pour avoir la liste de ce qui est
installé. C'est ce genre de petites incohérences qui énervent...

Et dpkg -l ne t'affiche que les premieres lettres des packages.

Comment faire pour avoir le nom complet? Ah bah, oui, la faut lire de
la doc.

Et c'est quoi ces binaires dans la debian? start-stop-daemon avec
des myriades d'options? Et pourquoi sur ma debian, il suffit
que j'ajoute un script dans /etc/crond.d/hourly.d/ pour qu'il soit
execute? Que signifie /etc/alternatives sur ma debian? Pourquoi
est ce qu'il est a la limite de l'impossible de derouler le boot
complet de la debian en partant de inittab? Et l'option "pin" pour
attacher un paquet sans bouger les autres, comment sont definis
les seuils?

Ah oui, si tu veux utiliser debian, il faut apprendre debian. Et
tous ses outils. Et surtout ne pas en sortir. Il y aura toujours
un developpeur qui aura pondu le script qui t'interesse. Genre mes
locales me prennent de la place, que faire? localepurge, bien sur!
Mais le jour ou tu as un vrai probleme, tu es cuit. Si tu changes de
systeme tu es cuit. Si tu dois utiliser dselect, tu es cuit.
--
Kevin

Patrick Lamaizière wrote:

Mouais. J'aime pas trop pkgsrc, à l'update il commence par déinstaller
avant de compiler les nouvelles versions. Ça conduit à des gags rigolos
quand la nouvelle version ou une dépendance ne compile pas...

:)

Bon, ben maintenant, je sais pourquoi je vais pas changer ma facon de
travailler.

Nicolas George wrote:

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.

Ben ce sont des raisons cons. Qd on cherche des infos sur un logiciel,
on va sur le site voir la doc du dit logiciel et pas sur le site de
Debian.

La moindre des choses des raisons techniques, ca serait de s'assurer que
tout fonctionne selon les configuration par defaut ou les
recommandations des logiciels qu'ils distribuent.

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

Stephane TOUGARD <stephane@unices.org> wrote:

recommandations d'Apache (et non pas celle de Debian). C'est un exemple,
mais ca me parait plus logique de suivre les recommandation du logiciel
utilise que les delires de l'equipe de Debian qui va t'eclater ton
fichier de conf a la mitrailleuse.

Là pour le coup, je compatis. J'ai installé Ubuntu sur mon portable,
pour ne pas me casser la nénette. C'est vrai que c'est pratique pour ce
genre d'usage. Mais quand je vois comment certains logiciels sont
éclatés, par exemple Java, je trouve qu'il faudrait passer les
Debianistes au lance flammes. Inutile de dire que quand ça ne marche
pas, on est dans la merde jusqu'au cou.

Bof, tu sais, si apt-get etait si bon, tout le monde l'utiliserait, hors
il se trouve qu'hormis sur des betes serveurs web, je ne le rencontre
jamais. Et meme la, la configuration par defaut des Apache est tellement
foireuse, compliquee et peu standard que la plupart du temps, ca depasse
meme pas un bete serveur PHP.

Apt-get est bon, l'infrastructure qui va avec est bonne. Le problème,
comme pour toutes les distributions, c'est les gens qui font les
paquets, et les consignes générales pour les faire. Si dans Debian il y
a des consignes pour éclater les paquets, genre mettre ceci dans /etc,
celà dans /var, etc. les mainteneurs de paquets seront obligés de le
faire, même et surtout si ça signifie de mettre une pagaille monstre
dans le paquet en question. Debian est une organisation démocratique et
bureaucratique, ce qui veut dire que l'efficacité est la dernière des
choses prises en considération. Heureusement que dans les temps reculés
il s'est trouvé des gens forts pour mettre en place le système et
introduire apt-get. Ce système a une telle force qu'il a finalement
envahi l'essentiel du champ des distributions Linux non commerciales.


--

Michel TALON

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

On 5 juil, 10:02, JKB <knatsc...@koenigsberg.fr> wrote:

g77 n'a jamais été un très bon compilateur Fortran (pas hyper fiable, et
exécutables pas très rapides).

Prouve-le. g77 était déjà plus rapide que le compilo fournit avec
HPUX 10.20 il y a dix ans. Maintenant, il n'était peut-être pas
aussi véloce que le DEC-Fortran, mais il a l'immense avantage d'être
disponible quasiment partout.

Disponible partout certes, mais avec des qualités d'implémentation
très inégales suivant les plate-formes.

Mais surtout, g77 ignorait certaines extensions à la norme qui étaient
néanmoins devenues des standards de fait et disponibles sur les
compilos de tous les fabriquants de machines: l'exemple le plus
typique étant les "pointeurs Cray", qui étaient à l'époque la seule
façon simple de faire de l'allocation dynamique en Fortran.

1/ c'est _hors_ norme
2/ les pointeurs existent dans g77 (cf l'utilisation faite par
vastf90 que je dois encore avoir sur une disquette)

Quant au Fortran 9x, à ma connaissance il n'existe pas de bon compilateur
libre. Pour un usage non commercial, le compilateur Intel est gratuit
toutefois (et il est d'un bon niveau).

Je n'ai pas encore eu de problèmes sérieux avec gfortran.
D'ailleurs, cela dépend des critères pour définir un _bon_
compilateur.

Le Fortran étant d'abord un langage de calcul scientifique, le critère
principal est une bonne optimisation du code (optimisation qui est
d'ailleurs devenue nettement plus complexe à réaliser pour les
compilos avec les syntaxes Fortran 90).

L'optimisation d'un code Fortran stipule que quelle que soit
l'architecture, le résultat est bon (moyennant les bonnes options de
compilation). Le critère n'est pas la vitesse mais la
reproductibilité, c'est un peu différent.

Deuxième critère: compiler sans problème les anciens codes, y compris
avec les extensions courantes aux normes précédentes.

Un compilo se doit de suivre au mieux la norme (d'ailleurs IVF ne la
suit pas, ni l'ancien compilo digital devenu compaq puis HP). Le
reste, c'est des conneries.

gfortran ne me parait vraiment pas suffisamment mature (g95 non plus
d'ailleurs). Et je doute même qu'il le soit vraiment un jour. Les deux
boîtes que je connais ont retenu sous PC/Linux le compilo Intel pour
le Fortran, alors que gcc est utilisé sans problème pour C/C++

Tiens, pour voir, j'ai essayé de compiler avec gfortran le code sur
lequel je travaille actuellement. Ce code compile sans problème sous
IRIX, sous Solaris, et sous Linux avec ifort. gfortran échoue par
contre sur 2 fichiers (et je ne peux aller plus loin car les fichiers
suivants ont besoin des infos de modules des fichiers qui échouent):

[XXXXX] gmake
gfortran -c -DPC -O3 -I. GCTdep.F
gfortran -c -DPC -O3 -I. GCT_lapack.F
gfortran -c -DPC -O3 -I. somglis.f
gfortran -c -DPC -O3 -I. sort.f
gfortran -c -DPC -O3 -I. csttk-4.F90
csttk-4.F90: In function ?cst_wrtrace?:
csttk-4.F90:504: fatal error: gfc_todo: Not Implemented: Scalarization
of non-elemental intrinsic: __transfer1
compilation terminated.
make: *** [csttk-4.o] Error 1
[XXXXX] ifort -c csttk-4.F90
[XXXXX] gmake
gfortran -c -DPC -O3 -I. rkinds-1.f90
gfortran -c -DPC -O3 -I. util-2.f90
util-2.f90: In function ?locase?:
util-2.f90:251: internal compiler error: in gfc_finish_var_decl, at
fortran/trans-decl.c:416
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
make: *** [util-2.o] Error 1

Bref...

J'aimerais surtout voir la gueule du source ou d'un exemple mimnal
qui ne compilerait pas pour voir ce qu'il y a dedans. Je n'ai
_jamais_ vu une limitation problématique à gfortran (pour g95, c'est
un autre débat).

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.

pehache-tolai <pehache.7@gmail.com> wrote:

gfortran ne me parait vraiment pas suffisamment mature (g95 non plus
d'ailleurs). Et je doute même qu'il le soit vraiment un jour. Les deux
boîtes que je connais ont retenu sous PC/Linux le compilo Intel pour
le Fortran, alors que gcc est utilisé sans problème pour C/C++

Chez nous les gens qui font du calcul scientifique en Fortran utilisent
exclusivement le compilateur Intel, vu les différences de performance
ébouriffantes avec le compilateur gnu. Quand les machines Digital
existaient, ils utilisaient évidemment le compilateur Digital.
Effectivement, pour le code C, avec les gcc récents il n'y a plus gros
écart avec le compilateur Intel.


--

Michel TALON