vrm a écrit 620 commentaires

si vous regarder la reflection dans java on se rend compte que int/double sont des artifices pour simplifier l'ecriture mais que se sont des Classes.

c'est assez bordélique int c'est donc entre un type & un classe Integer

> Quant à GNU, j'avoue ne pas trouver en quoi il serait révolutionnaire.

Aieee..

Gcc qui compile du C/C++/Java/Objective C/Fortran/Ada etc.. jusqu'a l'infini,
cherche un equivalent de suite de compilo cross platform supportant un collection de langage

ARGRGGG Linuxfr à revendu mon adresse email à google :(

hehe :)

java c'est tres bien coté serveur, surtout la gestion de la memoire, tu defini la taille de ton spoule et hop le GC se demerde.

pensé pour faire des applets ? tu rigole ? tu sais vraiment de quoi tu parle ?

meme orcale permet de mettre du java dans ses procédures stockés ..

de plus tu peux compiler java si ça te plais pas la jvm

enfin l'effet de mode il va bientot avoir 10ans non ?

<troll> et puis avec le bytecode, tu ramme pas comme dfu perl et tu evite les segfault & buffer overflow du C++</troll>

puis va faire un bench entre un serveur d'application avec tomcat sur solaris contre apache/php avant d"ecrire des bétises

"Le capitalisme est un bon système théorique, mais en pratique il part en c..."

Le capitalisme est très mauvais en thèorie (la somme des intêrets indivuels va dans le sens de l'interet commun) c'est de la pure betise mathématique. Il est juste un peu meilleur en pratique pas l'intervention régelmentaire de l'état, qui essaie de diriger le 'bordel ambient' vers l'intêret commun.

tu prends tes petites mains et tu traduit.

trop gros, passera pas ton troll ...

allé avoue le que tu est un fake ..
c'est pas possible de troller comme ça

c'est bien connu,
tu attend qu'il segfault et tu extrait le binaire du coredump

--> []

Ok pour clore de debas sur les pilotes Nvidia closed source de soit disante bonne qualité :

demande aux gars de crystalSpace ( http://crystal.sf.net(...) un framework 3D très sympa ) ils on isolé un drole de bug..

les drivers Nvidia sont tellement codé à l'arrache (je te passe les histoires de memory leack..) que leur gestion pourri des signaux arrive a crasher X quand tu utilise OSS (oui oui le son ..) de façon particulière.

Je prefere de l'open source moins rapide mais qui tiens la prod ...

ca fait logntemps que le probleme serai corrigé s'ils arretaient d'ignorer les problemes des utilisateurs Linux ( quoi part de marché pas assez grosse ?) ou nous permetrais d'acceder au sources pour corriger leurs bugs à 2 centimes d'euros.

Je prefere une communauté de gars bossant proprement et ouvertement pour rien qu'un mecs payé à 100% pour faire des bug qu'il refuse de corriger


Voila y en a marre de t'entendre dire que des conneries...

de toute façon matrox & nvidia ca suce car sur les boites il n'y a pas le logo SuSe
[-1E99]

c'est super d'incendier matrox comme ca gratuitement... super niveau ...

www.fsgs.com

a aussi été fermé par blizzard :(

ca c'est un troll un vrai :)

je viens de voir l'UTF16 dans oracle 9i mais nul part ailleur,

faut que j'essaie SAPDB alors :)

a non c'est openME qui va gagner ;)

sauf que le risque n'est pas le meme avec postgres puisque ca une implcation (apparement) lors de la saturation de l'espace.

m'enfin c'est mon serveur qui explose si j'active FSYNC :(

ne pas mettre la cache en ecriture reduit les perf par ~10
l'integrité est conservé, sauf crash hard/soft

si tu a un serveur stable c'est plutot conseillé ( par ex: interbase l'active par defaut sous unix mais pas sous NT .. ils sont pas fou)

tu l'active pas si tu n'as pas d'onduleur ou un serveur à gros risque

enfin dire que ne pas l'activer c'est 'la porte' c'est tres pretencieux et montre bien que tu sais pas de quoi tu parle :




FSYNC (boolean)


If this option is on, the PostgreSQL backend will use the fsync() system call in several places to make sure that updates are physically written to disk and do not hang around in the kernel buffer cache. This increases the chance by a large amount that a database installation will still be usable after an operating system or hardware crash. (Crashes of the database server itself do not affect this consideration.)

However, this operation slows down PostgreSQL, because at all those points it has to block and wait for the operating system to flush the buffers. Without fsync, the operating system is allowed to do its best in buffering, sorting, and delaying writes, which can make for a considerable performance increase. However, if the system crashes, the results of the last few committed transactions may be lost in part or whole; in the worst case, unrecoverable data corruption may occur.

This option is the subject of an eternal debate in the PostgreSQL user and developer communities. Some always leave it off, some turn it off only for bulk loads, where there is a clear restart point if something goes wrong, some leave it on just to be on the safe side. Because it is the safe side, on is also the default. If you trust your operating system, your hardware, and your utility company (or better your UPS), you might want to disable fsync.

It should be noted that the performance penalty from doing fsyncs is considerably less in PostgreSQL version 7.1 than it was in prior releases. If you previously suppressed fsyncs because of performance problems, you may wish to reconsider your choice.


en gros je prend le risque de revenir a un backup d'au max vieux d'une heure si j'ai un crash HARD vraiment mechant pendant une ecriture
et je gange ~10x de perf en ecriture en contrepartie.

Ce n'est pas un choix idiot, juste savoir etudier un risque.

oui mais c'est pas systématique, si tu as le cache en ecriture activé tu a de bonne chance de pas pouvoir repartir, enfin c'est pas si grave que ca :)

c'est surtout qu'il n'évolue pas trop :(
delphi c'était novateur, ca s'éssoufle un peu, ca manque de nouvautés (avis perso)

par contre il y a un truc qui me traumatise c'est borland c'est paradox pour windows, j'ai eu que des problemes avec, d'autre personne on eu le meme genre de gout amer avec paradox (window car sous dos ca roxait :D)?

le truc vicieux est que le recover ne marche pas systematiquement
ca me le fait un coup sur trois
j'ai mis à jour le kernel & postgres plusieur fois c'est toujours pareil.

j'ai fais des test ca ne le fait pas si on desasctive le cache en ecriture

enfin je fais gaffe c'est pas la mort :)
j'ai une copie de la base qui a explosé si vous voulez ca doit faire 1G / 200M zippé (à la louche)

j'ais envie de l'essaier, ca vaut vraiment le coup ?

je sais pas pourquoi, ca doit etre un choix au niveau perf

faut que je demande un jour sur la mailling liste par curiosité mais bon je pense pas que ca soit un prob de mauvaise volonté

Désolé tu te trompe :


13.1. Disk Filled

A filled data disk may result in subsequent corruption of database indexes, but not of the fundamental data tables. If the WAL files are on the same disk (as is the case for a default configuration) then a filled disk during database initialization may result in corrupted or incomplete WAL files. This failure condition is detected and the database will refuse to start up. You must free up additional space on the disk (or move the WAL area to another disk; see Section 11.3) and then restart the postmaster to recover from this condition.


c'est pas mois c'est la doc de postgres : www.postgresql.org/idocs/index.php?failu

oula on se calme

les 2 produit sont biens ca depend des gouts

postgresql a des chti prob de de faillure quand la place est pleinne :




13.1. Disk Filled

A filled data disk may result in subsequent corruption of database indexes, but not of the fundamental data tables. If the WAL files are on the same disk (as is the case for a default configuration) then a filled disk during database initialization may result in corrupted or incomplete WAL files. This failure condition is detected and the database will refuse to start up. You must free up additional space on the disk (or move the WAL area to another disk; see Section 11.3) and then restart the postmaster to recover from this condition.


c'est pas mois c'est la doc de postgres : http://www.postgresql.org/idocs/index.php?failure.html(...)

postgres a ses defauts et ses qualités, l'equipe de dev de postgres est tres claire sur les petit prob de postgres (c'est comme pour les vaccums)
Firebird c'est pas la pannacée non plus

c'est la vie

et puis avant de crier au FUD tu aurais mieux fais d'ouvrir la doc de postgres...


pour le :

AMHA, si tu en arrives là c'est que tu ne sais pas administrer une base de données. Le manque d'espace disque est néfaste à tout système de base de données pas seulement PostgreSQL. Quand cela arrive, c'est caractéristique d'une installation non pensée à l'avance et surtout pas suivie comme il se doit.


ca arrive tres souvent de remplire une base (bug dans un generateur qui par en boucle, un mauvais dimensionnement, etc..)

oracle par exemple d'envoie un paquet de message d'erruer se met a rammer mais ne s'arrete pas comme le fait postgres, tes donnée sont consultable mais des insert ne marche pas, tes update ramme ou partent en erreur.