matiasf a écrit 1969 commentaires

pgreplicator ne fait pas tourné deux serveurs en parallèle (pas de répartition de charge). Chaque serveur a sa "vie". Mais pgreplicator permet de synchroniser les serveurs entre eux (Toutes les nuits, heures, à la demande, sur trigger, etc...).

Néanmoins, c'est très interessant :
1 - pour les bases de donnée "itinérantes"
2 - pour avoir une copie à jour d'une serveur et opérationnel. çà permet d'avoir un backup toujour à jour.

Je sais surement tester à la première occasion.

> De plus j'ai du modifier quelques requêtes qui utilisaient la fonction datetime qui a disparu en version 7.3.

Il y a l'option --enable-integer-datetimes pour ./configure. Je ne sais pas si çà peut aider.

> je préfère rester en version 7.2.3

Ce qu'il faut espére est que la version 7.3.3 soit aussi au point que la 7.2.3...

> On a pas beaucoup d'écriture dans la base

Je ne connais pas ton applis, mais l'utilisation de transaction améliore significativement les performances. Tu regroupes plusieurs requêtes d'écriture dans une transaction. Il y a ainsi moins d'appel à fsync().

Pour améliorer de façon assez fabuleuse les performances en écriture de postgresql, tu peux désactiver sur le serveur PostgreSQL l'appel à fsync(). Par contre en cas de coupure de courant ou autre, tes données peuvent ne plus être cohérentes entre le serveur et le/les clients. Exemple :
- Client : Demande une place pour le train Paris-Lyon
- Serveur : retourne un numéro de place au client et écrit la réservation dans la base de donnée. La réservation sera définitivement écrite sur le disque dur une peu plus tard à la discrétion de l'OS.
- Coupure de courant : La réservation n'avait pas encore été écrite sur le disque dur.
- Retour courant : boot serveur.

On a maintenant un client bien réel qui a acheté la place 20 du train Paris-Lyon alors que cette information n'est pas écrite en base de donnée. La place 20 peut maintenant être vendue une seconde fois...
Si ton appli n'a pas ce type de problématique, que tu n'as pas de plantage et dispose d'un régulateur, alors tu peux envisager de désactiver l'appel à fsync().

> Le principe: 2 instances Oracle sur 2 machines différentes qui accèdent aux même données sur un disque partagé.

Je m'interroge si ce type de fonctionnement est plus rapide qu'une simple machine multiprocesseur...
En effet, un disque partagé c'est des communications (entre autre pour les verrouillages, vérification que le cache est à jour, etc...) via réseau. çà ressemble furieusement à une serveur et deux clients qui accèdent aux données. Sauf que dans ce cas, c'est les clients qui applique la "police" lors de l'accès aux donnée.

Une solution plus classique et "facilement" réalisable sous Linux est :
1 - un front-end pour répartir la charge
2 - plusieur machines applicatives avec des clients base de donnée. Les programmes, script, etc peuvent être sur un lecture nfs.
3 - un gros serveur (beaucoup de mémoire) de base de donnée.

Le serveur PostgreSQL est adapté à une utilisation multi-cpu (mais je ne sais pas dans quelle mesure). En effet, à chaque connection d'un client, le postmaster crée un processus serveur qui répond à un client. Si plusieurs client, alors plusieurs serveurs.
Voir ici pour une description pas très détaillée :
http://www.fr.postgresql.org/users-lounge/docs/7.2/postgres/arch-pg(...)

> Il y a aussi l'option "c"

J'ai beaucoup utilisé sous Linux 2.2. çà marchait très bien. J'ai trouvé un patch pour 2.4 :
http://www.alizt.com/(...)

Il y a aussi le problème des sauvegardes. Si tu passes des heures a "bidouiller" avec chattr et que le backup ne peut restaurer tous tes "chattr", c'est pas terrible. Enfin, ce n'est que pour ext(2 et 3). Ce n'est pas portable vers ReiserFR, XFS, NFS, etc...
Mais c'est une commande qu'il faut connaitre. Entre autre suite à un plantage disque il y a parfois des attributs un peu étrange qu'il faut virer (j'en ai fait l'expérience une foie et j'ai ramé avant de trouver chattr).

On peut aussi faire des trucs de cochon avec les exceptions. Style je catch systématiquement toute mes fonctions. C'est joli comme style de programmation mais c'est aussi un bon moyen pour oublier de libérer des ressources... Ou alors il faut faire du 100% object et là c'est lourdingue.

Pour ma part, les mécanismes d'exception doivent être employés "exceptionnellement" et leur usage doit être clairement défini.

J'ai l'impression que le marketing en programmation marche très bien. Certain pour vendre leur language bidule orienté truc arrive a faire passer l'idée qu'il n'est pas possible de faire un programme sérieux sans leur fonctionnalité. Le language C qui s'appuie sur des fonctionnalités de bas niveau prouve que l'on peut faire de grande chose avec des outils simples (Linux, Apache, etc, etc...). La programmation est quelque chose de complexe et la ramener a l'application ou non de "dogme" c'est une simplification abusive. La suppression de goto en est un exemple ... comique.

> en reprenant mes fichiers de conf
Les fichiers de conf ne sont pas forcément compatibles entre version. Même mineur (2.4.x).

> C# est presenté comme le remplacant de C++ pour la plateforme .Net
C'est pas l'impression que j'ai. Microsoft va pas réécrire MS Office en C# pour des raisons évidentes de perfo et de place mémoire.

> que le fait de laisser la possibilitée au progammeur de faire des methodes 'non virtuelles' est une heresie.

Les fonctions virtuelles c'est pour l'édition de lien à la volée. C'est utile lorsque tu n'as pas les sources d'une librairie. Pour ma part, je ne connais pas assez C# pour avoir un avis.

> Mais c# va tourner sur une machine virtuelle !!

Ouais mais une machine virtuelle qui support plusieurs languages...

> pourquoi pas garder l'intruction 'goto' tant que l'on y est ...

Le goto bien utilisé (principalement pour la gestion d'erreur ou pour sortir de plusieurs boucles impriquées) peut améliorer la lisibilité du code. D'ailleur il y a plus de 14700 goto dans Linux 2.4.18 ! Si tu codes un peu, l'emploi réflechi de goto d'évitera nombre de :

if (!faire_qqc1()) {
status = pas_ok ;
}
if (status == ok && !faire_qqc2()) {
status = pas_ok ;
}
if (status == ok) {
continuer_le_boulot ;
}
...
if (status == ok) {
return tout_va_bien ;
}
else {
return çà_merde_completement ;
}


pour un plus lisible :
if (!faire_qqc1()) {
goto error ;
}
if (!faire_qqc2()) {
goto_error ;
}
continuer_le_boulot() ;
return tout_va_bien ;
error:
return ca_merde_completement ;

Avec mon patch çà fait environ 3,14159265356 bogomips.
Ce patch permet d'avoir les mêmes performances en bogomips quelque soit la bécane. Comme çà t'as plus aucune raison d'acheter du hardware cher.

Mandrake! j'y crois pas.
On a droit à tout les RC et il y a même des news postées par des employés de Mandrake (pour critiquer la concurrence en plus !).

Les chouchoux de linuxfr c'est :
- debian
- mandrake
- openbsd

> dans l'autre tu prends volontairemment l'outil moins adapté?

Remarque pertinante.

Il y a plusieurs raisons.
Si les paquetages que je récupère sont centralisés et cohérents avec mon système RH 8.0 (paquetage RH 8.0 pour RH 8.0 du site RedHat, ou paquetage pour RH8.0 sur freshrpms) je suis plutôt pour l'utilisation d'outils de plus haut niveau. Sinon, çà fini toujours par foirer.

Un exemple. Je veux installer gnucash v 1.6.8 (RH 8.0 est livré avec 1.6.6). Cette version est disponible dans la distribe Rawhide de RedHat. Si je prends le binaire de gnucash de Rawhide, je dois passer à gtkhtml version 1.1.x. Or evolution de RH8.0 ne marche pas avec gtkhtml 1.1.x mais avec gtkhtml 1.0. Notes que les paquetages sont renseigné avec gtkhtml >= 1.0.4 et non avec gtkhtml >= 1.0.4 && < 1.1 . C'est déjà une anomalie que ne détecte pas urpmi . Donc je doit aussi mettre à jour evolution pour avoir gnucash 1.6.8. Hors la version d'evolution qui utilise gtkhtml 1.1 est la version 1.2. Cette version nécessite aussi de mettre à jour bonobo-conf, pilot-link et oaf. Bref je modifie d'un peu partout mon système uniquement pour passer de gnucash 1.6.6 à 1.6.8. De plus evolution 1.2 me semble un peu trop récent pour lui faire comfiance de gérer mon courrier. Il est claire que l'on peut trouver des cas encore plus complexe...

Pour mon cas, j'ai récupéré gnucash-1.6.8-x.src.rpm, retouché le fichier .spec et recompilé. En effet, les sources gnucash supportent gtkhtml 1.0. Et c'est tout ce que j'ai fais...

Seconde raison. J'aime avoir un système avec les paquetages de développement pour compiler des applis si nécessaire. Si j'utilise urpmi je ne suis pas sûr que ce que j'installe peut être compilé. C'est-à-dire que je n'ai pas forcément les paquetages devel de ma configuration (ou que je pourrai les retrouver). En compilant les nouveaux paquetage que j'installe je suis sûr que mon environnement de développement est synchro avec les programmes installés.

Je fait çà depuis longtemps. Et même si c'est un peu fastidieux çà marche très bien. J'avais une RH 6.2 avec Mozilla 1.0, galeon 1.2, evolution 1.0, gnucash 1.6, etc... et toujours une installation propre. Je doute fortement que urpmi, apt4rpm etc m'aurai permis de faire çà. Sinon ce serait avec le même contraite que Debian. C'est-à-dire que tout est centralisé, un gestion de paquetage lourdigue (pour ceux qui font les paquets), etc...

Comme tu le sous-entend à la fin, on parle trop de "format" de paquetage. urpmi qui semble très apprécié n'a pas demandé le changement du format rpm. apt4rpm qui offre pratiquement les mêmes fonctionnalité que apt n'a pas demandé le changement du format rpm. Il faudrai parlé de système de paquetage (format ET outil) voir même système de gestion de paquetage (contrôle des dépendances entre paquetage etc...).

C'est pas moi qui ait parlé de "grosse daube infame". J'ai "poussé" son raisonnement un peu plus loin.

Sinon comme tu le dis, MS répond a des attentes légitimes et c'est l'une des raisons de son succès. MS, le numéro 1 des OS et suite bureautique ne s'est pas fait en un jour.

> grosse daube infame

Car Visual Basic c'est mieu ?

Si MS marche fort en ne fesant que des "grosse daube infame" c'est que 90 % des utilisateurs d'ordinateur sont des cons... Reconnaissont à MS de savoir s'adapter à sa clientèle. Ce qui la plus grande qualité d'une boîte commerciale...

> Si je recompile mon noyau, est-ce que je vais avoir un reel changement de performance ou non?

çà ne va pas changer grand chose.

> ci recompiler les application donne vraiment un reel changement

Non plus.

> Mozilla est inutilisable

Avec un K6 2 500Mhz !
Bizarre çà...

> les nouveaux produits propriétaires
Je parle des "produits majeurs de MS". Windows XP, avec la suite mediaplayer (gravage de cd, cryptage, etc...), est passé inaperçu ici.

> puisque apple a beaucoup plus de choses à nous apporter que MS,

?!?
A bon... Il y a quelques années Apple était pire que MS (hardware non clonable, Quicktime, interdition de copier le thème aqua, etc...). Maintenant Apple n'a plus le chois et copie des freewares et fait du charme aux développeurs du freeware.

Franchement, je ne vois pas ce qu'a apporté Apple au free software. Par contre, via Darwin, le free software apporte beaucoup à Apple. Et dans Darwin il y a des gros morceau de freeBSD.

> permet de voir à qu'elle point il ce fout de faire ce type d'action au grand jour.

C'est vrai que débauché un haut-fonctionnaire européen çà va loin.

Le débauchage est une pratique courante. Dans l'automobile c'est si courant qu'on en parle même plus. Et que dire du sport automobile... Et c'est normal car c'est lié à la liberté de travailler.

Si MS se limitait à çà, il serait irréprochable.

> quelqu'un qui feint ignorer l'importance de Microsoft sur l'informatique ?

Il est pas là le problème. Je trouve même que çà manque de news MS. Par exemple, la sortie de produit majeur de MS ne passe jamais ici. Hors les "défenseurs du libre" peuvent en débattre. Surtout que contrairement a ce qui martelé ici MS ne fait pas que de la merde (C# est un bon exemple récent).

Le problème est que les news relatives à MS sont toujours des news "méchantes".

Comment dans ce cas reprocher au canard généraliste de ne pas parler de Linux alors qu'on a une attitude SYSTEMATIQUEMENT agréssive envers MS.

PS : J'aime pas MS.

Ceci ne marche pas pour compiler le noyau Linux. CC=gcc est codé en dure dans les Makefile. Dans ce cas, un trucs du style :
$ cd /usr/bin
$ mv gcc gcc-2.96
$ ln -s gcc-2.96 gcc
OU
$ ln -s gcc-3.2 gcc

marche parfaitement.

Il est claire que linuxfr a ses souffres douleur :
- Suse
- MS
- RedHat
- Xiniam (Plus depuis quelques mois)
- MDI

Cette news ne méritait pas la première page.

Le "make menuconfig" pose problème avec une RH 8.0 sous une console virtuelle Linux. En effet la RH 8.0 utilise unicode par défaut et "make menuconfig" ne supporte pas unicode actuellement. Dans ce cas, faire :
$ unicode_stop
$ export LANG=C # pas obligatoire

Il existe depuis quelques semaines http://bugzilla.kernel.org/.(...)
N'hésiter pas et tester Linux 2.5 avec votre hardware et poster des rapports bugs (détaillé !) s'il y a des problèmes.

Le noyau 2.5 doit fonctionner sans problème ( :-o ) avec toute distribution moderne. Néanmoins il faut utiliser un nouveau modutils (pas encore totalement finalisé). Récupérez le ici :
http://www.kernel.org/pub/linux/kernel/people/rusty/modules/(...)

Ce nouveau modutils marche parfaitement avec Linux 2.4 (il utilise l'ancien modutils sous 2.4).

IDE est en cours de récriture par Alan COX (entre autre, mais il est actuellement le mainteneur). Ce travail est fait pour Linux 2.4 ET 2.5. Pour ma part il y a quelques regressions depuis le 2.4.19. Mais c'est un mal nécessaire...