La base de l'interface graphique sous UNIX est le système X window. ça, tu ne peux pas y couper (hormis quelques anecdotes pour geeks comme DirectFB). Mais le serveur X ne traite que d'instructions bas niveau : il sait créer des fenêtres, tracer des lignes, mais pas afficher un beau bureau prêt à l'emploi avec des icônes & de belles décorations aux fenêtres...
ça, c'est le rôle de l'environnement de bureau (qui se base sur X évidemment), et il n'y en a pas qu'un, tu as le choix. KDE / Gnome sont des environnements très complets mais gourmands en ressources, alors que WindowMaker est un window-manager simple et léger. XFCE est un bon compromis à mon avis.
Par contre, il n'y a pas que l'environnement graphique qui pompe des ressources : les programmes "usuels" comme Mozilla Firefox, Openoffice ou Evolution seront difficilement utilisables, et là c'est plus délicat car on n'a pas vraiment autant de choix (ou plutôt on en a mais les logiciels en question ne sont souvent pas aussi conviviaux pour des débutants). Pour le traitement de texte, tu as abiword ou SIAG Office (à la limite, KOffice si tu rajoutes un peu de RAM. KDE a fait de gros progrès récemment). Pour le navigateur Web, tu as Opera.
N'empêche, personnellement je pense que la Mandriva est excellente sur des machines un peu plus récentes, mais pour un ordi avec peu de mémoire je conseillerais plutôt de regarder une distrib "allégée" sur Freshmeat. Ou alors essaie au moins de doubler la RAM (le 200 MHz n'a pas beaucoup d'importance).
Tout logiciel distribue sous licence compatible avec la GPL (ce qui inclut la licence BSD) peut etre lie a un bibliotheque GPL.
OK OK, j'ai peut-être dit des âneries (il me semblait que pour la GPL le bloc {appli + bibliothèque GPL} constituait un tout unique, devant être sous la même licence).
Mais dans ce cas je vais réitérer ma question : est-ce bien légal de mettre les KDElibs sous LGPL, et donc est-ce que ce serait légal de faire une appli commerciale se liant aux KDElibs (ça revient à détruire le "modèle" de Trolltech, qui veut que toute appli non libre entraîne l'acquisition d'une licence chez eux non ?)
Et puis, il y a qqch d'incohérent : j'ai le droit de faire un soft sous BSD utilisant une lib GPL, mais je n'ai pas le droit de faire un fork propriétaire du soft BSD (ce que la licence permet pourtant*) ? Donc ce n'est plus "vraiment" de la licence BSD puisque ce sont les termes de la GPL qui priment sur ma licence !?!
Bah de toutes les façons, la GPLv2 marche suffisament bien, non?
Je ne suis pas sûr qu'elle ait été suffisamment "testée" en situation de procès pour qu'on puisse dire cela. OK, il y a eu des exemples (p.ex. SIgma Design) mais était-ce dû à des pressions / accords amiables ou à un vrai procès ? Et qu'en serait-il en France ?
D'autre part, "marche bien" est tout relatif. La GPL a plein de qualités mais il me semble qu'elle pose des problèmes d'interopérabilités avec d'autres licences libre (dites moi si je me plante, je ne suis pas un expert du sujet). Par exemple, FreeBSD ne peut pas utiliser de code de Linux. Plus grave, je ne suis même pas sûr qu'un logiciel sous BSD/MPL/<n'importe quoi d'autre que GPL même si c'est une licence libre> puisse se linker à une bibliothèque GPL. OK, pour ça il y a la LGPL pour ça mais même la FSF la déconseille (http://www.gnu.org/licenses/why-not-lgpl.html). Je ne trouve pas que cette attitude soit bénéfique pour le logiciel libre en général (duplication de code inutile, etc...) car le logiciel libre ne se restreint pas à la GPL !
Petite question : QT est GPL mais les libs KDE sont LGPL -> comment est-ce possible ? Est-ce que cela signifie qu'on peut créer une appli non GPL utilisant les libs KDE sans devoir payer 1500$ à Trolltech ?
Non. Une VM peut faire dynamiquement des optimisations de très haut niveau
A une certaine époque, j'avais lu (dans un bouquin de Perl qui parlait aussi un peu de Java) que la VM Java était d'assez bas-niveau (un peu comme un assembleur) alors que celle de Perl était de très haut niveau (appels directement traduisibles en appels de fonctions C), ce qui expliquait la différence de vitesse entre Perl et Java. Je pensais que la CLR était un peu comme la JVM, une sorte "d'émulateur" pour un proc virtuel, avec donc des instructions de très bas niveau...
Maintenant, si je comprends bien, la CLR possède des instructions de plus haut niveau que la JVM, permettant davantage d'optimisations en tout genre ?
Mais à l'exécution tout ca est compilé en code natif (JIT)
Oui, mais je me dis que ça prend du temps de faire tous ces traitements (suffit de voir le temps de chargement d'une appli Java, ou le temps de compilation d'un programme C++ pour se dire qu'il vaut mieux les faire une fois pour toutes qu'à chaque lancement de l'appli). Du coup est-ce qu'on arrive quand même à concilier légèreté / rapidité de lancement avec toutes les optimisations en question ?
voire même avant (AOT)
Quand la VM existe, développer un compilateur n'est pas non plus super difficile car la VM est de bien plus haut niveau que l'assembleur
Donc il existe une manière de compiler du .NET en natif ? (comme avec gcj ?)
Ah, pendant que j'y suis, on parle beaucoup de Mono mais quid de DotGNU ? le second est une vraie alternative ou pas ?
J'admire .NET et C# qui sont pour moi l'étape logique après Java. Excepté deux ou trois conneries, C# est à mon avis strictement mieux que Java, ditto pour le framework. La techno est merveilleuse et les promesses pour la version 3 sont impressionnantes.
Je connais assez peu .NET mais je me pose régulièrement une question : pourquoi est-on obligé de passer par une machine virtuelle ? En effet, les avantages de .NET sont à ma connaissance :
- l'indépendance de la plate-forme (principal avantage de la VM, mais à mon avis ce n'était pas le but recherché par Microsoft)
- une API vaste et unifiée (mais pas besoin de créer une nouvelle plate-forme avec VM pour ça, c'est juste une histoire de mettre les moyens pour coder un bon framework et le rendre accessible depuis plein de langages)
- multi-langage (je vais peut-être dire une connerie mais il faut vraiment une VM pour ça ? y'aurait pas moyen de faire autrement, comme par exemple définir une ABI à laquelle tout le monde se conformerait ?)
- langages de haut niveau comme c#/delphi.NET/<votre_langage_favori> avec garbage collector, programmation fonctionnelle & co... (il existe déjà des langages compilés qui font tout ça, cf OCaml. Au pire il suffirait de coder un frontend c# pour gcc => pas besoin de VM non plus !)
Le principal avantage que je vois est d'avoir une machine virtuelle commune et bien optimisée pour les langages comme Perl/Python/Ruby (même si c'est aussi le but de Parrot, qui est apparemment spécialisée dans ce type de langages faiblement typés). A part ça, j'ai l'impression que le "manque" que .NET vient combler l'est / le serait tout aussi bien avec la mise au point d'une API bien foutue (style QT) + l'intégration de langages de haut niveau dans gcc (comme le D ou OCaml) + ABI facilitant l'interopérabilité du code objet entre différents langages.
Donc en gros, pourquoi l'avenir de l'informatique passerait t-il forcément par un dispositif avec une machine virtuelle ? (c'est quand même plus gros/lourd/lent que d'avoir un code qui s'execute directement non ?). Surtout que
- les logiciels libres n'ont besoin que d'une API portable (possibilité de recompiler pour chaque architecture)
- Microsoft ne recherche à mon avis pas vraiment à favoriser la portabilité (je ne vois pas quel est leur intérêt de promouvoir une telle architecture)
- les autres éditeurs de logiciels (propriétaires) peuvent être intéressés par l'aspect multi plates-formes, mais là encore une simple API portable (comme QT) résoud la majeure partie du problème (il suffit de compiler pour chaque architecture, mais ça reste la même base de code)
A ma connaissance
1) ce n'est pas la carte 3D qui se plie aux specs opengl mais plutôt le contraire (pilote opengl qui s'adapte au matos 3D)
2) mesa est bien 100% soft à l'origine, mais dans le cadre de l'architecture dri elle sert de base à une version "accélérée" (en fonction de ton driver). Par contre, dans l'exemple de ma nvidia (qui n'utilise pas le dri), si j'utilise le pilote libre nv + mesa "de base", alors je n'ai aucune accélération. (peut-être que ça ramera moins le jour où tous les ordinateurs du monde seront équipés de processeurs Cell, mais d'ici là... ;)
3) le rendu 2D ne sera pas près de s'estomper tant qu'on continuera de vouloir l'utiliser systématiquement ou de freiner les projets plus innovants sous couvert de rétro-compatibilité (ce qui risque d'être toujours le cas tant que les drivers 3D libre poseront problème). Et après tout, même le mode texte n'a pas isparu des cartes graphiques actuelles et reste utilisé sur de petites machines ou des serveurs
Oui soit, mais mesa ça rame franchement (c'est pas pour rien que evas/e17, cairo, arthur... disposent aussi d'un backend 2D classique, qui est davantage utilisable). J'ignore si mesa pourrait être davantage optimisée pour la 2D (i.e. avoir des performances comparable à SDL lorsqu'on est en mode glortho() par exemple) mais en l'état je ne pense que c'est plus une rustine qu'un choix viable (je ne pense pas que beaucoup de gens utiliseront glash s'ils ne dépassent pas les 2 ou 3 fps...).
Le problème des drivers libres est effectivement un prérequis important, mais c'est le problème d'une autre équipe, pas de glash qui doit chercher à faire le meilleur soft possible et éviter de réinventer la roue. Maintenant c'est vrai qu'ils auraient aussi pu se baser sur cairo ou evas...
Je vois plusieurs raisons :
- 80% des fonctionnalités nécessaires sont déjà dans OpenGL (rendu vectoriel, transformations, transparence, antialiasing...), ce qui permet d'alléger le code et donc d'éviter des bugs. Aujourd'hui la plupart des machines de bureau (celles susceptibles de faire tourner du flash) ont des cartes 3D (donc l'utilisateur a payé pour une puce contenant à 90% des fonctions 3D, autant les utiliser !).
- le rendu logiciel est très gourmand (essaie de jouer une video flash en plein écran, même sur une machine "correcte" de 1GHz). A contrario, OpenGL décharge le proc et est _très_ rapide même avec du code lisible (i.e. sans assembleur, non optimisé pour tel ou tel proc, etc...). La 2D vectorielle est en fait plus proche du rendu 3D (intrinsèquement vectoriel) que de la 2D bitmap. Dans ce domaine, le matériel 3D peut souvent faire des chose très sympathiques (effets de transparence, lumière, etc) inimaginables autrement à moins d'avoir un proc très puissant. Regarde les jeux comme critter ou chromium, et des projets comme e17/evas, cairo/glitz, Arthur/QT4, xgl, et un peu plus loin de nous Quartz extreme/MacOSX... Et pas besoin de machine super récentes : un PII400+RivaTNT peut déjà faire des choses très sympathiques !
- rien n'empêche de coder un backend purement SDL si ça motive du monde (mais à mon avis ça risque de ramer...)
Pour REACH, la comission est justement critiquée pour avoir un peu trop facilement cédé au lobby de l'industrie chimique. La plupart des mouvements écologistes (dont WWF et greenpeace, mais aussi les partis verts) se sont manifestées / ont voté contre la dernière version du texte, largement vidée de sa substance. (certains dirons qu'il y a quand même une petite avancée, mais le voter signifie qu'on n'aura rien de mieux durant de nombreuses années...)
J'ai un peu du mal à voir quels coûts fixes ça engendre vu que ce sont exactement les mêmes magazines à la page près. OK, il y a la pochette papier contenant le CD qui est présente sur une version et absente sur l'autre, ce qui nécessite un traîtement distinct à l'assemblage, mais vous auriez aussi pu choisir de l'insérer d'office en le laissant vide dans la version sans CD (et donc de n'avoir qu'une chaîne de production).
Je ne sais pas trop comment se déroule l'assemblage, mais j'imagine que l'insertion du CD dans sa pochette est la dernière opération non ? -> la machine qui s'en charge se bloquerait t-elle si elle était toujours approvisionnée en magazines d'un côté mais pas en CD de l'autre ? Autrement dit peut-on envisager comme solution d'avoir une unique chaîne de production avec simplement un défaut de CDs par rapport au nombre de mags ?
La demande de versions sans CD était vraiment négligeable face à celle avec CD ? Pour ma part, en tant qu'étudiant, le prix a fait la différence, même si j'étais en 56k !
D'autre part, 15F de plus (de ~20F à 35F à l'époque) juste pour le CD : il avait intérêt à être beaucoup beaucoup plus résistant qu'un CD-R et à avoir vraiment un contenu "qui se garde"... (rare dans le monde du libre). En fait à l'époque j'ai surtout eu l'impression que supprimer la version sans CD était une manière déguisée d'augmenter le prix du magazine (cela dit c'était peut-être légitime face aux coûts de production - je ne veux pas troller, ça n'est qu'une impression, je doute que le CD à lui seul ait un coût unitaire de l'ordre des 15F)
Je comprends qu'une demande asymétrique ait entraîné l'abandon de la double version en kiosque (vu que ça doit avoir un coût logistique qu'il faut rentabiliser). Par contre je ne vois pas vraiment pourquoi ne pas avoir maintenu la double version par abonnement, même avec une demande faible. De toutes façons, les éventuels stocks résiduels se seraient probablement écoulés lors des commandes de versions antérieures du magazine (si je commande un vieux n° de LM, à fortiori le CD ne me sert à rien puisqu'il est largement obsolète. Je préfère payer moins cher et ne pas avoir de CD !)
Mais bon, c'est du passé, ce qui compte c'est l'avenir !
Puisque le rédac'chef de LM passe sur le site, je voudrais lui suggérer de redonner la possibilité de s'abonner à LM sans CD (en ce qui me concerne j'ai arrêté le jour où ça n'a plus été possible -> trop cher ! (surtout pour des softs aisément téléchargeables sur l'ADSL...)).
Sinon (à l'inverse) je pense qu'une majorité des lecteurs utilisant le CD possède maintenant un lecteur DVD -> pourquoi ne pas passer définitivement au DVD ? (comme vos concurrents polonais...). ça ouvre des perspectives, comme par ex d'inclure une nouvelle distrib (ou au contraire la même à chaque fois, comme Aurox) dans chaque n°, ou bien de mettre toutes les contribs mandriva dans un seul n°...
Petite question pour combler mon ignorance : il semble qu'il existe deux projets "concurrents" : Mono et DotGNU. Le premier semble avoir davantage la vedette mais qu'en est-il du second ? Est-il encore vivant ? Qu'apporte t-il face à Mono (et inversement) ? Les 2 projets coopèrent t-ils un minimum ?
Autre chose : est-il envisageable / prévu de concevoir un frontend à GCC (CLR->RTL) un peu comme gcj ?
Je serais curieux de connaître les performances d'un Mesa optimisé pour The Cell. Est-ce que ça ramerait comme sur les CPUs actuels ou est-ce que ça pourrait être comparable à un GPU ? (dans ce cas plus besoin de GPU, un RAMDAC suffirait).
Dans le cas du MP3 / xvid je me demande si le problème vient vraiment des brevets de pressions de la MPAA...
Et puis, quand bien même y'aurait problème de brevets normalement c'est le _concepteur_ du logiciel contrefait qui risque un procès et non le dsitributeur, non ?
Et par la même occasion, est-ce que gstreamer concurrence Jack ou est-ce que c'est complémentaire ? -> http://jackit.sourceforge.net/(...)
Il me semblait que ce dernier était voué à devenir LE serveur de son low-latency (vu qu'il est même recommandé par alsa-project.org).
D'autre part, j'ai aussi entendu qqart que KDE pourrait utiliser gstreamer dans le futur mais quid de la dépendance glib dans ce cas ? qqun peut confirmer ? (no troll inside, c'est juste une question)
Mets-toi à la place du programmeur débutant. Pour se mettre à programmer, quelles docs trouve-t-il en premier à Carrouf dans le rayon des bouquins Sybex/Microapp à 10 euros -> C++/Java ! Et même s'il a appris que OCaml est un super langage, et qu'il se décide à acheter un bouquin pour s'y mettre (50 euros mini quand même), quel genre de bouquin trouve-t-il ? Une grosse intro très rigoureuse à la programmation fonctionnelle (voire au lambda-calcul), de l'algorithmique avec des arbres/listes chaînées, etc. Des choses très bien pour comprendre, acquérir de la rigueur et devenir un bon programmeur mais qui vont décourager notre programmeur débutant qui voudrait savoir rapidement faire des applis qui cartonnent comme avec Python... A quand un "Ocaml pour les nuls" ? :o)
Et si le programmeur connaît le C/C++ (comme moi), il veut aussi pouvoir s'y mettre rapidement en se raccrochant autant que possible à ce qu'il connaît. Ce serait une bonne chose si les concepteurs de OCaml écrivaient un bouquin/tutoriel visant le programmeur moyen (pas forcément étudiant en informatique) avec un peu plus de concrêt, genre un "OCaml pour les programmeurs C/C++, avec des exemples utilisant QT, OpenGL, SDL...
Enfin, apparemment (je ne maîtrise pas le sujet) il semble y avoir une véritable barrière à l'entrée pour les débutants qui voudraient utiliser OCaml avec des libs en C (pour lesquelles aucun binding officiel n'aurait été écrit). Notamment je crois qu'il faut faire gaffe à des détails liés au gc...
Je n'ai pas dit ça !
<ma vie>J'utilise régulièrement AtheOS/SyllableOS sur ma machine perso, et on ne va pas dire que c'est du vieil OS qui n'a pas bougé depuis 10 ans ou qui est super stable...</ma vie>
J'ai simplement dit qu'il y avait d'autres solutions à ce problème (parallélisation du lancement des services), directement implémentable dans les distributions "stables" et sans toucher à init. Maintenant peut-être que init a d'autres carences à combler et c'est très bien que des gens s'y attellent, mais c'est un autre débat !
A l'heure actuelle j'imagine mal une distrib "stable" ou grand public utiliser un init expérimental, alors que la solution que j'ai donnée est directement utilisable aujourd'hui et maintenant. Evidemment rien n'empêchera ces mêmes distribs d'utiliser une alternative à init le moment venu et quand elle sera finalisée mais c'est à plus long terme et il n'y a pas besoin d'attendre ça pour paralléliser le lancement des services...
On s'est mal compris : j'ai justement dit qu'il fallait comparer ce qui était comparable. Un amigaOS n'est _pas_ comparable à un OS sur PC (qui tourne sur plein de matos différents). Un fluxbox n'est pas non plus comparable à un bureau XP ou KDE. ça ne veut pas dire que l'un ou l'autre n'est pas bien, ça veut juste dire qu'il faut comparer à fonctionnalités équivalentes et sur du matos identique, donc dire "linux = alternative à MS, maintenant y'a de vrais bureaux comme KDE" d'un côté et "pour booter aussi vite que XP, utilises fluxbox" de l'autre me semble être un non sens (tout comme la comparaison "mon amiga bootait plus vite que ton PC" est vide de sens...).
Je trouve juste que à l'heure actuelle Linux+X11+KDE est _vraiment_ lent à booter (sur le même matériel) là où la "concurrence" a fait de gros progrès, et je pense que des modifications simples (démarrages parallèles des services) pourraient changer la donne.
D'accord, icewm et WindowMaker bootent plus rapidement qu'un KDE. Mais il faut comparer à fonctionnalités équivalentes, sinon je peux aussi dire que mon amiga bootait beaucoup + vite que Linux en mode console...
KDE n'est pas gros pq codé avec les pieds (m'enfin, j'en connais qui me diraient que le c++/templates...). KDE est gros pq il a beaucoup de fonctionnalités. OK, on ne les utilise pas forcément (WindowMaker me convient personnellement) mais c'est ce qui lui permet de soutenir la comparaison avec windoze (contrairement à icewm ou fluxbox).
Une implémentation triviale ne change pas init mais utilise "Make -j" avec un ou des Makefiles ad'hoc à la place de ces immondes liens symboliques dans rc*.d. C'est tellement simple et limpide qu'on se demande pourquoi personne ne l'a utilisé avant... (sans doute parce que tous les wizards comme webmin et linuxconf utilisent ce système, mais à tout problème y'a des solutions, surtout quand le jeu en vaut la chandelle...).
Personnellement je préfère cette approche (ou toute autre qui ne touche qu'aux initscripts et pas à init lui-même) pq init est stable (alors qu'un initng0.0.1 le sera forcément moins) et que c'est un programme important tout de même ! :)
Y'a pas que QT et gtk dans la vie. Si je cherche un toolkit C++ LGPL qui roxor y'a FOX-toolkit. Je ne sais pas pourquoi personne n'y pense jamais, surtout pour faire des applis commerciales (mieux que QT) et/ou multi plates-formes (bien mieux que gtk).
Techniquement, il serait plutôt à rapprocher de QT (C++, facile à utiliser (mais sans MOC), multi plates-formes, dessine lui-même ses trucs contrairement à wx, etc...), mais
- LGPL
- très complet pour la GUI. Contrairement à QT ou wx il ne cherche pas à être un framework complet mais se concentre uniquement sur la GUI.
- léger & rapide, mais pas encore thémable (look&feel "winowsien" par défaut. On aime ou on n'aime pas... Pour ma part ça ne me gène pas trop vu ses autres qualités)
- bien supporté sous d'autres langages (notamment ruby)
- et surtout, très stable bien qu'en évolution assez active.
Par contre je dois avouer que les fonctionnalités annoncées de QT4 sont séduisantes (notamment le canvas OpenGL, à faire pâlir Rasterman et son evas. J'en ai rêvé, ils l'ont fait !). QT aura toujours un cran d'avance, mais ça se paye ! (du moins si on développe des applis commerciales)
[^] # Re: Vieille machine
Posté par karteum59 . En réponse au message quelle mandriva pour un viel ordi. Évalué à 1.
ça, c'est le rôle de l'environnement de bureau (qui se base sur X évidemment), et il n'y en a pas qu'un, tu as le choix. KDE / Gnome sont des environnements très complets mais gourmands en ressources, alors que WindowMaker est un window-manager simple et léger. XFCE est un bon compromis à mon avis.
Par contre, il n'y a pas que l'environnement graphique qui pompe des ressources : les programmes "usuels" comme Mozilla Firefox, Openoffice ou Evolution seront difficilement utilisables, et là c'est plus délicat car on n'a pas vraiment autant de choix (ou plutôt on en a mais les logiciels en question ne sont souvent pas aussi conviviaux pour des débutants). Pour le traitement de texte, tu as abiword ou SIAG Office (à la limite, KOffice si tu rajoutes un peu de RAM. KDE a fait de gros progrès récemment). Pour le navigateur Web, tu as Opera.
N'empêche, personnellement je pense que la Mandriva est excellente sur des machines un peu plus récentes, mais pour un ordi avec peu de mémoire je conseillerais plutôt de regarder une distrib "allégée" sur Freshmeat. Ou alors essaie au moins de doubler la RAM (le 200 MHz n'a pas beaucoup d'importance).
[^] # Re: Nouveautés dans la GPLv3?
Posté par karteum59 . En réponse à la dépêche Le noyau Linux ne se convertira pas à la GPLv3 !. Évalué à 1.
OK OK, j'ai peut-être dit des âneries (il me semblait que pour la GPL le bloc {appli + bibliothèque GPL} constituait un tout unique, devant être sous la même licence).
Mais dans ce cas je vais réitérer ma question : est-ce bien légal de mettre les KDElibs sous LGPL, et donc est-ce que ce serait légal de faire une appli commerciale se liant aux KDElibs (ça revient à détruire le "modèle" de Trolltech, qui veut que toute appli non libre entraîne l'acquisition d'une licence chez eux non ?)
Et puis, il y a qqch d'incohérent : j'ai le droit de faire un soft sous BSD utilisant une lib GPL, mais je n'ai pas le droit de faire un fork propriétaire du soft BSD (ce que la licence permet pourtant*) ? Donc ce n'est plus "vraiment" de la licence BSD puisque ce sont les termes de la GPL qui priment sur ma licence !?!
[^] # Re: Nouveautés dans la GPLv3?
Posté par karteum59 . En réponse à la dépêche Le noyau Linux ne se convertira pas à la GPLv3 !. Évalué à -1.
Je ne suis pas sûr qu'elle ait été suffisamment "testée" en situation de procès pour qu'on puisse dire cela. OK, il y a eu des exemples (p.ex. SIgma Design) mais était-ce dû à des pressions / accords amiables ou à un vrai procès ? Et qu'en serait-il en France ?
D'autre part, "marche bien" est tout relatif. La GPL a plein de qualités mais il me semble qu'elle pose des problèmes d'interopérabilités avec d'autres licences libre (dites moi si je me plante, je ne suis pas un expert du sujet). Par exemple, FreeBSD ne peut pas utiliser de code de Linux. Plus grave, je ne suis même pas sûr qu'un logiciel sous BSD/MPL/<n'importe quoi d'autre que GPL même si c'est une licence libre> puisse se linker à une bibliothèque GPL. OK, pour ça il y a la LGPL pour ça mais même la FSF la déconseille (http://www.gnu.org/licenses/why-not-lgpl.html). Je ne trouve pas que cette attitude soit bénéfique pour le logiciel libre en général (duplication de code inutile, etc...) car le logiciel libre ne se restreint pas à la GPL !
Petite question : QT est GPL mais les libs KDE sont LGPL -> comment est-ce possible ? Est-ce que cela signifie qu'on peut créer une appli non GPL utilisant les libs KDE sans devoir payer 1500$ à Trolltech ?
[^] # Re: C# et le libre...
Posté par karteum59 . En réponse à la dépêche talweg, une migration vers Mono. Évalué à 2.
A une certaine époque, j'avais lu (dans un bouquin de Perl qui parlait aussi un peu de Java) que la VM Java était d'assez bas-niveau (un peu comme un assembleur) alors que celle de Perl était de très haut niveau (appels directement traduisibles en appels de fonctions C), ce qui expliquait la différence de vitesse entre Perl et Java. Je pensais que la CLR était un peu comme la JVM, une sorte "d'émulateur" pour un proc virtuel, avec donc des instructions de très bas niveau...
Maintenant, si je comprends bien, la CLR possède des instructions de plus haut niveau que la JVM, permettant davantage d'optimisations en tout genre ?
Oui, mais je me dis que ça prend du temps de faire tous ces traitements (suffit de voir le temps de chargement d'une appli Java, ou le temps de compilation d'un programme C++ pour se dire qu'il vaut mieux les faire une fois pour toutes qu'à chaque lancement de l'appli). Du coup est-ce qu'on arrive quand même à concilier légèreté / rapidité de lancement avec toutes les optimisations en question ?
Donc il existe une manière de compiler du .NET en natif ? (comme avec gcj ?)
Ah, pendant que j'y suis, on parle beaucoup de Mono mais quid de DotGNU ? le second est une vraie alternative ou pas ?
[^] # Re: C# et le libre...
Posté par karteum59 . En réponse à la dépêche talweg, une migration vers Mono. Évalué à 4.
Je connais assez peu .NET mais je me pose régulièrement une question : pourquoi est-on obligé de passer par une machine virtuelle ? En effet, les avantages de .NET sont à ma connaissance :
- l'indépendance de la plate-forme (principal avantage de la VM, mais à mon avis ce n'était pas le but recherché par Microsoft)
- une API vaste et unifiée (mais pas besoin de créer une nouvelle plate-forme avec VM pour ça, c'est juste une histoire de mettre les moyens pour coder un bon framework et le rendre accessible depuis plein de langages)
- multi-langage (je vais peut-être dire une connerie mais il faut vraiment une VM pour ça ? y'aurait pas moyen de faire autrement, comme par exemple définir une ABI à laquelle tout le monde se conformerait ?)
- langages de haut niveau comme c#/delphi.NET/<votre_langage_favori> avec garbage collector, programmation fonctionnelle & co... (il existe déjà des langages compilés qui font tout ça, cf OCaml. Au pire il suffirait de coder un frontend c# pour gcc => pas besoin de VM non plus !)
Le principal avantage que je vois est d'avoir une machine virtuelle commune et bien optimisée pour les langages comme Perl/Python/Ruby (même si c'est aussi le but de Parrot, qui est apparemment spécialisée dans ce type de langages faiblement typés). A part ça, j'ai l'impression que le "manque" que .NET vient combler l'est / le serait tout aussi bien avec la mise au point d'une API bien foutue (style QT) + l'intégration de langages de haut niveau dans gcc (comme le D ou OCaml) + ABI facilitant l'interopérabilité du code objet entre différents langages.
Donc en gros, pourquoi l'avenir de l'informatique passerait t-il forcément par un dispositif avec une machine virtuelle ? (c'est quand même plus gros/lourd/lent que d'avoir un code qui s'execute directement non ?). Surtout que
- les logiciels libres n'ont besoin que d'une API portable (possibilité de recompiler pour chaque architecture)
- Microsoft ne recherche à mon avis pas vraiment à favoriser la portabilité (je ne vois pas quel est leur intérêt de promouvoir une telle architecture)
- les autres éditeurs de logiciels (propriétaires) peuvent être intéressés par l'aspect multi plates-formes, mais là encore une simple API portable (comme QT) résoud la majeure partie du problème (il suffit de compiler pour chaque architecture, mais ça reste la même base de code)
[^] # Re: Enfin !
Posté par karteum59 . En réponse à la dépêche Gnash, le lecteur Flash libre. Évalué à 5.
1) ce n'est pas la carte 3D qui se plie aux specs opengl mais plutôt le contraire (pilote opengl qui s'adapte au matos 3D)
2) mesa est bien 100% soft à l'origine, mais dans le cadre de l'architecture dri elle sert de base à une version "accélérée" (en fonction de ton driver). Par contre, dans l'exemple de ma nvidia (qui n'utilise pas le dri), si j'utilise le pilote libre nv + mesa "de base", alors je n'ai aucune accélération. (peut-être que ça ramera moins le jour où tous les ordinateurs du monde seront équipés de processeurs Cell, mais d'ici là... ;)
3) le rendu 2D ne sera pas près de s'estomper tant qu'on continuera de vouloir l'utiliser systématiquement ou de freiner les projets plus innovants sous couvert de rétro-compatibilité (ce qui risque d'être toujours le cas tant que les drivers 3D libre poseront problème). Et après tout, même le mode texte n'a pas isparu des cartes graphiques actuelles et reste utilisé sur de petites machines ou des serveurs
[^] # Re: Enfin !
Posté par karteum59 . En réponse à la dépêche Gnash, le lecteur Flash libre. Évalué à 4.
Le problème des drivers libres est effectivement un prérequis important, mais c'est le problème d'une autre équipe, pas de glash qui doit chercher à faire le meilleur soft possible et éviter de réinventer la roue. Maintenant c'est vrai qu'ils auraient aussi pu se baser sur cairo ou evas...
[^] # Re: Enfin !
Posté par karteum59 . En réponse à la dépêche Gnash, le lecteur Flash libre. Évalué à 10.
- 80% des fonctionnalités nécessaires sont déjà dans OpenGL (rendu vectoriel, transformations, transparence, antialiasing...), ce qui permet d'alléger le code et donc d'éviter des bugs. Aujourd'hui la plupart des machines de bureau (celles susceptibles de faire tourner du flash) ont des cartes 3D (donc l'utilisateur a payé pour une puce contenant à 90% des fonctions 3D, autant les utiliser !).
- le rendu logiciel est très gourmand (essaie de jouer une video flash en plein écran, même sur une machine "correcte" de 1GHz). A contrario, OpenGL décharge le proc et est _très_ rapide même avec du code lisible (i.e. sans assembleur, non optimisé pour tel ou tel proc, etc...). La 2D vectorielle est en fait plus proche du rendu 3D (intrinsèquement vectoriel) que de la 2D bitmap. Dans ce domaine, le matériel 3D peut souvent faire des chose très sympathiques (effets de transparence, lumière, etc) inimaginables autrement à moins d'avoir un proc très puissant. Regarde les jeux comme critter ou chromium, et des projets comme e17/evas, cairo/glitz, Arthur/QT4, xgl, et un peu plus loin de nous Quartz extreme/MacOSX... Et pas besoin de machine super récentes : un PII400+RivaTNT peut déjà faire des choses très sympathiques !
- rien n'empêche de coder un backend purement SDL si ça motive du monde (mais à mon avis ça risque de ramer...)
[^] # Re: Manipulation
Posté par karteum59 . En réponse à la dépêche Projet de loi DADVSI: EUCD.INFO publie un dossier d'information complet et un appel. Évalué à 2.
[^] # Re: les potes a MISC
Posté par karteum59 . En réponse à la dépêche Revue de Presse - Novembre 2005. Évalué à -1.
LP est quand même loin d'un "voici" de la presse informatique !
[^] # Re: Linux mag & CD
Posté par karteum59 . En réponse à la dépêche Revue de Presse - Novembre 2005. Évalué à 1.
Je ne sais pas trop comment se déroule l'assemblage, mais j'imagine que l'insertion du CD dans sa pochette est la dernière opération non ? -> la machine qui s'en charge se bloquerait t-elle si elle était toujours approvisionnée en magazines d'un côté mais pas en CD de l'autre ? Autrement dit peut-on envisager comme solution d'avoir une unique chaîne de production avec simplement un défaut de CDs par rapport au nombre de mags ?
[^] # Re: Linux mag & CD
Posté par karteum59 . En réponse à la dépêche Revue de Presse - Novembre 2005. Évalué à 2.
D'autre part, 15F de plus (de ~20F à 35F à l'époque) juste pour le CD : il avait intérêt à être beaucoup beaucoup plus résistant qu'un CD-R et à avoir vraiment un contenu "qui se garde"... (rare dans le monde du libre). En fait à l'époque j'ai surtout eu l'impression que supprimer la version sans CD était une manière déguisée d'augmenter le prix du magazine (cela dit c'était peut-être légitime face aux coûts de production - je ne veux pas troller, ça n'est qu'une impression, je doute que le CD à lui seul ait un coût unitaire de l'ordre des 15F)
Je comprends qu'une demande asymétrique ait entraîné l'abandon de la double version en kiosque (vu que ça doit avoir un coût logistique qu'il faut rentabiliser). Par contre je ne vois pas vraiment pourquoi ne pas avoir maintenu la double version par abonnement, même avec une demande faible. De toutes façons, les éventuels stocks résiduels se seraient probablement écoulés lors des commandes de versions antérieures du magazine (si je commande un vieux n° de LM, à fortiori le CD ne me sert à rien puisqu'il est largement obsolète. Je préfère payer moins cher et ne pas avoir de CD !)
Mais bon, c'est du passé, ce qui compte c'est l'avenir !
# Linux mag & CD
Posté par karteum59 . En réponse à la dépêche Revue de Presse - Novembre 2005. Évalué à 4.
Sinon (à l'inverse) je pense qu'une majorité des lecteurs utilisant le CD possède maintenant un lecteur DVD -> pourquoi ne pas passer définitivement au DVD ? (comme vos concurrents polonais...). ça ouvre des perspectives, comme par ex d'inclure une nouvelle distrib (ou au contraire la même à chaque fois, comme Aurox) dans chaque n°, ou bien de mettre toutes les contribs mandriva dans un seul n°...
Enfin, à quand des "powerpacks" pour MISC ?
# Mono ou DotGNU ?
Posté par karteum59 . En réponse à la dépêche Interview De Icaza et actualité Mono. Évalué à 4.
Autre chose : est-il envisageable / prévu de concevoir un frontend à GCC (CLR->RTL) un peu comme gcj ?
[^] # Re: La 3D == gamers???
Posté par karteum59 . En réponse à la dépêche Projet Open Graphic : les premières cartes de test avant la fin de l'année !. Évalué à 2.
[^] # Re: Révolution
Posté par karteum59 . En réponse à la dépêche Sortie d'Amaya 8.8 et 9.2. Évalué à 2.
-> http://www.webstandards.org/act/acid2/test.html(...)
[^] # Re: La PS3 aura sa distrib Linux
Posté par karteum59 . En réponse à la dépêche Port de Linux sur le processeur Cell. Évalué à 1.
(qui sait, peut-être qu'on vendra des Télécran dans quelques années (en 1984+25 ans ?). Peut-être même qu'il y aura marqué PS4 dessus...)
[^] # Re: Libre, propriétaire et mp3
Posté par karteum59 . En réponse à la dépêche La Fedora Core 4 débarque. Évalué à 1.
Dans le cas du MP3 / xvid je me demande si le problème vient vraiment des brevets de pressions de la MPAA...
Et puis, quand bien même y'aurait problème de brevets normalement c'est le _concepteur_ du logiciel contrefait qui risque un procès et non le dsitributeur, non ?
[^] # Re: Hum
Posté par karteum59 . En réponse à la dépêche Sortie de WaveMixer 0.3. Évalué à 1.
Et par la même occasion, est-ce que gstreamer concurrence Jack ou est-ce que c'est complémentaire ? -> http://jackit.sourceforge.net/(...)
Il me semblait que ce dernier était voué à devenir LE serveur de son low-latency (vu qu'il est même recommandé par alsa-project.org).
D'autre part, j'ai aussi entendu qqart que KDE pourrait utiliser gstreamer dans le futur mais quid de la dépendance glib dans ce cas ? qqun peut confirmer ? (no troll inside, c'est juste une question)
[^] # Re: Dommage ...
Posté par karteum59 . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 4.
Et si le programmeur connaît le C/C++ (comme moi), il veut aussi pouvoir s'y mettre rapidement en se raccrochant autant que possible à ce qu'il connaît. Ce serait une bonne chose si les concepteurs de OCaml écrivaient un bouquin/tutoriel visant le programmeur moyen (pas forcément étudiant en informatique) avec un peu plus de concrêt, genre un "OCaml pour les programmeurs C/C++, avec des exemples utilisant QT, OpenGL, SDL...
Enfin, apparemment (je ne maîtrise pas le sujet) il semble y avoir une véritable barrière à l'entrée pour les débutants qui voudraient utiliser OCaml avec des libs en C (pour lesquelles aucun binding officiel n'aurait été écrit). Notamment je crois qu'il faut faire gaffe à des détails liés au gc...
[^] # Re: et l'essentiel?
Posté par karteum59 . En réponse à la dépêche Sylpheed-Claws: Changement de direction. Évalué à 1.
<ma vie>J'utilise régulièrement AtheOS/SyllableOS sur ma machine perso, et on ne va pas dire que c'est du vieil OS qui n'a pas bougé depuis 10 ans ou qui est super stable...</ma vie>
J'ai simplement dit qu'il y avait d'autres solutions à ce problème (parallélisation du lancement des services), directement implémentable dans les distributions "stables" et sans toucher à init. Maintenant peut-être que init a d'autres carences à combler et c'est très bien que des gens s'y attellent, mais c'est un autre débat !
A l'heure actuelle j'imagine mal une distrib "stable" ou grand public utiliser un init expérimental, alors que la solution que j'ai donnée est directement utilisable aujourd'hui et maintenant. Evidemment rien n'empêchera ces mêmes distribs d'utiliser une alternative à init le moment venu et quand elle sera finalisée mais c'est à plus long terme et il n'y a pas besoin d'attendre ça pour paralléliser le lancement des services...
[^] # Re: et l'essentiel?
Posté par karteum59 . En réponse à la dépêche Sylpheed-Claws: Changement de direction. Évalué à 1.
Je trouve juste que à l'heure actuelle Linux+X11+KDE est _vraiment_ lent à booter (sur le même matériel) là où la "concurrence" a fait de gros progrès, et je pense que des modifications simples (démarrages parallèles des services) pourraient changer la donne.
[^] # Re: et l'essentiel?
Posté par karteum59 . En réponse à la dépêche Sylpheed-Claws: Changement de direction. Évalué à -1.
KDE n'est pas gros pq codé avec les pieds (m'enfin, j'en connais qui me diraient que le c++/templates...). KDE est gros pq il a beaucoup de fonctionnalités. OK, on ne les utilise pas forcément (WindowMaker me convient personnellement) mais c'est ce qui lui permet de soutenir la comparaison avec windoze (contrairement à icewm ou fluxbox).
[^] # Re: et l'essentiel?
Posté par karteum59 . En réponse à la dépêche Sylpheed-Claws: Changement de direction. Évalué à 1.
ça fait longtemps que l'idée de démarrer les services en parallèle existe.
-> http://www-106.ibm.com/developerworks/linux/library/l-boot.html(...)
Une implémentation triviale ne change pas init mais utilise "Make -j" avec un ou des Makefiles ad'hoc à la place de ces immondes liens symboliques dans rc*.d. C'est tellement simple et limpide qu'on se demande pourquoi personne ne l'a utilisé avant... (sans doute parce que tous les wizards comme webmin et linuxconf utilisent ce système, mais à tout problème y'a des solutions, surtout quand le jeu en vaut la chandelle...).
Personnellement je préfère cette approche (ou toute autre qui ne touche qu'aux initscripts et pas à init lui-même) pq init est stable (alors qu'un initng0.0.1 le sera forcément moins) et que c'est un programme important tout de même ! :)
[^] # Et FOX-toolkit ?
Posté par karteum59 . En réponse à la dépêche wxWidgets 2.6 est sorti. Évalué à 4.
Techniquement, il serait plutôt à rapprocher de QT (C++, facile à utiliser (mais sans MOC), multi plates-formes, dessine lui-même ses trucs contrairement à wx, etc...), mais
- LGPL
- très complet pour la GUI. Contrairement à QT ou wx il ne cherche pas à être un framework complet mais se concentre uniquement sur la GUI.
- léger & rapide, mais pas encore thémable (look&feel "winowsien" par défaut. On aime ou on n'aime pas... Pour ma part ça ne me gène pas trop vu ses autres qualités)
- bien supporté sous d'autres langages (notamment ruby)
- et surtout, très stable bien qu'en évolution assez active.
-> http://www.fox-toolkit.org(...)
Par contre je dois avouer que les fonctionnalités annoncées de QT4 sont séduisantes (notamment le canvas OpenGL, à faire pâlir Rasterman et son evas. J'en ai rêvé, ils l'ont fait !). QT aura toujours un cran d'avance, mais ça se paye ! (du moins si on développe des applis commerciales)