"""
L'étude, qui porte sur plus de 100 entreprises réalisant un chiffre
d'affaires de plus de 2 Md$, indique que 70% des clients mainframe
dépenseront plus pour l'usage de Linux sur grands systèmes dans les deux
ans à venir qu'aujourd'hui.
On savait déjà qu'IBM poussait ses clients à l'usage de Linux sur
mainframe. Mais il semble que les clients de Big Blue adhèrent au
message du constructeur. Selon une étude réalisée pour le compte de CA
par The InfoPro, deux tiers des utilisateurs de grands systèmes z-series
prévoient une hausse de leurs capacités linux supérieure à 40% d'ici
deux ans.
"""
ah ben zut ça parle pas de windows ? wa pas de windows pour les
mainframes ? mais faut vite y compiler CE7 !!!
Et même en admettant que ça ait pu être normalisé en tant qu'extension de F77, ça n'a pas été reconduit en F90 et au-delà. Et F77 étant une norme obsolète, les extensions Y*n sont de fait obsolètes aussi.
Les extensions Y*X sont encore marquées comme extensions _valides_ et non _obsolètes_ dans la référence Fortran2003 que j'ai sous les yeux.
J'en doute fortement. Mais je ne trouve pas l'info pour le moment. Je me renseigne.
J'avais raison de douter. Encore une connerie de ta part :
"pehache-tolai" <pehache.7@gmail.com> a écrit dans le message de news:
7cbu8mF27gjtvU1@mid.individual.net
Et même en admettant que ça ait pu être normalisé en tant
qu'extension de F77, ça n'a pas été reconduit en F90 et au-delà. Et
F77 étant une norme obsolète, les extensions Y*n sont de fait
obsolètes aussi.
Les extensions Y*X sont encore marquées comme extensions _valides_
et non _obsolètes_ dans la référence Fortran2003 que j'ai sous les
yeux.
J'en doute fortement. Mais je ne trouve pas l'info pour le moment. Je
me renseigne.
J'avais raison de douter. Encore une connerie de ta part :
Et même en admettant que ça ait pu être normalisé en tant qu'extension de F77, ça n'a pas été reconduit en F90 et au-delà. Et F77 étant une norme obsolète, les extensions Y*n sont de fait obsolètes aussi.
Les extensions Y*X sont encore marquées comme extensions _valides_ et non _obsolètes_ dans la référence Fortran2003 que j'ai sous les yeux.
J'en doute fortement. Mais je ne trouve pas l'info pour le moment. Je me renseigne.
J'avais raison de douter. Encore une connerie de ta part :
Le 17-07-2009, ? propos de Re: 32 vs. 64 bits [était Re: Windows sur le mainframe], pehache-tolai ?crivait dans fr.comp.os.linux.debats :
> On 17 juil, 16:57, totof2000 wrote:
>> > 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 .....
> 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 pou r à > la base.
On s'en contrefiche. Le fait d'avoir des types de longueurs différentes, même si ça te semble inutile, est quelque chose d'intéressant (et parfois d'indispensable comme lorsque tu dois interfacer des bouts de C avec du Fortran). Il n'y a pas qu'en faisant du bas niveau que tu dois savoir exactement ce que tu fais.
Pour moi, interfacer des bouts de C avec du fortran entre dans la catégorie "programmation bas niveau" .... même si dans ce cas on ne fait pas d'accès au matériel.
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, 17:27, JKB <knatsc...@koenigsberg.fr> wrote:
Le 17-07-2009, ? propos de
Re: 32 vs. 64 bits [était Re: Windows sur le mainframe],
pehache-tolai ?crivait dans fr.comp.os.linux.debats :
> On 17 juil, 16:57, totof2000 <cdesques...@ifrance.com> wrote:
>> > 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 .....
> 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 pou r à
> la base.
On s'en contrefiche. Le fait d'avoir des types de longueurs
différentes, même si ça te semble inutile, est quelque chose
d'intéressant (et parfois d'indispensable comme lorsque tu dois
interfacer des bouts de C avec du Fortran). Il n'y a pas qu'en faisant
du bas niveau que tu dois savoir exactement ce que tu fais.
Pour moi, interfacer des bouts de C avec du fortran entre dans la
catégorie "programmation bas niveau" .... même si dans ce cas on ne
fait pas d'accès au matériel.
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], pehache-tolai ?crivait dans fr.comp.os.linux.debats :
> On 17 juil, 16:57, totof2000 wrote:
>> > 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 .....
> 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 pou r à > la base.
On s'en contrefiche. Le fait d'avoir des types de longueurs différentes, même si ça te semble inutile, est quelque chose d'intéressant (et parfois d'indispensable comme lorsque tu dois interfacer des bouts de C avec du Fortran). Il n'y a pas qu'en faisant du bas niveau que tu dois savoir exactement ce que tu fais.
Pour moi, interfacer des bouts de C avec du fortran entre dans la catégorie "programmation bas niveau" .... même si dans ce cas on ne fait pas d'accès au matériel.
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.
JKB
Le 18-07-2009, ? propos de Re: 32 vs. 64 bits [était Re: Windows sur le mainframe], totof2000 ?crivait dans fr.comp.os.linux.debats :
On 17 juil, 17:27, JKB wrote:
Le 17-07-2009, ? propos de Re: 32 vs. 64 bits [était Re: Windows sur le mainframe], pehache-tolai ?crivait dans fr.comp.os.linux.debats :
> On 17 juil, 16:57, totof2000 wrote:
>> > 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 .....
> 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.
On s'en contrefiche. Le fait d'avoir des types de longueurs différentes, même si ça te semble inutile, est quelque chose d'intéressant (et parfois d'indispensable comme lorsque tu dois interfacer des bouts de C avec du Fortran). Il n'y a pas qu'en faisant du bas niveau que tu dois savoir exactement ce que tu fais.
Pour moi, interfacer des bouts de C avec du fortran entre dans la catégorie "programmation bas niveau" .... même si dans ce cas on ne fait pas d'accès au matériel.
Oui, bon, mais on ne va pas obscursir encore plus les idées du sieur en question qui est en train de se dépatouiller avec les réponses sur le groupe fortran au sujet d'une question sur les real*8. En gros, il est en train de demander si le real*8 est 'standard' donc si ça fait partie de la norme. Réponse que je lui ai déjà donnée, mais passons. Lorsqu'il va tomber sur le fait qu'un real8 peut faire avec certains compilos sur une architecture non orientée 8 bits une longueur de 56 bits, il va revenir la bouche en coeur. Ce type mérite justement de lire les specs 77, 90, 95 et 2003 jusqu'à plus soif (et leurs extensions). Je lui fait grâce du Fortran 2008.
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 18-07-2009, ? propos de
Re: 32 vs. 64 bits [était Re: Windows sur le mainframe],
totof2000 ?crivait dans fr.comp.os.linux.debats :
On 17 juil, 17:27, JKB <knatsc...@koenigsberg.fr> wrote:
Le 17-07-2009, ? propos de
Re: 32 vs. 64 bits [était Re: Windows sur le mainframe],
pehache-tolai ?crivait dans fr.comp.os.linux.debats :
> On 17 juil, 16:57, totof2000 <cdesques...@ifrance.com> wrote:
>> > 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 .....
> 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.
On s'en contrefiche. Le fait d'avoir des types de longueurs
différentes, même si ça te semble inutile, est quelque chose
d'intéressant (et parfois d'indispensable comme lorsque tu dois
interfacer des bouts de C avec du Fortran). Il n'y a pas qu'en faisant
du bas niveau que tu dois savoir exactement ce que tu fais.
Pour moi, interfacer des bouts de C avec du fortran entre dans la
catégorie "programmation bas niveau" .... même si dans ce cas on ne
fait pas d'accès au matériel.
Oui, bon, mais on ne va pas obscursir encore plus les idées du sieur
en question qui est en train de se dépatouiller avec les réponses sur le
groupe fortran au sujet d'une question sur les real*8. En gros, il est
en train de demander si le real*8 est 'standard' donc si ça fait partie
de la norme. Réponse que je lui ai déjà donnée, mais passons. Lorsqu'il va
tomber sur le fait qu'un real8 peut faire avec certains compilos sur une
architecture non orientée 8 bits une longueur de 56 bits, il va revenir
la bouche en coeur. Ce type mérite justement de lire les specs 77, 90,
95 et 2003 jusqu'à plus soif (et leurs extensions). Je lui fait grâce du
Fortran 2008.
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 18-07-2009, ? propos de Re: 32 vs. 64 bits [était Re: Windows sur le mainframe], totof2000 ?crivait dans fr.comp.os.linux.debats :
On 17 juil, 17:27, JKB wrote:
Le 17-07-2009, ? propos de Re: 32 vs. 64 bits [était Re: Windows sur le mainframe], pehache-tolai ?crivait dans fr.comp.os.linux.debats :
> On 17 juil, 16:57, totof2000 wrote:
>> > 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 .....
> 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.
On s'en contrefiche. Le fait d'avoir des types de longueurs différentes, même si ça te semble inutile, est quelque chose d'intéressant (et parfois d'indispensable comme lorsque tu dois interfacer des bouts de C avec du Fortran). Il n'y a pas qu'en faisant du bas niveau que tu dois savoir exactement ce que tu fais.
Pour moi, interfacer des bouts de C avec du fortran entre dans la catégorie "programmation bas niveau" .... même si dans ce cas on ne fait pas d'accès au matériel.
Oui, bon, mais on ne va pas obscursir encore plus les idées du sieur en question qui est en train de se dépatouiller avec les réponses sur le groupe fortran au sujet d'une question sur les real*8. En gros, il est en train de demander si le real*8 est 'standard' donc si ça fait partie de la norme. Réponse que je lui ai déjà donnée, mais passons. Lorsqu'il va tomber sur le fait qu'un real8 peut faire avec certains compilos sur une architecture non orientée 8 bits une longueur de 56 bits, il va revenir la bouche en coeur. Ce type mérite justement de lire les specs 77, 90, 95 et 2003 jusqu'à plus soif (et leurs extensions). Je lui fait grâce du Fortran 2008.
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
"JKB" a écrit dans le message de news:
Oui, bon, mais on ne va pas obscursir encore plus les idées du sieur en question qui est en train de se dépatouiller avec les réponses sur le groupe fortran au sujet d'une question sur les real*8. En gros, il est en train de demander si le real*8 est 'standard' donc si ça fait partie de la norme.
Non mon crétin, tu ne sais pas lire.
J'ai demandé si bien qu'étant non requises par la norme, les extensions Y*n avaient fait l'objet d'une standardisation quelconque annexée à la norme Fortran (du style "si cette extension est implémentée, elle doit l'être de telle façon"), comme c'est le cas pour certaines autres fonctionnalités. La réponse a été claire : non.
Je rappelle que tu as dit dans ce fil : "Les extensions Y*X sont encore marquées comme extensions valides et non obsolètes dans la référence Fortran2003 que j'ai sous les yeux"
Et je rappelle que Steve Lionel m'a répondu : "I am not aware of any addendum to an ISO/ANSI Fortran standard describing syntax that has never been part of a Fortran standard, such as the TYPE*n syntax you asked about. It may be (and is) a widely-supported extension, but that's all it is, an extension, one that has never been part of the Fortran standard."
C'est à dire : "Je ne connais aucun addendum à aucun ISO/ANSI Fortran standard et décrivant une syntaxe qui n'a jamais fait partie du standard Fortran, comme la syntaxe TYPE*n dont vous parlez. Cela peut-être (et c'est) une extension très largement supportée, mais c'est tout ce que c'est, une extension, qui n'a jamais fait partie du standard Fortran".
Donc quand tu dis que les Y*X apparaissent comme extensions valides dans la référence F2003, je ne peux conclure qu'une chose : tu affabules.
Réponse que je lui ai déjà donnée, mais passons. Lorsqu'il va tomber sur le fait qu'un real8 peut faire avec certains compilos sur une architecture non orientée 8 bits une longueur de 56 bits, il va revenir la bouche en coeur.
Pauvre type. Dis-moi juste où j'ai bien pu dire qu'un REAL*8 devait obligatoirement toujours faire 64 bits : tu vas avoir du mal.
Comme tu es en difficulté sur la discussion en cours, où toutes les conneries que tu racontes sortent au grand jour, tu essaies encore ce que tu sais le mieux faire : étaler ta confiture pour faire oublier le reste, ce coup-ci avec les machines autres que 8bits, qui ne changent rien aux problèmes dont on discute.
T'es vraiment nase. Jusqu'à récemment je pensais que tu te la pétais un peu sur les forums. Après avoir vu ta page personnelle et au vu de toutes les conneries que tu racontes avec aplomb, je suis maintenant convaincu d'une chose : tu te la pètes beaucoup sur les forums.
-- pehache http://pehache.free.fr/public.html
"JKB" <knatschke@koenigsberg.fr> a écrit dans le message de news:
slrnh637je.uqv.knatschke@rayleigh.systella.fr
Oui, bon, mais on ne va pas obscursir encore plus les idées du sieur
en question qui est en train de se dépatouiller avec les réponses sur
le groupe fortran au sujet d'une question sur les real*8. En gros, il
est
en train de demander si le real*8 est 'standard' donc si ça fait
partie de la norme.
Non mon crétin, tu ne sais pas lire.
J'ai demandé si bien qu'étant non requises par la norme, les extensions Y*n
avaient fait l'objet d'une standardisation quelconque annexée à la norme
Fortran (du style "si cette extension est implémentée, elle doit l'être de
telle façon"), comme c'est le cas pour certaines autres fonctionnalités. La
réponse a été claire : non.
Je rappelle que tu as dit dans ce fil : "Les extensions Y*X sont encore
marquées comme extensions valides
et non obsolètes dans la référence Fortran2003 que j'ai sous les yeux"
Et je rappelle que Steve Lionel m'a répondu : "I am not aware of any
addendum to an ISO/ANSI Fortran standard describing syntax that has never
been part of a Fortran standard, such as the TYPE*n syntax you asked about.
It may be (and is) a widely-supported extension, but that's all it is, an
extension, one that has never been part of the Fortran standard."
C'est à dire : "Je ne connais aucun addendum à aucun ISO/ANSI Fortran
standard et décrivant une syntaxe qui n'a jamais fait partie du standard
Fortran, comme la syntaxe TYPE*n dont vous parlez. Cela peut-être (et c'est)
une extension très largement supportée, mais c'est tout ce que c'est, une
extension, qui n'a jamais fait partie du standard Fortran".
Donc quand tu dis que les Y*X apparaissent comme extensions valides dans la
référence F2003, je ne peux conclure qu'une chose : tu affabules.
Réponse que je lui ai déjà donnée, mais passons.
Lorsqu'il va tomber sur le fait qu'un real8 peut faire avec certains
compilos sur une architecture non orientée 8 bits une longueur de 56
bits, il va revenir la bouche en coeur.
Pauvre type. Dis-moi juste où j'ai bien pu dire qu'un REAL*8 devait
obligatoirement toujours faire 64 bits : tu vas avoir du mal.
Comme tu es en difficulté sur la discussion en cours, où toutes les
conneries que tu racontes sortent au grand jour, tu essaies encore ce que tu
sais le mieux faire : étaler ta confiture pour faire oublier le reste, ce
coup-ci avec les machines autres que 8bits, qui ne changent rien aux
problèmes dont on discute.
T'es vraiment nase. Jusqu'à récemment je pensais que tu te la pétais un peu
sur les forums. Après avoir vu ta page personnelle et au vu de toutes les
conneries que tu racontes avec aplomb, je suis maintenant convaincu d'une
chose : tu te la pètes beaucoup sur les forums.
Oui, bon, mais on ne va pas obscursir encore plus les idées du sieur en question qui est en train de se dépatouiller avec les réponses sur le groupe fortran au sujet d'une question sur les real*8. En gros, il est en train de demander si le real*8 est 'standard' donc si ça fait partie de la norme.
Non mon crétin, tu ne sais pas lire.
J'ai demandé si bien qu'étant non requises par la norme, les extensions Y*n avaient fait l'objet d'une standardisation quelconque annexée à la norme Fortran (du style "si cette extension est implémentée, elle doit l'être de telle façon"), comme c'est le cas pour certaines autres fonctionnalités. La réponse a été claire : non.
Je rappelle que tu as dit dans ce fil : "Les extensions Y*X sont encore marquées comme extensions valides et non obsolètes dans la référence Fortran2003 que j'ai sous les yeux"
Et je rappelle que Steve Lionel m'a répondu : "I am not aware of any addendum to an ISO/ANSI Fortran standard describing syntax that has never been part of a Fortran standard, such as the TYPE*n syntax you asked about. It may be (and is) a widely-supported extension, but that's all it is, an extension, one that has never been part of the Fortran standard."
C'est à dire : "Je ne connais aucun addendum à aucun ISO/ANSI Fortran standard et décrivant une syntaxe qui n'a jamais fait partie du standard Fortran, comme la syntaxe TYPE*n dont vous parlez. Cela peut-être (et c'est) une extension très largement supportée, mais c'est tout ce que c'est, une extension, qui n'a jamais fait partie du standard Fortran".
Donc quand tu dis que les Y*X apparaissent comme extensions valides dans la référence F2003, je ne peux conclure qu'une chose : tu affabules.
Réponse que je lui ai déjà donnée, mais passons. Lorsqu'il va tomber sur le fait qu'un real8 peut faire avec certains compilos sur une architecture non orientée 8 bits une longueur de 56 bits, il va revenir la bouche en coeur.
Pauvre type. Dis-moi juste où j'ai bien pu dire qu'un REAL*8 devait obligatoirement toujours faire 64 bits : tu vas avoir du mal.
Comme tu es en difficulté sur la discussion en cours, où toutes les conneries que tu racontes sortent au grand jour, tu essaies encore ce que tu sais le mieux faire : étaler ta confiture pour faire oublier le reste, ce coup-ci avec les machines autres que 8bits, qui ne changent rien aux problèmes dont on discute.
T'es vraiment nase. Jusqu'à récemment je pensais que tu te la pétais un peu sur les forums. Après avoir vu ta page personnelle et au vu de toutes les conneries que tu racontes avec aplomb, je suis maintenant convaincu d'une chose : tu te la pètes beaucoup sur les forums.
-- pehache http://pehache.free.fr/public.html
David Marec
pehache-tolai:
Après avoir vu ta page personnelle et au vu de toutes les conneries que tu racontes avec aplomb,
Lorsque l'on raconte une connerie, il *faut toujours* le faire avec aplomb.
Lorsque l'on raconte une connerie, il *faut toujours* le faire avec aplomb.
Sinon, ça compte pas.
Et ça permet de suivre le fil. Aplomb. -- Kevin
Stephane TOUGARD
JKB wrote:
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.
Ca, je sais pas et ce n'est pas la question de toutes facons.
La question, c'est est que Gimp est au niveau de PS et la reponse est non. Maintenant, non Gimp ne suffit pas a mes besoins, PS non plus de toutes facons.
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.
Ici, ca doit etre possible. En France, je sais pas.
JKB wrote:
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.
Ca, je sais pas et ce n'est pas la question de toutes facons.
La question, c'est est que Gimp est au niveau de PS et la reponse est
non. Maintenant, non Gimp ne suffit pas a mes besoins, PS non plus de
toutes facons.
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.
Ici, ca doit etre possible. En France, je sais pas.
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.
Ca, je sais pas et ce n'est pas la question de toutes facons.
La question, c'est est que Gimp est au niveau de PS et la reponse est non. Maintenant, non Gimp ne suffit pas a mes besoins, PS non plus de toutes facons.
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.
Ici, ca doit etre possible. En France, je sais pas.
Stephane TOUGARD
Patrice Karatchentzeff wrote:
C'est vrai : on ne voit même pas Hulk dans le film...
L'autre navet majeur de la production americaine. A penser qu'il y a un rapport entre l'usage abusif de la 3D et la navetude du resultat, il n'y qu'un pipolin que je n'hesiterai pas a franchir.
Patrice Karatchentzeff wrote:
C'est vrai : on ne voit même pas Hulk dans le film...
L'autre navet majeur de la production americaine. A penser qu'il y a un
rapport entre l'usage abusif de la 3D et la navetude du resultat, il n'y
qu'un pipolin que je n'hesiterai pas a franchir.
C'est vrai : on ne voit même pas Hulk dans le film...
L'autre navet majeur de la production americaine. A penser qu'il y a un rapport entre l'usage abusif de la 3D et la navetude du resultat, il n'y qu'un pipolin que je n'hesiterai pas a franchir.
Stephane TOUGARD
Hugolino wrote:
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 !!!
Non, je dis ca parce que c'est un navet. Ce n'est pas un jugement, c'est une constatation d'un etat de faits.
Hugolino wrote:
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 !!!
Non, je dis ca parce que c'est un navet. Ce n'est pas un jugement, c'est
une constatation d'un etat de faits.
