Posté par IsNotGood .
En réponse au journal x86_64.
Évalué à 1.
> (¹) cf. les différents comparatifs sur le net..
Mouaif...
Pour les quadri coeur, c'est grosso-modo la même chose. Le seul truc est qu'Intel est plus rapide (conséquence d'une fréquence plus élevée). A prix équivalent, les performance sont équivalentes.
Tu peux te payer l'Intel le plus cher ? Tu en as absolument besoin ? Quel conséquence pour toi si tu passes à un AMD certes moins performant (15 à 20% en gros) mais aussi beaucoup moins cher ?
Si Intel a un monopole (comprendre si AMD meurt), le prix des cpu sera plus élevé.
A une époque pas lointaine, c'est Intel qui était en difficulté (difficultés financières et techniques). Aujourd'hui c'est l'inverse. On serait très stupide de refuser de donner une sérieuse chance à AMD (d'autant plus qu'AMD a toujours été très ouvert au libre). Si Intel a un monopole (même s'il l'a acquis de façon loyal) ça ne sera pas cool.
Built from git commit: 861debbf8d649ce09d53d5880f819757ac9c7814
> il faudra patienter
Quelques signes d'encouragement ne peuvent pas faire de mal.
Enfin je suis persuadé que ça va évoluer plus vite que le projet nouveau.
Il y a deux (et plus) façons de comparer NVidia et ATI.
Si tu te fous du libre, NVidia est peut-être meilleur.
Si le libre est une priorité importante, ATI est gagnant sans l'ombre d'un doute.
Posté par IsNotGood .
En réponse au journal x86_64.
Évalué à 1.
> pour jouer à flightgear (il a dit à demi-mot qu'il va craquer, avant la fin de l'année sans doute :) )
Quelle année ?
J'ai joué (et beaucoup) à FightGear sur mon ancien PC qui n'avait qu'une Matrox G400 (32 Mo). Certes, j'ai désactivé des options, mais ça restait "super". Donc une Intel GMA3100 doit très certainement le faire les doigts dans le nez. Je préfère une ATI juste pour avoir de la concurrence. Ça serait un drame si AMD coule. Intel aurait alors une position dominante écrasante.
Progrès sympa d'un projet sympa et beaucoup plus.
Mais je crois que le driver libre d'ATI va faire des bonds de géants assez rapidement. C'est un atout énorme d'avoir un constructeur qui joue vraiment la carte du libre.
Posté par IsNotGood .
En réponse au journal x86_64.
Évalué à 1.
C'était un cadeau :-)
Donc j'ai subi. Avec grand plaisir vu la qualité du matos. Il y a même un petit caloduc qui serpente dans la carte mère et le cpu pour la dissipation thermique. C'est mignon et diablement efficace. Il va de soit qu'un overclocking est le bienvenu dans ce contexte...
> Mais pourquoi as-tu vendu ton âme au diable ?
Il faut que je me documente, et dans quelques semaines, je vais probablement passer à ATI.
> l'excellent chipset GMA3100 d'intel
Si on le trouve non intégré à une carte mère, c'est aussi une possibilité.
Posté par IsNotGood .
En réponse au journal x86_64.
Évalué à 1.
> (toutes les URL fonctionnent pour moi)
Idem et sur/en x86_64 (histoire de revenir au sujet du journal).
Beaucoup d'applet et des très compliqués marchent.
Il y en a beaucoup beaucoup plus d'applets qui marchent que d'applets qui ne marchent pas.
Posté par IsNotGood .
En réponse au journal x86_64.
Évalué à 1.
> Et bien j'ai pu constater que java ne fonctionne pas dans les navigateurs
Marche ici (et en mode 64 bits). Firefox est installé en 32 et 64 bits. Par défaut c'est la version 64 bits qui est utilisée.
NB : Fedora utilise IcedTea (un fork temporaire de OpenJDK) qui marche en 64 bits. Eclipse marche aussi très bien (comme la version i386). Ce n'est pas parfait (l'aide ne marche pas, comme i386), mais ça le fait. Disons que Azureus avec IcedTea marche aussi mal sous x86_64 que sous i386 (mais dans une poignée de semaines/mois ça va le faire).
NB: IcedTea pour ppc64 vient d'être terminé. Il sera pour F9 (peut-être en mise à jour de F8 mais j'en doute).
> D'ici 4-5 ans peut-être
A part flash (que je n'ai toujours pas installé d'ailleurs...), il n'y a pas de soucis. C'est la seule régression que j'ai. Regression facilement contournable si on lance firefox en 32 bits. Chose que je n'ai pas encore fait, mais ça doit probablement passer par "setarch i386 ...". /usr/bin/firefox a un "MOZ_ARCH=$(uname -m)". Tout le reste marche à l'identique (aussi bien ou aussi mal, c'est selon).
> quand la plupart du parc informatique sera dessus...
On sait déjà qu'on ne peut pas compter sur toi :-)
J'aime bien les petites brèves. C'est une excellente initiative.
Matthew Szulik aurait mérité une "vraie" dépêche en première page. Mais le personne est discret et probablement que personne n'a fait cette "vraie" dépêche (en tout cas pas moi :-)).
C'est tout de même le PDG depuis 10 ans de la distribution la plus importante, souvent la plus innovante (avec de sérieuses prises de risque pour faire avancer le libre), qui a fait Fedora, qui a le plus contribué au libre (au moins au niveau code), qui a acheté plein de boite pour mettre le code en GPL (près et peut-être plus de 200 millions de $), qui a dit "chiche" pour OLPC, qui a systèmatiquement dit non aux accords à la con type MS/Novell, qui a fait que Red Hat est toujours resté commauté friendly (n'est-ce pas Centos et autres clones), etc...
Il mérite mieux que d'être noyé dans des brèves de seconde page. M'enfin, il ne doit pas s'en plaindre. Le vedettariat n'était pas son truc.
Espérons que son successeur porte aussi fort le libre que lui.
Posté par IsNotGood .
En réponse au journal x86_64.
Évalué à 1.
Petite précision, un OS 32 bits ou 64 bits, indique uniquement la taille d'adressage des applis (2^32 pour du 32 bits, 2^64 pour du 64 bits).
Un OS 32 bits peut utilise un cpu très efficace en calcul sur 64 bits ou 128 bits (entier ou flottant). C'est aujourd'hui le cas.
Il y a peut-être confusion avec les cartes graphiques dites 64 bits ou 128 bits. Ici la taille indique le mot machine. C'est à dire la taille la mieu adaptée au GPU (par exemple ses registres). Ça n'indique pas la taille de l'adressage. Il n'y a pas de cartes graphiques de plus de 4 Go à ma connaissance et encore moins qui ont besoin d'un adressage supérieur à 2^64.
Posté par IsNotGood .
En réponse au journal x86_64.
Évalué à 1.
> Si on osait caser la compatibilité i386, je pense que l'on pourrait aussi avoir un mode 32 bits plus rapide que le 64 bits sur x86_64.
La compatibilité est déjà cassée. Le "truc" est que les amd64 ou Intel Core 2 supportent les deux jeux d'instructions. Évidemment, parfois on retourne les mêmes instructions. Inutile de réinventer la roue.
Posté par IsNotGood .
En réponse au journal x86_64.
Évalué à 1.
> Si quelqu'un dans la salle peut me donner une raison de passer en 64 bits...
Ben oui, il n'y a aucun raisons "évidentes" de passer à 64 bits. Je n'ai jamais dit le contraire.
Le 64 bits se justifie si on a un gros besoin de mémoire (plus de 4 Go (ou 2 ?) par processus ou plus de 64 Go pour le système (i686 a le mode PAE)).
> PS : en dehors des applis réclamant plus de 2 Go de RAM
Plus de 2 Go (ou 4?) de mémoire virtuelle (pas seulement de RAM).
> Tu codes de la même façon, OK, mais du coup je ne vois aucun interet de passer en 64 bits si c'est pour avoir xactement la même chose.
Quel est le coût de passer à 64 bits ?
Un peu plus de mémoire consommé (les pointeurs sont sur 8 octets et non 4).
Donc passons à 64 bits, ainsi ça marche aussi dans le cas (même si actuellement peu probable) où on a un gros besoin de mémoire.
S'il y a beaucoup de uniquement x86_64, on pourra peut-être avoir des cpu moins chez. Actuellement ils doivent supporter x86_64 ET i686. Partout ou le i686 peut-être utilisé, le x86_64 peut-être utilisé.
Posté par IsNotGood .
En réponse au journal x86_64.
Évalué à 2.
> Quel genre d'optimisation logiciel il est possible de faire pour tirer partie du 64bits ?
Il n'y a rien à faire !
C'est le compilateur qui gère ça.
Si tu as besoin d'un int (un mot machine), utilise un int (s'il est 32 bits sous un OS 64 bits, ce n'est pas un problème de performance, c'est même souvent un atout (moins de pression sur le cache)).
Utilise un short si ça te suffit. Notons que ça fait depuis des années que le bus de donnée des pentium et équivalent est sur 64 bits. Le x86_64 n'a rien changé ici (à ma connaissance).
Faire des calculs en long alors que int suffit, n'apportent rien. C'est seulement pour des optimisations très très spécifiques (pour dans certain cas faire un calcul en long au-lieu de deux en int).
Pour la mémoire, c'est comme d'habitude, size_t/ptrdiff_t (32 bits sur OS 32 bits, 64 bits sur OS 64 bits).
Surtout, ne rien faire de spécifique pour 32 bits et 64 bits. Il suffit de programmer selon les règles de l'art et tout baigne.
Tu peux avoir des gains plus "massif" en utilisant MMX/SSE/etc (que je ne connais pas :-)).
> Parce que personnellement, je développe toujours de la même façon sur cette plateforme.
Continu. OS 32 bits ou 64 bits, je programme toujours de la même façon et je ne vois pas de raison de changer.
Pour une lib j'utilise souvent le MixedCase. Pour le reste, j'utilise le pas_mixed_case.
Je préfère le pas_mixed_case. Mais c'est un détail. Un choix de nom de variable (ou famille de variables), qu'il soit MixedCase ou non, est beaucoup plus important.
L'intérêt du MixedCase, et notamment pour des langages type C++, est que les noms sont plus courts :
MaClasseQuiVaBien::EtUneVariableMemble
ma_classe_qui_va_bien::et_une_variable_memble
Très bien, on peut théoriquement "justifier" mature.
Mais la langue c'est aussi la pratique.
On peut très probablement lire "Vista n'est pas mûr, Vista n'est pas arrivé à maturité, n'est pas prêt pour l'entreprise, etc". On va rarement lire "Vista n'est pas mature".
Surtout que dans le contexte qui nous préoccupe, "mature" n'apporte rien.
Demande à ton père ou ton "pépé" ce que veut dire mature. Il va peut-être trouver, mais il va se gratter la tête avant.
> Le débat n'est pas du tout le même avec le pr0n
Mature je l'ai vu quasi exclusivement que dans pr0n. Même pour les sites anglais.
> je ne me permettrais pas de jeter l'opprobre, ni des fruits pourris, sur notre cher "FRLinux".
Évidemment.
J'utilise souvent des terme anglais. Plus particulièrement "suck". Suck serait dans Wikitionnaire ou autre, ça ne serait pas un justificatif pour son emploi en français. Il fait parti de mon argot. Jamais je l'utiliserais pour un article ou pour toute correspondance un brin soutenue.
On peut avoir la faiblesse d'utiliser un terme anglais qu'on a lu 50 000 fois. C'est totalement compréhensible. Mais bien que son usage son courrant par un petit groupe, on n'a pas à en faire un terme français du jours au lendemain afin d'éviter d'avoir à reconnaitre qu'on est (légitimement) laxiste avec le français.
> J'éprouve la même aversion pour les fanboys Apple et Ubuntu qu'on retrouve sur digg par exemple...
Mouaif...
Je ne promet pas la lune. Je "conseille" hypra rarement Red Hat ou Fedora. Il m'arrive même souvent de dire "Fedora n'est pas la distribution qu'il te faut". Les gens doivent tester et faire leur choix. Je ne masque pas la vérité. Par exemple je ne dis pas que Fedora est sans bug et parfaite pour le desktop. Etc.
Comme fanboy on fait mieux que moi.
> C'est juste que les "adorateurs" de RedHat comme toi ont une façon assez pénible
Le nombre de commentaire désagréable que tu as fait sur moi doit être assez impressionnant. Comme pénible tu sais te poser.
> Sur une RedHat (pas Fedora), donc stable, il y a des paquets de corrections de bugs
Fedora a aussi des corrections. Et beaucoup. D'autant plus que Fedora est "blending edge".
Par exemple F8 est sortit il y a peu. Il y a eu plus de 5 Go (!) de mise à jour (source ou binaire, les deux ensembles ça fait plus de 10). Il y a actuellement 2,7 Go de mise à jours (les paquets src.rpm ; 3,1 Go pour les binaires).
Ce que n'offre pas Fedora par rapport à RHEL, c'est la stabilité de l'API. Fedora peut "casser" la compatibilité à tout moment.
> Red Hat n'est pas le "patron" du libre, mais a une influence significative. Il faut le reconnaitre.
Et on peut aussi évidemment s'interroger sur l'influence qu'a le libre sur Red Hat. Autant d'un point de vu technologique que méthodologie, management, etc.
# il faut bien que quelqu'un s'y colle
Posté par IsNotGood . En réponse au journal il faut bien que quelqu'un s'y colle. Évalué à 1.
[^] # Re: AMD vs. Intel
Posté par IsNotGood . En réponse au journal x86_64. Évalué à 1.
Mouaif...
Pour les quadri coeur, c'est grosso-modo la même chose. Le seul truc est qu'Intel est plus rapide (conséquence d'une fréquence plus élevée). A prix équivalent, les performance sont équivalentes.
Tu peux te payer l'Intel le plus cher ? Tu en as absolument besoin ? Quel conséquence pour toi si tu passes à un AMD certes moins performant (15 à 20% en gros) mais aussi beaucoup moins cher ?
Si Intel a un monopole (comprendre si AMD meurt), le prix des cpu sera plus élevé.
A une époque pas lointaine, c'est Intel qui était en difficulté (difficultés financières et techniques). Aujourd'hui c'est l'inverse. On serait très stupide de refuser de donner une sérieuse chance à AMD (d'autant plus qu'AMD a toujours été très ouvert au libre). Si Intel a un monopole (même s'il l'a acquis de façon loyal) ça ne sera pas cool.
[^] # Re: pourquoi t'as acheté une nvidia ?
Posté par IsNotGood . En réponse au journal x86_64. Évalué à 1.
Pas seulement.
[admin@one ~]$ yum info xorg-x11-drv-radeonhd
Available Packages
Name : xorg-x11-drv-radeonhd
Arch : x86_64
Version: 1.0.0
Release: 0.4.20071219git.fc8
Size : 174 k
Repo : updates-testing
Summary: Xorg X11 radeonhd driver for AMD GPG r5xx/r6xx Chipsets
Description:
X.org X11 radeonhd driver for AMD GPG r5xx/r6xx Chipsets.
This package is a snapshot of a work in progress. You may experience
regressions, bugs, errors, broken displays, and other undesirable phenomena.
radeonhd mailing list: http://lists.opensuse.org/radeonhd/
Built from git commit: 861debbf8d649ce09d53d5880f819757ac9c7814
> il faudra patienter
Quelques signes d'encouragement ne peuvent pas faire de mal.
Enfin je suis persuadé que ça va évoluer plus vite que le projet nouveau.
Il y a deux (et plus) façons de comparer NVidia et ATI.
Si tu te fous du libre, NVidia est peut-être meilleur.
Si le libre est une priorité importante, ATI est gagnant sans l'ombre d'un doute.
[^] # Re: pourquoi t'as acheté une nvidia ?
Posté par IsNotGood . En réponse au journal x86_64. Évalué à 1.
Quelle année ?
J'ai joué (et beaucoup) à FightGear sur mon ancien PC qui n'avait qu'une Matrox G400 (32 Mo). Certes, j'ai désactivé des options, mais ça restait "super". Donc une Intel GMA3100 doit très certainement le faire les doigts dans le nez. Je préfère une ATI juste pour avoir de la concurrence. Ça serait un drame si AMD coule. Intel aurait alors une position dominante écrasante.
> http://nouveau.freedesktop.org/wiki/Nouveau_Companion_32
Progrès sympa d'un projet sympa et beaucoup plus.
Mais je crois que le driver libre d'ATI va faire des bonds de géants assez rapidement. C'est un atout énorme d'avoir un constructeur qui joue vraiment la carte du libre.
[^] # Re: pourquoi t'as acheté une nvidia ?
Posté par IsNotGood . En réponse au journal x86_64. Évalué à 1.
Donc j'ai subi. Avec grand plaisir vu la qualité du matos. Il y a même un petit caloduc qui serpente dans la carte mère et le cpu pour la dissipation thermique. C'est mignon et diablement efficace. Il va de soit qu'un overclocking est le bienvenu dans ce contexte...
> Mais pourquoi as-tu vendu ton âme au diable ?
Il faut que je me documente, et dans quelques semaines, je vais probablement passer à ATI.
> l'excellent chipset GMA3100 d'intel
Si on le trouve non intégré à une carte mère, c'est aussi une possibilité.
[^] # Re: soixante-quatre bites powaaaa !
Posté par IsNotGood . En réponse au journal x86_64. Évalué à 1.
Idem et sur/en x86_64 (histoire de revenir au sujet du journal).
Beaucoup d'applet et des très compliqués marchent.
Il y en a beaucoup beaucoup plus d'applets qui marchent que d'applets qui ne marchent pas.
[^] # Re: soixante-quatre bites powaaaa !
Posté par IsNotGood . En réponse au journal x86_64. Évalué à 1.
Je viens de dire une connerie, l'aide ne marche pas que sous i386, mais marche avec x86_64. Comme quoi....
[^] # Re: soixante-quatre bites powaaaa !
Posté par IsNotGood . En réponse au journal x86_64. Évalué à 1.
Marche ici (et en mode 64 bits). Firefox est installé en 32 et 64 bits. Par défaut c'est la version 64 bits qui est utilisée.
NB : Fedora utilise IcedTea (un fork temporaire de OpenJDK) qui marche en 64 bits. Eclipse marche aussi très bien (comme la version i386). Ce n'est pas parfait (l'aide ne marche pas, comme i386), mais ça le fait. Disons que Azureus avec IcedTea marche aussi mal sous x86_64 que sous i386 (mais dans une poignée de semaines/mois ça va le faire).
NB: IcedTea pour ppc64 vient d'être terminé. Il sera pour F9 (peut-être en mise à jour de F8 mais j'en doute).
> D'ici 4-5 ans peut-être
A part flash (que je n'ai toujours pas installé d'ailleurs...), il n'y a pas de soucis. C'est la seule régression que j'ai. Regression facilement contournable si on lance firefox en 32 bits. Chose que je n'ai pas encore fait, mais ça doit probablement passer par "setarch i386 ...". /usr/bin/firefox a un "MOZ_ARCH=$(uname -m)". Tout le reste marche à l'identique (aussi bien ou aussi mal, c'est selon).
> quand la plupart du parc informatique sera dessus...
On sait déjà qu'on ne peut pas compter sur toi :-)
# Petites brèves
Posté par IsNotGood . En réponse à la dépêche Matthew Szulik quitte Red Hat, tests de performance JavaScript et Valgrind 3.3.0. Évalué à 3.
Matthew Szulik aurait mérité une "vraie" dépêche en première page. Mais le personne est discret et probablement que personne n'a fait cette "vraie" dépêche (en tout cas pas moi :-)).
C'est tout de même le PDG depuis 10 ans de la distribution la plus importante, souvent la plus innovante (avec de sérieuses prises de risque pour faire avancer le libre), qui a fait Fedora, qui a le plus contribué au libre (au moins au niveau code), qui a acheté plein de boite pour mettre le code en GPL (près et peut-être plus de 200 millions de $), qui a dit "chiche" pour OLPC, qui a systèmatiquement dit non aux accords à la con type MS/Novell, qui a fait que Red Hat est toujours resté commauté friendly (n'est-ce pas Centos et autres clones), etc...
Il mérite mieux que d'être noyé dans des brèves de seconde page. M'enfin, il ne doit pas s'en plaindre. Le vedettariat n'était pas son truc.
Espérons que son successeur porte aussi fort le libre que lui.
[^] # Re: soixante-quatre bites powaaaa !
Posté par IsNotGood . En réponse au journal x86_64. Évalué à 1.
s/retourne/retrouve/
[^] # Re: soixante-quatre bites powaaaa !
Posté par IsNotGood . En réponse au journal x86_64. Évalué à 1.
Un OS 32 bits peut utilise un cpu très efficace en calcul sur 64 bits ou 128 bits (entier ou flottant). C'est aujourd'hui le cas.
Il y a peut-être confusion avec les cartes graphiques dites 64 bits ou 128 bits. Ici la taille indique le mot machine. C'est à dire la taille la mieu adaptée au GPU (par exemple ses registres). Ça n'indique pas la taille de l'adressage. Il n'y a pas de cartes graphiques de plus de 4 Go à ma connaissance et encore moins qui ont besoin d'un adressage supérieur à 2^64.
[^] # Re: soixante-quatre bites powaaaa !
Posté par IsNotGood . En réponse au journal x86_64. Évalué à 1.
La compatibilité est déjà cassée. Le "truc" est que les amd64 ou Intel Core 2 supportent les deux jeux d'instructions. Évidemment, parfois on retourne les mêmes instructions. Inutile de réinventer la roue.
[^] # Re: soixante-quatre bites powaaaa !
Posté par IsNotGood . En réponse au journal x86_64. Évalué à 1.
Ben oui, il n'y a aucun raisons "évidentes" de passer à 64 bits. Je n'ai jamais dit le contraire.
Le 64 bits se justifie si on a un gros besoin de mémoire (plus de 4 Go (ou 2 ?) par processus ou plus de 64 Go pour le système (i686 a le mode PAE)).
> PS : en dehors des applis réclamant plus de 2 Go de RAM
Plus de 2 Go (ou 4?) de mémoire virtuelle (pas seulement de RAM).
> Tu codes de la même façon, OK, mais du coup je ne vois aucun interet de passer en 64 bits si c'est pour avoir xactement la même chose.
Quel est le coût de passer à 64 bits ?
Un peu plus de mémoire consommé (les pointeurs sont sur 8 octets et non 4).
Donc passons à 64 bits, ainsi ça marche aussi dans le cas (même si actuellement peu probable) où on a un gros besoin de mémoire.
S'il y a beaucoup de uniquement x86_64, on pourra peut-être avoir des cpu moins chez. Actuellement ils doivent supporter x86_64 ET i686. Partout ou le i686 peut-être utilisé, le x86_64 peut-être utilisé.
[^] # Re: pire?
Posté par IsNotGood . En réponse au journal x86_64. Évalué à -2.
Ubuntu ?
[^] # Re: soixante-quatre bites powaaaa !
Posté par IsNotGood . En réponse au journal x86_64. Évalué à 2.
Il n'y a rien à faire !
C'est le compilateur qui gère ça.
Si tu as besoin d'un int (un mot machine), utilise un int (s'il est 32 bits sous un OS 64 bits, ce n'est pas un problème de performance, c'est même souvent un atout (moins de pression sur le cache)).
Utilise un short si ça te suffit. Notons que ça fait depuis des années que le bus de donnée des pentium et équivalent est sur 64 bits. Le x86_64 n'a rien changé ici (à ma connaissance).
Faire des calculs en long alors que int suffit, n'apportent rien. C'est seulement pour des optimisations très très spécifiques (pour dans certain cas faire un calcul en long au-lieu de deux en int).
Pour la mémoire, c'est comme d'habitude, size_t/ptrdiff_t (32 bits sur OS 32 bits, 64 bits sur OS 64 bits).
Surtout, ne rien faire de spécifique pour 32 bits et 64 bits. Il suffit de programmer selon les règles de l'art et tout baigne.
Tu peux avoir des gains plus "massif" en utilisant MMX/SSE/etc (que je ne connais pas :-)).
> Parce que personnellement, je développe toujours de la même façon sur cette plateforme.
Continu. OS 32 bits ou 64 bits, je programme toujours de la même façon et je ne vois pas de raison de changer.
[^] # Re: J'ai testé
Posté par IsNotGood . En réponse au journal windows (auto)mobile !. Évalué à 2.
Ou appuyer sur l'embrayage, le frein et l'accélérateur en même temps (sauf si un clavier PC101 est branché sur Blue&Me).
# Re:
Posté par IsNotGood . En réponse au journal mixedCase or not ?. Évalué à 1.
Pour une lib j'utilise souvent le MixedCase. Pour le reste, j'utilise le pas_mixed_case.
Je préfère le pas_mixed_case. Mais c'est un détail. Un choix de nom de variable (ou famille de variables), qu'il soit MixedCase ou non, est beaucoup plus important.
L'intérêt du MixedCase, et notamment pour des langages type C++, est que les noms sont plus courts :
MaClasseQuiVaBien::EtUneVariableMemble
ma_classe_qui_va_bien::et_une_variable_memble
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal Test Zenwalk 4.8. Évalué à 1.
Mais la langue c'est aussi la pratique.
On peut très probablement lire "Vista n'est pas mûr, Vista n'est pas arrivé à maturité, n'est pas prêt pour l'entreprise, etc". On va rarement lire "Vista n'est pas mature".
Surtout que dans le contexte qui nous préoccupe, "mature" n'apporte rien.
Demande à ton père ou ton "pépé" ce que veut dire mature. Il va peut-être trouver, mais il va se gratter la tête avant.
> Le débat n'est pas du tout le même avec le pr0n
Mature je l'ai vu quasi exclusivement que dans pr0n. Même pour les sites anglais.
> je ne me permettrais pas de jeter l'opprobre, ni des fruits pourris, sur notre cher "FRLinux".
Évidemment.
J'utilise souvent des terme anglais. Plus particulièrement "suck". Suck serait dans Wikitionnaire ou autre, ça ne serait pas un justificatif pour son emploi en français. Il fait parti de mon argot. Jamais je l'utiliserais pour un article ou pour toute correspondance un brin soutenue.
On peut avoir la faiblesse d'utiliser un terme anglais qu'on a lu 50 000 fois. C'est totalement compréhensible. Mais bien que son usage son courrant par un petit groupe, on n'a pas à en faire un terme français du jours au lendemain afin d'éviter d'avoir à reconnaitre qu'on est (légitimement) laxiste avec le français.
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal Test Zenwalk 4.8. Évalué à 0.
On dit aujoud'hui la même chose qu'hier, mais avec des mots différents. Surtout s'ils sentent l'anglais.
Vas chercher dans la litérature, même du vingtième siècle, l'emploi de mature...
Bon courage.
J'ai seulement souvenir de "mâture" (avec un 'â') pour les mâts d'un bateau.
J'ai vu "mature" mais seulement pour le vin.
# Re:
Posté par IsNotGood . En réponse au journal Test Zenwalk 4.8. Évalué à -1.
"Matures" ?!?
C'est quoi ce vocabulaire de p0rn ?
Murs, aboutis, arrivés à maturité, etc...
Causons français quand on cause ... français.
[^] # Re: équivalent de Centos
Posté par IsNotGood . En réponse au journal Matthew Szulik démissionne. Évalué à 1.
Mouaif...
Je ne promet pas la lune. Je "conseille" hypra rarement Red Hat ou Fedora. Il m'arrive même souvent de dire "Fedora n'est pas la distribution qu'il te faut". Les gens doivent tester et faire leur choix. Je ne masque pas la vérité. Par exemple je ne dis pas que Fedora est sans bug et parfaite pour le desktop. Etc.
Comme fanboy on fait mieux que moi.
> C'est juste que les "adorateurs" de RedHat comme toi ont une façon assez pénible
Le nombre de commentaire désagréable que tu as fait sur moi doit être assez impressionnant. Comme pénible tu sais te poser.
[^] # Re: Reprenons...
Posté par IsNotGood . En réponse au journal Ubuntu a finit de manger son pain blanc ?. Évalué à 1.
Ubuntu sort tous les 6 mois (comme Fedora, Mandriva, OpenSuse, etc).
[^] # Re: Fedora, c'est mieux que ubuntu
Posté par IsNotGood . En réponse au journal Ubuntu a finit de manger son pain blanc ?. Évalué à 1.
Fedora a aussi des corrections. Et beaucoup. D'autant plus que Fedora est "blending edge".
Par exemple F8 est sortit il y a peu. Il y a eu plus de 5 Go (!) de mise à jour (source ou binaire, les deux ensembles ça fait plus de 10). Il y a actuellement 2,7 Go de mise à jours (les paquets src.rpm ; 3,1 Go pour les binaires).
Ce que n'offre pas Fedora par rapport à RHEL, c'est la stabilité de l'API. Fedora peut "casser" la compatibilité à tout moment.
# Un cadeau qui fait plaisir à tout le monde
Posté par IsNotGood . En réponse au journal Que vais-je offrir pour Noël à mon entourage?. Évalué à 2.
[^] # Re: équivalent de Centos
Posté par IsNotGood . En réponse au journal Matthew Szulik démissionne. Évalué à 1.
Et on peut aussi évidemment s'interroger sur l'influence qu'a le libre sur Red Hat. Autant d'un point de vu technologique que méthodologie, management, etc.