fortran, linux

On 2007-07-05, Stephane TOUGARD <stephane@unices.org> wrote:

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.

Oui oui, puisque comme tu nous l'as expliqué, ta facon de travailler est
la meilleure, et la seule valable. Tous ceux qui ne travaillent pas
comme toi sont des abrutis. Pas la peine de tester ou de se renseigner,
tu sais deja d'avance que tout le reste c'est pourris. Et puis ces gens
n'ont pas une societé à leur nom avec des clients qui veullent des
logiciels proprios en Asie, donc ils ne peuvent raconter que des conneries.

Merci Stephane TOUGARD de nous donner le privilège de te parler, et de
nous apprendre comment l'admin UNIX ca marche. Tu es un peu notre idole
à tous ici.

Nicolas

JKB wrote:

Et comment s'est-elle fait attaquer ? Ça m'intéresse, parce depuis

J'en sais rien et j'en ai rien a foutre. J'ai fait confiance a la
politique de securite d'une distrib, ca a donne ca. J'ai re-installe,
restaure les backup parce que des gens attendaient que ce serveur
tourne.

La j'ai fait les choses a ma maniere et la machine a tenu sans probleme
quelques annees.

Ubuntu aussi commence a monter
(pas encore teste).

1/ Que serait ubuntu sans debian ?

M'en fous, j'en sais rien. Mais le fait est qu'un mec recupere le boulot
de Debian et il commence a percer dans certains millieux ou Debian n'est
meme pas encore cite.

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

Ca c'est possible, moi ce qui m'interesse c'est ce que l'editeur a
valide et quand me dit qu'il travaille a valider une Ubuntu, je pense
juste que je devrai peut etre un jour travailler avec.

Quand je lui dis "Debian", Ubuntu, c'est une Debian pas stable, il me
repond que derriere Ubuntu, il y a une societe et une demarche qui
permet de valider quelque chose. C'est meme pas technique comme choix.

De toutes facons, pour cette editeur on utilise la SuSE et elle est tres
bien.

NetBSD est une bouse pas finie (sauf peut-être sur i386). Il faut

Pas pire qu'OpenBSD, c'est un OS de geek, personne n'en disconvient.

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

FreeBSD est largement aussi performant qu'un Linux, il a un process
d'upgrade du systeme absolument royal de simplicite, un systeme de
package qui permet de personnaliser a l'extreme sans sortir des process
du systeme et tout en respectant les specificites de chaque programme. A
mon avis, le meilleur serveur OS et de tres tres loin meilleur a Debian.

Solaris : un truc infâme (et j'utilise Solaris depuis SunOS 1.4.x

Solaris, c'est un OS industriel, c'est a dire qu'on installe une config
validee par un editeur pour un client, pour repondre a un besoin
particulier, c'est grave dans le marbre et on y touche plus.

On parle de securite, on parle pas de performance, c'est pas le
probleme. J'ai des plateformes SS7 sous Solaris, elles existaient aussi
sous Linux, mais l'editeur travaille sur Solaris par defaut, donc on a
retenu Solaris. Pour les upgrade, c'est le process de l'editeur et hors
sauvegarde et monitoring, on touche meme pas aux machines.

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.

RedHat, c'est le Solaris du Linux. Si c'est necessaire, on passe par la,
sinon on choisit autre chose.

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

Tu as une vision bien etriquee de la chose.

Michel Talon wrote:

Oui, Ubuntu ou Debian c'est quand même essentiellement pareil. Le gros
avantage, c'est la facilité de mise à jour automatique. Il faut être
honnête, dans ce domaine, c'est ce qu'il y a de mieux. C'est un domaine
où FreeBSD est nettement moins au point.

Euh, les opinions divergent tres franchement sur ce dernier point.

Nicolas George <nicolas$george@salle-s.org> wrote:

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.

Bien sûr qu'il y a des raisons techniques à ces choix, je les vois très
bien. Il n'empêche que le pragmatisme, dans un certain nombre de cas,
c'est de laisser les choses telles que le concepteur du logiciel les a
voulues, et pas de mettre à tout prix les choses dans le moule de la
distribution. Par exemple, Sun livre Java tout entier dans un directory,
les autres programmes, comme Tomcat s'attendent à trouver les choses
comme ça, il suffit de déclarer JAVA_HOME, et ça marche. Le pragmatisme
c'est de laisser les choses qui marchent en l'état, et pas de casser
tout en se croyant plus malin. Pareil pour inn, ou pour d'autres
programmes que le concepteur a voulu monolithiques.

--

Michel TALON

Stephane TOUGARD <stephane@unices.org> wrote:

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

Oui, Ubuntu ou Debian c'est quand même essentiellement pareil. Le gros
avantage, c'est la facilité de mise à jour automatique. Il faut être
honnête, dans ce domaine, c'est ce qu'il y a de mieux. C'est un domaine
où FreeBSD est nettement moins au point.

--

Michel TALON

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

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.

SL <nospam@nospam.fr> a écrit :

Le nroff ou troff disponible à l'époque était peut être moins fini. Du
côté de la facilité d'utilisation pure, le TeX pur n'a pas l'air
beaucoup plus facile à manier.

Bof, faut pas exagérer non plus... il y a plein de gens qui utilisent
TeX sans faire de LaTeX...

LaTeX, c'est un langage de secrétaire pour les secrétaires : c'est
tout.

PK

--
      |      _,,,---,,_       Patrice KARATCHENTZEFF
ZZZzz /,`.-'`'    -.  ;-;;,_   mailto:p.karatchentzeff@free.fr
     |,4-  ) )-,_. , (  `'-'  http://p.karatchentzeff.free.fr
    '---''(_/--'  `-'_)       

Kevin Denis wrote:

[...]

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.

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

--
Izatis

On 5 juil, 12:00, JKB <knatsc...@koenigsberg.fr> wrote:

Mais surtout, g77 ignorait certaines extensions à la norme qui étai ent
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 s eule
façon simple de faire de l'allocation dynamique en Fortran.

1/ c'est _hors_ norme

Je sais bien que c'est hors norme. Seulement, à l'époque où la norme
Fortran ne fournissait *aucun* mécanisme d'allocation dynamique (avant
Fortran 90, donc) il fallait bien trouver des solutions. Respecter la
norme c'est très bien, mais par moment il faut être un peu
pragmatique...

Et la syntaxe des pointeurs Cray s'était peu à peu imposée, au point
de devenir une extension "standard de fait", implémentée par tous les
grands constructeurs (en tous cas dans le monde Unix, je ne sais pas
pour VMS). Tout compilo ne proposant pas cette extension s'excluait
d'entrée du jeu dans les applis industrielles.

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

Les "pointeurs Cray" ou bien la syntaxe F90 ? A ma connaissance les
"pointeurs Cray" n'ont jamais existé dans g77, en tous cas pas à
l'époque où il y en avait besoin.

Il est évident qu'aujourd'hui il faut écrire le nouveau code Fortran
avec la syntaxe d'allocation dynamique de la norme, et ne plus
utiliser les "pointeurs Cray". Néanmoins, compte tenu des montagnes de
codes existant et utilisant ces fameux pointeurs, un compilo Fortran
sérieux doit savoir les compiler.

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 optio ns de
compilation). Le critère n'est pas la vitesse mais la
reproductibilité, c'est un peu différent.

La reproductibilité est un critère tellement évident que je n'ai mê me
pas songé à le citer. Un compilateur qui donne des résultats faux,
c'est direct poubelle :-)

Et je maintiens qu'en calcul scientifique, le critère de la vitesse
d'exécution est souvent LE premier critère.

Deuxième critère: compiler sans problème les anciens codes, y com pris
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.

Suivre la norme pour un compilo veut dire compiler tout code
respectant ladite norme. Ce qui n'empêche pas de compiler des
extensions à la norme.

Encore une fois, à cause de certaines limitations importantes qu'à
longtemps eu le Fortran, de nombreuses applications écrites en Fortran
ont longtemps eu recours à certaines extensions. Ce code existe et il
faut en tenir compte.

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

Alors, pour le premier fichier, la compilation plante sur
l'instruction:
des% trbuff(14) = transfer(-1.0, 0)
Le compilo se plaint que le premier argument de transfer() est un
scalaire. Or dans ce que je comprends de la norme, rien ne dit que ce
premier argument ne puisse pas être un scalaire. Et sur une dizaine de
compilos, seul gfortran se plante dessus.

Pour le second fichier, j'ai isolé le code qui fait planter gfortran:
module util_2

contains

!
*************************************************************************** ***
function locase(string)
!
*************************************************************************** ***
character(len=*), intent(in) :: string
character(len=len(string)) :: locase
!
*************************************************************************** ***
locase = string
end function locase

end module util_2
Si j'enlève l'affectation (locase=), ou bien si je compile la même
fonction en dehors du module, ça passe. Ce bout de code est pour moi
valide (et d'ailleurs même si il ne l'était pas, gfortran ne devrait
pas faire une 'internal compiler error')


re-bref, en 10mn j'ai revérifié que gfortran n'était pas fiable...

--
pehache

Nicolas George wrote:

Bon, alors ca ne m'interesse pas. J'essaye depuis hier de faire du
in-charte et de troller sur Debian, si tu viens pas infirmer/confirmer
cela, deja t'es hors sujet.

Dénoncer ton intolérance dans l'utilisation d'un Linux est parfaitement dans
le thème de ce groupe.

Enfin, il y en a qu'on marche. C'est deja ca, pas trop perdu la main.