Thomas Cataldo a écrit 205 commentaires

Pour éviter les pbs et pouvoir utiliser une clef usb sans pb il faut rajouter 'sync' dans les options de montage. C'est surement ce qu'ils ont du faire.

devpts ça n'a rien à voir, c'est juste les pseudo-terminaux (tapes tty dans un xterm et en console).

non, *renard qui brule* ce serait burningfox

Ouai, sauf que le but c'est pas de faire tourner kde, mais des applis. Quand j'ai besoin de lancer une nouvelle appli, il faut pas que je sois pas obligé d'attendre 5 secondes que le panel kde soit de-swappé.

alien -t mondriver.rpm, et hop, tu as ton tgz.

Oui, enfin la réponse à ce retour c'est "Pas de pb, on vous le fait mais c'est plus cher de 40% avec une interface non-web.". Et là on obtient toujours "Va pour le web, au moins les navigateurs on voit à peu près comment ça marche".

D'où le certificat client sur portables des commerciaux. Merci mod_ssl.

Je suis désolé mais je ne comprend toujours pas pourquoi il est compliqué d'utiliser une application web en déplacement. Ils utilisent un OS sans navigateur tes commerciaux ?

Et tu ferai comment si c'était pas une appli web ? tu prendrai un dump de la base avant chaque déplacement ?

Pour ceux qui ne sont pas au courant une application gnome est une application gtk2 qui respecte les HIG. Pas besoin d'être lié à autre chose que gtk pour être une application gnome.

> Existe-t-il un environnement graphique, un OS ou un jeu en Java qui tienne la route ?

Le jeux "Vampire, the masquerade" est en Java.

> Est-ce que Java est porté sur plus de 11 architectures ?

Ben si tu considère gcj/gij alors oui

> Est-ce que Java peut tourner sur des machines avec très peu de ressources ?

Les téléphones portables, et les VMs pour PDA (J9 d'IBM par exemple)

Donc la réponse à tes questions est loin d'être non.

Ou pkill [nom du process] qui marche sur la pluspart des unix, contrairement à killall...

Donc mandrake et gentoo pour les graphistes qui font du gimp, et debian pour les autres :-)

Perso je ne trouve pas les différences négligeables : plus de 20 % de différence sur une compil de noyau, ça fait pas mal je trouve.

Mais bon ça reste un bench...

CGT/MEDEF

Et en plus ça existe le "windows update" pour linux. Ca s'appelle dselect et c'est les petits gars de chez debian qui font ça.

On lance dselect, on choisit update dans le menu, et inspecte la liste des nouveautés (select), et hop install. Et on répète l'opération tout les jours :-)

Le ACX100 de TI est un 11Mb qui est capable de faire du 22Mb si toute la chaine wifi est en ACX100.

Sinon pour l'intant le mode "AdHoc" (carte à carte) fontionne, mais le mode "Managed" (avec access point) ne fonctionne pas, en tout cas pour moi.

Sinon pour l'instant il n'y a pas de locks dans le driver, donc ça marchouille sur du monoproc, et ça deadlocke au chargement du module en SMP.

Yep mais c'est pas aliacom qui a fait le site web. Par contre il a migré de websphere vers tomcat.

C'est pas que ça doit tourner sans gros changement, c'est que la "gnome developper platform" garantie 2 ans de stabilité API et ABI se qui signifie pas de recompil nécessaire.

http://java.sun.com/docs/books/performance/1st_edition/html/JPRAMFo(...)

C'est la partie sur la consommation mémoire du bouquin de sun sur la performance des applications Java. Le livre présente aussi pas mal de technique pour limiter la consommation de mémoire, optimisez le temps de démarrage d'une application, etc. En gros il apporte des réponses aux personnes qui restent dans l'idée qu'une appli java ça met forcément longtemps à démarrer et ça bouffe plein de ram.

On trouve plein de petites choses intéressantes dans ce livre comme par exemple comment copier un fichier. Ils présentent 4 façons de le faire, de la façon neuneu à la façon correcte. Les temps d'executions des 4 méthodes sont (en ms) : 10800, 130, 33 et 22. Donc la méthode correcte/optimisée est 490 fois plus rapide que la méthode neuneu. Evidemment si on compare avec le même programme en C/C++, on va surement 2 ou 3 fois plus vite en C/C++. Le but de ce bouquin n'est pas de montrer que Java ça casse tout, c'est juste de montrer que la pluspart des arguments avancés contre Java ne sont pas forcément liés à la JVM et à son utilisation de la RAM.

C'est pas du gtk, c'est toujours du dessin avec des méthodes paint fait pour ressembler au theme gtk. Donc ça rame toujour autant. SWT par contre utilise bien le toolkit natif de la plateforme (gtk, mfc ou motif suivant l'os).

SAP est surtout le premier revendeur de base Oracle en europe. Au bout d'un moment, ils ont réalisé le manque à gagner, forké adabas et porté l'intégralité de leurs produits sur SAPDB. Toutes les nouvelles installations de R/3 se font sur SAPDB actuellement, sauf si le client insiste pour avoir du oracle.

Pour ceux qui doutent de la véracité de la news, voilà un mail issu de la liste sapdb.general en provenance d'un des managers de sap qui explique ce qui va se passer pour sapdb, et un peu pour mysql (même si je me fiche pas mal de ce qui arrive à mysql) :

--------------------------------
MySQL will offer a rebranded version of SAP DB as a MySQL product. So
SAP DB does not go away and
will also be offered in the future under as Open Source under GPL. The
SAP DB team you know stays
in place and takes care of the ongoing development and and support of
SAP DB. Future SAP DB
releases will come as planned. SAP is and remains responsible for the
SAP DB code base. MySQL plans to
add the rebranded SAP DB as a new product line to its present MySQL
Classic and MySQL Pro product
lines.

Regards,

Rudolf Munz
---------------------------------

Donc pour resumer mysql ab (la boîte) va releaser du sapdb et sap va continuer à releaser du sapdb et n'a pas prévu de releaser du mysql ou de faire quoi que ce soit avec mysql.

On peut compter le temps entre la découverte de la faille et la disponibilité d'un correctif sous quelque forme que ce soit (un patch donc). Lui il compte le temps entre la découverte de la faille, et la disponibilité du correctif packagé pour une distribution donnée.

A mon avis sa façon de compter est la bonne. Si on trouves une faille dans la libc 2.3.x, et que j'ai une redhat 9, je penses que celui qui remplace sa libc par une 2.3.x patchée et compilée à la main est :
- soit sacrément doué, et comprend toutes les différences entre la libc de la redhat 9 et la libc "standard" (NPTL, sysenter/sysexit,...) et l'impact que ça peut avoir sur ça machine
- soit complètement inconscient de la portée du changement qu'il réalise.

Il y a un très bon résumé de ce qu'il faut (ou ne faut pas) dans le kernel pour obtenir des perfs optimales avec une BD correcte dans le compte rendu (dont je ne trouves plus l'url) du dernier symposium sur le kernel à ottawa.

Non, les raw devices c'est pas vraiment une ruine d'un passé lointain. Le but est simplement de dire au noyau de l'OS en question de n'utiliser absolument aucun cache.

Pour une base de données le noyau _doit_ être un driver, et être bête et méchant : on lui dit "lit 8Ko à partir de tel endroit", on veut qu'il lise 8Ko, pas qu'il fasse du read-head et lise 4Mo juste au cas où on lirait les octets suivants. La base de données ne veut pas que le noyau cache les octets lus. pourquoi ? Ben parce que la base fait son propre cache, et la mémoire que le noyau perd à cacher n'importe quoi serait bien mieux employée par la base.

C'est con mais les algos de filesystem sont complètement inadaptés aux bases de données.

Du coup il y a deux possibilités :
- utiliser des raw devices (et là linux à encore un peu de boulot)
- utiliser des gros fichiers (bonjour tablespace ;-)

et il faut en plus que le noyau soit "gentil" et permette de désactiver toute forme de cache.

Il y a un très bon résumé de ce qu'il faut (ou ne faut pas) dans le kernel pour obtenir des perfs optimales avec une BD correcte.