> Rappellons par exemple qu'on a jamais reussi a booter un kernel VaX avec gcc3 ...
Je vais faire une remarque naïve pour les z'élites d'OpenBSD, mais il me semble plus facile de corriger un bug de gcc que d'écrire un compilateur...
Je me trompe ?
Si à chaque bug/limitation de gcc il faut un compilateur, on n'est pas sorti de la merde...
Pardon, je n'ai jamais utilisé mingw. J'ai utilisé gcc sous HPUX, DEC et Linux mais jamais sous Windows.
J'ai du code qui compile sous Windows et Linux, et sous Linux (gcc) la compilation est beaucoup plus lente. Mais je m'en fous.
> je préfére un compilo aussi strict, respectueux des normes et ubiquitaire que l'est GCC, à un compilo plus rapide bogué et avec un support des normes incomplet.
VC++ c'est "pire". Il y a des cas (certe complexes) où VC++ perd le type d'un pointeur.
Par exemple :
class CToto : public virtual CTiti, public virtual CTutu {}
CToto * ptoto = new CToto ;
CTiti * ptiti = ptoto ; // plantage avec VC++ alors que ça roule avec gcc. Un dynamic_cast n'arrange rien (il est d'ailleur sans intérêt ici normalement).
VC++ m'a donné des cauchemards. J'avais finit de coder (3 mois de développement), j'étais content de ma hiérarchie d'object "et tout". Je compile: OK. J'exécute : explosion dans tous les coins. Je "porte" sous Linux/gcc, ça marche comme un charme. Ça m'a pris presque deux semaines pour voir que c'était un bug de VC++. Ça m'a pris une semaines pour réorganiser mon code afin qu'il tourne avec VC++. Donc : 3 semaines de perdu. Et vraiment perdu. Si le compilateur est lent, je peux boire un café, discuter, bosser sur autre chose, etc...
> - Admettons qu'une distrib linux commerciale soit à la place de Windows, pourrais-t-on l'attaquer de même parce qu'elle propose KDE par défaut, et pas XFCE ou GNOME par exemple ?
Théorique oui.
Mais le libre c'est libre...
Donc tout le monde peu fournir du GNU/Linux avec ou sans KDE, etc...
Par contre pour Windows, il n'y a que MS qui fournit Windows et qui compose ce qui va avec Windows. Ça fait une différence énorme. Sûr que des constructeurs à l'époque de Netscape/IE aurait bien aimé virer IE. Mais si MS ne le permet pas, ben ce n'est pas possible.
Le libre ne permet pas de faire de l'abus de position dominante. Par exemple disons que Red Hat a une position dominante dans le serveur. Comment Red Hat peut abuser de sa position dominante s'il peut y avoir Centos, ou Oracle qui fork RHEL, etc... ?
Le libre ne permet pas de faire de l'abus de position dominante.
Il n'est pas reproché à MS d'avoir une position dominante, mais d'abuser de sa position dominante.
> - Ne risque-t-on pas d'obliger Microsoft à vendre un système complètement vide ( pas de lecteur multimédia, pas de navigateur internet, pas de logiciel de gravure, ... ) pour ne pas fausser la concurrence ?
Non. Il est demandé (et imposé) à MS de fournir une version sans WMP. Ça n'interdit pas à MS de fournir une version de Windows avec WMP.
> Pour Ubuntu par exemple tout le monde trouve normal d'avoir ces éléments installé par défaut, mais pourquoi pour Windows ça ne serait pas normal ?
Je retourne la question.
Démontre qu'Ubuntu fait un abus de position dominante.
> pourquoi iront on condamné Microsoft sur le fait qu' il distribue par défaut un lecteur multimédia ??
Il y a déjà une petite erreur. MS est condamné pour fournir Windows uniquement avec un lecteur multimédia et celui de MS
WMP serait pas défaut, ça impliquerait qu'on pourrait l'enlever ou que les fabriquant de PC pourrait l'enlever. Ce n'est pas le cas.
> l' abus de position dominante se situe plutôt dans les arcanes des accords entre Microsoft et les constructeurs/assembleurs.
La commission a dit que non. Ou du moins elle n'a pas de preuve. Chaque constructeur est libre de fournir uniquement Windows, ou pas Windows, ou rien , ou une alternative, etc...
MS a fait des abus avec les constructeurs, notamment aux USA et MS a perdu. Jusqu'à aujourd'hui, il n'y a pas de preuve de telle pratique en Europe. Pratique qui consiste a faire un prix préférenciel si le constructeur s'engage à ne vendre que du Windows.
> Ce n' est pas à M.S., du moins pas seul, de racquer.
Pauvre gentil MS. MS en a rien à foutre des 500 Millions d'¤ d'amende. Ce qui emmerde MS, c'est qu'on va lui imposer de jouer la "concurrence libre et non faussée".
> Là ça sent fort la taxe "t' es riche donc j' en veux" et pas du tout la justice.
Et pourquoi le "t'es riche" ?
Le "t'es riche" est en partit car MS abuse de sa position dominante. La commission a fait un formidable travail et l'a très bien démontré.
Je me suis mis à Visual C++ depuis quelques mois (faut bien manger :-)), et quand je vois des critiques sur gcc, je ne comprend pas. Gcc est de la balle. Qu'il compile 10 fois plus lentement que Visual C++, je m'en fous.
> Mais on va prendre des exemples concrets.
> geom_journal sous FreeBSD:
Certe, mais c'est changé tout les combiens ?
Tous les 3 mois ou tous les ans ?
Es-ce intéressant d'utliser et de développer un compilo "bas de gamme" qui va vite uniquement pour ça ?
De plus ses programmes se compilent vite. Ils sont très petits et même si tu en as une dixaine, c'est l'affaire de 10 minutes (c'est le temps pour la bécane, pour toi ça risque d'être plus long (récupérer les sources, ./configure, installation, etc...)).
C'est quasi sans intérêt. De plus il faut voir la contre partie. Un compilo qui fait moins de vérification que gcc, qui n'est pas cross-plateform, qui n'est pas "renforcé" (controle de débordement), etc, etc...
C'est très bien de faire un "make word" pour voir si tout est cohérent. On peut trouver des bugs etc...
Mais les développeurs qui font ça sont rares. En tout cas, il a autre chose à foutre que ça.
Je dis ça sans le moindre mépris, mais ce n'est pas un boulot de développeur, c'est un boulot de testeur (et j'ai beaucoup fait de tests et j'ai beaucoup de respect pour les testeurs, il faut du talent pour être un bon testeur). Dans le cas de Fedora, il y a des bécanes qui sont affectées à ça avec des procédures automatiques, un scheduler pour plannifier les tests, etc...
Au "petit matin" un mail est envoyé sur la mailing devel et les développeurs regardent ce qui les concernes.
En passant, Fedora utilise moch ce qui permet avec une bécane de compiler un programme pour FC4, FC5, FC6, F7, pour i386 pour amd64, etc.
Tu ne lance pas à moch à chaque fois que tu change une ligne de ton code, mais lorsque tu veux diffuser et t'assurer de la qualité du code (es-ce qu'il compile partout ? sur toute les architectures ? il y a-t-il des fichiers en conflit avec d'autres paquets, etc).
> c'est pas la meme chose que modifier le code du routing, UFS ou autres changements intrusifs.
En passant, Linus Torvalds (himself) utiliser une Fedora. Les changements intrusifs il connait et il ne recompile pas tout tout les matins (Fedora n'est pas Gentoo).
Linus Torvalds est un "plouc" car il ne fait pas de "make word" ?
> Quand tu changes une structure "sensible" ou que tu ajoutes du code intrusif,
Ben tu le fais rarement. Sinon il y a un bug de conception. De plus il y a la libc entre le noyau et les applis et la libc supporte les versions (on peut donc avoir plusieurs versions d'une API).
Un OS qui demande de tout recompiler toutes les semaines est un OS qui sucks grave de chez grave.
> il faut _toujours_ tout recompiler.
Non.
> que modifier le code du routing, UFS
Dans ce cas tu recompiles le noyau et c'est l'affaire de 10 ou 20 minutes.
> C'est fallacieux de comparer un BSD a fedora.
Ouais, BSD c'est naze, il faut tout recompiler toutes les semaines.
Quand tu es développeur (et pas seulement un gentoo lover), tu ne passes pas ton temps à compiler des OS. Tu compiles ton code et il y a make pour compiler que ce qui est nécessaire. Make peut aussi compiler en parallèle (option -j) pour profiter d'un dual/quad core/cpu. Dans ce contexte, la vitesse de gcc est largement bonne.
Je suivais la mailing devel Fedora. Les rebuilds de tout l'OS (dit mass rebuild chez Fedora) sont très rares (un par an à cause d'un changement de version majeur de gcc). Pour F8 ça a été exceptionnel, il y a eu 2 mass rebuild (le premier a utilisé un gcc buggé). Les mass rebuild sont fait en une voire deux journées et pour 4 architectures. Il me faut préciser que Fedora utilise un cluster pour les compilations. Les développeurs Fedora ne font pas des "make world" histoire pour pourrir la planète, il récupère les binaires fait par Fedora.
> C'est aussi pour ca qu'il est important pour un projet consequent de compiler rapidement
Tu veux dire que les *BSD sont des OS gras ?
> au moins le code a passe le test du "make word".
> Il serait 5 à 10 fois plus rapide que gcc et produirait des binaires suffisament optimisé
Visual C++ est aussi très rapide pour compiler (probablement 4 à 6 fois plus rapide que gcc).
Pour le reste il n'est pas du niveau de gcc. Je boose actuellement avec Visual C++ (consigne du boss), ben c'est presque une daube à côté de gcc.
Que Visual C++ soit plus rapide que gcc, ne lui donne aucun charme de plus. Si à l'avenir je peux éviter Visual C++, je l'éviterai.
En gros on peut dire que ça ne sert à rien. Il faut aussi bootstrapper le compilateur. Ça ne sert à rien sauf :
- à faire plaisir à des développeurs. Si c'est leur truc, il n'y a rien à redire.
- permettre aux fanatiques BSD de dire "HAHA ! on s'en torche de GNU et de sa (L)GPL tyranique, on a un compilateur ultra-plus-mieux-bien que ce tout pourri et archi-lent de gcc.
En passant, gcc se bootstrappe. Pour compiler gcc, on commence par compiler un mini-gcc (qui ne fait que compilateur C, n'est pas cross-plateforme, n'est pas optimisé, etc) et ce dernier est utilisé pour compiler gcc. Ça doit être un poil plus compliqué car je crois qu'il y a stage1 stage2 et final.
Il n'y a qu'un fichier .doc ...
Je l'ouvre avec OOo. Mais j'affichage est naze. De plus ce document est naze. Même Word 2003 en chie pour l'ouvrir et au final proposer des liens vers le site ISO. C'est sans intérêt.
> De toutes façons il me semble qu'ODF a suivi la procédure normale.
Oui, mais il y a toujours un vote avec des commentaires. ODF n'a pas eu de BRM car il a été ratifié au premier vote. Mais il aurait pû y avoir BRM (même si ce n'était pas une procédure fast-track).
> mais il n'y a eu je crois que des OUI. Pas de BRM donc dans ce cas là.
Je ne demande pas les commentaires du BRM :-)
OOXML n'en a pas encore non plus.
> D'abord un lien vers les commentaires... c'est des .doc:
Un .doc et des html (pas terrible).
Le .doc ne passe pas sous OOo (v2.0.4).
En survolant les commentaires, j'ai l'impression que les carottes sont cuites...
pBpG qui n'arrête pas de dire que OOXML est complètement documenté, devrait lire les commentaires de l'ISO. OOXML n'est ps complètement documenté et en plus il est mal foutu.
Et en lisant les commentaires, on voit aussi que OOXML fait référence à des formats désignés comme propriétaires (VML, etc...).
> Enfin il semble que même les vote OUI puissent devenir des NON.
Je pense que quelqu'uns vont ralier la position de la France (AFNOR). C'est-à-dire que OOXML va avoir un NON avec la proposition de AFNOR d'attachée (proposition reformulée probablement).
> comme celui de la Grèce
Les commentaires de l'ANSI ne sont pas tendres non plus. Pourtant ils ont voté OUI...
Quelqu'un a-t-il le commentaire sur ODF (s'ils existent). Juste pour faire une comparaison.
Non standard et propriétaire c'est très différent. XUL de Firefox est non standard (il n'existe pas de standard Xul) mais Xul n'est pas propriétaire.
Pour ce qui est de la doc, JBoss est disponible en source donc il n'y a pas de problème de format fermé. Donc ce n'est ni propriétaire, ni fermé, c'est peut-être non-standard mais j'en doute.
> moi j'ai compris interface ne respectant pas le standard j2ee
JBoss est certifié J2EE compatible depuis plusieurs années.
Enfin c'est Red Hat qui dirige principalement JBoss (Red Hat a acheté JBoss il y a un peu plus d'un ans plus plusieurs centaine de millions de $ si j'ai bonne mémoire) et Red Hat n'a pas pour habitude de ne pas respecter les standards. Bien au contraire.
Je me demande si Earered ne confond pas JBoss de l'époque pré-Red Hat et le JBoss actuel. L'ancien JBoss était critiqué pour ne pas être totalement libre (j'ai oublié les détails de l'histoire).
Pour info, avant le rachat de JBoss, Red Hat bossait sur Jonas qui était au-dessus de tout soupçon. Red Hat ne fournissait pas JBoss mais Jonas. Du moins il me semble car je n'utilise pas Java :-)
> Ah ben bravo.
>
> Il y a tous les jours des gens tirés au sort pour être jurés. J'espère que tu auras la chance de passer au travers ...
Je ne demande pas de condanné sans étude/procès. Mais pour moi, actuellement, MS a magouillé. Pour ce qui est de la langue, demande à pBpG. Il te servira du "tant qu'on n'a pas la preuve, MS est innocent" à l'envis. Devant la lois MS est innocent actuellement, mais je ne suis pas dans un jurés actuellement.
> Là, pour le coup, je m'étais déjà fait une opinion il y a trois ans
Ah ben bravo.
En passant, je n'ai jamais été un adèpte du "présumé innocent" qui est une formulation ridicule. On ne lance pas une action en justice s'il y a présomption d'innocence, mais s'il y a présomption de culpabilité.
> Mais utiliser les interfaces propriétaires de JBoss est probablement pire en terme de concurence et d'indépendance (il n'y a que RedHat en face) que d'utiliser les interfaces standard d'un serveur d'application).
IL N'Y A PAS D'INTERFACE PROPRIÉTAIRE DANS JBOSS !!!
Ou alors cite les.
> Websphere a aussi des interfaces propriétaires.
Tu dis que Websphere en a (je n'en sais rien), mais Jboss n'en a pas.
Pour info, les sources de JBoss : http://labs.jboss.com/projects/download
C'est principalement (exclusivement ?) du LGPL. Si tu veux accuser JBoss, avance des arguments. Je ne dis pas que tu as forcément tord, mais on n'accuse pas sans preuve ou au moins sans quelques éléments.
Pour info toujours, Red Hat fait une offre COMMERCIALE (et non propriétaire) de JBoss. Red Hat vend un service qui est accompagné de conditions. Tu peux ne pas être d'accord avec les conditions du service, mais Jboss reste définitivement libre. C'est la même chose pour RHEL (dont la liberté est entre autre prouvée avec Centos).
> websphere en utilisant seulement les interfaces standardisées, plutot que jboss et ses interfaces propriétaires
JBoss est libre et est sous licence LGPL. Donc il est impossible qu'il ait des interfaces propriétaires (sauf magouille à la MS/Novell, ce qui n'est pas le cas ici).
Je ne connais pas les détails de cette histoire, mais c'est affligeant. Affligeant qu'on tente de manipuler bassement une instance politique.Et comme d'habitude, les intérêts de MS sont en jeux. Bref, comme d'hab MS a magouiller. Je sens que pBpG va me demander des preuves... Même si je n'ai pas de preuve, il n'y a pas de doute pour moi.
Je serais très très très favorable qu'une enquête soit menée contre Gartner. Je doute que ceci fasse plaisir à MS... Pourtant, ça ne serait que pour avoir la vérité...
Positivons. Disons qu'il y a un vent de panique chez MS.
[^] # Re: Re ; Fin de gcc dans les *BSD ?
Posté par IsNotGood . En réponse au journal Fin de gcc dans les *BSD ?. Évalué à 2.
Je vais faire une remarque naïve pour les z'élites d'OpenBSD, mais il me semble plus facile de corriger un bug de gcc que d'écrire un compilateur...
Je me trompe ?
Si à chaque bug/limitation de gcc il faut un compilateur, on n'est pas sorti de la merde...
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal Fin de gcc dans les *BSD ?. Évalué à 2.
J'ai du code qui compile sous Windows et Linux, et sous Linux (gcc) la compilation est beaucoup plus lente. Mais je m'en fous.
> je préfére un compilo aussi strict, respectueux des normes et ubiquitaire que l'est GCC, à un compilo plus rapide bogué et avec un support des normes incomplet.
VC++ c'est "pire". Il y a des cas (certe complexes) où VC++ perd le type d'un pointeur.
Par exemple :
class CToto : public virtual CTiti, public virtual CTutu {}
CToto * ptoto = new CToto ;
CTiti * ptiti = ptoto ; // plantage avec VC++ alors que ça roule avec gcc. Un dynamic_cast n'arrange rien (il est d'ailleur sans intérêt ici normalement).
VC++ m'a donné des cauchemards. J'avais finit de coder (3 mois de développement), j'étais content de ma hiérarchie d'object "et tout". Je compile: OK. J'exécute : explosion dans tous les coins. Je "porte" sous Linux/gcc, ça marche comme un charme. Ça m'a pris presque deux semaines pour voir que c'était un bug de VC++. Ça m'a pris une semaines pour réorganiser mon code afin qu'il tourne avec VC++. Donc : 3 semaines de perdu. Et vraiment perdu. Si le compilateur est lent, je peux boire un café, discuter, bosser sur autre chose, etc...
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal Fin de gcc dans les *BSD ?. Évalué à 1.
Où tu as lu ça ?
Je ne crois pas les développeurs assez cons pour dire "jamais".
[^] # Re: ceci n' est pas un troll
Posté par IsNotGood . En réponse à la dépêche La Cour de justice européenne confirme la sanction de Microsoft. Évalué à 8.
Théorique oui.
Mais le libre c'est libre...
Donc tout le monde peu fournir du GNU/Linux avec ou sans KDE, etc...
Par contre pour Windows, il n'y a que MS qui fournit Windows et qui compose ce qui va avec Windows. Ça fait une différence énorme. Sûr que des constructeurs à l'époque de Netscape/IE aurait bien aimé virer IE. Mais si MS ne le permet pas, ben ce n'est pas possible.
Le libre ne permet pas de faire de l'abus de position dominante. Par exemple disons que Red Hat a une position dominante dans le serveur. Comment Red Hat peut abuser de sa position dominante s'il peut y avoir Centos, ou Oracle qui fork RHEL, etc... ?
Le libre ne permet pas de faire de l'abus de position dominante.
Il n'est pas reproché à MS d'avoir une position dominante, mais d'abuser de sa position dominante.
> - Ne risque-t-on pas d'obliger Microsoft à vendre un système complètement vide ( pas de lecteur multimédia, pas de navigateur internet, pas de logiciel de gravure, ... ) pour ne pas fausser la concurrence ?
Non. Il est demandé (et imposé) à MS de fournir une version sans WMP. Ça n'interdit pas à MS de fournir une version de Windows avec WMP.
> Pour Ubuntu par exemple tout le monde trouve normal d'avoir ces éléments installé par défaut, mais pourquoi pour Windows ça ne serait pas normal ?
Je retourne la question.
Démontre qu'Ubuntu fait un abus de position dominante.
[^] # Re: ceci n' est pas un troll
Posté par IsNotGood . En réponse à la dépêche La Cour de justice européenne confirme la sanction de Microsoft. Évalué à 6.
Il y a déjà une petite erreur. MS est condamné pour fournir Windows uniquement avec un lecteur multimédia et celui de MS
WMP serait pas défaut, ça impliquerait qu'on pourrait l'enlever ou que les fabriquant de PC pourrait l'enlever. Ce n'est pas le cas.
> l' abus de position dominante se situe plutôt dans les arcanes des accords entre Microsoft et les constructeurs/assembleurs.
La commission a dit que non. Ou du moins elle n'a pas de preuve. Chaque constructeur est libre de fournir uniquement Windows, ou pas Windows, ou rien , ou une alternative, etc...
MS a fait des abus avec les constructeurs, notamment aux USA et MS a perdu. Jusqu'à aujourd'hui, il n'y a pas de preuve de telle pratique en Europe. Pratique qui consiste a faire un prix préférenciel si le constructeur s'engage à ne vendre que du Windows.
> Ce n' est pas à M.S., du moins pas seul, de racquer.
Pauvre gentil MS. MS en a rien à foutre des 500 Millions d'¤ d'amende. Ce qui emmerde MS, c'est qu'on va lui imposer de jouer la "concurrence libre et non faussée".
> Là ça sent fort la taxe "t' es riche donc j' en veux" et pas du tout la justice.
Et pourquoi le "t'es riche" ?
Le "t'es riche" est en partit car MS abuse de sa position dominante. La commission a fait un formidable travail et l'a très bien démontré.
# YOUPI !!!
Posté par IsNotGood . En réponse au journal Microsoft - UE : décision lundi. Évalué à 3.
MS a perdu.
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal Fin de gcc dans les *BSD ?. Évalué à 5.
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal Fin de gcc dans les *BSD ?. Évalué à -1.
> geom_journal sous FreeBSD:
Certe, mais c'est changé tout les combiens ?
Tous les 3 mois ou tous les ans ?
Es-ce intéressant d'utliser et de développer un compilo "bas de gamme" qui va vite uniquement pour ça ?
De plus ses programmes se compilent vite. Ils sont très petits et même si tu en as une dixaine, c'est l'affaire de 10 minutes (c'est le temps pour la bécane, pour toi ça risque d'être plus long (récupérer les sources, ./configure, installation, etc...)).
C'est quasi sans intérêt. De plus il faut voir la contre partie. Un compilo qui fait moins de vérification que gcc, qui n'est pas cross-plateform, qui n'est pas "renforcé" (controle de débordement), etc, etc...
C'est très bien de faire un "make word" pour voir si tout est cohérent. On peut trouver des bugs etc...
Mais les développeurs qui font ça sont rares. En tout cas, il a autre chose à foutre que ça.
Je dis ça sans le moindre mépris, mais ce n'est pas un boulot de développeur, c'est un boulot de testeur (et j'ai beaucoup fait de tests et j'ai beaucoup de respect pour les testeurs, il faut du talent pour être un bon testeur). Dans le cas de Fedora, il y a des bécanes qui sont affectées à ça avec des procédures automatiques, un scheduler pour plannifier les tests, etc...
Au "petit matin" un mail est envoyé sur la mailing devel et les développeurs regardent ce qui les concernes.
En passant, Fedora utilise moch ce qui permet avec une bécane de compiler un programme pour FC4, FC5, FC6, F7, pour i386 pour amd64, etc.
Tu ne lance pas à moch à chaque fois que tu change une ligne de ton code, mais lorsque tu veux diffuser et t'assurer de la qualité du code (es-ce qu'il compile partout ? sur toute les architectures ? il y a-t-il des fichiers en conflit avec d'autres paquets, etc).
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal Fin de gcc dans les *BSD ?. Évalué à -2.
En passant, Linus Torvalds (himself) utiliser une Fedora. Les changements intrusifs il connait et il ne recompile pas tout tout les matins (Fedora n'est pas Gentoo).
Linus Torvalds est un "plouc" car il ne fait pas de "make word" ?
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal Fin de gcc dans les *BSD ?. Évalué à -2.
Ben tu le fais rarement. Sinon il y a un bug de conception. De plus il y a la libc entre le noyau et les applis et la libc supporte les versions (on peut donc avoir plusieurs versions d'une API).
Un OS qui demande de tout recompiler toutes les semaines est un OS qui sucks grave de chez grave.
> il faut _toujours_ tout recompiler.
Non.
> que modifier le code du routing, UFS
Dans ce cas tu recompiles le noyau et c'est l'affaire de 10 ou 20 minutes.
> C'est fallacieux de comparer un BSD a fedora.
Ouais, BSD c'est naze, il faut tout recompiler toutes les semaines.
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal Fin de gcc dans les *BSD ?. Évalué à 3.
Quand tu es développeur (et pas seulement un gentoo lover), tu ne passes pas ton temps à compiler des OS. Tu compiles ton code et il y a make pour compiler que ce qui est nécessaire. Make peut aussi compiler en parallèle (option -j) pour profiter d'un dual/quad core/cpu. Dans ce contexte, la vitesse de gcc est largement bonne.
Je suivais la mailing devel Fedora. Les rebuilds de tout l'OS (dit mass rebuild chez Fedora) sont très rares (un par an à cause d'un changement de version majeur de gcc). Pour F8 ça a été exceptionnel, il y a eu 2 mass rebuild (le premier a utilisé un gcc buggé). Les mass rebuild sont fait en une voire deux journées et pour 4 architectures. Il me faut préciser que Fedora utilise un cluster pour les compilations. Les développeurs Fedora ne font pas des "make world" histoire pour pourrir la planète, il récupère les binaires fait par Fedora.
> C'est aussi pour ca qu'il est important pour un projet consequent de compiler rapidement
Tu veux dire que les *BSD sont des OS gras ?
> au moins le code a passe le test du "make word".
J'en ai des frissons dans le dos.
# Re:
Posté par IsNotGood . En réponse au journal Fin de gcc dans les *BSD ?. Évalué à 3.
Visual C++ est aussi très rapide pour compiler (probablement 4 à 6 fois plus rapide que gcc).
Pour le reste il n'est pas du niveau de gcc. Je boose actuellement avec Visual C++ (consigne du boss), ben c'est presque une daube à côté de gcc.
Que Visual C++ soit plus rapide que gcc, ne lui donne aucun charme de plus. Si à l'avenir je peux éviter Visual C++, je l'éviterai.
[^] # Re: Fin de gcc dans les *BSD
Posté par IsNotGood . En réponse au journal Fin de gcc dans les *BSD ?. Évalué à 0.
- à faire plaisir à des développeurs. Si c'est leur truc, il n'y a rien à redire.
- permettre aux fanatiques BSD de dire "HAHA ! on s'en torche de GNU et de sa (L)GPL tyranique, on a un compilateur ultra-plus-mieux-bien que ce tout pourri et archi-lent de gcc.
En passant, gcc se bootstrappe. Pour compiler gcc, on commence par compiler un mini-gcc (qui ne fait que compilateur C, n'est pas cross-plateforme, n'est pas optimisé, etc) et ce dernier est utilisé pour compiler gcc. Ça doit être un poil plus compliqué car je crois qu'il y a stage1 stage2 et final.
J'ai rien contre pcc, mais j'ai rien pour.
# Rien à foutre
Posté par IsNotGood . En réponse au journal Le Monde baisse encore son niveau.... Évalué à -10.
Bonne journée.
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal GnuTLS 2.0. Évalué à 0.
Qu'elle ne se force pas à un passage en LGPL v3, ne va surprendre personne.
J'y comprend rien.
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal GnuTLS 2.0. Évalué à -1.
Non. Y a quelque chose qui m'échappe.
# Re:
Posté par IsNotGood . En réponse au journal GnuTLS 2.0. Évalué à -1.
Que veut dire cette phrase ?
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal OOXML précisions sur la phase suivante. Évalué à 1.
http://www.groklaw.net/pdf/CountryComments.zip
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal OOXML précisions sur la phase suivante. Évalué à 1.
Il n'y a qu'un fichier .doc ...
Je l'ouvre avec OOo. Mais j'affichage est naze. De plus ce document est naze. Même Word 2003 en chie pour l'ouvrir et au final proposer des liens vers le site ISO. C'est sans intérêt.
> De toutes façons il me semble qu'ODF a suivi la procédure normale.
Oui, mais il y a toujours un vote avec des commentaires. ODF n'a pas eu de BRM car il a été ratifié au premier vote. Mais il aurait pû y avoir BRM (même si ce n'était pas une procédure fast-track).
> mais il n'y a eu je crois que des OUI. Pas de BRM donc dans ce cas là.
Je ne demande pas les commentaires du BRM :-)
OOXML n'en a pas encore non plus.
# Re:
Posté par IsNotGood . En réponse au journal OOXML précisions sur la phase suivante. Évalué à 1.
> D'abord un lien vers les commentaires... c'est des .doc:
Un .doc et des html (pas terrible).
Le .doc ne passe pas sous OOo (v2.0.4).
En survolant les commentaires, j'ai l'impression que les carottes sont cuites...
pBpG qui n'arrête pas de dire que OOXML est complètement documenté, devrait lire les commentaires de l'ISO. OOXML n'est ps complètement documenté et en plus il est mal foutu.
Et en lisant les commentaires, on voit aussi que OOXML fait référence à des formats désignés comme propriétaires (VML, etc...).
> Enfin il semble que même les vote OUI puissent devenir des NON.
Je pense que quelqu'uns vont ralier la position de la France (AFNOR). C'est-à-dire que OOXML va avoir un NON avec la proposition de AFNOR d'attachée (proposition reformulée probablement).
> comme celui de la Grèce
Les commentaires de l'ANSI ne sont pas tendres non plus. Pourtant ils ont voté OUI...
Quelqu'un a-t-il le commentaire sur ODF (s'ils existent). Juste pour faire une comparaison.
[^] # Re: bin quoi?
Posté par IsNotGood . En réponse à la dépêche Interopérabilité : Réponse à la Commission Européenne à propos du rapport Gartner sur l'interopérabilité. Évalué à 1.
Pour ce qui est de la doc, JBoss est disponible en source donc il n'y a pas de problème de format fermé. Donc ce n'est ni propriétaire, ni fermé, c'est peut-être non-standard mais j'en doute.
> moi j'ai compris interface ne respectant pas le standard j2ee
JBoss est certifié J2EE compatible depuis plusieurs années.
Enfin c'est Red Hat qui dirige principalement JBoss (Red Hat a acheté JBoss il y a un peu plus d'un ans plus plusieurs centaine de millions de $ si j'ai bonne mémoire) et Red Hat n'a pas pour habitude de ne pas respecter les standards. Bien au contraire.
Je me demande si Earered ne confond pas JBoss de l'époque pré-Red Hat et le JBoss actuel. L'ancien JBoss était critiqué pour ne pas être totalement libre (j'ai oublié les détails de l'histoire).
Pour info, avant le rachat de JBoss, Red Hat bossait sur Jonas qui était au-dessus de tout soupçon. Red Hat ne fournissait pas JBoss mais Jonas. Du moins il me semble car je n'utilise pas Java :-)
[^] # Re: Re:
Posté par IsNotGood . En réponse à la dépêche Interopérabilité : Réponse à la Commission Européenne à propos du rapport Gartner sur l'interopérabilité. Évalué à 1.
>
> Il y a tous les jours des gens tirés au sort pour être jurés. J'espère que tu auras la chance de passer au travers ...
Je ne demande pas de condanné sans étude/procès. Mais pour moi, actuellement, MS a magouillé. Pour ce qui est de la langue, demande à pBpG. Il te servira du "tant qu'on n'a pas la preuve, MS est innocent" à l'envis. Devant la lois MS est innocent actuellement, mais je ne suis pas dans un jurés actuellement.
> Là, pour le coup, je m'étais déjà fait une opinion il y a trois ans
Ah ben bravo.
En passant, je n'ai jamais été un adèpte du "présumé innocent" qui est une formulation ridicule. On ne lance pas une action en justice s'il y a présomption d'innocence, mais s'il y a présomption de culpabilité.
[^] # Re: bin quoi?
Posté par IsNotGood . En réponse à la dépêche Interopérabilité : Réponse à la Commission Européenne à propos du rapport Gartner sur l'interopérabilité. Évalué à 1.
IL N'Y A PAS D'INTERFACE PROPRIÉTAIRE DANS JBOSS !!!
Ou alors cite les.
> Websphere a aussi des interfaces propriétaires.
Tu dis que Websphere en a (je n'en sais rien), mais Jboss n'en a pas.
Pour info, les sources de JBoss :
http://labs.jboss.com/projects/download
C'est principalement (exclusivement ?) du LGPL. Si tu veux accuser JBoss, avance des arguments. Je ne dis pas que tu as forcément tord, mais on n'accuse pas sans preuve ou au moins sans quelques éléments.
Pour info toujours, Red Hat fait une offre COMMERCIALE (et non propriétaire) de JBoss. Red Hat vend un service qui est accompagné de conditions. Tu peux ne pas être d'accord avec les conditions du service, mais Jboss reste définitivement libre. C'est la même chose pour RHEL (dont la liberté est entre autre prouvée avec Centos).
[^] # Re: bin quoi?
Posté par IsNotGood . En réponse à la dépêche Interopérabilité : Réponse à la Commission Européenne à propos du rapport Gartner sur l'interopérabilité. Évalué à 1.
JBoss est libre et est sous licence LGPL. Donc il est impossible qu'il ait des interfaces propriétaires (sauf magouille à la MS/Novell, ce qui n'est pas le cas ici).
Ton troll est minable.
# Re:
Posté par IsNotGood . En réponse à la dépêche Interopérabilité : Réponse à la Commission Européenne à propos du rapport Gartner sur l'interopérabilité. Évalué à 2.
Je serais très très très favorable qu'une enquête soit menée contre Gartner. Je doute que ceci fasse plaisir à MS... Pourtant, ça ne serait que pour avoir la vérité...
Positivons. Disons qu'il y a un vent de panique chez MS.