> Même sur GNA, il y a plus d'utilisateurs que d'employés chez RedHat et à mon avis, le coeur du libre, il est là, pas chez RedHat.
Sur ce point, globalement, je suis entièrement d'accord.
Tes stats sont "gentilles" (je ne mets pas en cause les chiffres), mais il y a contributeur et contributeur. Je suis un contributeur. Mais mes contributions n'ont rien à voir avec les contributions de Alan Cox, Dave Jones, etc... Le nombre n'est pas très significatif. Morton a déjà dit que 98 % de Linux était développé par des employés de société (IBM, Intel, Oracle, Red Hat, etc). 98 % du code de Linux est fait par 10 % des contributeurs.
> RedHat là dedans, ce n'est pas grand chose, juste une entité commerciale qui participe à sa manière au libre.
Ce n'est pas grand chose dans le sens où il n'est pas le centre de gravité. C'est totalement juste.
Ce n'est pas Dieu le père ou le soleil. Mais sa contribution n'est pas une goute d'eau. Red Hat n'est pas le "patron" du libre, mais a une influence significative. Il faut le reconnaitre. Comme Debian tu pourrais dire. Ben oui. Jamais je ne dirais que Debian ou équivalent n'est qu'une goute d'eau.
> Bref, je suis plus marri par le départ prochain de M. Spevack
Fedora est un projet qui ne sera jamais à maturité. C'est un projet qui doit bouger, qui doit toujours promettre plus qu'il ne peut réellement faire. C'est le seul moyen pour en faire un "bouillon" où des idées et des fortes personnalités sortiront.
Quelque soit le leader, il ne peut pas gérer totalement Fedora. C'est impossible. Spevack a fait de formidables avancées mais des points ont été un peu négligé (ceci dit sans critiquer Spevack). Du sang neuf, d'autres compétences, une autre vision, d'autres priorités ne peuvent pas faire de mal à Fedora à priori.
NB : Je ne pousse pas Spevack vers la sortie :-) C'est le "bazard" Fedora qui veut ça.
> ça va être plus dur de lui trouver un successeur à sa hauteur. :)
Fedora trouvera. Ça sera différent.
Saluons Fedora et Spevack pour avoir fait cette annonce très tôt. Le choix d'un nouveau leader ainsi que les nouvelles priorités va se faire sans précipitation et la transition au mieux.
> Des "LTS" sous forme de Red Hat qui sont quand même 'achement plus sérieuses mais pas très dessquetopppe.
RHEL c'est une Fedora. Donc c'est autant dessquetopppe que Fedora.
La dernière RHEL est basée sur FC6, la prochaine sera probablement basée sur F10.
> Mandriva : idem sauf qu'une version est supportée 1 an, et pas de LTS.
Il y a Mandriva Corporate Server/Desktop.
Il me semble qu'on oublie souvent d'envisager Centos pour le Desktop et le semi-geek.
Pour ce qui est de Debian, si Debian sort tous les 1 ans ou 18 mois et avec une solide procédure de mise à jour, ça peut devenir un système séduisant pour beaucoup de semi-geek.
> Dans ce cas, tu n'argumentes pas ta conclusion : tu livres ta vision du futur.
Ce n'est pas une inspiration "divine".
Si tu dis qu'à l'avenir le changement est qu'Ubuntu va stagner, il faut déjà démontrer que Ubuntu a progressé. C'est la raison de l'utilisation de google trend.
Je montre que Fedora est perte en popularité. Fedora a le mérite d'offrir des statistiques assez fiables. Il serait bien venu qu'Ubuntu et d'autre le fasse aussi. Je pense (car je ne l'ai pas "démontré") que quasiment toutes les distributions sont en perte de vitesse.
Je dis que cette perte de vitesse des distributions (sauf Ubuntu) va s'arrêter.
Bref, c'est argumenté (probablement pas assez). Je ne vais pas remettre toute l'argumentation ici. Malheureusement je n'ai pas de machine à voyager pour démontrer que mes prévisions sont justes. Et je ne vais pas m'engager sur mes prévisions qui sont fait plus part divertissement qu'autre chose.
Je serais très très très heureux que tu utilises ta machine à voyager dans le temps pour démontrer que mes prévisions sont fausses. C'est gentil de me reprocher mon manque d'argument, mais maintenant c'est à vous d'argumenter.
> Je me demande si ca a vraiment un sens de comparé fedora et ubuntu dans leurs utilisations. Le public n'est à mon avis pas le même.
Je dirais le public visé. On ne peut mettre les gens dans une boite uniquement. Des gens sont sous Fedora, passe à Ubuntu, puis Debian, puis Mandriva, puis Centos...
Il y a des recoupements entre les utilisateurs Ubuntu et Fedora. Forcément. Mais ces distributions ne sont pas en concurrence car les objectifs ne sont pas les même (comme tu le dis).
Fedora ne sera pas en concurrence avec Ubuntu. C'est pour moi clair. Mais une future RHEL 6 Desktop ou SLES 11 le sera plus frontalement. Lorsque Linux ne sera plus un truc de "geek", lorsqu'il aura plus de 10 % d'utilisateur, le point d'entré ne sera plus Ubuntu, mais des distributions plus "professionnelles" (long support, stabilité API/ABI, etc). Certes, Ubuntu peut s'adapter et donc l'histoire n'est pas écrite.
> Au contraire, ubuntu avait conservé l'ancier driver
Pour info, Fedora fournissait aussi l'ancien driver.
Prend ce journal pour un divertissement.
Seul les faits comptent.
Effectivement je peux me tromper. Je le dis plus d'une fois. Je n'ai pas imaginé que le succès d'Ubuntu serait aussi fulgurant et fort, je ne pensais pas que Fedora continurait de baisser en popularité. Deux erreurs que je reconnais sans problème.
Partant de là, tu peux mettre en doute mes prévisions. Mais moi j'argumente. Pas toi.
Ce sont seulement des prévisions. Libre à toi de me coller une étiquette d'expert.
> Si tu t'appuies sur le trend de Google pour établir ta concluion, c'est plutôt éloquent.
Je ne l'ai pas utilisé pour faire ma conclusion, mais pour argumenter. Le constat est que Ubuntu grimpe actuellement. Et je dis que Ubuntu ne va plus grimper mais stagner (donc je ne dis pas ce que "dis" google trend).
Oui mais les travailleurs en France (ou ailleurs) sont soumis au droit français et donc aux charges française :-)
Faudrait aussi voir si Red Hat France n'est pas une boite française :-)
Sinon, effectivement j'aurais aimé que Red Hat soit basé en France. Évidemment.
Donc en mode Xen (j'y reviens plus loins).
C'est actuellement quasiment la même chose. Les différences entre Xen et KVM sont génées par libvirt (utilisé par virt-manager). Actuellement RHEL 5.x n'utilise que Xen. Les dernières versions de Fedora utilise KVM par défaut, non car actuellement KVM est forcément mieux que Xen, mais seulement car KVM (et paravirt_ops) est vu comme l'avenir de la virtualisation et Fedora est principalement dédié à la communauté des développeurs. Bien que Red Hat ne communique pas sur ça, il y a fort à parier que RHEL 6 va passer à KVM (au moins par défaut).
> Après c'est peut-etre juste les tutoriaux qui sont de mauvaise foi.
Peut-être mais je ne crois pas. Il ne doivent pas être à jour.
Le problème de l'installation en mode paravirtualisation est que l'installeur (qui est sur le CD par exemple) doit reconnaitre le matos qu'on lui propose. Tous les installeurs n'était pas au fait de Xen à ses début. Autre problème, c'est l'affichage, etc... Au début de Xen, il n'y avait pas de périphérique pour faire l'affichage. Donc on ne pouvait utiliser l'installeur et il fallait utiliser des "hacks". On pouvait faire tourner une installation de Linux mais pas son installeur.
J'imagine que les "debootstraop ou rpmstrap" sont (ou étaient) là principalement pour contourner ce problème.
> Parce que ton exemple montre l'utilisation dans un cadre 'support hardware'.
Certes, mais ça va devenir hypra commun dans quelques années et la paravirtualisation de Xen va devenir obsolète (au moins pour les serveurs).
Notons que la transition va se faire dans la douceur (plus ou moins). Fedora va mettre les bouchées doubles pour que paravirt_ops de F9 (qui n'aura pas XenSource) supporte Xen dom0 et domU. Donc si tu as une machine virtuelle qui tourne sous Xen (domU), elle tournera aussi sur une serveur qui n'utilise pas XenSource.
Le plan sur la virtualisation pour F9 (jugé très ambitieux pour ne pas dire risqué) : http://fedoraproject.org/wiki/Features/XenPvops
> > D'après Max Spevack, il semblerait que Jim Whitehurst utiliserait déjà Fedora.
>
> Tant mieux, mais je ne suis pas convaincu que ce soit très important :-)
Ooops. Je veux dire que ce n'est pas important que ça soit Fedora ou autre ou même qu'il utilise Linux ou non. Ce qui compte est qu'il comprenne le modèle du libre, son fonctionnement global, ses bénéfices. Il doit être "sensible" à tout ça et non chercher à appliquer des solutions du monde propriétaire car ça marche dans le monde propriétaire. Évidemment, s'il utilise Fedora (notamment car c'est une distribution orienté communauté du libre) avant même être embauché chez Red Hat, c'est un excellent signe.
> D'après Max Spevack, il semblerait que Jim Whitehurst utiliserait déjà Fedora.
Tant mieux, mais je ne suis pas convaincu que ce soit très important :-)
Je ne pense pas qu'il va "révolutionner" Red Hat, son coeur de métier et son expertise, dans les premiers mois.
Je ne serais pas étonné qu'il soit quasi invisible les premiers mois.
Red Hat a eu une croissance soutenue depuis plusieurs années. Red Hat a encore un gros potentiel de croissance. Mais ça doit être géré au niveau organisation et personnel. Par exemple Red Hat c'est maintenant environ 3 000 employés !
les perceptives de Red Hat a moyen terme sont claires :
- virtualisation
- linux automation
- jboss
- RHX
Je vois une réorganisation de Red Hat (pas ce que fait Red Hat) afin de se préparer les "montées en charge" à venir. Puis une profonde réflexion pour définir des plans à (très) long terme. La question d'investir le marché du desktop sera évidemment abordé en profondeur.
Donc, pour ma part, il faut a Red Hat aujourd'hui un excellent "gestionnaire" pour mettre en place une solide organisation. Mais Red Hat n'est pas une boite comme les autres, il faudra préserver ses spécificités qui font son succès, il faudra beaucoup d'imagination et d'intelligence.
Je ne crois pas que le couple RHEL/Fedora soit impacté significativement.
Par contre on va peut-être voir plus de moyen pour la communcation autour de Fedora (et RHEL Desktop). Même si le marché du desktop est encore assez ridicule, c'est dès aujourd'hui qu'il faut placer ses pions et notamment au niveau de l'image.
C'était mon sentiment. Je suis très peu inquiet à moyen terme.
Parce je connais X dans les grandes lignes et avec X tu peux avoir des fenêtres qui sont des textures. Côté client ce n'est pas forcément une texture, mais côté serveur ça ne pose pas de problème. C'est principalement X11 qui "cause" à la carte graphique.
Ce n'est pas Compiz qui fait la transparence, c'est le serveur X11. Compiz "configure" le serveur X11 (lui dit quel est la transparence de telle ou telle fenêtre, etc).
Effectivement on n'est pas obligé d'utiliser OpenGL pour faire de la transparence. On n'est pas obligé non plus d'utiliser OpenGL pour faire de la 3D. Mais sans OpenGL les performances sont lamentables.
Juste un petit exemple. 4 fenêtres en transparence de 1600x1200 en (A)RGB32 : presque 30 Mo !
La transparence est appliquée en cascade.
Lecture des deux premières fenêtre => 15 Mo.
Résultat temporaire => 7 Mo.
Lecture du résultat temporaire et lecture de la troisième fenêtre => 15 Mo
....
Lecture = 15 *3 = 45 Mo
Ecriture = 7 * 3 = 21 Mo
Soit pour une image = 66 Mo !
Si une fenêtre est une vidéo à 25 fps et qu'elle est au fond on a au minimum => 66*25 = 1,6 Go/s !
Certes les derniers CPU peuvent peut-être supporter ça. Mais c'est très très limite.
Les cartes graphique savent bouffer ça à une vitesse "terrifiante".
Sans parler de 3D, l'autre chose que font les cartes graphiques à une vitesse "terrifiante", c'est le redimensionnement d'image et l'antialiasing (qui peut être très très coûteux si fait avec le cpu de la carte mère).
Donc OK, OpenGL n'est pas nécessaire pour la transparence. Mais il faut être con pour s'en passer.
NB : Je connais bien Direct3D (je développe avec) et je ne suis pas naïf dans ce domaine.
Tu veux que lergonomie englobe l'esthétique. Bien.
Fais ta définition des termes à toi. Mais ne l'impose aux autres. Ergonomie et esthétique n'ont rien à voir (voir les définitions qu'on trouve dans les dicos).
> C'est quoi le lien entre utiliser OpenGL dans Gtk et faire des fenêtres transparentes ?
C'est pour faire de la transparence par pixel ou par widget. Compiz c'est par fenêtre.
> Parce que les fenêtres transparentes, c'est le composite manager et un canal alpha sur la fenêtre, c'est tout.
Tu peux aussi "dessiner" le contenu des fenêtres" en ARGB (alpha par pixel). Ainsi la transparence n'est plus pour l'ensemble de la fenêtre, mais par pixel. Les quelques copies d'écran le montre clairement.
> Et actuellement, seuls les pilotes nvidia supportent la redirection d'un rendu OpenGL.
J'en doute. Ou alors tu parles de Linux uniquement.
Enfin, tu peux faire un rendu dans un texture, puis utiliser cette texture lors du render de l'écran. Ça tout le monde peut le faire je crois.
La redirection de rendu, c'est pour les trucs "tordus" type reflets, etc...
> En clair : votre fenêtre dessinée en OpenGL n'est gérable par un composite manager qu'avec les pilotes nvidia.
Non.
La fenêtre n'est qu'une texture. Ici la particularité est que la texture est remplis avec un "rendu" (la texture est une render target). Puis la texture (parmis d'autres) est utilisé pour faire l'affichage à l'écran. Il n'y a pas de rendu dans la texture pendant le rendu à l'écran. Donc quasiment tous les drivers doivent le supporter.
> Le problème est que quand on parle de signature électronique le standard c'est plutôt X.509 utilisé avec CMS http://en.wikipedia.org/wiki/Cryptographic_Message_Syntax et la multitude de protocoles qui en dérivent (S/MIME par exemple pour le mail).
Gnupg supporte tout ça, c'est la version 2 de gnupg. En général c'est dans le paquet gnupg2. Ce n'est pas un remplaçant complet de gnupg (v1), il doit être considéré comme un complément. Donc il n'y a pas de problème à installer gnupg (v1) avec gnupg2.
gpgsm is a tool similar to gpg to provide digital encryption and signing servicesd on X.509 certificates and the CMS protocol. It is mainly used as a backend for S/MIME mail processing. gpgsm includes a full features certificate management and complies with all rules defined for the German Sphinx project.
Pour info, gnupg peut aussi chiffrer sans clée public/privée.
C'est l'option "--symmetric".
Techniquement il est possible d'utiliser gnupg pour les partitions chiffrés, mais ça serait horriblement lent et de toute manière gnupg n'a pas été prévu pour ce cas.
> Savez vous que 90 % du business OpenSource s'effectue aux états-unis
Sûr ?
En passant toujours, Red Hat emploi beaucoup de monde en Europe, Inde, etc...
Alan Cox qui est sous contrat Red Hat bosse en Europe par exemple.
En passant, une petite vidéo d'Alan Cox dans sa région : http://www.redhatmagazine.com/2007/12/18/video-alan-cox-and-(...)
C'est un point que Szulik a souvent souligné. Indiquant aussi le haut niveau des développeurs européens. Je ne serais pas étonné que Red Hat ait plus de développeur en Europe qu'aux USA.
Certe la boite est basée aux USA, mais l'argent gagné par les développeurs est dépensé en Europe (ou ailleurs). Comme quoi la mondialisation ce n'est pas le mal absolu.
> Sous NetBSD, tu prend ton iso x86, tu lui fais pointer dessus, tu prend le kernel Xen_domU_install, tu fais pointer dessus et tu lance.
Tu peux faire pareil avec Linux. Évidemment virt-manager le supporte.
Libvirt/virt-manager est principalement, voire exclusivement, développé par Red Hat. Si tu as vu la vidéo, tu peux imaginer des scénarios où les machines virtuelles sont construites en 3 ou 5 minutes de façon automatique. La cible de Red Hat est actuellement les serveurs. Ceci combiné à lvm et GFS2 peut donner ça (amazon EC2) : http://www.redhat.com/about/news/prarchive/2007/amazon.html (actuellement en public beta)
C'est-à-dire un fournisseur de machine virtuelle. Tu paies pour la quatité de cpu, mémoire et disque que tu utilises. Tout peut être changé à la volée.
Red Hat est très ambitieux dans ce domaine.
Pour un usage plus desktop (typiquement une installation d'un autre OS depuis les CD), c'est supporté : http://www.phoronix.com/scan.php?page=article&item=656&a(...)
C'est une "démo" de Fedora 7, une version de test.
Le test a été fait avec KVM (Fedora, et donc Red Hat/RHEL, va petit à petit abandonner Xen).
Le développement de la virtualisation est très dynamique dans le monde Linux.
Le HIG de Gnome ou n'importe quel HIG ne parle pas d'esthétique.
Les personnes qui s'occupent du graphisme (esthétique) sont très rarement les même qui s'occupent de l'ergonomie.
Que toutes les applis de Gnome respectent le HIG est un plus pour le confort. Les interface sont plus rapidement conpréhensibles, etc... Mais c'est souvent au détriment de l'esthétique. Considère Totem qui respecte le HIG de Gnome et donc a un haut soucis d'ergonomie. Ben il n'est pas très esthétique par rapport à d'autres lecteurs. L'esthétique a été sacrifié. Ou est moins prioritaire que l'orgonomie. Donc ils ne vont pas de paire.
L'esthétique ce n'est qu'une affaire de goût. Je peux être efficace même avec un theme graphique très moche (du moment qu'il est lisible).
L'ergonomie peut être presque mesuré (nombre de clique, nombre d'éléments que l'utilisateur doit connaitre, etc).
L'esthétique ne peut être mesuré. Au mieux on peut avoir son niveau de popularité. Notons qu'il dépend des cultures, des modes, etc... Ce qui était moche hier peut-être joli aujourd'hui, ...
Par contre, l'esthétique fait souvent parti du design. Mais alors on n'est plus uniquement dans le fonctionnel/ergonomie. Dans l'automobile, esthétique et design vont quasi de paire. Car on ne vend pas de voiture uniquement sur l'aspect fonctionnel/ergonomique, mais beaucoup sur le style.
Pour les camions, c'est une autre histoire. Le confort et donc ergonomie est primoridale puis des gens y travail 8 heures par jours. Ben c'est moche. Regarde l'intérieur d'un camion et compare avec l'intérieur d'une voiture.
Notons aussi les bureaux dans les ateliers. L'ergonomie est importante puisque des gens y travaillent. Mais c'est moche. C'est moins moche pour certains bureaux mais seulement car on y reçoit souvent des clients. L'image de la société y est en parti en jeu.
Non. Il y a des themes pour mal-voyant, il ne cherche pas à être esthétique, mais ergonomique. C'est-à-dire permettre au mal-voyant de travail dans le meilleur confort.
Va dans une usine, l'ergonomie y est prioritaire. Ben les machines, sont vertes, oranges, il y a du jaune, du blanc, du rouge, c'est moche avec 0 soucis esthétique. Mais c'est très claire.
Vim dans une console peut être considéré comme ergonomique pour l'utilisateur qui le maitrise. Mais niveau esthétique c'est 0.
[^] # Re: VLC sous Linux
Posté par IsNotGood . En réponse à la dépêche L'ensemble des sessions de JRES en vidéo à la demande. Évalué à 1.
Et pas seulement avec VLC.
[^] # Re: équivalent de Centos
Posté par IsNotGood . En réponse au journal Matthew Szulik démissionne. Évalué à 1.
Sur ce point, globalement, je suis entièrement d'accord.
Tes stats sont "gentilles" (je ne mets pas en cause les chiffres), mais il y a contributeur et contributeur. Je suis un contributeur. Mais mes contributions n'ont rien à voir avec les contributions de Alan Cox, Dave Jones, etc... Le nombre n'est pas très significatif. Morton a déjà dit que 98 % de Linux était développé par des employés de société (IBM, Intel, Oracle, Red Hat, etc). 98 % du code de Linux est fait par 10 % des contributeurs.
> RedHat là dedans, ce n'est pas grand chose, juste une entité commerciale qui participe à sa manière au libre.
Ce n'est pas grand chose dans le sens où il n'est pas le centre de gravité. C'est totalement juste.
Ce n'est pas Dieu le père ou le soleil. Mais sa contribution n'est pas une goute d'eau. Red Hat n'est pas le "patron" du libre, mais a une influence significative. Il faut le reconnaitre. Comme Debian tu pourrais dire. Ben oui. Jamais je ne dirais que Debian ou équivalent n'est qu'une goute d'eau.
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal Matthew Szulik démissionne. Évalué à 1.
Fedora est un projet qui ne sera jamais à maturité. C'est un projet qui doit bouger, qui doit toujours promettre plus qu'il ne peut réellement faire. C'est le seul moyen pour en faire un "bouillon" où des idées et des fortes personnalités sortiront.
Quelque soit le leader, il ne peut pas gérer totalement Fedora. C'est impossible. Spevack a fait de formidables avancées mais des points ont été un peu négligé (ceci dit sans critiquer Spevack). Du sang neuf, d'autres compétences, une autre vision, d'autres priorités ne peuvent pas faire de mal à Fedora à priori.
NB : Je ne pousse pas Spevack vers la sortie :-) C'est le "bazard" Fedora qui veut ça.
> ça va être plus dur de lui trouver un successeur à sa hauteur. :)
Fedora trouvera. Ça sera différent.
Saluons Fedora et Spevack pour avoir fait cette annonce très tôt. Le choix d'un nouveau leader ainsi que les nouvelles priorités va se faire sans précipitation et la transition au mieux.
[^] # Re: Reprenons...
Posté par IsNotGood . En réponse au journal Ubuntu a finit de manger son pain blanc ?. Évalué à 1.
RHEL c'est une Fedora. Donc c'est autant dessquetopppe que Fedora.
La dernière RHEL est basée sur FC6, la prochaine sera probablement basée sur F10.
> Mandriva : idem sauf qu'une version est supportée 1 an, et pas de LTS.
Il y a Mandriva Corporate Server/Desktop.
Il me semble qu'on oublie souvent d'envisager Centos pour le Desktop et le semi-geek.
Pour ce qui est de Debian, si Debian sort tous les 1 ans ou 18 mois et avec une solide procédure de mise à jour, ça peut devenir un système séduisant pour beaucoup de semi-geek.
[^] # Re: Google Trend
Posté par IsNotGood . En réponse au journal Ubuntu a finit de manger son pain blanc ?. Évalué à 1.
Ce n'est pas une inspiration "divine".
Si tu dis qu'à l'avenir le changement est qu'Ubuntu va stagner, il faut déjà démontrer que Ubuntu a progressé. C'est la raison de l'utilisation de google trend.
Je montre que Fedora est perte en popularité. Fedora a le mérite d'offrir des statistiques assez fiables. Il serait bien venu qu'Ubuntu et d'autre le fasse aussi. Je pense (car je ne l'ai pas "démontré") que quasiment toutes les distributions sont en perte de vitesse.
Je dis que cette perte de vitesse des distributions (sauf Ubuntu) va s'arrêter.
Bref, c'est argumenté (probablement pas assez). Je ne vais pas remettre toute l'argumentation ici. Malheureusement je n'ai pas de machine à voyager pour démontrer que mes prévisions sont justes. Et je ne vais pas m'engager sur mes prévisions qui sont fait plus part divertissement qu'autre chose.
Je serais très très très heureux que tu utilises ta machine à voyager dans le temps pour démontrer que mes prévisions sont fausses. C'est gentil de me reprocher mon manque d'argument, mais maintenant c'est à vous d'argumenter.
[^] # Re: Fedora / Ubuntu des publics différents
Posté par IsNotGood . En réponse au journal Ubuntu a finit de manger son pain blanc ?. Évalué à 1.
Je dirais le public visé. On ne peut mettre les gens dans une boite uniquement. Des gens sont sous Fedora, passe à Ubuntu, puis Debian, puis Mandriva, puis Centos...
Il y a des recoupements entre les utilisateurs Ubuntu et Fedora. Forcément. Mais ces distributions ne sont pas en concurrence car les objectifs ne sont pas les même (comme tu le dis).
Fedora ne sera pas en concurrence avec Ubuntu. C'est pour moi clair. Mais une future RHEL 6 Desktop ou SLES 11 le sera plus frontalement. Lorsque Linux ne sera plus un truc de "geek", lorsqu'il aura plus de 10 % d'utilisateur, le point d'entré ne sera plus Ubuntu, mais des distributions plus "professionnelles" (long support, stabilité API/ABI, etc). Certes, Ubuntu peut s'adapter et donc l'histoire n'est pas écrite.
> Au contraire, ubuntu avait conservé l'ancier driver
Pour info, Fedora fournissait aussi l'ancien driver.
[^] # Re: \o/ Un devin!
Posté par IsNotGood . En réponse au journal Ubuntu a finit de manger son pain blanc ?. Évalué à 1.
Seul les faits comptent.
Effectivement je peux me tromper. Je le dis plus d'une fois. Je n'ai pas imaginé que le succès d'Ubuntu serait aussi fulgurant et fort, je ne pensais pas que Fedora continurait de baisser en popularité. Deux erreurs que je reconnais sans problème.
Partant de là, tu peux mettre en doute mes prévisions. Mais moi j'argumente. Pas toi.
Ce sont seulement des prévisions. Libre à toi de me coller une étiquette d'expert.
> et de vendre du papier^W^W^W^W^W.
Heureusement qu'il y a les "^W".
[^] # Re: Google Trend
Posté par IsNotGood . En réponse au journal Ubuntu a finit de manger son pain blanc ?. Évalué à 1.
Je ne l'ai pas utilisé pour faire ma conclusion, mais pour argumenter. Le constat est que Ubuntu grimpe actuellement. Et je dis que Ubuntu ne va plus grimper mais stagner (donc je ne dis pas ce que "dis" google trend).
[^] # Re: En passant...
Posté par IsNotGood . En réponse au journal Matthew Szulik démissionne. Évalué à 1.
Faudrait aussi voir si Red Hat France n'est pas une boite française :-)
Sinon, effectivement j'aurais aimé que Red Hat soit basé en France. Évidemment.
[^] # Re: Ca bouge !
Posté par IsNotGood . En réponse à la dépêche Sortie de NetBSD 4.0. Évalué à 1.
Donc en mode Xen (j'y reviens plus loins).
C'est actuellement quasiment la même chose. Les différences entre Xen et KVM sont génées par libvirt (utilisé par virt-manager). Actuellement RHEL 5.x n'utilise que Xen. Les dernières versions de Fedora utilise KVM par défaut, non car actuellement KVM est forcément mieux que Xen, mais seulement car KVM (et paravirt_ops) est vu comme l'avenir de la virtualisation et Fedora est principalement dédié à la communauté des développeurs. Bien que Red Hat ne communique pas sur ça, il y a fort à parier que RHEL 6 va passer à KVM (au moins par défaut).
> Après c'est peut-etre juste les tutoriaux qui sont de mauvaise foi.
Peut-être mais je ne crois pas. Il ne doivent pas être à jour.
Le problème de l'installation en mode paravirtualisation est que l'installeur (qui est sur le CD par exemple) doit reconnaitre le matos qu'on lui propose. Tous les installeurs n'était pas au fait de Xen à ses début. Autre problème, c'est l'affichage, etc... Au début de Xen, il n'y avait pas de périphérique pour faire l'affichage. Donc on ne pouvait utiliser l'installeur et il fallait utiliser des "hacks". On pouvait faire tourner une installation de Linux mais pas son installeur.
J'imagine que les "debootstraop ou rpmstrap" sont (ou étaient) là principalement pour contourner ce problème.
> Parce que ton exemple montre l'utilisation dans un cadre 'support hardware'.
Certes, mais ça va devenir hypra commun dans quelques années et la paravirtualisation de Xen va devenir obsolète (au moins pour les serveurs).
Notons que la transition va se faire dans la douceur (plus ou moins). Fedora va mettre les bouchées doubles pour que paravirt_ops de F9 (qui n'aura pas XenSource) supporte Xen dom0 et domU. Donc si tu as une machine virtuelle qui tourne sous Xen (domU), elle tournera aussi sur une serveur qui n'utilise pas XenSource.
Le plan sur la virtualisation pour F9 (jugé très ambitieux pour ne pas dire risqué) :
http://fedoraproject.org/wiki/Features/XenPvops
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal Matthew Szulik démissionne. Évalué à 1.
>
> Tant mieux, mais je ne suis pas convaincu que ce soit très important :-)
Ooops. Je veux dire que ce n'est pas important que ça soit Fedora ou autre ou même qu'il utilise Linux ou non. Ce qui compte est qu'il comprenne le modèle du libre, son fonctionnement global, ses bénéfices. Il doit être "sensible" à tout ça et non chercher à appliquer des solutions du monde propriétaire car ça marche dans le monde propriétaire. Évidemment, s'il utilise Fedora (notamment car c'est une distribution orienté communauté du libre) avant même être embauché chez Red Hat, c'est un excellent signe.
[^] # Re: En passant...
Posté par IsNotGood . En réponse au journal Matthew Szulik démissionne. Évalué à 2.
Achetes des actions Red Hat :-)
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal Matthew Szulik démissionne. Évalué à 1.
Tant mieux, mais je ne suis pas convaincu que ce soit très important :-)
Je ne pense pas qu'il va "révolutionner" Red Hat, son coeur de métier et son expertise, dans les premiers mois.
Je ne serais pas étonné qu'il soit quasi invisible les premiers mois.
Red Hat a eu une croissance soutenue depuis plusieurs années. Red Hat a encore un gros potentiel de croissance. Mais ça doit être géré au niveau organisation et personnel. Par exemple Red Hat c'est maintenant environ 3 000 employés !
les perceptives de Red Hat a moyen terme sont claires :
- virtualisation
- linux automation
- jboss
- RHX
Je vois une réorganisation de Red Hat (pas ce que fait Red Hat) afin de se préparer les "montées en charge" à venir. Puis une profonde réflexion pour définir des plans à (très) long terme. La question d'investir le marché du desktop sera évidemment abordé en profondeur.
Donc, pour ma part, il faut a Red Hat aujourd'hui un excellent "gestionnaire" pour mettre en place une solide organisation. Mais Red Hat n'est pas une boite comme les autres, il faudra préserver ses spécificités qui font son succès, il faudra beaucoup d'imagination et d'intelligence.
Je ne crois pas que le couple RHEL/Fedora soit impacté significativement.
Par contre on va peut-être voir plus de moyen pour la communcation autour de Fedora (et RHEL Desktop). Même si le marché du desktop est encore assez ridicule, c'est dès aujourd'hui qu'il faut placer ses pions et notamment au niveau de l'image.
C'était mon sentiment. Je suis très peu inquiet à moyen terme.
[^] # Re: Zarb
Posté par IsNotGood . En réponse au journal GTK+ et OpenGL pour bientot ??. Évalué à 1.
Désolé d'être désagréable, mais tu fumes quoi ?
Parce je connais X dans les grandes lignes et avec X tu peux avoir des fenêtres qui sont des textures. Côté client ce n'est pas forcément une texture, mais côté serveur ça ne pose pas de problème. C'est principalement X11 qui "cause" à la carte graphique.
Ce n'est pas Compiz qui fait la transparence, c'est le serveur X11. Compiz "configure" le serveur X11 (lui dit quel est la transparence de telle ou telle fenêtre, etc).
Effectivement on n'est pas obligé d'utiliser OpenGL pour faire de la transparence. On n'est pas obligé non plus d'utiliser OpenGL pour faire de la 3D. Mais sans OpenGL les performances sont lamentables.
Juste un petit exemple. 4 fenêtres en transparence de 1600x1200 en (A)RGB32 : presque 30 Mo !
La transparence est appliquée en cascade.
Lecture des deux premières fenêtre => 15 Mo.
Résultat temporaire => 7 Mo.
Lecture du résultat temporaire et lecture de la troisième fenêtre => 15 Mo
....
Lecture = 15 *3 = 45 Mo
Ecriture = 7 * 3 = 21 Mo
Soit pour une image = 66 Mo !
Si une fenêtre est une vidéo à 25 fps et qu'elle est au fond on a au minimum => 66*25 = 1,6 Go/s !
Certes les derniers CPU peuvent peut-être supporter ça. Mais c'est très très limite.
Les cartes graphique savent bouffer ça à une vitesse "terrifiante".
Sans parler de 3D, l'autre chose que font les cartes graphiques à une vitesse "terrifiante", c'est le redimensionnement d'image et l'antialiasing (qui peut être très très coûteux si fait avec le cpu de la carte mère).
Donc OK, OpenGL n'est pas nécessaire pour la transparence. Mais il faut être con pour s'en passer.
NB : Je connais bien Direct3D (je développe avec) et je ne suis pas naïf dans ce domaine.
[^] # Re: pas de l'ergonomie
Posté par IsNotGood . En réponse au journal De l'ergonomie de KDE. Évalué à 2.
Fais ta définition des termes à toi. Mais ne l'impose aux autres. Ergonomie et esthétique n'ont rien à voir (voir les définitions qu'on trouve dans les dicos).
[^] # Re: Enooorme !
Posté par IsNotGood . En réponse au journal La Flame War de l'année ?. Évalué à 1.
Il me semble bien que c'est de toi (GeneralZod) que je l'ai lu en premier.
[^] # Re: Zarb
Posté par IsNotGood . En réponse au journal GTK+ et OpenGL pour bientot ??. Évalué à 2.
reflets de l'ensemble de la scène et pas seulement de ce qu'il y a dans la fenêtre.
[^] # Re: Zarb
Posté par IsNotGood . En réponse au journal GTK+ et OpenGL pour bientot ??. Évalué à 1.
C'est pour faire de la transparence par pixel ou par widget. Compiz c'est par fenêtre.
> Parce que les fenêtres transparentes, c'est le composite manager et un canal alpha sur la fenêtre, c'est tout.
Tu peux aussi "dessiner" le contenu des fenêtres" en ARGB (alpha par pixel). Ainsi la transparence n'est plus pour l'ensemble de la fenêtre, mais par pixel. Les quelques copies d'écran le montre clairement.
> Et actuellement, seuls les pilotes nvidia supportent la redirection d'un rendu OpenGL.
J'en doute. Ou alors tu parles de Linux uniquement.
Enfin, tu peux faire un rendu dans un texture, puis utiliser cette texture lors du render de l'écran. Ça tout le monde peut le faire je crois.
La redirection de rendu, c'est pour les trucs "tordus" type reflets, etc...
> En clair : votre fenêtre dessinée en OpenGL n'est gérable par un composite manager qu'avec les pilotes nvidia.
Non.
La fenêtre n'est qu'une texture. Ici la particularité est que la texture est remplis avec un "rendu" (la texture est une render target). Puis la texture (parmis d'autres) est utilisé pour faire l'affichage à l'écran. Il n'y a pas de rendu dans la texture pendant le rendu à l'écran. Donc quasiment tous les drivers doivent le supporter.
[^] # Re: Putain 10 ans !
Posté par IsNotGood . En réponse au journal GnuPG à 10 ans. Évalué à 1.
Gnupg supporte tout ça, c'est la version 2 de gnupg. En général c'est dans le paquet gnupg2. Ce n'est pas un remplaçant complet de gnupg (v1), il doit être considéré comme un complément. Donc il n'y a pas de problème à installer gnupg (v1) avec gnupg2.
[^] # Re: Putain 10 ans !
Posté par IsNotGood . En réponse au journal GnuPG à 10 ans. Évalué à 1.
Fais par exemple "man gpgsm" :
Pour info, gnupg peut aussi chiffrer sans clée public/privée.
C'est l'option "--symmetric".
Techniquement il est possible d'utiliser gnupg pour les partitions chiffrés, mais ça serait horriblement lent et de toute manière gnupg n'a pas été prévu pour ce cas.
[^] # Re: En passant...
Posté par IsNotGood . En réponse au journal Matthew Szulik démissionne. Évalué à 2.
Sûr ?
En passant toujours, Red Hat emploi beaucoup de monde en Europe, Inde, etc...
Alan Cox qui est sous contrat Red Hat bosse en Europe par exemple.
En passant, une petite vidéo d'Alan Cox dans sa région :
http://www.redhatmagazine.com/2007/12/18/video-alan-cox-and-(...)
C'est un point que Szulik a souvent souligné. Indiquant aussi le haut niveau des développeurs européens. Je ne serais pas étonné que Red Hat ait plus de développeur en Europe qu'aux USA.
Certe la boite est basée aux USA, mais l'argent gagné par les développeurs est dépensé en Europe (ou ailleurs). Comme quoi la mondialisation ce n'est pas le mal absolu.
[^] # Re: Ca bouge !
Posté par IsNotGood . En réponse à la dépêche Sortie de NetBSD 4.0. Évalué à 1.
Tu peux faire pareil avec Linux. Évidemment virt-manager le supporte.
Libvirt/virt-manager est principalement, voire exclusivement, développé par Red Hat. Si tu as vu la vidéo, tu peux imaginer des scénarios où les machines virtuelles sont construites en 3 ou 5 minutes de façon automatique. La cible de Red Hat est actuellement les serveurs. Ceci combiné à lvm et GFS2 peut donner ça (amazon EC2) :
http://www.redhat.com/about/news/prarchive/2007/amazon.html (actuellement en public beta)
C'est-à-dire un fournisseur de machine virtuelle. Tu paies pour la quatité de cpu, mémoire et disque que tu utilises. Tout peut être changé à la volée.
Red Hat est très ambitieux dans ce domaine.
Pour un usage plus desktop (typiquement une installation d'un autre OS depuis les CD), c'est supporté :
http://www.phoronix.com/scan.php?page=article&item=656&a(...)
C'est une "démo" de Fedora 7, une version de test.
Le test a été fait avec KVM (Fedora, et donc Red Hat/RHEL, va petit à petit abandonner Xen).
Le développement de la virtualisation est très dynamique dans le monde Linux.
[^] # Re: Houla....
Posté par IsNotGood . En réponse au journal FlightGear en version 1.0. Évalué à 1.
Ce qu'il faut c'est une modélisation 3D.
[^] # Re: pas de l'ergonomie
Posté par IsNotGood . En réponse au journal De l'ergonomie de KDE. Évalué à 3.
Le HIG de Gnome ou n'importe quel HIG ne parle pas d'esthétique.
Les personnes qui s'occupent du graphisme (esthétique) sont très rarement les même qui s'occupent de l'ergonomie.
Que toutes les applis de Gnome respectent le HIG est un plus pour le confort. Les interface sont plus rapidement conpréhensibles, etc... Mais c'est souvent au détriment de l'esthétique. Considère Totem qui respecte le HIG de Gnome et donc a un haut soucis d'ergonomie. Ben il n'est pas très esthétique par rapport à d'autres lecteurs. L'esthétique a été sacrifié. Ou est moins prioritaire que l'orgonomie. Donc ils ne vont pas de paire.
L'esthétique ce n'est qu'une affaire de goût. Je peux être efficace même avec un theme graphique très moche (du moment qu'il est lisible).
L'ergonomie peut être presque mesuré (nombre de clique, nombre d'éléments que l'utilisateur doit connaitre, etc).
L'esthétique ne peut être mesuré. Au mieux on peut avoir son niveau de popularité. Notons qu'il dépend des cultures, des modes, etc... Ce qui était moche hier peut-être joli aujourd'hui, ...
Par contre, l'esthétique fait souvent parti du design. Mais alors on n'est plus uniquement dans le fonctionnel/ergonomie. Dans l'automobile, esthétique et design vont quasi de paire. Car on ne vend pas de voiture uniquement sur l'aspect fonctionnel/ergonomique, mais beaucoup sur le style.
Pour les camions, c'est une autre histoire. Le confort et donc ergonomie est primoridale puis des gens y travail 8 heures par jours. Ben c'est moche. Regarde l'intérieur d'un camion et compare avec l'intérieur d'une voiture.
Notons aussi les bureaux dans les ateliers. L'ergonomie est importante puisque des gens y travaillent. Mais c'est moche. C'est moins moche pour certains bureaux mais seulement car on y reçoit souvent des clients. L'image de la société y est en parti en jeu.
[^] # Re: pas de l'ergonomie
Posté par IsNotGood . En réponse au journal De l'ergonomie de KDE. Évalué à 2.
Non. Il y a des themes pour mal-voyant, il ne cherche pas à être esthétique, mais ergonomique. C'est-à-dire permettre au mal-voyant de travail dans le meilleur confort.
Va dans une usine, l'ergonomie y est prioritaire. Ben les machines, sont vertes, oranges, il y a du jaune, du blanc, du rouge, c'est moche avec 0 soucis esthétique. Mais c'est très claire.
Vim dans une console peut être considéré comme ergonomique pour l'utilisateur qui le maitrise. Mais niveau esthétique c'est 0.