Windows sur le mainframe

Le Fri, 17 Jul 2009 07:23:30 +0000, JKB a écrit :

On va effectivement trouver des trucs qui ne sont pas dans Gimp,
mais c'est à la marge. J'aimerais savoir quel est le pourcentage
d'utilisateurs de Photoshop qui ne pourraient utiliser Gimp directement.

Je ne suis pas sûr que ça soit la bonne façon d'envisager la chose.
Normalement, Photoshop est un outil professionel, ce n'est pas destiné à
retailler les photos du petit dernier de Mâme Michu.
Pour cet usage, il y a d'autres logiciels chez Adobe même.

Donc si on se replace dans le cadre d'une utilisation pro et en
production, je ne suis pas sûr que Gimp puisse rendre les mêmes services.

En tout cas dans mon cas (photogravure/pré-press print, je l'utilise
essentiellement pour de la retouche photo pour du tirage offset ou
hélio), c'est tout vu : je fais le test régulièrement en suivant
l'évolution des deux logiciels et je ne remplacerai pas mon baril de
Photoshop par Gimp.

Ne serait-ce que pour la qualité de l'intégration dans un flux PostScript/
PDF avec du CTP ou de l'offset numérique derrière.

Ca n'enlève rien aux qualités de Gimp, c'est juste que ce n'est
aujourd'hui pas le produit qui réponde à mon besoin, et n'est AMA pas
équivalent dans ce cadre de référence.

Gnîii ? J'ai acheté pour mon équipe de developpeurs des machines
montées qui m'ont coûtées 350 euros HT (avec des core2quad et 4 Go de
mémoire). J'aimerais savoir où tu peux trouver ce genre de configuration
avec la Ouïndowzerie.

Mouais, dans le cadre d'une activité pro vu ce qu'on facture la journée
le prix de la machine on s'en fout un peu, hein.
La disponibilité et la productivité sont des notions vachement plus
impoortantes AMA.


--
La Bête des Vosges

Le 17-07-2009, ? propos de
Re: Windows sur le mainframe,
Hugolino ?crivait dans fr.comp.os.linux.debats :

Le 17-07-2009, Stephane TOUGARD <stephane@unices.org> a écrit :

JKB wrote:

> Donc ne la ramène pas. Je te signal aimablement que bon nombre
> d'effets spéciaux du film Titanic ont été fait sur un cluster d'alpha,
> avec un linux issu d'une redhat 5.0 et gimp qui n'en était pas encore à
> sa version 1 (puisqu'il s'agissait d'une 0.9.4).

En meme temps, Titanic est un des pires navets de la production
americaine.

Tu dis ça parce que tu n'aimes pas les belles histoires d'amour. C'est
la *preuve* que le linuxien est un être chafoin, aigri et sociopathe !!!

Oui ?! Et alors ?

JKB, chic, un _vrai_ débat ;-)

--
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 17-07-2009, ? propos de
Re: Windows sur le mainframe,
La Bete des Vosges (Francis Chartier) ?crivait dans fr.comp.os.linux.debats :

Le Fri, 17 Jul 2009 07:23:30 +0000, JKB a écrit :

On va effectivement trouver des trucs qui ne sont pas dans Gimp,
mais c'est à la marge. J'aimerais savoir quel est le pourcentage
d'utilisateurs de Photoshop qui ne pourraient utiliser Gimp directement.

Je ne suis pas sûr que ça soit la bonne façon d'envisager la chose.
Normalement, Photoshop est un outil professionel, ce n'est pas destiné à
retailler les photos du petit dernier de Mâme Michu.
Pour cet usage, il y a d'autres logiciels chez Adobe même.

Donc si on se replace dans le cadre d'une utilisation pro et en
production, je ne suis pas sûr que Gimp puisse rendre les mêmes services.

En tout cas dans mon cas (photogravure/pré-press print, je l'utilise
essentiellement pour de la retouche photo pour du tirage offset ou
hélio), c'est tout vu : je fais le test régulièrement en suivant
l'évolution des deux logiciels et je ne remplacerai pas mon baril de
Photoshop par Gimp.

Ne serait-ce que pour la qualité de l'intégration dans un flux PostScript/
PDF avec du CTP ou de l'offset numérique derrière.

Ca n'enlève rien aux qualités de Gimp, c'est juste que ce n'est
aujourd'hui pas le produit qui réponde à mon besoin, et n'est AMA pas
équivalent dans ce cadre de référence.

Gnîii ? J'ai acheté pour mon équipe de developpeurs des machines
montées qui m'ont coûtées 350 euros HT (avec des core2quad et 4 Go de
mémoire). J'aimerais savoir où tu peux trouver ce genre de configuration
avec la Ouïndowzerie.

Mouais, dans le cadre d'une activité pro vu ce qu'on facture la journée
le prix de la machine on s'en fout un peu, hein.
La disponibilité et la productivité sont des notions vachement plus
impoortantes AMA.

Quand tu développes pour toi, tu ne factures pas _directement_. Tu
commences par investir.

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.

On 17 juil, 13:07, Hugolino <hugol...@free.fr> wrote:

>  Toi non plus tu ne connais pas la différence entre "utiliser" et
>  "connaître" ?

Si.

Visiblement non.

Tout ça pour essayer de te faire comprendre qu'il est vraiment dommage
tu ne prennes pas la peine d'écrire sur papier hygiénique, ton avis d e
trou du cul prétendant connaître un logiciel sans pour autant
l'utiliser.

J'ai prétendu une seule chose : que Gimp ne pouvait pas rendre les
mêmes services que Photoshop. C'est une réalité et il n'y a pas besoi n
de les utiliser *régulièrement* pour le constater.

Le reste c'est tes broderies habituelles sans intérêt.

Ça pourrait au moins avoir une utilité à tous les lecteurs
de ce ng que tu fais régulièrement chier avec tes inepties débiles.

Et apparemment tu aimes bien en chier, sinon tu m'aurais plonké depuis
longtemps.

>  Oulà, t'es en colère, toi... C'est parce que j'avais montré à tout le
>  monde que tu n'y connaissais pas grand-chose dans un fil sur fcom-w ?

Celui où tu prétendais que je n'avais pas compris la différence ent re
connexions sortantes et entrantes

Oui. Tu as compris, maintenant ?

C'est aussi celui où tu avais peur qu'un PC derrière une box-routeur
et ouvrant un partage CIFS puisse se faire trouer de l'extérieur, ce
qui est à mourir de rire de la part de quelqu'un qui prétend
habituellement avoir quelques compétences en la matière.

alors que c'est toi qui ne comprenais
pas que le critère discriminant était sur l'initiation de la connexio n ?
JKB l'avait très bien expliqué dans le message de M-ID:
<slrnh05tcq.s3d.knatsc...@rayleigh.systella.fr>, mais tu avais bien
évidemment pris soin de ne pas répondre à ça...

JKB répondait à Jérôme Lambert et pas à moi. Et par ailleurs JL a vait
parfaitement répondu à JKB, et je n'avais rien à ajouter.

--
pehache

Le 17-07-2009, JKB <knatschke@koenigsberg.fr> a écrit :

Hugolino ?crivait dans fr.comp.os.linux.debats :
> Le 17-07-2009, Stephane TOUGARD <stephane@unices.org> a écrit :
>> JKB wrote:
>>
>> > Donc ne la ramène pas. Je te signal aimablement que bon nombre
>> > d'effets spéciaux du film Titanic ont été fait sur un cluster
>> > d'alpha, avec un linux issu d'une redhat 5.0 et gimp qui n'en
>> > était pas encore à sa version 1 (puisqu'il s'agissait d'une
>> > 0.9.4).
>>
>> En meme temps, Titanic est un des pires navets de la production
>> americaine.
>
> Tu dis ça parce que tu n'aimes pas les belles histoires d'amour.
> C'est la *preuve* que le linuxien est un être chafoin, aigri et
> sociopathe !!!

Oui ?! Et alors ?

JKB, chic, un _vrai_ débat ;-)

Mais tout à fait ! La question peut se résumer ainsi:

Pour utiliser un système qui ne représente que «1% de part de marché»,
le linuxien ne doit-il pas sombrer dans une ascèse absolue, un peu comme
on sombre dans l'alcoolisme ? Ou, a contrario, doit-il faire preuve
d'ouverture d'esprit pour quitter la masse panurgeante des analphabêêtes
de l'in-faux ?

Et d'ailleurs ce fameux critère du «1% de part de marché» est-il
pertinent ? Cela a-t-il un quelconque intérêt de parler d'informatique
personnelle en utilisant une unité de mesure économique, oubliant par là
toutes les implications sociologisantes, éducationnellistiques et
culturesques ?

Linux est-il un système réservé à une élite, et donc un système de
droite ? Ou n'est-il adopté que par la lie de l'humanité, les inadaptés
anarcho-troskistes de l'ultra-gauche antigouvernementale ?


Every night in my dreams
I see you, I feel you,
That is how I know you go on

Far across the distance
And spaces between us
You have come to show you go on

Near, far, wherever you are
I believe that the heart does go on
Once more you open the door
And you're here in my heart
And my heart will go on and on

Love can touch us one time
And last for a lifetime
And never let go till we're one

Love was when I loved you
One true time I hold to
In my life we'll always go on

Near, far, wherever you are
I believe that the heart does go on
Once more you open the door
And you're here in my heart
And my heart will go on and on

There is some love that will not go away

You're here, there's nothing I fear,
And I know that my heart will go on
We'll stay forever this way
You are safe in my heart
And my heart will go on and on



--
A l'âge de bière, les hommes vivaient dans les tavernes.
Hugo (né il y a 1 427 285 350 secondes)

On 16 juil, 12:49, JKB <knatsc...@koenigsberg.fr> wrote:

en évidence le phénomène. Ça se mesure sur les x86, mais c'est
plus difficile car gcc est sournois, il se permet souvent d'aligner la
mémoire dans le dos de l'utilisateur.

Il me semble même que c'est son comportement par défaut non (ça fait
un bail que j'ai plus joué à ce genre de truc) ?

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 17-07-2009, ? propos de
Re: 32 vs. 64 bits [était Re: Windows sur le mainframe],
totof2000 ?crivait dans fr.comp.os.linux.debats :

On 16 juil, 12:49, JKB <knatsc...@koenigsberg.fr> wrote:

en évidence le phénomène. Ça se mesure sur les x86, mais c'est
plus difficile car gcc est sournois, il se permet souvent d'aligner la
mémoire dans le dos de l'utilisateur.

Il me semble même que c'est son comportement par défaut non (ça fait
un bail que j'ai plus joué à ce genre de truc) ?

Non, pas par défaut (au moins pour les versions de gcc sur
lesquelles j'ai testé le truc). Pour s'en convaincre, il y a quelques
lignes d'assembleur qui provoquent un SIGBUS dès qu'un accès a lieu sur
une variable non alignée. Mettre ça au début d'un programme provoque
assez rapidement un SIGBUS sur un programme fonctionne sans.

Pour s'en convaincre, il suffit de compiler un truc comme firefox ou
seamonkey sur une architecture demandant des alignements mémoire...

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.

On 16 juil, 20:57, "pehache-tolai" <pehach...@gmail.com> wrote:

"JKB" <knatsc...@koenigsberg.fr> a écrit dans le message de news:
slrnh5u7i0.bmh.knatsc...@rayleigh.systella.fr



>>> Pour ceux qui codent en Fortran, il existe une foultitude de
>>> logical*(1/2/4/8/16) destinés à palier à ce genre de problème
>>> d'alignement sur des processeurs qui n'utilisent pas d'alignement
>>> mémoire.

>> En fait pratiquement aucun rapport avec les problèmes d'alignement !

> Si. Les logical* proviennent des extension VAX et sont justement là
> pour éviter d'avoir des problèmes d'aligement dans les structures
> (elles aussi en extension VAX). C'est même leur seul intérêt (g âcher
> de la place pour gagner en vitesse).

Un compilo qui ne sait pas aligner tout seul les données dans une struc ture,
quitte à laisser des trous, c'est pas très sérieux.

Tout dépend du compilo et de ce que tu fais avec ....

Quand tu fais du dev bas niveau avec des accès hard, tu n'as pas
toujours envie que le compilo réorganise tes structures sans te
prévenir .....

>> Certains compilateurs fournissent donc des types LOGICAL(n), qui /
>> peuvent/ éventuellement occuper moins de 32 bits, dans le but
>> d'économiser de la mémoire. Mais d'une part la portabilité n'a r ien
>> de garantie (la norme ne requiert que le type LOGICAL de base) et
>> d'autre part un LOGICAL(1) quand il existe peut fort bien occuper en
>> réalité 32 bits (la norme n'imposant aucune taille pour les types
>> LOGICAL supplémentaires).

> Les déclarations X*Y proviennent des extensions VAX et le Y est le
> nombre d'octets de la variable. J'aimerais que tu nous donnes ici un
> seul compilo fortran qui pour logical*1 positionne autre chose d'un
> drapeau sur un octet

Fais ton choix :

http://www.idris.fr/su/Vectoriel/brodie/options_fortran.html

> (au passage, ces trucs ont été normalisés, enfin
> presque, dans un draft qui s'appelle Fortran-84, ce qui fait que
> lorsque tu vois extensions VAX sur un compilo, c'est quelque chose de
> _très_ précis).

Voilà : ça n'a *jamais* été normalisé. Et de fait écrire un c ode en
supposant par exemple que REAL*8 va occuper la même place qu'un DOUBLE
PRECISION est casse-gueule du point de vue portabilité (cas vécu).



> Au passage, LOGICAL*1 et LOGICAL(1), ce n'est pas la même chose. Je
> te laisse chercher un peu.

Exact

>> De toute façon la "philosophie" du Fortran est généralement de f aire
>> abstraction de la façon dont sont représentées les données en
>> mémoire. Les LOGICAL(n) ne sont donc pas trop dans l'esprit Fortran.

> Il y a longtemps que tu n'as pas vu un code Fortran, toi !

J'en fais juste tous les jours, ou presque.

Et je maintiens : en comparaison du C, la norme Fortran se soucie très peu
de la façon dont sont représentées les données en mémoire, et ça s'est
accentué depuis le Fortran 90 (tableaux qui ne sont plus forcément co ntigus
en mémoire, etc...). La seule contrainte de ce genre en Fortran est qu' un
REAL ou un LOGICAL doivent occuper exactement la place d'un INTEGER (sans
que ce soit forcément un mot machine) et qu'un COMPLEX ou un DOUBLE
PRECISION doivent occuper la place de deux REAL. Tout le reste est à la
libre appréciation du compilo.

D'ailleurs je note que les extensions Y*n n'ont jamais été normalis ées alors
qu'elles étaient très courantes. A la place ce sont les Y(KIND=m) q ui l'ont
été, qui sont très différents des Y*n comme tu l'as rappelé, et qui
notamment ne disent *rien* sur la place occupée en mémoire.

--
pehachehttp://pehache.free.fr/public.html

Le 17-07-2009, ? propos de
Re: 32 vs. 64 bits [était Re: Windows sur le mainframe],
totof2000 ?crivait dans fr.comp.os.linux.debats :

On 16 juil, 20:57, "pehache-tolai" <pehach...@gmail.com> wrote:

"JKB" <knatsc...@koenigsberg.fr> a écrit dans le message de news:
slrnh5u7i0.bmh.knatsc...@rayleigh.systella.fr



>>> Pour ceux qui codent en Fortran, il existe une foultitude de
>>> logical*(1/2/4/8/16) destinés à palier à ce genre de problème
>>> d'alignement sur des processeurs qui n'utilisent pas d'alignement
>>> mémoire.

>> En fait pratiquement aucun rapport avec les problèmes d'alignement !

> Si. Les logical* proviennent des extension VAX et sont justement là
> pour éviter d'avoir des problèmes d'aligement dans les structures
> (elles aussi en extension VAX). C'est même leur seul intérêt (gâcher
> de la place pour gagner en vitesse).

Un compilo qui ne sait pas aligner tout seul les données dans une structure,
quitte à laisser des trous, c'est pas très sérieux.

Tout dépend du compilo et de ce que tu fais avec ....

Quand tu fais du dev bas niveau avec des accès hard, tu n'as pas
toujours envie que le compilo réorganise tes structures sans te
prévenir .....

Même sans ça. Tu peux très bien faire des hypothèses sur le
placement en mémoire de tes objets pour optimiser certains codes.
J'ai en particulier un A* pas piqué des vers optimisé aux petits oignons
qui se casserait la gueule assez rapidement si le compilo décidait de
faire des choses dans mon dos.

>> Certains compilateurs fournissent donc des types LOGICAL(n), qui /
>> peuvent/ éventuellement occuper moins de 32 bits, dans le but
>> d'économiser de la mémoire. Mais d'une part la portabilité n'a rien
>> de garantie (la norme ne requiert que le type LOGICAL de base) et
>> d'autre part un LOGICAL(1) quand il existe peut fort bien occuper en
>> réalité 32 bits (la norme n'imposant aucune taille pour les types
>> LOGICAL supplémentaires).

> Les déclarations X*Y proviennent des extensions VAX et le Y est le
> nombre d'octets de la variable. J'aimerais que tu nous donnes ici un
> seul compilo fortran qui pour logical*1 positionne autre chose d'un
> drapeau sur un octet

Fais ton choix :

http://www.idris.fr/su/Vectoriel/brodie/options_fortran.html

> (au passage, ces trucs ont été normalisés, enfin
> presque, dans un draft qui s'appelle Fortran-84, ce qui fait que
> lorsque tu vois extensions VAX sur un compilo, c'est quelque chose de
> _très_ précis).

Voilà : ça n'a *jamais* été normalisé. Et de fait écrire un code en
supposant par exemple que REAL*8 va occuper la même place qu'un DOUBLE
PRECISION est casse-gueule du point de vue portabilité (cas vécu).

Si, en extension du Fortran-77, justement. J'ai un draft IEEE
là-dessus. C'est même pour cela que les extension VAX/VMS sont portables
d'un compilo à l'autre. Même le compilo Fortran 5.x de Microsoft les
comprenait, c'est dire !

> Au passage, LOGICAL*1 et LOGICAL(1), ce n'est pas la même chose. Je
> te laisse chercher un peu.

Exact

Tu as pourtant écrit juste un peu plus haut LOGICAL(n) alors que je
te parle de LOGICAL*n, ce qui est _différent_.

>> De toute façon la "philosophie" du Fortran est généralement de faire
>> abstraction de la façon dont sont représentées les données en
>> mémoire. Les LOGICAL(n) ne sont donc pas trop dans l'esprit Fortran.

> Il y a longtemps que tu n'as pas vu un code Fortran, toi !

J'en fais juste tous les jours, ou presque.

Un type qui est infoutu de faire la différence entre LOGICAL(kind=n)
et LOGICAL*n devrait commencer par changer de métier.

Et je maintiens : en comparaison du C, la norme Fortran se soucie très peu
de la façon dont sont représentées les données en mémoire, et ça s'est
accentué depuis le Fortran 90 (tableaux qui ne sont plus forcément contigus
en mémoire, etc...).

Gnîii ? Là, tu mélanges allègrement deux notions, mais venant de
toi, je m'attends vraiment à tout !...

La seule contrainte de ce genre en Fortran est qu'un
REAL ou un LOGICAL doivent occuper exactement la place d'un INTEGER (sans
que ce soit forcément un mot machine) et qu'un COMPLEX ou un DOUBLE
PRECISION doivent occuper la place de deux REAL. Tout le reste est à la
libre appréciation du compilo.

Faux. J'ai la flemme de chercher dans la doc, mais j'ai au moins un
contre-exemple. INTEGER et LOGICAL (de base) sont de même longueur.
Quant à REAL, rien n'est dit. J'ai plusieurs compilo pour lesquels la
longueur du REAL est supérieure à celle de l'INTEGER.
Tu t'avances aussi beaucoup en disant qu'un DOUBLE PRECISION est deux
fois plus long qu'un REAL. Enfin, c'est à toi de voir.

D'ailleurs je note que les extensions Y*n n'ont jamais été normalisées alors
qu'elles étaient très courantes. A la place ce sont les Y(KIND=m) qui l'ont
été, qui sont très différents des Y*n comme tu l'as rappelé, et qui
notamment ne disent *rien* sur la place occupée en mémoire.

Ça, c'est parce que tu codes comme un pied. Il y a un mécanisme qui
te permet de trouver le type à balancer dans le KIND en fonction de ta
plage. Je te laisse là encore chercher.

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.

On 17 juil, 16:57, totof2000 <cdesques...@ifrance.com> wrote:

> Un compilo qui ne sait pas aligner tout seul les données dans une str ucture,
> quitte à laisser des trous, c'est pas très sérieux.

Tout dépend du compilo  et de ce que tu fais avec ....

Quand tu fais du dev bas niveau avec des accès hard, tu n'as pas
toujours envie que le compilo réorganise tes structures sans te
prévenir .....

Quand on veut faire du dev bas niveau avec des accès hard, on ne le
fait pas en Fortran, tout simplement. Il y a des langages plus
adaptés, plutôt que de faire des contorsions qui n'est pas fait pour à
la base.

--
pehache