Pas si mauvais que ça. Il n'y a pas de Xsara turbo 4x4 de 300 ch avec double amortisseur réglable, boite semi-automique qui fait des changement de rapport en 5 centième de seconde, répartition de la motricité ultra sophistiqué, boite de vitesses à crabot, embrayge carbone, possibilité de changer la boite de vitesse ou n'importe quoi en moins de 15 min, frein à main assisté, etc... dans le catalogue Citroën.
Un tel truc coût un pognon montrueux.
> Les voitures sont réellement dérivees des modeles de production (chassis, bloc moteur)
Mouaif...
Le chassis d'origine est tellement renforcé par les arceaux de sécurité etc qu'il ne sert pratiquement à rien à part "faire joli".
Pour le bloc moteur, ce n'est pas un problème car la puissance est limité et car les moteurs de la WRC sont bichonnés (équilibrage nickel du vilbrequin, pièces mobiles ultra légères, carter sec, etc...).
Un bloc moteur de série doit faire au moins 100 000 km, avec de l'huile de merde (et parfois presque pas d'huile), des jeux "énormes" (comparé à ce qui se fait en compétition) au niveau du vilbrequin, bielle, piston, etc...
Une Xsara (ou C4) WRT n'a plus grand chose à voir avec la voiture de série.
> par la suite ça bave car rien que le fait de penser proposer un compilateur alternatif pour leurs sources en C, entrainent une levé de bouclier de gens comme toi
J'en ai rien à foutre qu'OpenBSD utilise autre chose que gcc. Vu comme OpenBSD est prêt systématiquement à gerber sur Linux et la GPL, j'en serai heureux même. Il donne systématique des leçons, critiques les outils GNU, etc...
Très bien, qu'ils ne les utilisent pas. S'ils ne les utilisent pas et font du troll/fud, ça m'énerverait beaucoup moins.
Ce qui m'insupporte c'est de voir des gens qui profitent de gcc et vomissent sur gcc.
De combien à contribué OpenBSD à gcc ?
0,01 % ou 0, 02 % ?
Pourtant OpenBSD utilise 100 % de gcc.
On va dire encore qu'il n'ont pas les moyens de développer un compilateur. Très bien encore. Avec gcc, ils ont quelques qu'il n'ont pas les moyens de développer. Ça fait encore une raison de moins de critiquer gratuitement gcc.
> du GNUisme
C'est une seconde nature...
Vois ta contradiction :
- "car rien que le fait de penser proposer un compilateur alternatif pour leurs sources en C, entrainent une levé de bouclier de gens comme toi,"
Si je suis "GNUiste" alors je ne ferai pas une levée de bouclier.
Alors, je suis "GNUiste" ou non ?
C'est de la critique gratuite/facile tout ça. Si gcc est comme ci alors c'est mal et s'il est comme ça alors ... c'est mal aussi. Tout ce qui n'est pas gcc est bien. Dans ce cas, il faut assumer et ne pas utiliser gcc.
J'utilise openssh, je ne vomis pas sur openssh. Pourtant il y a une alternative GPL.
> Maintenant, si tu prends toute remarque négative comme une insulte envers ce projet,
Dans le cas que tu donnes, oui.
Tu peux faire une critique de gcc, il y a toujours des choses à améliorer.
Mais dire que gcc est tellement pourrave qu'il faut passer à un "sous-compilateur", c'est une insulte.
Et quel est l'argumentaire pour "descendre" gcc ?
> GCC is developed by people who have vastly different goals from us.
Un compilateur, c'est un compilateur. Ce n'est pas une machine à café. Donc le "vastly different goals from us", je ne le comprend pas.
> Here is some *more* flame material.
C'est un compliment pour toi ?
> GCC is mostly a commercial compiler, these days.
Et ? Il l'a acheté combien ?
Il y a peu Theo se félicitait d'avoir des contributions de société et il trouvait ça bien. Mais si c'est GCC, "bing", ça devient mal.
Marrant.
Et pourquoi le "these days". Si ma mémoire ne me trahie pas, OpenBSD n'est même pas à la version 4 de gcc qui est sortie depuis des années. OpenBSD est à la version 3.3 (tout une époque...).
> They mostly target *fast* i386 architectures and PowerPC.
Et ?
C'est là où il y a le plus d'utilisateur, c'est là où il y a le plus de contribution.
Qu'il fasse pcc ou n'importe quoi, ça sera la même chose (pour peu que pcc soit vaguement populaire).
En passant, OpenBSD utilisant gcc 3.3, il ne doivent rien remarquer de ces modifications.
> *but* the compiler is getting bigger and bigger, and slower and slower (very much so).
Comment il le sait, OpenBSD est à la version 3.3 de gcc...
C'est con, mais gcc a gagné en rapidité ces derniers temps. Il en a perdu à l'introduction de SSA et maintenant il en gagne. De plus, ça ne veut rien dire. Un compilateur ce n'est pas un truc pour l'utilisateur final, ce n'est pas un jeux ou les fps compte, ça n'a pas des critères d'ergonomies, etc... Avant tout, il rend un service (compiler, générer du code machine). Le service est-il bon ? La majorité pense que oui.
> GCC warnings are not *really* useful. The -Wall flag shows many right things, and quite a few wrong issues.
Ben qu'il nous casse pas les couilles avec ça et qu'il désactive les warnings s'il veut coder comme porc. C'est ses oignons. NB : c'est l'option "-w" pour désactiver les warnings. C'est aussi configurable au niveau système.
> - There is a lot of churn in GCC which ends up with it no longer supporting some architectures that are still relevant to us.
Et ?
C'est ses oignons. Si personne ne veut d'une architecture mais seulement lui, ben qu'il retrousse ses manches. Passer à pcc ne change rien à ce problème.
pcc supporte des architectures "exotiques" ? Je ne crois pas.
Pcc est-il cross-plateform ? C'est important pour tester les architecture exotique sans avoir des tonnes de matériel.
> - The whole design of GCC is perverted
Encore un compliment ou une affirmation gratuite ?
> This is broken by design
Encore un compliment ? Une critique argumenté ?
> as the GPL people
La conspiration des adorateurs de la GPL. Mais oui...
> This also makes it impossible to write interesting tools, such as intermediate analyzers
C'est carrément impossible !
> This also makes it impossible to plug old legacy back-ends for old architectures into newer compilers.
?!?!
Si tu veux un vieux compilateur, utilise un vieux compilateur ! C'est exactement ce que fait OpenBSD. Il utilise gcc 2.95 et 3.3. Des vieux compilateurs.
Sûr que pcc n'aura jamais cette "feature" (utiliser des vieux backend avec un nouveau frontend). On en fait le pari ?
> every GCC update is an engineering nightmare,
Comment il sait ça?
OpenBsd n'est même pas à la version 4 de gcc...
> because there is NO simple choice. You gain some capabilities, and you also lose some important stuff.
S'il le dit...
En tout cas pour OpenBSD on n'en sait rien car OpenBSD a arrêté le temps depuis gcc 3.3.
> Even when you conform, it's hard to write code to the GNU coding standards, which are probably the most illegible coding guidelines for C. It's so obvious it was written by a lisp programmer. As a result, I've even lost interest into rewriting and getting in the GCC repository a few pieces.
La belle excuse....
> - some of their most recent advances do not have a chance to work on OpenBSD, like preparsed includes,
Ben il faut faire le portage. C'est un "peu" le boulot d'OpenBSD.
> which depend on mmap() at a fixed location.
Ben dans ce cas ça ne marche pas sous Linux non plus.
Le "méchant" Red Hat (et pas seulement Red Hat) utilise des adresses alléatoires pour RHEL et Fedora.
Bref, du gros pipo.
> - there are quite a few places in GCC and G++ where you cannot have full functionality without having a glibc-equivalent around.
C'est un problème de portage, c'est à OpenBSD de faire le boulot (du moins de ne pas se plaindre si ce n'est pas fait).
> - some of the optimisation choices are downright dangerous
Puisque tu le dis. Depuis quelques jours c'est un feux d'artifice d'exposion de bécane qui compile avec gcc.
> and wrong for us (like optimizing memory fills away, even if they deal with crypto keys).
C'est un problème de portage.
> - don't forget the total nightmare of autoconf/libtool/automake.
Toujours le même troll...
Ben qu'OpenBSD fasse l'équivalent d'autoconf/libtool/automake et qui marche partout. Après on en recause.
> And GCC is *the only program in the ports tree* that actually uses its own libtool. Its configuration and reconfiguration fails abysmally when you try to use a system-wide libtool.
Enfin une bonne critique....
Ce bug ne demande qu'à être corrigé.
Mais je m'interroge. Ça ne serait pas un bug de gcc 3.3 qui a été corrigé depuis des lustres ? Mais OpenBSD ne serait pas au courrant car il reste sckotché à gcc 3.3.
> I could actually go on for pages...
Compliment ou critique constructive ?
Et de quoi ?
De gcc 3.3 ?
> I will happily switch to another compiler, so frustrating has been the road with GCC.
Bon débarras. Qu'OpenBSD n'utilise plus GCC.
> I've actually been de facto maintainer of GCC on OpenBSD for a few years by now
Ça n'a pas été trop dure puisque que gcc est en version 3.3 dans OpenBSD.
Il y a peut-être encore gcc 2.95 dans la dernière OpenBSD que ça ne m'étonnerait pas.
Ben on va voir ce que va faire pcc.
Vu comme ils prennent de haut gcc, ils ont intérêt à faire un truc qui arrache sa mère.
Je te paris que pcc restera un petit truc. Même les Gentoo lovers qui sont accros à la compilation ne vont pas l'utiliser...
J'en prend le pari.
Et si pcc c'est seulement faire un compilateur qui n'est pas cross-plateform, qui est peu optimisé, qui supporte peu de cpu, qui ne fait C et pas C++, etc, et bien il est mal venu de cracher sur gcc. Surtout qu'openBSD va rester dépendant de gcc pour encore très longtemps.
Mais ça c'est classique de openBSD boys. Ça ne manque pas une ocasion de cracher sur les outils GPL alors qu'ils les utilisent. Ce que j'utilise sous licence BSD, je ne crache pas dessus.
Ce n'est pas n'importe quoi, le procès dure depuis plusieurs années (il a débuté en 1998 ?). Le procès ne conserne pas que la France et pas que l'administration française.
Donc, c'est presque rien pour MS.
> Et je te rappelle qu'il y a aussi une astreinte de 3 millions d'euros par jour de retard
Ça ce n'est pas rien.
Pas ans ça fait 1 milliard d'¤. Ici MS c'est pris 500 millions d'¤ pour un procès de presque 10 ans. Maintenant c'est presque 20 fois plus. Si le 3 millions d'¤ par jour est justifié, alors les 500 millions d'¤ en presque 10 ans sont presque rien.
> Sinon, ca m'interesserait d'avoir une reproduction du probleme.
Désolé, mais le code est propriétaire :-(
J'avais fait un fichier .cpp minimum pour reproduire le bug (savoir spécifiquement ce qui ne marchait pas) mais j'ai foutu ce fichier à la poubelle. C'est ce fichier qui marchait nickel avec gcc et qui plantait toujours VC++. La vrai appli n'a pas été porté sous Linux (c'est quasi impossible).
Si tu vires tous les "public virtual", ça semble marcher sous VC++. Mais je n'ai plus ce que je veux et plein de duplication de donné très difficile à gérer. Donc ça semble marcher par j'ai fait peu de tests pour ce cas.
Autre problème avec VC++, je voulais un "constructeur virtuel". Un truc dans ce goût : CMixerBmpD3D::Clone() = 0;
CMixerBmpD3DTex::Clone() ;
CMixerShot::Clone() = 0;
CMixerShotTex::Clone() ;
CMixerShotTex * pTex = ... ; // <= C'est un CMixerShotTex
f(pTex) ;
f(CMixerBmpD3D * pBmpD3D) {
CMixerBmpD3D * p = pBmpD3D->Clone() ; // Ici avec VC++ appel de CMixerBmpD3DTex::Clone() et non CMixerShotTex::Clone().
}
Grand pasBill pasGates, grand spécialiste de Windows, dans le débuggeur lorsque je suis sur "delete quelquechosequejaidéfini" et que je fais un "pas à pas détaillé" , pourquoi parfois il me fait un "pas à pas principal" ?
C'est vraiment casse couille.
En passant, j'ai aucun warning sous gcc et aucun warning sous VC++.
Le dynamic_cast déclenche une exception __non_rtti_object (ou un truc dans ce goût) alors que c'est compilé avec /GR (stupidement non par défaut dans le compilateur VC++, ce qui ne respecte pas le standard ISO...).
> T'es sur que le probleme vient du compilo et que tu n'as pas fait une bourde qui par chance passe dans gcc ?
Voilà ce qui ne marchait pas (une petite partie des entêtes) : class CMixerBmpD3D : public virtual CBmpD3DDesc {
virtual ... = 0 ;
}
class CMixerBmpD3DSurf : public virtual CMixerBmpD3D {
}
class CMixerBmpD3DTex : public virtual CMixerBmpD3D {
}
class CMixerShot : public virtual CShotDesc, public virtual CMixerBmpD3D {
int entier_CMxierShot ;
virtual ... = 0 ;
void fonction_CMixerShot() {
entier_CMixerShot++ ;
}
class CMixerShotSurf : public virtual CMixerShot, public virtual CMixerBmpD3DSurf {
}
class CMixerShotTex : public virtual CMixerShot, public virtual CMixerBmpD3DTex {
}
Ce qui ne marchait était par exemple :
CMixerShotTex * pTex = new CMixerShotTex ;
CMixerShot * pShot = pTex ;
pShot->fonction_CMixerShot() ; // plantage.
Il n'y a pas forcément plantage à l'appel de la fonction mais plantage lors de "entier_CMixerShot++". Un affichage de "*this" dans le débuggeur donne du n'importe quoi alors que je suis dans une fonction membre ! C'est définitivement une erreur du compilateur.
Autre problème :
CMixerShotTex * pTex = new CMixerShotTex ;
CMixerShot * pShot = dynamic_cast<CMixerShot *>(pTex) ;
Le dynamic_cast n'est pas nécessaire. Mais si je l'utilise, pShot est égal à NULL. C'est encore définitivement une erreur du compilateur.
Autre problème :
CMixerShotTex * pTex = new CMixerShotTex ;
f(pTex) ;
f(CMixerShot * pShot) {
CMixerShotTex * pTex = dynamic_cast<CMixerShotTex *>(pShot) ; // retourne NULL alors que c'est un CMixerShotTex *
}
Pour régler le problème, j'ai viré CMixerShot (j'ai déplacé des données/fonctions) et tout regroupé dans CMixerBmpD3D.
> T'es sur que le probleme vient du compilo
Oui, j'ai vu une page web qui en parle mais je ne l'ai plus. Parfois VC++ n'arrive pas à déterminer le type d'un object.
Les "public virtual" sont nécessaires car il y a des données en commun entre CShotDesc et CMixerBmpD3D entre autre.
tcc est sous licence GPL ce qui arrache des hurlements de douleur aux BSDistes.
Juré, c'est une horreur. Certains se tapent la tête contre les murs, d'autres se font des saignées, etc...
> Ubuntu a eu bcp de buzz autour d'elle alors c'est elle qu'on met en avant
Je dis ça, je dis rien... mais le boss d'Ubuntu dit qu'Ubuntu n'est pas pour les masses mais pour les "amateurs".
Si lui le dit, ça passe comme une lettre à la poste, si je le dis ça fait scandale. Mais c'est la vérité.
Red Hat est grosso-modo sur la même longueur d'onde qu'Ubuntu (du moins son boss).
> c'est vraiment pas le problème d'avoir des distros "pour les masses"
Ce n'est actuellement pas prioritaire, mais c'est un réel problème, un travail très long.
> Tu penses que Linux a besoin d'une distro non communautaire pour percer.
Désolé pour la brutalité de la réponse, mais tu n'as rien compris.
Ce qu'il faut pour "les masses", c'est un truc type RHEL (ou Novell, qu'importe). Quelque chose avec un long support et une API source et binaire stable, etc.
Les distributions communautaires ne fournisse pas de telle distribution. Ou il n'y en a qu'une qui le fournit et c'est Centos. Mais ça ne compte pas car c'est un "bête" clone de RHEL.
Debian n'offre que quelques mois de support lorsqu'un nouvelle release sort. Sarge n'est plus maintenu depuis longtemps.
> Mais avec ce raisonnement, le développeur qui aime la façon de faire gentoo, va utiliser gentoo. Il ne participera pas au développement de la distro "pour les masses",
Ce n'est absolument pas ce que j'ai dit. La distribution "pour les masses" sera gérée par Red Hat par exempre (ou autre, qu'importe). Mais il n'y aura qu'un travail de packaging et de test. Les développements seront upstream et dans les distributions "communautaires" type Gentoo, Fedora, OpenSuse, etc...
RHEL n'innove pas, c'est seulement l'application de développements de la communauté du libre.
Le rôle des distributions communautaires, même avec une RHEL (ou autre) pour les masses, reste crucial. Ce sont elles (et la communauté du libre dans son ensemble) qui fait/fera le succès d'un truc type RHEL "pour les masses". Et comme RHEL depend de la communauté du libre, Red Hat investira en recherche et développement dans les distributions communautaire (Fedora typiquement) et les développement upstream. Il n'y aura presque rien en recherche et développement dans RHEL.
> Tu penses que Linux a besoin d'une distro non communautaire pour percer. Je pense que ce qui fait la différence de linux, ce n'est pas ça supériorité technique, c'est sa philosophie, et entre autre la communauté.
Et ?
J'en suis très content pour toi.
Ce que tu pays avec RHEL, c'est un service. Le service de maintenir un OS sans casser la compatibilité source et binaire, tu pays des tests, etc...
Tu payes un service, ça ne va pas contre le libre.
> Sauf que les deux sont regroupées dans un seul et unique projet… Debian.
Et alors ?
De plus, ce n'est pas le cas. Unstable/testing de Debian, ce n'est pas Fedora, c'est Rawhide (branche développement de Fedora). Debian "stable" est plus proche de Fedora "finale" que de RHEL.
Il n'y a pas d'équivalent RHEL dans Debian. La dernier Debian stable est Eth et Sarge n'est plus maintenu. RHEL 2.1, 3, 4 sont encore maintenues (et pour longtemps). En gros lorsqu'une Debian sort, la version précédente est maintenue moins d'un ans (8 mois pour Sarge si j'ai bonne mémoire). Pour RHEL c'est minimum 7 ans de durée de vie. Si la version suivante sort au bout de 18 mois (ce qui est typiquement le cas), il reste 5 ans et demi. Rien à voir avec les 8 mois de Debian.
Mon "vrai" exemple qui ne marche pas fait plusieurs milliers de ligne. Désolé de ne pas avoir fait un copié/collé ici. Enfin, il faut aussi utiliser les fonctions virtuelles pures pour avoir ce problème.
> class Bar : public virtual Bob, public virtual Foo
Aucun.
Notons que la compatibilité sur tous les gcc 4 n'est pas assurée. Par exemple ce qui est compilé avec Fedora 5 ne peut tourner sur Fedora 4. Ce n'est pas un problème de version de librairie mais de compilateur/édition de lien. Mais ce n'est pas un problème car pratiquement personne ne l'a remarqué :-)
> Le but est de faire percer Linux. Ce n'est peut être pas important pour tous le monde.
Sa percée doit être un conséquence de son excellence. Il ne faut pas prendre le problème à l'envers.
La percée de Linux ne passera pas par une distribution qui doit être stable, dynamique et adaptée aux développeurs. Un tel truc n'existe pas et n'existera jamais.
Quand je lis que Fedora est une distribution Desktop qui remplace RHL, je me marre. C'est faux. Fedora est une distribution pour les "enthousiastes" du libre, pour la communauté du libre. Le linux pour les masses ne sera pas incarné par Fedora, ni Ubuntu ni OpenSuse ni Mandriva.
Le linux pour les masses sera "incarné" par une distribution stable (pas un truc qui change tous les 6 mois comme Fedora ou Ubuntu). Ça pourrait être une RHEL Desktop. Et la, il ne faut pas paniquer ! Les Fedora/Ubuntu/Gentoo/Debian/etc auront toujours un rôle major. Une RHEL Desktop (ou Novell ou Ubuntu+, qu'importe) ne sera pas développé sur et pour RHEL mais sur et pour Fedora/Ubuntu/etc. RHEL Desktop sera peut-être populaire, mais son avenir sera entre les mains de la communauté (Fedora/etc).
Le rôle de RHEL sera de packager, tester, certifier auprès d'Adobe, etc...
Donc, si on parle de percée de Linux, il faut, à mon avis, distinguer distribution pour les masses (l'utilisateur lambda) et distribution communauté (pour les enthousiaste qui veulent les dernières innovations, les développeurs, etc).
Tu veux qu'une distribution fasse les deux. A mon avis :
1 - ce n'est pas possible
2 - c'est un mauvais objectif
Ton problème est "universel". Red Hat l'a. La solution de Red Hat est RHEL et Fedora. Peut-être que la solution/réflexion de Red Hat fera avancé ta réflexion. Red Hat n'est pas le seul à faire ça mais il est quasiment le premier à le faire et de façon très agressive. Ça a débuté avec RHL 2.1 AS puis Fedora.
Je te conseille de bien analyser le modèle RHEL/Fedora/communauté upstream. C'est riche d'enseignement et aussi si tu bosses sous/pour Debian.
> Le modele de fedora est certe très dyamique mais dans le cadre d'utilisation orienté serveur très peu fiable:
Oui, rien n'est parfait.
De plus, il ne faut pas mélanger fiabilité et stabilité. Fedora n'est pas stable, mais est fiable. Pour du desktop on veut du fiable, pour du serveur on veut du fiable et stable (pas de changement de version de php par exemple).
> La encore, le modèle de développement n'est pas optimal puisqu'il ne convient pas au plus grand nombre.
Tu n'es pas claire. De quoi tu parles ? Quel est ta préoccupation ?
Si tu parles en tant que développeur web, RHEL est nickel. C'est fiable et stable.
Si tu parles en tant que développeur libre, Fedora (ou Gentoo) est nickel. C'est une distribution qui veut bosser avec l'upstream, y participer. Tout le contraire de RHEL. Si t'as un projet super existant tu peux avoir un développeur Fedora qui frappe à ta porte afin de bosser ensemble sur une nouvelle fonctionnalité. Ça n'arrive pas avec RHEL.
Lève tes contradictions. Tu veux du dynamique (changement de version) et du stable (pas de changement de version).
Ce n'est pas possible et c'est pour celà qu'il y a RHEL et Fedora. RHEL est stable et Fedora dynamique (et fiable).
Et tu parles de quoi ?
Du modèle de développement ou de maintenance ?
Le modèle de maintenance de RHEL et Fedora sont très différents. RHEL ne fait que des backport pour assurer la compatibilité source et binaire (et aussi au niveau des drivers/module noyau). Fedora ne se soucis pas (ou assez peu) de la compatibilité source et binaire.
Les tests sur RHEL sont très formalisés avec des tests d'Oracle, Dell, etc...
Les tests sur Fedora sont plus souples/empiriques. Si ça marche pour un panel d'utilisateur significatif, ben Fedora sort la mise à jour. Si ça ne marche pas pour un client, ben RHEL ne sort pas la mise à jour.
Ce qui est fait par RHEL et qui n'est pas du développement (mais de la maintenance/support) coûte très cher. Ce n'est pas un travail très innovant ou exitant et c'est pour ça qu'il est cher. Très peu de développeur upstream font des patch backport, les tests, etc... RHEL le fait et c'est cher. Fedora ne le fait pas et c'est gratuit.
RHEL n'a pas de modèle de développement (pour caricaturer). Fedora en a un et c'est "priorité à l'upstream".
Si tu veux du dynamic et stable, ça n'existe pas et ça n'existera jamais. C'est pour celà qu'il y a RHEL ET Fedora. RHEL (du moins son "développement") ne peut exister sans Fedora.
* To do as much of the development work as possible directly in the upstream packages. We will in general prefer moving to a newer version for updates rather than backport fixes.
...
Non-Objectives of Fedora
...
* Fedora shall not be a dumping ground for unmaintained or poorly designed software.
> Le modèle de développement où tout est figé convient à Red Hat Linux qui a les moyens de le supporter.
Red Hat Linux n'existe plus et depuis longtemps. Il y a RHEL (Red Hat Entreprise Linux) et Fedora.
RHEL n'a pas vraiment de "modèle de dléveloppement". RHEL n'est pas développé, c'est un fork de Fedora.
Pour RHEL 5, c'est un fork de FC6. Puis RHEL 5 est paufiné/maintenu (et non développé sauf pour quelques cas bien précis).
Donc pour Red Hat le développement est fait dans Fedora. Et pour Fedora, ce n'est pas le modèle figé. Fedora est même très agressif. Une version "stable" de Fedora peut avoir une mise à jour vers une version majeur d'un logicel. FC6 est sorti avec un noyau 2.6.18, puis mise à jours vers 2.6.19, 2.6.20, 2.6.21, 2.6.22 et 2.6.23 est déjà en cours de maturation. Fedora veut être au plus proche de la version upstream et les corrections de sécurité sont dans la mesure du possible des mises à jour vers la version upstream.
Là n'est pas le coeur du problème. Il y a des règles, MS les viole. MS pourrait faire des abus de position dominante et perdre du pognon que ça ne changerait rien pour la comission (sauf le niveau de l'amende).
Si MS n'avait pas de pognon à gagner en violant les règles, MS n'aurait pas fait trainer le procès.
Même avec cette énorme amende, MS gagne à tricher (et largement).
Il n'y a que l'astreinte de 3 millions par jour qui va calmer MS.
[^] # Re: Errata
Posté par IsNotGood . En réponse au journal Les distributions linux nouvelle génération. Évalué à 2.
Pas si mauvais que ça. Il n'y a pas de Xsara turbo 4x4 de 300 ch avec double amortisseur réglable, boite semi-automique qui fait des changement de rapport en 5 centième de seconde, répartition de la motricité ultra sophistiqué, boite de vitesses à crabot, embrayge carbone, possibilité de changer la boite de vitesse ou n'importe quoi en moins de 15 min, frein à main assisté, etc... dans le catalogue Citroën.
Un tel truc coût un pognon montrueux.
> Les voitures sont réellement dérivees des modeles de production (chassis, bloc moteur)
Mouaif...
Le chassis d'origine est tellement renforcé par les arceaux de sécurité etc qu'il ne sert pratiquement à rien à part "faire joli".
Pour le bloc moteur, ce n'est pas un problème car la puissance est limité et car les moteurs de la WRC sont bichonnés (équilibrage nickel du vilbrequin, pièces mobiles ultra légères, carter sec, etc...).
Un bloc moteur de série doit faire au moins 100 000 km, avec de l'huile de merde (et parfois presque pas d'huile), des jeux "énormes" (comparé à ce qui se fait en compétition) au niveau du vilbrequin, bielle, piston, etc...
Une Xsara (ou C4) WRT n'a plus grand chose à voir avec la voiture de série.
[^] # Re: OpenBSD utilise gcc 3.3. Les nazes.
Posté par IsNotGood . En réponse au journal Fin de gcc dans les *BSD ?. Évalué à 2.
J'en ai rien à foutre qu'OpenBSD utilise autre chose que gcc. Vu comme OpenBSD est prêt systématiquement à gerber sur Linux et la GPL, j'en serai heureux même. Il donne systématique des leçons, critiques les outils GNU, etc...
Très bien, qu'ils ne les utilisent pas. S'ils ne les utilisent pas et font du troll/fud, ça m'énerverait beaucoup moins.
Ce qui m'insupporte c'est de voir des gens qui profitent de gcc et vomissent sur gcc.
De combien à contribué OpenBSD à gcc ?
0,01 % ou 0, 02 % ?
Pourtant OpenBSD utilise 100 % de gcc.
On va dire encore qu'il n'ont pas les moyens de développer un compilateur. Très bien encore. Avec gcc, ils ont quelques qu'il n'ont pas les moyens de développer. Ça fait encore une raison de moins de critiquer gratuitement gcc.
> du GNUisme
C'est une seconde nature...
Vois ta contradiction :
- "car rien que le fait de penser proposer un compilateur alternatif pour leurs sources en C, entrainent une levé de bouclier de gens comme toi,"
Si je suis "GNUiste" alors je ne ferai pas une levée de bouclier.
Alors, je suis "GNUiste" ou non ?
C'est de la critique gratuite/facile tout ça. Si gcc est comme ci alors c'est mal et s'il est comme ça alors ... c'est mal aussi. Tout ce qui n'est pas gcc est bien. Dans ce cas, il faut assumer et ne pas utiliser gcc.
J'utilise openssh, je ne vomis pas sur openssh. Pourtant il y a une alternative GPL.
[^] # Re: OpenBSD utilise gcc 3.3. Les nazes.
Posté par IsNotGood . En réponse au journal Fin de gcc dans les *BSD ?. Évalué à 0.
Peut-être car openbsd n'a quasiment rien fait depuis au moins 3 ans dans gcc ?
Ce n'est pas peut-être, c'est sûrement.
> Je te laisse te masturber sur la superiorité de redhat qui se bat sans relâche contre le monde entier qui ne désire que sa perte.
Quand as-tu lu ou entendu que j'avais peur pour l'avenir de Red Hat ?
Jamais.
Toi tu retournes te masturber sur ce que j'aurais dit sur Red Hat et sur les trolls d'OpenBSD sur gcc.
[^] # Re: Re ; Fin de gcc dans les *BSD ?
Posté par IsNotGood . En réponse au journal Fin de gcc dans les *BSD ?. Évalué à -2.
Ben pareil avec mes sources.
Tous truc "technique" est compliqué. On ne devient pas codeur gcc ou Linux du jour au lendemain.
[^] # Re: Fin de gcc dans les *BSD
Posté par IsNotGood . En réponse au journal Fin de gcc dans les *BSD ?. Évalué à -1.
La BSD c'est bon pour les brevets et les brevet c'est tout bon pour les avocats.
[^] # OpenBSD utilise gcc 3.3. Les nazes.
Posté par IsNotGood . En réponse au journal Fin de gcc dans les *BSD ?. Évalué à -3.
Dans le cas que tu donnes, oui.
Tu peux faire une critique de gcc, il y a toujours des choses à améliorer.
Mais dire que gcc est tellement pourrave qu'il faut passer à un "sous-compilateur", c'est une insulte.
Et quel est l'argumentaire pour "descendre" gcc ?
> GCC is developed by people who have vastly different goals from us.
Un compilateur, c'est un compilateur. Ce n'est pas une machine à café. Donc le "vastly different goals from us", je ne le comprend pas.
> Here is some *more* flame material.
C'est un compliment pour toi ?
> GCC is mostly a commercial compiler, these days.
Et ? Il l'a acheté combien ?
Il y a peu Theo se félicitait d'avoir des contributions de société et il trouvait ça bien. Mais si c'est GCC, "bing", ça devient mal.
Marrant.
Et pourquoi le "these days". Si ma mémoire ne me trahie pas, OpenBSD n'est même pas à la version 4 de gcc qui est sortie depuis des années. OpenBSD est à la version 3.3 (tout une époque...).
> They mostly target *fast* i386 architectures and PowerPC.
Et ?
C'est là où il y a le plus d'utilisateur, c'est là où il y a le plus de contribution.
Qu'il fasse pcc ou n'importe quoi, ça sera la même chose (pour peu que pcc soit vaguement populaire).
En passant, OpenBSD utilisant gcc 3.3, il ne doivent rien remarquer de ces modifications.
> *but* the compiler is getting bigger and bigger, and slower and slower (very much so).
Comment il le sait, OpenBSD est à la version 3.3 de gcc...
C'est con, mais gcc a gagné en rapidité ces derniers temps. Il en a perdu à l'introduction de SSA et maintenant il en gagne. De plus, ça ne veut rien dire. Un compilateur ce n'est pas un truc pour l'utilisateur final, ce n'est pas un jeux ou les fps compte, ça n'a pas des critères d'ergonomies, etc... Avant tout, il rend un service (compiler, générer du code machine). Le service est-il bon ? La majorité pense que oui.
> GCC warnings are not *really* useful. The -Wall flag shows many right things, and quite a few wrong issues.
Ben qu'il nous casse pas les couilles avec ça et qu'il désactive les warnings s'il veut coder comme porc. C'est ses oignons. NB : c'est l'option "-w" pour désactiver les warnings. C'est aussi configurable au niveau système.
> - There is a lot of churn in GCC which ends up with it no longer supporting some architectures that are still relevant to us.
Et ?
C'est ses oignons. Si personne ne veut d'une architecture mais seulement lui, ben qu'il retrousse ses manches. Passer à pcc ne change rien à ce problème.
pcc supporte des architectures "exotiques" ? Je ne crois pas.
Pcc est-il cross-plateform ? C'est important pour tester les architecture exotique sans avoir des tonnes de matériel.
> - The whole design of GCC is perverted
Encore un compliment ou une affirmation gratuite ?
> This is broken by design
Encore un compliment ? Une critique argumenté ?
> as the GPL people
La conspiration des adorateurs de la GPL. Mais oui...
> This also makes it impossible to write interesting tools, such as intermediate analyzers
C'est carrément impossible !
> This also makes it impossible to plug old legacy back-ends for old architectures into newer compilers.
?!?!
Si tu veux un vieux compilateur, utilise un vieux compilateur ! C'est exactement ce que fait OpenBSD. Il utilise gcc 2.95 et 3.3. Des vieux compilateurs.
Sûr que pcc n'aura jamais cette "feature" (utiliser des vieux backend avec un nouveau frontend). On en fait le pari ?
> every GCC update is an engineering nightmare,
Comment il sait ça?
OpenBsd n'est même pas à la version 4 de gcc...
> because there is NO simple choice. You gain some capabilities, and you also lose some important stuff.
S'il le dit...
En tout cas pour OpenBSD on n'en sait rien car OpenBSD a arrêté le temps depuis gcc 3.3.
> Even when you conform, it's hard to write code to the GNU coding standards, which are probably the most illegible coding guidelines for C. It's so obvious it was written by a lisp programmer. As a result, I've even lost interest into rewriting and getting in the GCC repository a few pieces.
La belle excuse....
> - some of their most recent advances do not have a chance to work on OpenBSD, like preparsed includes,
Ben il faut faire le portage. C'est un "peu" le boulot d'OpenBSD.
> which depend on mmap() at a fixed location.
Ben dans ce cas ça ne marche pas sous Linux non plus.
Le "méchant" Red Hat (et pas seulement Red Hat) utilise des adresses alléatoires pour RHEL et Fedora.
Bref, du gros pipo.
> - there are quite a few places in GCC and G++ where you cannot have full functionality without having a glibc-equivalent around.
C'est un problème de portage, c'est à OpenBSD de faire le boulot (du moins de ne pas se plaindre si ce n'est pas fait).
> - some of the optimisation choices are downright dangerous
Puisque tu le dis. Depuis quelques jours c'est un feux d'artifice d'exposion de bécane qui compile avec gcc.
> and wrong for us (like optimizing memory fills away, even if they deal with crypto keys).
C'est un problème de portage.
> - don't forget the total nightmare of autoconf/libtool/automake.
Toujours le même troll...
Ben qu'OpenBSD fasse l'équivalent d'autoconf/libtool/automake et qui marche partout. Après on en recause.
> And GCC is *the only program in the ports tree* that actually uses its own libtool. Its configuration and reconfiguration fails abysmally when you try to use a system-wide libtool.
Enfin une bonne critique....
Ce bug ne demande qu'à être corrigé.
Mais je m'interroge. Ça ne serait pas un bug de gcc 3.3 qui a été corrigé depuis des lustres ? Mais OpenBSD ne serait pas au courrant car il reste sckotché à gcc 3.3.
> I could actually go on for pages...
Compliment ou critique constructive ?
Et de quoi ?
De gcc 3.3 ?
> I will happily switch to another compiler, so frustrating has been the road with GCC.
Bon débarras. Qu'OpenBSD n'utilise plus GCC.
> I've actually been de facto maintainer of GCC on OpenBSD for a few years by now
Ça n'a pas été trop dure puisque que gcc est en version 3.3 dans OpenBSD.
Il y a peut-être encore gcc 2.95 dans la dernière OpenBSD que ça ne m'étonnerait pas.
Si tu veux des critiques constructives sur gcc, t'en trouvera ici par exemple :
http://www.gccsummit.org/2007/
[^] # Re: Re ; Fin de gcc dans les *BSD ?
Posté par IsNotGood . En réponse au journal Fin de gcc dans les *BSD ?. Évalué à -7.
Vu comme ils prennent de haut gcc, ils ont intérêt à faire un truc qui arrache sa mère.
Je te paris que pcc restera un petit truc. Même les Gentoo lovers qui sont accros à la compilation ne vont pas l'utiliser...
J'en prend le pari.
Et si pcc c'est seulement faire un compilateur qui n'est pas cross-plateform, qui est peu optimisé, qui supporte peu de cpu, qui ne fait C et pas C++, etc, et bien il est mal venu de cracher sur gcc. Surtout qu'openBSD va rester dépendant de gcc pour encore très longtemps.
Mais ça c'est classique de openBSD boys. Ça ne manque pas une ocasion de cracher sur les outils GPL alors qu'ils les utilisent. Ce que j'utilise sous licence BSD, je ne crache pas dessus.
[^] # Re: Une peccadille !
Posté par IsNotGood . En réponse à la dépêche La Cour de justice européenne confirme la sanction de Microsoft. Évalué à 2.
Ce n'est pas n'importe quoi, le procès dure depuis plusieurs années (il a débuté en 1998 ?). Le procès ne conserne pas que la France et pas que l'administration française.
Donc, c'est presque rien pour MS.
> Et je te rappelle qu'il y a aussi une astreinte de 3 millions d'euros par jour de retard
Ça ce n'est pas rien.
Pas ans ça fait 1 milliard d'¤. Ici MS c'est pris 500 millions d'¤ pour un procès de presque 10 ans. Maintenant c'est presque 20 fois plus. Si le 3 millions d'¤ par jour est justifié, alors les 500 millions d'¤ en presque 10 ans sont presque rien.
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal Fin de gcc dans les *BSD ?. Évalué à 1.
Désolé, mais le code est propriétaire :-(
J'avais fait un fichier .cpp minimum pour reproduire le bug (savoir spécifiquement ce qui ne marchait pas) mais j'ai foutu ce fichier à la poubelle. C'est ce fichier qui marchait nickel avec gcc et qui plantait toujours VC++. La vrai appli n'a pas été porté sous Linux (c'est quasi impossible).
Si tu vires tous les "public virtual", ça semble marcher sous VC++. Mais je n'ai plus ce que je veux et plein de duplication de donné très difficile à gérer. Donc ça semble marcher par j'ai fait peu de tests pour ce cas.
Autre problème avec VC++, je voulais un "constructeur virtuel". Un truc dans ce goût :
CMixerBmpD3D::Clone() = 0;
CMixerBmpD3DTex::Clone() ;
CMixerShot::Clone() = 0;
CMixerShotTex::Clone() ;
CMixerShotTex * pTex = ... ; // <= C'est un CMixerShotTex
f(pTex) ;
f(CMixerBmpD3D * pBmpD3D) {
CMixerBmpD3D * p = pBmpD3D->Clone() ; // Ici avec VC++ appel de CMixerBmpD3DTex::Clone() et non CMixerShotTex::Clone().
}
Marche nickel avec gcc, sucks avec VC++.
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal Fin de gcc dans les *BSD ?. Évalué à 2.
C'est vraiment casse couille.
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal Fin de gcc dans les *BSD ?. Évalué à 1.
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal Fin de gcc dans les *BSD ?. Évalué à 1.
Le dynamic_cast déclenche une exception __non_rtti_object (ou un truc dans ce goût) alors que c'est compilé avec /GR (stupidement non par défaut dans le compilateur VC++, ce qui ne respecte pas le standard ISO...).
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal Fin de gcc dans les *BSD ?. Évalué à 1.
Voilà ce qui ne marchait pas (une petite partie des entêtes) :
class CMixerBmpD3D : public virtual CBmpD3DDesc {
virtual ... = 0 ;
}
class CMixerBmpD3DSurf : public virtual CMixerBmpD3D {
}
class CMixerBmpD3DTex : public virtual CMixerBmpD3D {
}
class CMixerShot : public virtual CShotDesc, public virtual CMixerBmpD3D {
int entier_CMxierShot ;
virtual ... = 0 ;
void fonction_CMixerShot() {
entier_CMixerShot++ ;
}
class CMixerShotSurf : public virtual CMixerShot, public virtual CMixerBmpD3DSurf {
}
class CMixerShotTex : public virtual CMixerShot, public virtual CMixerBmpD3DTex {
}
Ce qui ne marchait était par exemple :
CMixerShotTex * pTex = new CMixerShotTex ;
CMixerShot * pShot = pTex ;
pShot->fonction_CMixerShot() ; // plantage.
Il n'y a pas forcément plantage à l'appel de la fonction mais plantage lors de "entier_CMixerShot++". Un affichage de "*this" dans le débuggeur donne du n'importe quoi alors que je suis dans une fonction membre ! C'est définitivement une erreur du compilateur.
Autre problème :
CMixerShotTex * pTex = new CMixerShotTex ;
CMixerShot * pShot = dynamic_cast<CMixerShot *>(pTex) ;
Le dynamic_cast n'est pas nécessaire. Mais si je l'utilise, pShot est égal à NULL. C'est encore définitivement une erreur du compilateur.
Autre problème :
CMixerShotTex * pTex = new CMixerShotTex ;
f(pTex) ;
f(CMixerShot * pShot) {
CMixerShotTex * pTex = dynamic_cast<CMixerShotTex *>(pShot) ; // retourne NULL alors que c'est un CMixerShotTex *
}
Pour régler le problème, j'ai viré CMixerShot (j'ai déplacé des données/fonctions) et tout regroupé dans CMixerBmpD3D.
> T'es sur que le probleme vient du compilo
Oui, j'ai vu une page web qui en parle mais je ne l'ai plus. Parfois VC++ n'arrive pas à déterminer le type d'un object.
Les "public virtual" sont nécessaires car il y a des données en commun entre CShotDesc et CMixerBmpD3D entre autre.
[^] # Re: Fin de gcc dans les *BSD
Posté par IsNotGood . En réponse au journal Fin de gcc dans les *BSD ?. Évalué à 1.
Juré, c'est une horreur. Certains se tapent la tête contre les murs, d'autres se font des saignées, etc...
[^] # Re: Errata
Posté par IsNotGood . En réponse au journal Les distributions linux nouvelle génération. Évalué à 2.
Je dis ça, je dis rien... mais le boss d'Ubuntu dit qu'Ubuntu n'est pas pour les masses mais pour les "amateurs".
Si lui le dit, ça passe comme une lettre à la poste, si je le dis ça fait scandale. Mais c'est la vérité.
Red Hat est grosso-modo sur la même longueur d'onde qu'Ubuntu (du moins son boss).
> c'est vraiment pas le problème d'avoir des distros "pour les masses"
Ce n'est actuellement pas prioritaire, mais c'est un réel problème, un travail très long.
[^] # Re: Errata
Posté par IsNotGood . En réponse au journal Les distributions linux nouvelle génération. Évalué à 1.
Désolé pour la brutalité de la réponse, mais tu n'as rien compris.
Ce qu'il faut pour "les masses", c'est un truc type RHEL (ou Novell, qu'importe). Quelque chose avec un long support et une API source et binaire stable, etc.
Les distributions communautaires ne fournisse pas de telle distribution. Ou il n'y en a qu'une qui le fournit et c'est Centos. Mais ça ne compte pas car c'est un "bête" clone de RHEL.
Debian n'offre que quelques mois de support lorsqu'un nouvelle release sort. Sarge n'est plus maintenu depuis longtemps.
> Mais avec ce raisonnement, le développeur qui aime la façon de faire gentoo, va utiliser gentoo. Il ne participera pas au développement de la distro "pour les masses",
Ce n'est absolument pas ce que j'ai dit. La distribution "pour les masses" sera gérée par Red Hat par exempre (ou autre, qu'importe). Mais il n'y aura qu'un travail de packaging et de test. Les développements seront upstream et dans les distributions "communautaires" type Gentoo, Fedora, OpenSuse, etc...
RHEL n'innove pas, c'est seulement l'application de développements de la communauté du libre.
Le rôle des distributions communautaires, même avec une RHEL (ou autre) pour les masses, reste crucial. Ce sont elles (et la communauté du libre dans son ensemble) qui fait/fera le succès d'un truc type RHEL "pour les masses". Et comme RHEL depend de la communauté du libre, Red Hat investira en recherche et développement dans les distributions communautaire (Fedora typiquement) et les développement upstream. Il n'y aura presque rien en recherche et développement dans RHEL.
> Tu penses que Linux a besoin d'une distro non communautaire pour percer. Je pense que ce qui fait la différence de linux, ce n'est pas ça supériorité technique, c'est sa philosophie, et entre autre la communauté.
Et ?
J'en suis très content pour toi.
Ce que tu pays avec RHEL, c'est un service. Le service de maintenir un OS sans casser la compatibilité source et binaire, tu pays des tests, etc...
Tu payes un service, ça ne va pas contre le libre.
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal Les distributions linux nouvelle génération. Évalué à 2.
Et alors ?
De plus, ce n'est pas le cas. Unstable/testing de Debian, ce n'est pas Fedora, c'est Rawhide (branche développement de Fedora). Debian "stable" est plus proche de Fedora "finale" que de RHEL.
Il n'y a pas d'équivalent RHEL dans Debian. La dernier Debian stable est Eth et Sarge n'est plus maintenu. RHEL 2.1, 3, 4 sont encore maintenues (et pour longtemps). En gros lorsqu'une Debian sort, la version précédente est maintenue moins d'un ans (8 mois pour Sarge si j'ai bonne mémoire). Pour RHEL c'est minimum 7 ans de durée de vie. Si la version suivante sort au bout de 18 mois (ce qui est typiquement le cas), il reste 5 ans et demi. Rien à voir avec les 8 mois de Debian.
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal Fin de gcc dans les *BSD ?. Évalué à 1.
> class Bar : public virtual Bob, public virtual Foo
Tes virtual ne servent à rien dans ton exemple.
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal Fin de gcc dans les *BSD ?. Évalué à 2.
Notons que la compatibilité sur tous les gcc 4 n'est pas assurée. Par exemple ce qui est compilé avec Fedora 5 ne peut tourner sur Fedora 4. Ce n'est pas un problème de version de librairie mais de compilateur/édition de lien. Mais ce n'est pas un problème car pratiquement personne ne l'a remarqué :-)
[^] # Re: Errata
Posté par IsNotGood . En réponse au journal Les distributions linux nouvelle génération. Évalué à 2.
Sa percée doit être un conséquence de son excellence. Il ne faut pas prendre le problème à l'envers.
La percée de Linux ne passera pas par une distribution qui doit être stable, dynamique et adaptée aux développeurs. Un tel truc n'existe pas et n'existera jamais.
Quand je lis que Fedora est une distribution Desktop qui remplace RHL, je me marre. C'est faux. Fedora est une distribution pour les "enthousiastes" du libre, pour la communauté du libre. Le linux pour les masses ne sera pas incarné par Fedora, ni Ubuntu ni OpenSuse ni Mandriva.
Le linux pour les masses sera "incarné" par une distribution stable (pas un truc qui change tous les 6 mois comme Fedora ou Ubuntu). Ça pourrait être une RHEL Desktop. Et la, il ne faut pas paniquer ! Les Fedora/Ubuntu/Gentoo/Debian/etc auront toujours un rôle major. Une RHEL Desktop (ou Novell ou Ubuntu+, qu'importe) ne sera pas développé sur et pour RHEL mais sur et pour Fedora/Ubuntu/etc. RHEL Desktop sera peut-être populaire, mais son avenir sera entre les mains de la communauté (Fedora/etc).
Le rôle de RHEL sera de packager, tester, certifier auprès d'Adobe, etc...
Donc, si on parle de percée de Linux, il faut, à mon avis, distinguer distribution pour les masses (l'utilisateur lambda) et distribution communauté (pour les enthousiaste qui veulent les dernières innovations, les développeurs, etc).
Tu veux qu'une distribution fasse les deux. A mon avis :
1 - ce n'est pas possible
2 - c'est un mauvais objectif
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal Les distributions linux nouvelle génération. Évalué à 1.
Ton problème est "universel". Red Hat l'a. La solution de Red Hat est RHEL et Fedora. Peut-être que la solution/réflexion de Red Hat fera avancé ta réflexion. Red Hat n'est pas le seul à faire ça mais il est quasiment le premier à le faire et de façon très agressive. Ça a débuté avec RHL 2.1 AS puis Fedora.
Je te conseille de bien analyser le modèle RHEL/Fedora/communauté upstream. C'est riche d'enseignement et aussi si tu bosses sous/pour Debian.
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal Les distributions linux nouvelle génération. Évalué à 2.
Oui, rien n'est parfait.
De plus, il ne faut pas mélanger fiabilité et stabilité. Fedora n'est pas stable, mais est fiable. Pour du desktop on veut du fiable, pour du serveur on veut du fiable et stable (pas de changement de version de php par exemple).
> La encore, le modèle de développement n'est pas optimal puisqu'il ne convient pas au plus grand nombre.
Tu n'es pas claire. De quoi tu parles ? Quel est ta préoccupation ?
Si tu parles en tant que développeur web, RHEL est nickel. C'est fiable et stable.
Si tu parles en tant que développeur libre, Fedora (ou Gentoo) est nickel. C'est une distribution qui veut bosser avec l'upstream, y participer. Tout le contraire de RHEL. Si t'as un projet super existant tu peux avoir un développeur Fedora qui frappe à ta porte afin de bosser ensemble sur une nouvelle fonctionnalité. Ça n'arrive pas avec RHEL.
Lève tes contradictions. Tu veux du dynamique (changement de version) et du stable (pas de changement de version).
Ce n'est pas possible et c'est pour celà qu'il y a RHEL et Fedora. RHEL est stable et Fedora dynamique (et fiable).
Et tu parles de quoi ?
Du modèle de développement ou de maintenance ?
Le modèle de maintenance de RHEL et Fedora sont très différents. RHEL ne fait que des backport pour assurer la compatibilité source et binaire (et aussi au niveau des drivers/module noyau). Fedora ne se soucis pas (ou assez peu) de la compatibilité source et binaire.
Les tests sur RHEL sont très formalisés avec des tests d'Oracle, Dell, etc...
Les tests sur Fedora sont plus souples/empiriques. Si ça marche pour un panel d'utilisateur significatif, ben Fedora sort la mise à jour. Si ça ne marche pas pour un client, ben RHEL ne sort pas la mise à jour.
Ce qui est fait par RHEL et qui n'est pas du développement (mais de la maintenance/support) coûte très cher. Ce n'est pas un travail très innovant ou exitant et c'est pour ça qu'il est cher. Très peu de développeur upstream font des patch backport, les tests, etc... RHEL le fait et c'est cher. Fedora ne le fait pas et c'est gratuit.
RHEL n'a pas de modèle de développement (pour caricaturer). Fedora en a un et c'est "priorité à l'upstream".
Si tu veux du dynamic et stable, ça n'existe pas et ça n'existera jamais. C'est pour celà qu'il y a RHEL ET Fedora. RHEL (du moins son "développement") ne peut exister sans Fedora.
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal Les distributions linux nouvelle génération. Évalué à 3.
http://fedoraproject.org/wiki/Objectives
# Re:
Posté par IsNotGood . En réponse au journal Les distributions linux nouvelle génération. Évalué à 4.
Red Hat Linux n'existe plus et depuis longtemps. Il y a RHEL (Red Hat Entreprise Linux) et Fedora.
RHEL n'a pas vraiment de "modèle de dléveloppement". RHEL n'est pas développé, c'est un fork de Fedora.
Pour RHEL 5, c'est un fork de FC6. Puis RHEL 5 est paufiné/maintenu (et non développé sauf pour quelques cas bien précis).
Donc pour Red Hat le développement est fait dans Fedora. Et pour Fedora, ce n'est pas le modèle figé. Fedora est même très agressif. Une version "stable" de Fedora peut avoir une mise à jour vers une version majeur d'un logicel. FC6 est sorti avec un noyau 2.6.18, puis mise à jours vers 2.6.19, 2.6.20, 2.6.21, 2.6.22 et 2.6.23 est déjà en cours de maturation. Fedora veut être au plus proche de la version upstream et les corrections de sécurité sont dans la mesure du possible des mises à jour vers la version upstream.
Le modèle de Fedora est très très dynamique.
[^] # 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é à 5.
Là n'est pas le coeur du problème. Il y a des règles, MS les viole. MS pourrait faire des abus de position dominante et perdre du pognon que ça ne changerait rien pour la comission (sauf le niveau de l'amende).
Si MS n'avait pas de pognon à gagner en violant les règles, MS n'aurait pas fait trainer le procès.
Même avec cette énorme amende, MS gagne à tricher (et largement).
Il n'y a que l'astreinte de 3 millions par jour qui va calmer MS.
Quand le crime paye....