Thomas Cataldo a écrit 205 commentaires

Java n'est utile dans OO.org que pour écrire des extensions plus vite qu'en c++, et pour connecter à des sources de données par JDBC, ce qui est bien plus simple à faire que d'utiliser odbc sous linux.

Java n'est nécessaire _que_ pour compiler oo.org. Debian et redhat le font tourner sans java, et ça rame quand même comme de la merde (sur bi-p3 1go avec du scsi, et sans rien faire à côté)

J'avais plus Java, python et smalltalk en tête plutôt que php.

Par contre C++ n'est pas problématique, sauf quand c'est mal utilisé est qu'on trouve des char* et des malloc partout. Si on utilise la STL ou autre, pas de souci, sauf si le problème est dans la STL bien sur.

> utiliser alloca() quand vous le pouvez

man alloca :

CONFORMING TO
[...]
This function is not in POSIX or SUSv3.

BUGS
The alloca function is machine and compiler dependent. Its use is discouraged.

On many systems alloca cannot be used inside the list of arguments of a function call, because the stack space reserved by alloca would appear on the stack in the middle of the space for the function arguments.


Je ne sais plus qui croire là ;-) Mais pour tout le reste je suis complètement d'accord, surtout pour apache/cron.

Sans vouloir lancer "une polémique" si les gens incompétents arrêtaient d'utiliser des languages de progs où chaque manipulation de chaines de caractères est un trou de sécurité potentiel, on aurait beaucoup moins de soucis.

Ok, je viens de regarder la page de man. Il faut que je mettes mes options dans le xpdfrc. Pour l'antialias ils disent de mettre "freetypeControl high" dans ~/.xpdfrc

Bon j'arrêtes de "polémiquer" sur xpdf.

Peut être que j'ai mal exploré le menu mais :
- pas de plein écran;
- pas d'antialiasing;
- la sélection avec un carré, (je ne sais jamais ce que je vais copier/coller).

(j'ai la 2.02 sur ma debian)

Sur le principe je suis complètement d'accord. Mais le fric généré par les ventes de la suse à permis de payer des développeurs à plein temps sur ALSA, à plein temps sur ReiserFS, à plein temps sur le noyau...

Le problème, c'est qu'il y a pas mal de projet qui ont besoin de ressources, mais qui sont tellement rébarbatifs ou couteux pour le développeur que si on ne paye pas quelqu'un pour le faire, personne ne le fera : par exemple pour développer des drivers de cartes son, c'est mieux d'avoir les cartes sons. Pour tester la scalabilité du noyau en SMP, les quadri ou octo xeons ne sont pas offerts. Pour tester que l'installeur marche sur les derniers portables ou les derniers matériels assemblés, ça demande de l'argent aussi.

Par exemple, tu regardes l'installeur debian, les tests sont fait par les utilisateurs et les développeurs. Donc si ça boote pour les developpeurs alors c'est bon. Le pb c'est que les développeurs il achètent du matériel qu'il savent supporté, pas la dernière carte réseau à 10euros chez l'assembleur du coin et le super controlleur raid à 2000euros pièce. Ce qui fait que dès qu'il faut installer une debian sur une machine que les developpeurs debian n'ont pas, il faut recréer des disquettes de boot en mettant un noyau redhat ou suse (-ac ou -aa) à la place : pour installer sur un xserver IBM récent, sur des dell poweredge, et sur des portables dell, c'est le cas. L'installeur ne se lance même pas.

Et si après l'install d'une distrib (debian dans mon cas) :
- j'installe acroread
- la dernière jvm sun (pour faire tourner tomcat, jboss, eclipse, et mes applis)

Et ce que ça fait de moi un traitre à la cause ? Si il y avait une autre vm libre qui marche (compatible j2se1.4), ou un lecteur de pdf pratique et qui marche (xpdf ? lol) je les utiliserai. Et la debian je l'utilise paske je la trouve techniquement supérieure, pas pour l'idéologie.

Je prend l'exemple de la VM, paske celui qui me répond qu'il suffit de contribuer ne doit pas avoir la moindre idée de la complexité d'une VM et du retard des VM libres. On ne peut pas se contenter de militer pour le libre, au bout d'un moment il faut le faire le boulot, et dire que la VM est pas libre et que donc on peut pas bosser, c'est pas super productif.

Allez voir sur slashdot au lieu de troller dans le vide. Vous pouvez la télécharger avec bittorrent.

Il faut utiliser un org.eclipse.swt.StyledText.

Pour un environnement de dev, le temps de démarrage moi je m'en fout. Ce qui compte c'est qu'il m'aide à coder plus vite. Pour openoffice ça peut être critique quand on veut juste lire un fichier de 20 lignes. Eclipse n'est pas fait pour consulter un .java de 20 lignes. Il y a 'cat' pour ça.

Essaie de rajouter un paramètre à une méthode utilisée 500 fois dans ton projet avec eclipse, et tente la même chose avec vi/emacs/gedit/... Avec eclipse je fais ça en 2 min, lancement de eclipse compris, et sans avoir à réfléchir ;-)

new posix thread library

Les binaires debian fonctionnent. Comme tu semble avoir une mandrake, récupère les paquets deb et transforme les en rpms avec alien.

Sinon si ça peut t'aider :
tom@buffy:~ $ ldd /usr/bin/lmule
libexpat.so.1 => /usr/lib/libexpat.so.1 (0x40021000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40040000)
libwx_gtk-2.4.so => /usr/lib/libwx_gtk-2.4.so (0x4008f000)
libz.so.1 => /lib/libz.so.1 (0x4062b000)
libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 (0x40638000)
libm.so.6 => /lib/libm.so.6 (0x40681000)
libc.so.6 => /lib/libc.so.6 (0x406a2000)
libgtk-1.2.so.0 => /usr/lib/libgtk-1.2.so.0 (0x407b3000)
libgdk-1.2.so.0 => /usr/lib/libgdk-1.2.so.0 (0x408d8000)
libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x4090b000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4092c000)
libgmodule-1.2.so.0 => /usr/lib/libgmodule-1.2.so.0 (0x409e7000)
libgthread-1.2.so.0 => /usr/lib/libgthread-1.2.so.0 (0x409ea000)
libdl.so.2 => /lib/libdl.so.2 (0x409ee000)
libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x409f1000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x409f9000)
libpng.so.2 => /usr/lib/libpng.so.2 (0x40a06000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x40a31000)
libtiff.so.3 => /usr/lib/libtiff.so.3 (0x40a4f000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Mais il ne semble pas y avoir beaucoup de monde dessus actuellement. Ben l'avenir de hurd, c'est surtout le micro noyau l4. Et sur le portage hurd vers l4, on peut considérer qu'il n'y a q'une seule personne (neil walfield, celui qui a ajouté les pthreads à hurd). Par contre pour compiler des packages pour debian hurd, là il y a pas mal de monde. Il y a aussi pas mal de gens qui écrivent des translators (les programmes qui permettent de monter un serveur ftp comme un dur par exemple). Il manque vraiment des programmeurs sur le "coeur" (pour ne pas dire kernel) du hurd, histoire par exemple qu'ils ne se retrouvent pas avec 200 types de systèmes de fichiers supportés, mais tous limités à 2Go (comme c'est le cas pour ext2 et jfs en ce moment).

En ce qui me concerne, j'avais essayé SAPDB il y a quelques mois, et le produit semblait tout sauf abouti. Des fichiers dans tous les sens, une installation qui merdait, rien de folichon... Le produit est abouti, c'est juste que ç'est pas du clef en main. Les scripts d'installation fonctionne parfaitement et permettent une evolution d'une version à l'autre avec une simplicité evangélique. Ce qui peut sembler déroutant, c'est l'abscence de script (ou autre) de création de base. Il y a une bonne raison à celà, c'est qu'il n'existe pas de façon générique de créer une base : tu peux en vouloir une de 100meg sur le dur prenant 64Meg de ram et 1 CPU, dans /le_site_de_mami, et une autre sur des "raw devices", utilisant plusieurs partitions de 4Go, 7CPU et 2Go de ram. Evidemment pour le dev, tu utilise un script générique qui prend la taille de la bd en paramètre, et c'est tout. Pour les fichiers partout, moi j'ai tout le(s) runtime(s) (car il est possible de faire cohabiter plusieurs version du noyau de la base) dans /usr/sapdb, et toutes mes bases sous /database/<nom_de_la_base>, avec sous ce répertoire 1 répertoire backup, 1 répertoire log et un répertoire data, ce qui me permet de mettre des points de montage là ou il faut. En fait le point clef, c'est la souplesse, tout en fait ce que tu veux, exactement comme oracle. Tu n'est pas obligé de mettre toutes tes bd sous un répertoire unique, tu n'est pas obligé d'avoir toutes tes bases qui utilisent la même version, et surtout tu n'est pas obligé de faire démarrer et d'arrêter toutes les bases en même temps, car il y a séparation totale entre les différentes bases de données. Qu'est ce qui a merdé quand tu a essayé d'installer ? j'ai déjà fait l'installation à partir des tgz sur debian 2.2,3.0 et sid ainsi que sur toutes les redhat de la 6.2 à la 8, et l'install a tjs marché.

Par rapport à postgresql, il offre une meilleure scalabilité et une meilleure stabilité, ce qui est très dépendant de ce que tu essaye de faire tourner dans chacune des 2 bases. Pour la rapidité, même combat, c'est très dépendant de ce que tu fait tourner. Par exemple si le bench c'est 1000 insert, puis 1000 update, puis 1000 select, c'est toujours MySQL qui gagne. Par contre si tu execute ce test avec 10 machines clientes simultanement, la donne s'inverse et c'est probablement SAPDB qui l'emporte.

Les résultats de perfs dépendent aussi du language pour le client de test. Par exemple SAPDB fournit un vrai support des prepared statement dans le noyau de la bd. Donc si je fais mon test avec 1000 I/U/S en java avec juste 3 prepared statement, et une seule machine cliente, MySQL et PostgreSQL (qui tous deux implementent les prepared statement comme de la manipulation de chaine dans le driver) ne gagnent plus.

La différence se fait surtout au niveau des outils annexes (par exemple, sous Linux, ça a l'air plus pauvre pour SAPdb que pour les autres).

Mais non, mais non, il commence à y avoir des outils : moi, histoire de me faire de la pub, je réécris le client d'administration graphique en java, car l'original est en GPL, mais est en VB (windows seulement donc). Ca ce passe ici : http://dbmjui.sourceforge.net(...) et c'est en GPL.

Mon avis sur le fait qu'il n'y ait pas beaucoup d'outils annexes, c'est que tout est déjà fourni (au moins pour windows) : driver odbc, interface d'admin graphique (DBMGUI), Interface SQL avec visual query et compagnie (SQLStudio), et interface d'admin/outil de requette (WebDBM, un ensemble de cgi en c++) pour toutes les autres plateformes, driver JDBC, interface python et interface perl.

Bon, là on sort vraiment du sujet mais sur un 2.4 pas patché, seul l'espace utilisateur est préemtif. Donc un appel système, genre l'écriture d'un buffer sur le disque, ne peut être interrompu. C'est différent pour le 2.5.

Pour le noyau préemptif, ça dépend justement. C'est pas adapté à toutes les charges de travail, et en plus ça donne une impression de rapidité plus grande pour généralement un temps d'execution plus long...

Et la question des options de compils, du compilo ou de l'optimisation pour un proc donné, c'est un sujet souvent débattu. Mon avis c'est optimisation pour un cpu donné pour tous les softs qui ont de l'assembleur propre à un cpu dans leur source (kernel, libc et openssl par exemple). Pour le reste, les débats à ce sujet sont suffisamment nombreux pour, au moins, se poser des questions : voir débat sur gcc-3.2 sur la liste linux-kernel, les débats très récurrent sur debian-devel à ce sujet, ou encore les collections de benchs que l'on voit passer sur les sites de news.

Globalement, ces débats finissent tjs par un post du genre : "montre moi un benchmark applicatif (pas un microbenchmark) (sans assembleur mmx/sse/3dnow ou autre) sur lequel la compilation pour un proc donné fourni une optimisation significative (> à 5% et constant)". En général ces posts restent sans réponse...

Pour economiser de l'espace disque, je te conseilles localepurge (c'est pour debian). Tu choisis les locales que tu veux garder, et il efface toutes les autres après chaque install d'un paquet. Moi j'ai gagné une centaine de megs comme ça.

Un beau jour il faudra m'expliquer comment une distribution peut être plus légère qu'une autre : c'est les mêmes softs qui tourne dessus.

Je ne vois pas comment une distrib X avec :
- gnome 2.2
- xfree86 4.3
- libc2.3.1
- mes logiciels pour bosser

Peut être plus rapide qu'une distrib Y avec les mêmes soft. Si tu me dis que la distrib utilise un noyau préemptif, du prelinking, nptl ou je ne sais quoi, là oui peut être qu'elle est plus légère.

Mais bon, c'est pas le système de package qui fait tourner les softs...et les softs lancés au démarrage sont paramétrables sur toutes les distribs que je connais.

sync n'est pas une opération asynchrone sous linux depuis belle lurette. Je ne suis même pas sur que ça l'ai été un jour. Donc un seul sync suffit.

apt-get install debian-keyring

[+]

Stallman (fait croire qu'il) utilise hurd. Hurd (les dev) utilisent linux pour le dev. Linus utilise bitkeeper pour le dev de linux. Donc quelque part hurd repose sur bitkeeper. Il doit avoir du mal à dormir le gros barbu avec sa flutte.

Grâce aux XP, linuxfr avait un côté ludique. Sans les XP il reste quoi ? Les news déjà parues il y a une (voire deux) semaine sur tous les autres sites ?