Bruno Ethvignot a écrit 346 commentaires

Un argument qui est avancé encore et encore est que nous ne devrions pas utiliser OpenGL en raison de tout l'ancien matériel en service dans les pays en voie de développement. Il y a deux solutions à ce problème. D'abord, OpenGL est une API extensible. Par l'intermédiaire de solutions de rechange logicielle (fallbacks) elle est capable de fonctionner sur le plus petit matériel. OpenGL ES fournit également des profils d'API. Les profils sont des sous-ensembles bien définis de l'API OpenGL. Si nécessaire nous pourrions définir un profil minimum couvrant la plus petite API OpenGL possible. La taille du code ne devrait pas être un problème, une implémentation propriétaire d'OpenGL ES de 100 Ko est disponible. Un profil OpenGL supplémentaire ne nécessite pas un support de la virgule flottante. Rien n'empêche de réaliser des équivalents en open source si nous choisissons d'y consacrer les ressources.

L'autre argument est simplement d'exécuter du logiciel qui a été conçu pour fonctionner sur le matériel en service. Personne ne s'attend à ce qu'un IBM PC fasse fonctionner Windows Longhorn mais le même PC continue à faire fonctionner DOS sans problème.

Le point essentiel ici est qu'OpenGL est plus extensible qu'EXA. L'extensibilité d'EXA est incomplète au plus haut point, elle ne couvre pas des fonctionnalités avancées du GPU comme la 3D et la programmabilité. Avec OpenGL il est possible d'avoir une seule API pour tout : du téléphone cellulaire au superordinateur.


http://linux.tlk.fr/traitement-graphique/
Jon Smirl - 30 août 2005 - Ancien développeur Xegl

J'avais essayé de développer un site avec la technologie ASP.net en 2004 juste avec un éditeur de texte (sans l'environnement vendu par Microsoft)

Et honnêtement j'ai trouvé cela bien compliqué par rapport à du PHP, et aussi assez lent.

Les contrôles pissaient du code en fonction du navigateur, ce que je trouve inacceptable, surtout que mon Firefox est reconnu comme un navigateur ne sachant que gérer du HTML 3.

Les contrôles cela m'a fait penser un peu aux composants de Mason (un framework basé sur mod_perl). A l'époque pas de templates, j'ai été obligé d'utiliser des contrôles pour simuler les templates.

Sans compter que dès que j'ai voulu faire quelque chose d'un peu compliqué j'ai dû commencer à compiler des assemblies.

A mon humble avis pour la majorité des sites Web PHP s'impose naturellement.

Je vais être un peu en désaccord avec l'avis général... mais je n'aime pas l'orientation que Novell veut donner à X.
Même si c'est principalemt David Reveman qui a bossé sur XGL, d'autres (trop rares) développeurs comme Jon Smirl ont participés. Le code est d'ailleurs incorporé à xorg :
http://lists.freedesktop.org/archives/xorg/2006-January/0119(...)

Je comprends bien la necessité de faire des trucs "jolis" pour attirer le chaland
Je ne pense pas que la 3D sur le bureau soit uniquement là pour faire jolie, elle peut aussi servir utilement, par exemple des rotations à la volée pour les appareils de projection ou la mise à l'échelle d'un écran entier pour les malvoyants. De plus 90 % des puces graphiques sont consacrés au traitement 3D alors pourquoi ne pas l'utiliser pour gérer l'affichage en 3D ? Si cela continue dans quelques années les cartes graphiques feront plus que de la 3D.

De mon côté j'espère que XGL améliorera mon expérience utilisateur et que les impressions de lenteur de X-Window (clignotement, lenteur de rafraichissement, déplacement des fenêtres saccadées) vont disparaitres.

Ça va sacrifier la transparence réseau,
Je ne suis pas certain que XGL va sacrifier la transparence réseau. XGL est juste une réécriture du protocole X au dessus de EGL. L'API de X reste inchangée. Je ne vois pas pourquoi la transparence réseau ne fonctionnerait plus. Un article du Linux Journal sur No Machine et le protocole NX prouve que le protocole X peut être compressé à 200:1 ou plus. http://www.linuxjournal.com/article/8477

Ceci dit, si y'a un gourou du sujet pour m'expliquer quels choses indispensables/très utiles ne sont possibles qu'avec Xgl, je suis preneur.
A lire « Le point sur le traitement graphique sous Linux » de Jon Smirl :
http://linux.tlk.fr/traitement-graphique/

Je ne sais pas si cela peut t'aider, j'ai voulu installer une Livebox avec le Sagem XG760A pour mes parents.

Mais Le XG760A ne fonctionne pas avec la version Ndiswrapper 1.2 livrée avec la Mandriva 2006. Le modprobe gèle.

Par contre le XG760A fonctionne avec la version compilée 1.7 de Ndiswrapper : http://ndiswrapper.sourceforge.net/

Cela fonctionne mais ceci est beaucoup plus lent que par un câble RJ45 en Ethernet. Est-ce normal ?

N'ayant que deux ports USB avec l'imprimante Samsung ML-1510 (qui elle a des pilotes Linux données par Samsung) et un appareil photo Kodak CX7530 (supporté par gphoto2 et gthumb), j'ai décidé de remplacer le XG760A par un câble RJ45 de vingt métres...

Par contre c'est un non sens d'installer une Mandriva 2005 LE. Je te conseille fin avril de passer à la Ubuntu Dapper Drake.

C'est une bien triste nouvelle... Apple ne fera plus de Macintosh.

Apple arrête donc le Macintosh et Apple fait du compatible PC tout comme Dell. Le Macintosh va tout simplement aller rejoindre l'Amiga et l'Atari ST

Encore un pas vers la monoculture ? La mort du Macintosh c'est aussi la disparition du PowerPC dans les ordinateurs de bureau. J'avais surtout acheté un iMac puis un iBook pour tester Linux sur une autre architecture.... Je vais voir si jeux trouver des iMac G5 d'occasion car je ne compte par achter mes PC chez Apple.

Après ils expliquent pourquoi ça va déchirer, que Apple bosse dessus pr MacOS, et que Windows Vista devrait en avoir un bout aussi.

Comme écrit ci-dessus on pourrait comprendre que MacOS et Fenêtre(r) Vista(r) vont intégrer des bouts de XGL !

La tendance actuelle est effectivement d'utiliser la puissance du GPU des cartes 3D actuelles pour accélérer l'affichage du bureau et pouvoir aussi faire quelques effets sympas. Apple, DirectFB et EXA utilisent déjà quelques fonctions d'OpenGL pour accélérer l'affichage.

Mais la tendance va plus loin maintenant, par exemple les fenêtres seront directement des textures gérées par le matériel 3D. XGL est un pas dans cette direction, mais XGL est un projet parmi d'autres qui ne concerne que Xorg. Apple avec Quartz et Microsoft avec WGF (DirectX10) vont dans la même direction mais à ma connaissance ne partage pas de code avec XGL. Je suppose que les implémentations doivent être bien différentes car XGL, aussi prometteur qu'il soit, n'est ni plus ni moins qu'un serveur X au dessus d'OpenGL.

Je ne crois pas que XGL soit développé en secret pas Novell. Même si Aaron Siego a répandu la rumeur le mois dernier que Novell avait repris le développement de XGL pour en faire un produit propriétaire, la mise à disposition du code source de XGL par David Reveman, développeur pour le compte de Novell prouve le contraire.

XGL n'est pour l'instant qu'un serveur expérimental et n'est pas encore intégré au code de Xorg.

XGL bien que prometteur manque tout simplement de développeurs. Des gens comme Zack Rusin, David Reveman, Dave Airlie, et Eric Anholt travaillent sur le projet quand ils le peuvent.

Le 11 août dernier Jon Smirl annoncait sont intention de se retirer du projet faute d'avoir pu attirer d'autres développeurs :
http://linuxfr.org/2005/10/06/19684.html

J'avais acheté le livre : « Programming Linux Games » :
http://linuxfr.org/2002/10/25/10111.html

Le livre est un peu ancien mais cela peut donner une idée.

Je pense qu'il faut bien distinguer deux choses.

Premiérement l'apprentissage d'une API, que ce soit SDL, Clanlib ou OpenGL. Ces accès à l'API représentent finalement qu'en faible partie du jeu.

Deuxièment les algorithmes plus général utilisés par les jeux. Par exemples les techniques décrites dans les livres « Game Programming Gems » fonctionnent aussi bien sur Fenêtre(r) que sur notre système favori Linux :
http://www.gameprogramminggems.com/

Sinon tu peux commencer à bidouiller les nombreuses sources de jeux libres existantes sous Linux. Trouve le jeu le plus proche de ce que tu veux faire et va voir comment c'est fait.

Pour les casses briques par exemple tu peux voir les sources du célèbre LBreakout2 :
http://lgames.sourceforge.net/index.php?project=LBreakout2
Ou Briquolo un casse brique en 3D :
http://briquolo.free.fr/fr/
Ou encore TecnoballZ le casse briques que j'ai développé :
http://linux.tlk.fr/games/TecnoballZ/

Un serveur X par dessus OpenGL serait plus rapide
Peut-être un peu. On associe souvent (parfois inconsciemment) OpenGL et rapidité, et on oublie que ce n'est qu'une API, une manière d'attaquer le driver.


D'après les vidéos des démos de XGL (le serveur X au-dessus d'OpenGL) le déplacement des fenêtres sont bigrement plus rapides :
http://vizzzion.org/stuff/xgl_wanking.avi
http://www.gnome.org/%7Eseth/blog-images/monkey-hoot/mpeg4/W(...)

Ce qui parait logique car d'après Jon Smirl ancien développeur de XGL/XEGL « la 3D est simplement plus rapide que la 2D, personne ne rend ses fonctions 2D plus rapides, toute la technologie silicium entre dans la 3D ». Toujours d'après Jon Smirl : « Dans certains cas ces nouveaux bureaux accélérés (par le GPU) peuvent s'afficher plus de cent fois plus rapidement que sur un ancien modèle. »

Xgl se sert aussi d'une nouvelle fonctionnalité d'OpenGL, les objets framebuffer (FBO) qui pour une application a l'apparence d'une fenêtre de dessin normale. Mais pour le gestionnaire de fenêtres, les fenêtres ressemblent à des textures et peuvent être manipulées avec des commandes de dessin normales comme le multitexture. Un gestionnaire de fenêtres basé sur OpenGL comme Luminosity peut combiner des fenêtres en utilisant un z-buffer et supprimer les limites de l'ordre Z strictement 2D et transformer une fenêtre en vague et à plusieurs reprises entrecroiser une autre fenêtre.

L'intérêt d'avoir un serveur X basée sur OpenGL et aussi de n'avoir qu'un seul pilote à maintenir au lieu des pilotes XAA, OpenGL à maintenir. Sans compter sur les nouveaux pilotes EXA.

X.org a choisi une solution à court terme en implémentant le sparadrap EXA repoussant ainsi la sortie du prometteur XGL de deux années. EXA/Render est uniquement un sous-ensemble de l'API générique OpenGL Mesa et risque d'être engraissé de nouvelles fonctionnalités, alors qu'avec OpenGL il est possible d'avoir une seule API pour tout.

Ultimate++ est une suite pour développer rapidement d'applications multi-plateformes. Il inclut un ensemble de bibliothèques (GUI, SQL, etc.) et un environnement de développement intégré (IDE).

http://upp.sourceforge.net/

LinuxFr c'est aussi des dépêches de seconde page affichées à gauche sur la page d'accueil !

Par exemple cette dépêche est parue hier :
Firefox et DADVSI dans Le Monde
http://linuxfr.org/2005/12/02/19991.html

Sur MozillaZine-fr on en a parlé avant hier :
http://www.mozillazine-fr.org/archive.phtml?article=7737f

--
Redécouvrez le Web avec Firefox :
http://www.mozilla-europe.org/fr/products/firefox/

Un documentaire est disponible ici (malheureusement c'est au format propriétaire Quicktime je regrette) :
http://www.andycarvin.com/archives/2005/11/the_100_laptop.ht(...)

Cependant mplayer sur 80x86 arrive à le lire.

Vous pouvez aussi utiliser ce mirroir :
mplayer http://lunxer.se/mirrors/100laptop.mov

J'ai un peu gonflé la sauce inconciemment ou involontairement. En fait la configuration Pegasos que j'avais vu était à 1 560 CHF soit 1 016,88 Euros.
http://www.pegasos-suisse.com/fr/ordering/basic/index.php

Donc le Pegasos reste plus cher qu'un Macintosh, se limite au G4 et a une diffusion très réduite. Il ne faut pas attendre à une machine Pegasos équipée d'un G5 ni sur les survivants de l'Amiga pour sortir des machines PowerPC de bureau intéressantes.

Au lieu d'unir leurs forces les derniers survivants de la communauté Amiga se sont divisés et se sont entretués. A lire l'interview de Nicolas Det développeur MorphOS :
http://obligement.free.fr/articles/itwdet.php

Oui, d'un coté il y'a la disparition d'une plate forme accessible en PPC,
C'est la disparition du seul ordinateur de bureau PPC grand public accessible à tous. Les autres plate-formes PPC sont rares, chers et ont deux ans de retard sur Apple.
Par exemple 2402 euros pour un PEGASOS CPU G4 1Ghz + 256Mo de RAM sans écran. Quand à un ordinateur de bureau G5 ormis Apple, il n'en existe pas à ma connaissance...

Et OSX est un unix, même si ce n'est pas libre, de la diversité sur les PC ne peut pas faire de mal.
La diversité des architectures n'est pas mal non plus.

Il y'a une foule de choses pratiques, comme le navigateur de fichiers en mode colonnes, exposé qui est une pure merveille, le système d'installation des soft qui est simple au possible...
Le navigateur en mode colonnes vient du NeXT.

IBM etait l'ancien ennemi

Petit souvenir, la pub Apple de 1984 annonçant le Macintosh à IBM :

Quelques photos :
http://cours.cegep-st-jerome.qc.ca/530-lem-p.l/mac-1984.htm

La vidéo :
http://www.apple-history.com/?page=gallery&model=1984&am(...)

Si nous restons dans une logique de logiciels libres, comme le voudrai ce site, la disparition du processeur PowerPC dans les machines d'Apple n'est pas une bonne chose.

En effet les machines d'Apple permettaient d'avoir des machines non 80x86 disponibles un peu partout, à un prix relativement abordable, et assez jolies. Ainsi les développeurs de logiciels libres sous Linux et *BSD pouvaient installer un système libre sur une architecture PowerPC et compiler et tester leurs développements sur cette architecture.

Donc on devrait attendre que la dernier vrai Macintosh à base de PowerPC sorte pour l'acheter et oublier les compatibles PC du nom de MacTel.

Et oui derrière cette appellation MacTel se cache un véritable compatible PC qui ressemblera comme deux gouttes d'eau à un compatible PC sorti de chez Dell, sauf bien entendu la carrosserie qui sera digne j'en suis certain du design unique d'Apple.

Car si le Mac est un PC dans le sens (Personnal Computer), un PC n'est pas un Mac. Et les machines Intel d'Apple seront bien des compatibles PC et non plus des Macintosh. Le Macintosh a bien changé en vingt-ans, perdant un peu à peu son âme à mesure qu'Apple introduisait les technologies issues du monde PC dans son bébé jusqu'à ce jour funeste de 2006 où le Macintosh ira rejoindre l'Amiga et l'Atari ST pour laisser sa place au standard PC introduit par son ancien ennemi des années 1980, j'ai nommé IBM.

Excuse moi je ne trouve pas la comparaison pertinente.

Si on joue à un jeu propriétaire alors pourquoi ne pas utiliser un pilote graphique propriétaire ? J'avoue ne pas savoir si les rares jeux propriétaires sous Linux fonctionnent avec des pilotes libres ?

Mais généralement un jeu libre utilisant la bibliothèque OpenGL tournera très bien avec les pilotes libres de certaines cartes Radeon et de certaines cartes Intel (Intel fourni des pilotes open source pour certaines de leurs puces). Voir l'état du support des cartes graphiques :
http://dri.freedesktop.org/wiki/Status

Si certaines fonctions ne sont pas prises en charge par le matériel elles sont émulées par Mesa. J'ai joué à pas mal de jeux libres 3D avec ma Radeon 7200. Bien entendu ce ne sont pas des jeux avec une 3D aussi complexe que Doom 3, la 3D des jeux libres n'est pas aussi poussée que celle des jeux propriétaires.

Donc si je joue à un jeu libre je peux avoir, si je le désire une solution libre de bout en bout et multiplate-forme.

Je salue l'effort de Sun, mais Looking Glass ne peut à l'heure actuelle être une solution libre de bout en bout et multiplate-forme. Pour finir je pense que les logiciels bas-niveaux comme ce qui touche au traitement graphique doit être écrit en C. Xorg a mon humble avis a déjà des problèmes de performance et d'occupation mémoire, pourquoi charger la charue avec une JVM (combien une JVM occupe-elle de mémoire ?) et du bytecode ? Mais comme écrit Romain Looking Glass est plutôt un environnement de test du bureau 3D. Personnellement je crois plus à des projets comme XGL. Mais remercions Sun pour les idées et le code GPL (de Looking Glass mais aussi d'OpenOffice :-)

Attention cepandant si comme moi, après avoir installé une Mandriva PowerPack 2006, vous vous précipitez sur Easy URPMI pour configurez vos sources URPMI réseaux après avoir lancé un urpmi.removemedia -a . Certains paquets n'existent que sur le DVD.

Par exemple pour configurer mon imprimante drakprinter gelait complétement à l'installation de CUPS. Après fait l'essai plusieurs fois, j'ai essayé de le lancer drakprinter en mode console et j'ai vu qu'il affichait des messages d'erreur dans la console il ne trouvait pas les paquets gutenprint-cups, gutenprint-ijs, gutenprint-foomatic, gutenprint-escputil, gutenprint-gimp2.

J'ai monté les ISO de mon DVD et j'ai pu rajouter les sources suivantes pour que cela fonctionne :
urpmi.addmedia mainDVD file://mnt/powerpack/media/main with ../media_info/hdlist1.cz
urpmi.addmedia mainFIRM file://mnt/powerpack/media/firmwares/ with ../media_info/hdlist2.cz
urpmi.addmedia moduleDVD file://mnt/powerpack/media/modules/ with ../media_info/hdlist3.cz
urpmi.addmedia dkmsDVD file://mnt/powerpack/media/dkms/ with ../media_info/hdlist4.cz
urpmi.addmedia pluginsDVD file://mnt/powerpack/media/plugins/ with ../media_info/hdlist5.cz
urpmi.addmedia contribDVD file://mnt/powerpack/media/contrib/ with ../media_info/hdlist6.cz

Je te rapelle que Microsoft a déjà été condamné de nombreuses fois
Oui Microsoft a été condamné de nombreuses fois... Mais honnêtement, ces condamnations ne sont-elles pas que du vent ? La société Microsoft a changé ? Oui elle plus puissante, gagne plus d'argent, et vérouille de plus en plus de technologies. Les états du monde entier restent impuissants devant la puissance financière de Microsoft.

Commodore a officiellement présenté l'Amiga 1000 en fanfare au centre de Lincoln à nouvel York le 23 juillet 1985. C'était l'ordinateur le plus avançé de son temps. A l'origine L'Amiga 1000 a été conçu quelques années plus tôt par une petite compagnie de la Californie appelée Amiga Incorporated et a été financé par trois dentistes de Floride voulant investir dans une console de jeu de tueur.

Ce site retrace l'historique de l'Amiga :
http://membres.lycos.fr/etb/bref.html(...)

Comme beaucoup j'ai été un passionné d'Amiga entre 1987 et 1994. Excellente machine. Dommage que Commodore l'ait tuée.

Poutant en août Jon Smirl a décidé d'arrêter son travail sur EGL et Xgl. Qu'en est-il du projet ?
http://lists.freedesktop.org/archives/xorg/2005-August/009168.html(...)
http://www.osnews.com/comment.php?news_id=11550(...)

La fin de l'article « The State of Linux Graphics » de ce même Jon Smirl n'est pas très positif. Traduction rapide :

« Mon expérience avec l'échec de Xegl m'a enseigné que réaliser un sous-système graphique est un travail important et compliqué, de loin trop compliqué pour qu'une ou deux personnes l'abordent. Dans l'ensemble, la communauté de X.org a à peine assez de ressources pour construire un seul serveur. Diviser ces ressources dans plusieurs voies à l'unique conséquence d'empiler des projets à moitié finis. Je sais que les développeurs préfèrent travailler sur ce qui les intéresse, au lieu de donner des ressources disponibles à X.org, cette approche n'apportera pas à un nouveau serveur ou même un bureau pleinement compétitif basé sur le vieux serveur à court terme. Peut-être est-il temps à X.org d'établir une feuille de route que tout le monde devra suivre. »

A ce troll je répondrai la chose suivante la GPL est la liberté du code, le code ne pourra en aucun cas se retrouver enfermé dans un logiciel propriétaire. Alors que la licence BSD est la liberté du programmeur du faire du code ce que bon lui semble, comme l'enfermer dans un shareware par exemple.

Explication peu rigoureuse à mon goût. La société Netscape a été créé par les gens qui ont développés NCSA Mosaic, sur lequel a été basé les premières versions de Netscape et aussi dans une moindre mesure IE. Netscape s'est d'ailleurs appelé Mosaic Communication avant d'être forcé de changer en Netscape Communication.
http://mozilla.tlk.fr/faq5.php(...)

Le produit phare de Netscape est devenu non rentable lorsque la société Netscape à décider le donner. Netscape n'a jamais fait faillite, mais à commencer à plonger dans le rouge et à licencier. En mars 1998 le projet Mozilla et son organisation ont alors été créés, bien qu'au début Netscape ait préféré perdre du temps à continuer le développement de Netcape Communicator.

Enfin AOL a racheté la société Netscape en mars 1999, surtout pour le portail pense-ton, mais sans jamais rien faire de concret avec les navigateurs Netscape ou Mozilla, bien qu'il ait financé le développement pendant cinq années.

En juillet 2003 (un mois après un accord à l'amiable entre Microsoft AOL qui rapporta 750 millions à AOL) AOL vire les deniers employés de Netscape. Les locaux de Netscape sont démantelés. Netscape est vraiment mort.
http://mozillazine-fr.org/archive.phtml?article=3422(...)

La fondation Mozilla nait des cendres de Netscape et continue le développement.

A lire :
http://mozilla.tlk.fr/article1.php(...)
http://mozilla.tlk.fr/article2.php(...)
http://mozilla.tlk.fr/article8.php(...)

Perl v5.8.6 / Fedora Core 4

Tout est OK. Tu n'as pas un caractère invisible qui traine ?

Commence toujours tes programmes par :
use strict;
use diagnostics;

La version francophone de MozillaZine aussi :
La fondation Mozilla annonce la création de Mozilla Corporation
http://www.mozillazine-fr.org/archive.phtml?article=7085(...)