Après je ne sais pas ce que vaut mon raisonnement....je suis curieux de voir les autres réponses !
Il est tout à fait bienvenu ! Je n'avais pas pensé plus que ça au rendement de l'alimentation. Voilà une réflexion qui change la donne, merci beaucoup.
J'espère que ça va donner envie aux programmeurs Python qui voudraient passer à un langage qui a au moins la même expressivité que Python et qui est plus rapide et plus fiable (typage statique...)
Ou alors ils peuvent utiliser Cython [http://cython.org/] pour certains morceaux de leur programme (typage statique possible et même conseillé pour obtenir des performances assez proches du C il parait).
Cela dit, Scala semble être un langage intéressant, que je n'ai regardé que de loin sans le pratiquer. En fait, le soucis avec les langages sur la JVM me semble du côté de la consommation mémoire [http://shootout.alioth.debian.org/u32/benchmark.php?test=all(...)]. Constatation réelle ou non significative ?
En fait il s'agirait de rester sur le choix proposé par défaut et de pouvoir, dans certains cas, employer une autre version. Un exemple serait de dire à son serveur HTTP qu'il va utiliser PHP 5.3 et non la version 5.1 proposée par défaut.
De fait, n'est-il pas possible de compiler ladite nouvelle version dans /usr/local et d'appeler un exécutable différent (/usr/local/bin/php53 et non /usr/bin/php) ? J'ai bien conscience que cela peut impliquer de compiler davantage de choses que le seul langage.
Dans cet ordre d'idée, j'ai d'ailleurs re-découvert tout à l'heure une possible solution sous Debian avec le script update-alternatives[1, 2 et 3]. Visiblement, il est grâce à lui possible de choisir quelle alternative sera préférée, au niveau du système et certainement au niveau de l'utilisateur.
Par contre, je ne comprends pas bien en quoi Gentoo ou FreeBSD y arriveraient mieux là-dessus ? (bon, je ne les connais pas bien)
En effet, c'est peut-être un à priori. Je vois que sous FreeBSD il est souvent proposé de multiples versions de certains programmes, dont les langages de programmation[4]. J'avais l'impression qu'il était possible de facilement définir quelle serait celle préférée par défaut[5], tout en pouvant en appeler d'autres.
Tu as entièrement raison, ce que je demande plus haut est tout à fait possible sous Arch et même assez facilement.
En fait, et j'aurais certainement du le préciser, je m'intéresse à Gentoo dans une perspective serveur.
J'adore Arch et malgré la sortie d'un kernel-lts, j'hésite quand même à l'utiliser dans ce cadre. Le choix se fera sur pas mal de critères. J'ai d'ailleurs demandé conseil sur certains d'entre eux aujourd'hui (questions dispatchées dans plusieurs forums).
J'ai un peu avancé aujourd'hui face aux questions soulevées ici. Pour ceux que ça intéresse :
- Le déploiement *CGI - Perl, Python... ou ELF si c'est possible - ne semble pas être la panacée car, en tout cas chez un certain nombre d'hébergeurs mutualisés, seul le CGI simple est disponible. En gros, il faut vraiment avoir peu de visiteurs pour que les performances restent acceptables.
- Je me rends compte également que, dans le cas de Python, lorsque celui-ci est disponible via CGI, il s'agit encore bien souvent de la branche 2.4, arrivée en 2004 alors que la 2.5 a fait son apparition en 2006. Ceci est souvent dû aux dépôts de Debian Etch et / ou de CentOS/RHEL 5.x mais ça limite de plus en plus le choix des technologies à employer.
Bref, dans le royaume du Web mutualisé et à bas prix, le PHP reste très souvent le roi. Une idée pourrait être de produire du PHP sans en écrire, comme avec haXe[1], le langage qui se compile vers un tas d'autres.
Dans le même ordre d'idée, j'ai moi aussi quelques questions à vous poser :
- Prévoyez-vous une soumission au Shootout[1] ? Vala, dont vous parlez plus haut n'a pas, il me semble, été accepté mais les résultats paraissaient plutôt bons[2] et proches du C. Où pensez-vous que se situe OOC en termes de performances ? Peut-on d'ores et déjà l'estimer au dessus de ce qu'obtiennent Java ou C# Mono ?
- En dehors de Vala, OOC me fait également penser à Go. Certes Go n'est pas un langage objet et de nombreuses choses différencient les deux langages. Néanmoins, il semblerait que Go essaie à moyen terme de trouver un bon compromis entre performances brutes, concurrence, simplicité de développement (dont le temps de compilation) et batteries incluses. Comment OOC se positionne-t-il au niveau de la concurrence ? Par rapport au développement, si je comprends bien, cela se passe comme Vala : une première compilation ou traduction vers du C puis une seconde phase par un compilateur C. Est-ce que cela ne risque pas de rendre le développement de programmes complexes assez long ? (bien des aspects m'échappent certainement, étant donnée mon inculture des langages compilés et de leurs écosystèmes, d'où la question !)
- Il existe un micro-framework[3] orienté développement Web pour OOC; imaginez-vous qu'OOC puisse être employé dans ce cadre ou n'est-ce pas vraiment le but ?
- Ruby a RoR, Vala a l'environnement Gnome, Go a Google et une équipe renommée - je sursimplifie, veuillez m'en excuser - pensez-vous à orienter consciemment OOC vers un certain type de développement (bases de données, jeux vidéo... ) ?
Il est vrai que la situation est meilleure aujourd'hui.
La norme 1.2 semble toujours en cours d'élaboration[1]. La version 1.1 et celle-ci apportent, selon Wikipedia[2] : une meilleure prise en charge de l'accessibilité, des métadonnées Dublin Core et RDF, des formules pour le tableur basées sur OpenFormula, le support des signatures...
Je n'ai pas davantage de détails mais un plongeon dans le brouillon[3] pourra éclairer les motivés.
Le poids plume que représente Slitaz est fréquemment comparé à d'autres distributions de sa catégorie.
TuxRadar s'est prêté[1] récemment à ce jeu et a mis côte à côte Slitaz, Crunchbang[2], Puppy[3] (dont la variante fr est Toutou[4]), Damn Small Linux[5], Lubuntu[6], Tiny Core[7], Unity Linux[8] et enfin VectorLinux[9].
Chacune a été testée sur un Pentium 200Mhz doté de 256Mo de RAM. Le choix du magazine s'est porté sur Slitaz, qui finit première devant Crunchbang :
There can be only one winner in the context of our group test, and it should be Slitaz. It's fast, easy on memory, and comes with a considered selection of apps. Not being able to install new software easily apart from stuff in the Slitaz package format is one of the few drawbacks, but for a fast, lightweight desktop it's hard to beat.
Il est vrai que l'immense majorité des projets Apache semble développée en Java. Malgré tout, ce n'est pas le cas de tous (je pense notamment à CouchDB, en Erlang).
Visiblement, si j'en crois Wikipédia [http://en.wikipedia.org/wiki/Apache_Foundation] En, les projets de la fondation Apache ont en commun : The Apache projects are characterized by a collaborative, consensus-based development process and an open and pragmatic software license. Each project is managed by a self-selected team of technical experts who are active contributors to the project.[...]
Among the ASF's objectives are to provide legal protection to volunteers working on Apache projects, and to prevent the Apache brand name from being used by other organizations without permission...
Merci patrick_g pour cette dépêche, comme toujours très intéressante.
Une petite question : en janvier dernier, il avait été annoncé sur la liste gcc-dev [http://thread.gmane.org/gmane.comp.gcc.devel/111603/focus=11(...)] que GCCGO, l'un des deux compilateurs du langage de programmation de Google, serait inclus dans GCC 4.5 or later.
Visiblement, il n'a pas été intégré dans la 4.5, avez-vous des nouvelles à ce propos ? Je ne suis pas bien au courant de la manière dont cela se passe mais l'acceptation du comité GCC signifie-t-il que GCCGO fera partie du compilateur standard, au même titre que g++, GNAT... ?
Il est vrai que Vala semble avoir de bonnes armes pour aider au développement d'applications GTK. La question que je me pose est de savoir si Vala est voué à se cantonner aux applications de bureau et à GTK / Gobject ou s'il pourrait aller dans d'autres domaines.
Car en dehors de la différence dynamique / statique et compilé / interprété (je me doute qu'il y en a bien d'autres mais je connais trop mal Vala), Python bénéficie d'une forte communauté, forgée dans le temps certes mais qui lui permet d'être employé pour énormément de choses aujourd'hui. D'ailleurs, le soucis des performances semble être en partie compensable (je pense surtout à Cython voire à Psyco, en attendant les avancées d'Unladen / Pypy ).
Étant données les performances de Vala et malgré la dépendance à GObject, pourrait-il aller dans l'embarqué ?
Autre domaine potentiel : le Web. En dehors d'une expérimentation FCGI [https://launchpad.net/libvfcgi], je pense notamment à Blitzen, serveur d'application en développement et présenté il y a quelques temps par Samos [http://linuxfr.org/~Samos/28924.html].
Et tant qu'à élargir (trop ?), je me demande aussi si Go ne pourrait pas à terme se poser en concurrent de Vala / Python dans le cadre de GTK. Le langage est très jeune, pas réellement objet, mais serait plutôt performant - version gccgo -, viserait entre autres ceux qui font du C et son lien vers GTK, bien que tiers, parait vivant [http://github.com/mattn/go-gtk].
Parmi les références, il y a le site LangPop [http://langpop.com/] qui essaie de mesurer la popularité selon divers moyens comme le nombre de recherches sur Yahoo, l'offre de jobs sur Craiglist, le nombre de livres vendus chez Powell ou encore les actualités Reddit, le nombre d'utilisateurs IRC...
Ca reste toujours partiel mais peut-être plus large et mieux décrit. En revanche, la timeline proposée ne semble pas à première vue très précise et il est difficile de coroborer les résultats de Tiobe (notamment par rapport à Go, non intégré pour le moment).
Bonjour et bravo à vous et aux autres participants pour tout ce travail.
Maintenant que le site et Setup sont en bonne voie, quels sont vos plans pour la suite de Logram ? Sur quoi comptez-vous vous concentrer ?
Par rapport à l'environnement de bureau, Panache - s'il n'a pas changé de nom - est l'un des rares environnements à se baser sur QT; quelles sont les grandes étapes à suivre avant l'arrivée d'une version stable ?
PS : pour ceux que cela intéresse, il existe un panache-git via l'AUR de ArchLinux.
De mémoire, RadeonHD avait notamment été créé pour prendre en charge des cartes récentes, ce que ne faisait pas le pilote Radeon à l'époque. Radeon aussi a profité des spécifications d'AMD. Or, aujourd'hui, Radeon a largement rattrapé son retard sur ce point puisque la 3D, certes expérimentale, semble active jusqu'aux HD4xxx et que la HD5xxxx fonctionne sans accélération.
De fait, on peut se demander l'intérêt actuel du pilote RadeonHD, qui semble évoluer moins vite, notamment, il me semble, parce qu'ils ne voulaient pas utiliser l'AtomBIOS [voir http://www.phoronix.com/scan.php?page=article&item=radeo(...)], ce qui n'est plus le cas aujourd'hui. Si quelqu'un pouvait éclairer ce point :)
Une solution pourrait être de regarder du côté de Seamonkey, qui me paraissait plus "léger" que Firefox, un comble certes. Un certain nombre d'extensions sont compatibles, dont FireBug mais visiblement pas WebDeveloper.
Sinon, je suis tombé récemment sur Conkeror [http://conkeror.org/] (non pas celui de KDE), qui est un navigateur sous moteur Gecko compatible avec FireBug Lite et très léger. Par contre il peut s'avérer déroutant puisqu'il se commande au clavier.
Merci pour ce journal qui m'a permis de (re)découvrir une association qui me parait jouer un rôle véritablement important, surtout vus les risques latents qui pèsent sur la liberté sur Internet.
Vous avez mon soutien, j'espère qu'il pourra bientôt se transformer en temps.
Cela dit, avec une installation ultra minimale et un choix fin des paquets, il est peut-être possible d'avoir un environnement graphique sous Debian, ArchLinux, Slackware... (les trois demandant à minima 64Mo).
Par rapport à tes remarques sur Javascript et l'attente d'ECMA v4, j'ai récemment redécouvert haXe, un langage et compilateur qui pourrait t'intéresser car il est traduit vers plusieurs plate-formes et langages, dont Javascript.
Ne développant pas - encore - en haXe, je ne saurai juger de la qualité du code produit mais le langage, orienté objet, apporte un certain nombre de choses dont certaines font partie de l'ECMA v4. Pour plus de détails, je vous renvoie sur le site officiel, qui parlera bien mieux que moi des spécificités du langage :
[http://haxe.org/doc/intro]
[http://haxe.org/doc/features]
[http://haxe.org/doc/why]
[^] # Re: Est-ce une bonne idée....
Posté par Yakulu . En réponse au message Serveur domestique polyvalent et consommation reduite. Évalué à 1.
Il est tout à fait bienvenu ! Je n'avais pas pensé plus que ça au rendement de l'alimentation. Voilà une réflexion qui change la donne, merci beaucoup.
[^] # Re: Scala
Posté par Yakulu . En réponse au journal Javascript plus rapide que python ! (une suite possible). Évalué à 1.
Ou alors ils peuvent utiliser Cython [http://cython.org/] pour certains morceaux de leur programme (typage statique possible et même conseillé pour obtenir des performances assez proches du C il parait).
Cela dit, Scala semble être un langage intéressant, que je n'ai regardé que de loin sans le pratiquer. En fait, le soucis avec les langages sur la JVM me semble du côté de la consommation mémoire [http://shootout.alioth.debian.org/u32/benchmark.php?test=all(...)]. Constatation réelle ou non significative ?
# Merci
Posté par Yakulu . En réponse au message Confiner un processus. Évalué à 2.
[^] # Re: Un bout de solution
Posté par Yakulu . En réponse au message Cohabitation de versions différentes d'un même paquet. Évalué à 1.
En fait il s'agirait de rester sur le choix proposé par défaut et de pouvoir, dans certains cas, employer une autre version. Un exemple serait de dire à son serveur HTTP qu'il va utiliser PHP 5.3 et non la version 5.1 proposée par défaut.
De fait, n'est-il pas possible de compiler ladite nouvelle version dans /usr/local et d'appeler un exécutable différent (/usr/local/bin/php53 et non /usr/bin/php) ? J'ai bien conscience que cela peut impliquer de compiler davantage de choses que le seul langage.
Dans cet ordre d'idée, j'ai d'ailleurs re-découvert tout à l'heure une possible solution sous Debian avec le script update-alternatives[1, 2 et 3]. Visiblement, il est grâce à lui possible de choisir quelle alternative sera préférée, au niveau du système et certainement au niveau de l'utilisateur.
Par contre, je ne comprends pas bien en quoi Gentoo ou FreeBSD y arriveraient mieux là-dessus ? (bon, je ne les connais pas bien)
En effet, c'est peut-être un à priori. Je vois que sous FreeBSD il est souvent proposé de multiples versions de certains programmes, dont les langages de programmation[4]. J'avais l'impression qu'il était possible de facilement définir quelle serait celle préférée par défaut[5], tout en pouvant en appeler d'autres.
1 : http://linux.die.net/man/8/update-alternatives
2 : http://linuxbasics.org/tutorials/using/debian_update-alterna(...)
3 : http://www.debian.org/doc/FAQ/ch-customizing.en.html#s-diver(...)
4 : http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/#dirlist
5 : http://forums.freebsd.org/showthread.php?t=1390
[^] # Re: pas compris
Posté par Yakulu . En réponse au message Mélange binaires et sources. Évalué à 2.
En fait, et j'aurais certainement du le préciser, je m'intéresse à Gentoo dans une perspective serveur.
J'adore Arch et malgré la sortie d'un kernel-lts, j'hésite quand même à l'utiliser dans ce cadre. Le choix se fera sur pas mal de critères. J'ai d'ailleurs demandé conseil sur certains d'entre eux aujourd'hui (questions dispatchées dans plusieurs forums).
# Premiers éléments de réponses
Posté par Yakulu . En réponse au message Applications Web en FCGI. Évalué à 3.
- Le déploiement *CGI - Perl, Python... ou ELF si c'est possible - ne semble pas être la panacée car, en tout cas chez un certain nombre d'hébergeurs mutualisés, seul le CGI simple est disponible. En gros, il faut vraiment avoir peu de visiteurs pour que les performances restent acceptables.
- Je me rends compte également que, dans le cas de Python, lorsque celui-ci est disponible via CGI, il s'agit encore bien souvent de la branche 2.4, arrivée en 2004 alors que la 2.5 a fait son apparition en 2006. Ceci est souvent dû aux dépôts de Debian Etch et / ou de CentOS/RHEL 5.x mais ça limite de plus en plus le choix des technologies à employer.
Bref, dans le royaume du Web mutualisé et à bas prix, le PHP reste très souvent le roi. Une idée pourrait être de produire du PHP sans en écrire, comme avec haXe[1], le langage qui se compile vers un tas d'autres.
[1] : http://haxe.org/doc/intro
[^] # Re: C'est quoi Grong
Posté par Yakulu . En réponse à la dépêche Conférence Parinux - Le langage de programmation GO. Évalué à 2.
grong - Small authoritative DNS name server by Stéphane Bortzmeyer (aka bortzmeyer)
Plus de détails sont disponibles, toujours en anglais, sur le readme GitHub : [http://github.com/bortzmeyer/grong]
[^] # Re: Joli
Posté par Yakulu . En réponse à la dépêche Le langage ooc auto-hébergé - les nouveautés de rock 0.9.0. Évalué à 8.
- Prévoyez-vous une soumission au Shootout[1] ? Vala, dont vous parlez plus haut n'a pas, il me semble, été accepté mais les résultats paraissaient plutôt bons[2] et proches du C. Où pensez-vous que se situe OOC en termes de performances ? Peut-on d'ores et déjà l'estimer au dessus de ce qu'obtiennent Java ou C# Mono ?
- En dehors de Vala, OOC me fait également penser à Go. Certes Go n'est pas un langage objet et de nombreuses choses différencient les deux langages. Néanmoins, il semblerait que Go essaie à moyen terme de trouver un bon compromis entre performances brutes, concurrence, simplicité de développement (dont le temps de compilation) et batteries incluses. Comment OOC se positionne-t-il au niveau de la concurrence ? Par rapport au développement, si je comprends bien, cela se passe comme Vala : une première compilation ou traduction vers du C puis une seconde phase par un compilateur C. Est-ce que cela ne risque pas de rendre le développement de programmes complexes assez long ? (bien des aspects m'échappent certainement, étant donnée mon inculture des langages compilés et de leurs écosystèmes, d'où la question !)
- Il existe un micro-framework[3] orienté développement Web pour OOC; imaginez-vous qu'OOC puisse être employé dans ce cadre ou n'est-ce pas vraiment le but ?
- Ruby a RoR, Vala a l'environnement Gnome, Go a Google et une équipe renommée - je sursimplifie, veuillez m'en excuser - pensez-vous à orienter consciemment OOC vers un certain type de développement (bases de données, jeux vidéo... ) ?
En tout cas bravo.
1 : [http://shootout.alioth.debian.org/]
2 : [http://code.google.com/p/vala-benchmarks/wiki/BenchResults]
3 : [http://github.com/joshthecoder/ooc-web]
[^] # Re: Hein ?
Posté par Yakulu . En réponse au journal Oracle rend payant le plugin ODF pour Office. Évalué à 1.
La norme 1.2 semble toujours en cours d'élaboration[1]. La version 1.1 et celle-ci apportent, selon Wikipedia[2] : une meilleure prise en charge de l'accessibilité, des métadonnées Dublin Core et RDF, des formules pour le tableur basées sur OpenFormula, le support des signatures...
Je n'ai pas davantage de détails mais un plongeon dans le brouillon[3] pourra éclairer les motivés.
1 : [http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=o(...)]
2 : [http://en.wikipedia.org/wiki/OpenDocument#Standardization]
3 : [http://docs.oasis-open.org/office/v1.2/part1/cd04/OpenDocume(...)]
# Comparatif de distributions allégées
Posté par Yakulu . En réponse à la dépêche SliTaz GNU/Linux 3.0. Évalué à 10.
TuxRadar s'est prêté[1] récemment à ce jeu et a mis côte à côte Slitaz, Crunchbang[2], Puppy[3] (dont la variante fr est Toutou[4]), Damn Small Linux[5], Lubuntu[6], Tiny Core[7], Unity Linux[8] et enfin VectorLinux[9].
Chacune a été testée sur un Pentium 200Mhz doté de 256Mo de RAM. Le choix du magazine s'est porté sur Slitaz, qui finit première devant Crunchbang :
There can be only one winner in the context of our group test, and it should be Slitaz. It's fast, easy on memory, and comes with a considered selection of apps. Not being able to install new software easily apart from stuff in the Slitaz package format is one of the few drawbacks, but for a fast, lightweight desktop it's hard to beat.
1 : [http://tuxradar.com/content/whats-best-lightweight-linux-dis(...)]
2 : [http://crunchbanglinux.org/]
3 : [http://www.puppylinux.com/]
4 : [http://toutoulinux.free.fr/]
5 : [http://www.damnsmalllinux.org/]
6 : [http://lubuntu.net/]
7 : [http://www.tinycorelinux.com/]
8 : [http://unity-linux.org/]
9 : [http://www.vectorlinux.com/]
[^] # Re: Fondation Apache et Java
Posté par Yakulu . En réponse à la dépêche La fondation Apache sort Cassandra 0.6. Évalué à 5.
Pour une liste détaillée, il faudra se référer à cette page : [http://projects.apache.org/indexes/language.html].
Visiblement, si j'en crois Wikipédia [http://en.wikipedia.org/wiki/Apache_Foundation] En, les projets de la fondation Apache ont en commun :
The Apache projects are characterized by a collaborative, consensus-based development process and an open and pragmatic software license. Each project is managed by a self-selected team of technical experts who are active contributors to the project.[...]
Among the ASF's objectives are to provide legal protection to volunteers working on Apache projects, and to prevent the Apache brand name from being used by other organizations without permission...
[^] # Re: kvm limité ?
Posté par Yakulu . En réponse au message Virtualisation et vx-t. Évalué à 4.
# GCCGO
Posté par Yakulu . En réponse à la dépêche Sortie de GCC 4.5. Évalué à 4.
Une petite question : en janvier dernier, il avait été annoncé sur la liste gcc-dev [http://thread.gmane.org/gmane.comp.gcc.devel/111603/focus=11(...)] que GCCGO, l'un des deux compilateurs du langage de programmation de Google, serait inclus dans GCC 4.5 or later.
Visiblement, il n'a pas été intégré dans la 4.5, avez-vous des nouvelles à ce propos ? Je ne suis pas bien au courant de la manière dont cela se passe mais l'acceptation du comité GCC signifie-t-il que GCCGO fera partie du compilateur standard, au même titre que g++, GNAT... ?
Merci d'avance.
[^] # Re: Python vs Vala
Posté par Yakulu . En réponse à la dépêche Un combat de clients de microblogging. Évalué à 3.
Car en dehors de la différence dynamique / statique et compilé / interprété (je me doute qu'il y en a bien d'autres mais je connais trop mal Vala), Python bénéficie d'une forte communauté, forgée dans le temps certes mais qui lui permet d'être employé pour énormément de choses aujourd'hui. D'ailleurs, le soucis des performances semble être en partie compensable (je pense surtout à Cython voire à Psyco, en attendant les avancées d'Unladen / Pypy ).
Étant données les performances de Vala et malgré la dépendance à GObject, pourrait-il aller dans l'embarqué ?
Autre domaine potentiel : le Web. En dehors d'une expérimentation FCGI [https://launchpad.net/libvfcgi], je pense notamment à Blitzen, serveur d'application en développement et présenté il y a quelques temps par Samos [http://linuxfr.org/~Samos/28924.html].
Et tant qu'à élargir (trop ?), je me demande aussi si Go ne pourrait pas à terme se poser en concurrent de Vala / Python dans le cadre de GTK. Le langage est très jeune, pas réellement objet, mais serait plutôt performant - version gccgo -, viserait entre autres ceux qui font du C et son lien vers GTK, bien que tiers, parait vivant [http://github.com/mattn/go-gtk].
[^] # Re: Foutaises !
Posté par Yakulu . En réponse au journal Le langage C serait redevenu le langage le plus utilisé. Évalué à 6.
Parmi les références, il y a le site LangPop [http://langpop.com/] qui essaie de mesurer la popularité selon divers moyens comme le nombre de recherches sur Yahoo, l'offre de jobs sur Craiglist, le nombre de livres vendus chez Powell ou encore les actualités Reddit, le nombre d'utilisateurs IRC...
Ca reste toujours partiel mais peut-être plus large et mieux décrit. En revanche, la timeline proposée ne semble pas à première vue très précise et il est difficile de coroborer les résultats de Tiobe (notamment par rapport à Go, non intégré pour le moment).
# La suite
Posté par Yakulu . En réponse à la dépêche Le projet Logram fête ses deux ans. Évalué à 3.
Maintenant que le site et Setup sont en bonne voie, quels sont vos plans pour la suite de Logram ? Sur quoi comptez-vous vous concentrer ?
Par rapport à l'environnement de bureau, Panache - s'il n'a pas changé de nom - est l'un des rares environnements à se baser sur QT; quelles sont les grandes étapes à suivre avant l'arrivée d'une version stable ?
PS : pour ceux que cela intéresse, il existe un panache-git via l'AUR de ArchLinux.
[^] # Re: radeon VS radeonhd
Posté par Yakulu . En réponse au journal Ayé, de nouveaux pilotes pour carte ATI sont sortis !!! \o/. Évalué à 4.
De fait, on peut se demander l'intérêt actuel du pilote RadeonHD, qui semble évoluer moins vite, notamment, il me semble, parce qu'ils ne voulaient pas utiliser l'AtomBIOS [voir http://www.phoronix.com/scan.php?page=article&item=radeo(...)], ce qui n'est plus le cas aujourd'hui. Si quelqu'un pouvait éclairer ce point :)
[^] # Re: Extensions pour firefox
Posté par Yakulu . En réponse au message changement de distrib. Évalué à 1.
Sinon, je suis tombé récemment sur Conkeror [http://conkeror.org/] (non pas celui de KDE), qui est un navigateur sous moteur Gecko compatible avec FireBug Lite et très léger. Par contre il peut s'avérer déroutant puisqu'il se commande au clavier.
[^] # Re: Slitaz
Posté par Yakulu . En réponse au message Portable 233Mhz. Évalué à 1.
# Merci
Posté par Yakulu . En réponse au journal Toile-Libre : Réquisition judiciaire et appel aux dons. Évalué à 4.
Vous avez mon soutien, j'espère qu'il pourra bientôt se transformer en temps.
[^] # Re: Slitaz
Posté par Yakulu . En réponse au message Portable 233Mhz. Évalué à 2.
Le lien de l'ISO stable est ok chez moi [http://www.slitaz.org/fr/get/index.html#stable]
[^] # Re: Idées de distributions
Posté par Yakulu . En réponse au message Portable 233Mhz. Évalué à 1.
A noter que le wiki d'ArchLinux dispose d'une page bienvenue pour les applications légères : [http://wiki.archlinux.org/index.php/Lightweight_Applications].
# Idées de distributions
Posté par Yakulu . En réponse au message Portable 233Mhz. Évalué à 2.
C'est la mémoire qui me semble le plus gros handicap ici. Parmi la liste de distributions possibles / envisageables, il y a peut-être plus récent, dont :
* SliTaz [http://www.slitaz.org/fr/doc/handbook/index.html]
* ToutouLinux (version française de Puppy) [http://www.moulinier.net/]
Si la RAM venait à manquer, des distributions comme DeLi [http://www.delilinux.de/index-fr.html] devraient faire l'affaire.
Cela dit, avec une installation ultra minimale et un choix fin des paquets, il est peut-être possible d'avoir un environnement graphique sous Debian, ArchLinux, Slackware... (les trois demandant à minima 64Mo).
Bon courage !
[^] # Re: Aie !
Posté par Yakulu . En réponse au journal Amarok 1.4 revient sous le nom de Clémentine. Évalué à 2.
* Panache du projet Logram ( http://www.logram-project.org/ )
* Antico ( http://www.antico.netsons.org/index.html )
Je n'ai testé aucun des deux par contre et ne suis pas sûr que beaucoup de paquets existent.
[^] # Re: ExtJs
Posté par Yakulu . En réponse au sondage Ma bibliothèque javascript préférée. Évalué à 1.
Ne développant pas - encore - en haXe, je ne saurai juger de la qualité du code produit mais le langage, orienté objet, apporte un certain nombre de choses dont certaines font partie de l'ECMA v4. Pour plus de détails, je vous renvoie sur le site officiel, qui parlera bien mieux que moi des spécificités du langage :
[http://haxe.org/doc/intro]
[http://haxe.org/doc/features]
[http://haxe.org/doc/why]