C'est bizarre car moi dans le cadre de mon boulot, sous une ubuntu karmic, j'ouvre des exports CSV de 360 000 lignes sans aucun problème, et c'est même rapide.
Le pire c'est que ça marche aussi bien sous Microsoft Office 2007, alors qu'inconsciemment j'aurais pensé que ce dernier allait se vautré comme une merde.
Ça doit surrement dépendre de la quantité de ram dispo sur la bécane...
Que XMPP soit à la mode ou pas, on s'en fou, que ton dieu Google bricole avec XMPP c'est bien mais on s'en fou...
La question ici, c'est : est-ce que XMPP peut-être intéressant à être utilisé dans un système de supervision comme protocole de communication ?
Selon toi non, Nagios c'est le top et XML c'est oversize pour faire ça, bon ben pas la peine d'en faire un fromage.
Après ce qui est intéressant c'est de voir des avis différents, par exemple plus haut, on nous dis que redhat à sortie un truc en rapport avec ça... Peut-être alors que c'est pas si nul que ça...
cf. commentaire plus haut mais tu peux rajouter tout ce qui te passes par la tête :
Imagine, qu'en plus d'avoir un système de supervision, tu peux avoir un système de controle a distance de tes machines, un système de déploiements de logiciels, etc, pas seulement sur tes serveurs mais aussi sur ton parc de postes clients...
Pour superviser ton parc de serveur avec Nagios, tu fais comment ? tu prends un serveur et tu installe/configure ton système de supervision dessus.
Si tu veux checker un certains nombre de services sur un certains nombres de serveurs, tu fais quoi, tu as un script/plugins qui va aller vérifier à intervale régulier que par exemple ton service est toujours ok.
Au final, tu va te retrouver avec plein de scripts qui vont pinger, vérifier que tel ou tel port est ouvert, etc, à interval régulier le tout en parallèle.
Ici dans mon hypothèse, tu as un agent sur le serveur, qui va t'avertir que tel service est down en poussant sur le réseau cette info. Sur ta console d'administration si ton serveur est déconnecté du réseau, tu le sait immédiatemment.
Après, pour vérifier que tel service fonctionne correctement, il existe surrement des trucs moderne dans nos kernels basé sur les évènements qui te dis automatiquement que le port 80 n'est pas plus en écoute sur telle interface ou que le processus avec le pid 845 vient de se terminer, etc... A l'époque de djbdns daemontools était bien capable de superviser des services. On a bien inotify qui permet de monitorer les changements sur le système de fichiers de manière évènementiel.
En gros, il suffit de programmer le système de manière évènementiel, à chaque fois qu'un évènement se déclenche une alerte est poussée via XMPP... et toi dans la milliseconde tu recoit un beau message sur iphone que te dis que ton serveur est down.
Après, au final ça se trouve ça utilise moins de bande passante que du snmp, du ping ou autre car ça cause sur réseau uniquement en cas d'évènement et pas toutes les 5 minutes.
Ensuite XMPP, c'est décentralisé, tu peut aussi monitorer des serveurs qui ne sont pas sur le même réseau que ton serveur nagios.
Oui je vois assez 20k services envoyer leur état en temps réel à une machine avec du XML ... C'est claire que ça va alléger la charge de décoder 20k messages XML en temps réel. Le push peut-être intéressant en supervision dans certains cas et est disponible sur nagios, mais ce n'est pas _la_ solution pour alléger le tout.
Pourtant à l'origine XMPP à été développé pour faire de la messagerie instantanée, et donc le fait de pouvoir gérer un nombre important de chose simultanement est pris en compte dès le départ dans la définition du protocole. Pourquoi tous les serveurs XMPP se vantent alors de pouvoir gérer plusieurs milliers/millions d'utilisateurs ?
Après je ne pensais pas forcement du côté des performances, c'est certain que balancer des paquets icmp ou udp prendera moins de bande passante que d'envoyer des données en XML.
En XMPP je voyais plutôt le côté extensiblité et nouvelles possiblités par rapport à Nagios ou autre.
Firefox s'améliore mais le gagnant sous Sunspider est Chromium grâce à Google V8. Les autres browsers qui tournent avec webkit restent semblable à Chromium.
Je dirais même que j'ai une plus grande confiance dans l'avenir de la base de données d'OpenStreetMap que dans l'avenir de la base de données de Wikipedia. Car, les données d'OSM sont directement exploitables par d'autres logiciels tandis que dans mediawiki, il est difficile à un programme externe de retrouver une donnée précise d'une série d'articles. Et pourtant, Wikipedia est devenu un acteur majeur dans le monde des encyclopédies.
Ouais mais le Javascript c'est à la mode maintenant, on en mets partout, même dans les PDF, Adobe ils assurent de ce côté là, ça ouvre quelques failles de sécurité de plus pour les méchants :)
Autant pour moi, il fallait installer kipi-plugins qui permet de faire tout ça. En effet je n'utilise pas KDE ni Gnome... Bon je testerais ça voir si ça tiens la route :)
Tu peux utiliser Amazon S3, c'est conçu pour ça (décentralisé et tolérant aux pannes). Tu n'as pas de limite, tu payes en fonction de ton usage.
Pour le chiffrement des données tu peux utiliser un script perso qui utilise gnupg ou bien duplicity comme dit plus haut.
Sinon si tu as énormément de données Amazon à ouvert en beta son service d'import/export, en gros tu leur envoie un disque amovible et ils te transfèrent tes données. Ça évite de passer plusieurs semaines à uploader ton bazzar...
Par contre tu payes en dollars US, un inconvéniant si tu stocke que quelques Giga ça te coûte plus cher en frais bancaire :)
Je viens d'acheter un Asus eeePC 1005HA-M, j'ai installer une ArchLinux dessus avec kernel compilé à la mano. Pour l'instant j'ai 2 problèmes :
- Le driver pour la carte réseau (module atl1c) ne fonctionne qu'avec les dernières releases candidates du kernel, parfois lorsque je retire le câble RJ45 la machine freeze complètement sauf X où je peut encore bouger la souris.
- Le driver pour la carte wifi n'est pas encore très stable (module ath9k), lorsqu'il n'y a pas d'activité réseau, il se désassocie du point d'accès wifi tout seul, du coup je obliger de générer du trafic réseau pour éviter de perdre ma connexion.
Donc je remets à jour mon kernel depuis le dépôt git de temps de temps, les bugs finissent par disparaître au fur et à mesure... Sinon tout le reste fonctionne apparemment, je pense que ces bugs seront corrigés dans les prochaines releases du kernel.
Penser à garder la petite partition de type EFI car le BIOS mets en cache des trucs qui accélère le démarrage de la bécane.
Tu crois vraiment que leur mouchard va s'installer sur une distrib Linux ? et si j'utilise OpenBSD 64 bits ou n'importe quel OS représentant une part infime du marché du desktop...
Bref, vraiment une débilité leur loi, une fois plus.
Au mieux, pour nous utilisateurs d'internet, tout le monde va se mettre a utiliser des solutions chiffrées, ce qui rendera tout leur système inopérant à moins qu'ils sortent une autre loi débile pour interdire l'utilisation de VPN ou tout autre protocole chiffré. Là se sont les entreprises qui vont se marrer, bref... une loi de plus a mettre a la poubelle.
Tout comme Hadopi qui est totalement inaplicable... Je suis tout a fait d'accord avec toi.
C'est pas demain la veille que j'autoriserait un mouchard s'installer sur mon Linux... Si ça existera un jour, notre super gouvernement serait bien capable de te forcer à utiliser un OS propriétaire....
Ce qui me révolte c'est comment des politiques peuvent sortir des lois aussi débiles à l'heure actuelle. Il paraît que la France est en crise mais non, on enfonce le clou...
Au final, on trouve derrière les enjeux de l'eDemocratie, une certaine constance de la part des Etats-Unis et de la France qui proposent, chacun de leur coté, deux visions radicalement opposées de l’avenir de la démocratie : Libre et ouverte pour l’un, surveillées, contrôlée et verouillée pour l’autre, mais les deux pays ont au moins ce mérite d’être, chacun dans son genre, à l’avant garde de l’innovation. Open Source d’un coté, Hadopi et Loppsi de l’autre, les deux approches sont aujourd’hui observées par de nombreuses démocraties dans le monde qui se demandent où se site leur avenir et quel modèle adopter. Une rivalité vieille de plus de deux cents ans, finalement, mais avec des modèles qui divergent de plus en plus.
Vous croyez avoir tout vu avec Hadopi, l'Internet français n'est pas au bout de ses soufrances, la Loppsi arrive ! la loi pour la performance de la sécurité intérieure.
[^] # Re: En effet
Posté par Frédéric . En réponse à la dépêche OpenOffice.org 3.2 est disponible. Évalué à 1.
[^] # Re: import de fichiers CSV dans Calc
Posté par Frédéric . En réponse à la dépêche OpenOffice.org 3.2 est disponible. Évalué à 2.
Le pire c'est que ça marche aussi bien sous Microsoft Office 2007, alors qu'inconsciemment j'aurais pensé que ce dernier allait se vautré comme une merde.
Ça doit surrement dépendre de la quantité de ram dispo sur la bécane...
[^] # Re: Peu importe le protocole
Posté par Frédéric . En réponse au journal Supervision et XMPP, why not ?. Évalué à 2.
La question ici, c'est : est-ce que XMPP peut-être intéressant à être utilisé dans un système de supervision comme protocole de communication ?
Selon toi non, Nagios c'est le top et XML c'est oversize pour faire ça, bon ben pas la peine d'en faire un fromage.
Après ce qui est intéressant c'est de voir des avis différents, par exemple plus haut, on nous dis que redhat à sortie un truc en rapport avec ça... Peut-être alors que c'est pas si nul que ça...
[^] # Re: Peu importe le protocole
Posté par Frédéric . En réponse au journal Supervision et XMPP, why not ?. Évalué à 1.
Pour Nagios et compagnie c'est pareil, si le serveur de supervision tombe ben....
Tiens question pour les pros Nagios, ça existe un système de haute-disponiblité pour Nagios ?
Je parle d'un truc simple, pas une usine a gaz avec un fichier de config de 10000 lignes de perl :)
[^] # Re: Peu importe le protocole
Posté par Frédéric . En réponse au journal Supervision et XMPP, why not ?. Évalué à 3.
Imagine, qu'en plus d'avoir un système de supervision, tu peux avoir un système de controle a distance de tes machines, un système de déploiements de logiciels, etc, pas seulement sur tes serveurs mais aussi sur ton parc de postes clients...
Bon ok ça existe déjà :)
[^] # Re: xmpp adapté ?
Posté par Frédéric . En réponse au journal Supervision et XMPP, why not ?. Évalué à 2.
Si tu veux checker un certains nombre de services sur un certains nombres de serveurs, tu fais quoi, tu as un script/plugins qui va aller vérifier à intervale régulier que par exemple ton service est toujours ok.
Au final, tu va te retrouver avec plein de scripts qui vont pinger, vérifier que tel ou tel port est ouvert, etc, à interval régulier le tout en parallèle.
Ici dans mon hypothèse, tu as un agent sur le serveur, qui va t'avertir que tel service est down en poussant sur le réseau cette info. Sur ta console d'administration si ton serveur est déconnecté du réseau, tu le sait immédiatemment.
Après, pour vérifier que tel service fonctionne correctement, il existe surrement des trucs moderne dans nos kernels basé sur les évènements qui te dis automatiquement que le port 80 n'est pas plus en écoute sur telle interface ou que le processus avec le pid 845 vient de se terminer, etc... A l'époque de djbdns daemontools était bien capable de superviser des services. On a bien inotify qui permet de monitorer les changements sur le système de fichiers de manière évènementiel.
En gros, il suffit de programmer le système de manière évènementiel, à chaque fois qu'un évènement se déclenche une alerte est poussée via XMPP... et toi dans la milliseconde tu recoit un beau message sur iphone que te dis que ton serveur est down.
Après, au final ça se trouve ça utilise moins de bande passante que du snmp, du ping ou autre car ça cause sur réseau uniquement en cas d'évènement et pas toutes les 5 minutes.
Ensuite XMPP, c'est décentralisé, tu peut aussi monitorer des serveurs qui ne sont pas sur le même réseau que ton serveur nagios.
[^] # Re: Peu importe le protocole
Posté par Frédéric . En réponse au journal Supervision et XMPP, why not ?. Évalué à 3.
Oui je vois assez 20k services envoyer leur état en temps réel à une machine avec du XML ... C'est claire que ça va alléger la charge de décoder 20k messages XML en temps réel. Le push peut-être intéressant en supervision dans certains cas et est disponible sur nagios, mais ce n'est pas _la_ solution pour alléger le tout.
Pourtant à l'origine XMPP à été développé pour faire de la messagerie instantanée, et donc le fait de pouvoir gérer un nombre important de chose simultanement est pris en compte dès le départ dans la définition du protocole. Pourquoi tous les serveurs XMPP se vantent alors de pouvoir gérer plusieurs milliers/millions d'utilisateurs ?
Après je ne pensais pas forcement du côté des performances, c'est certain que balancer des paquets icmp ou udp prendera moins de bande passante que d'envoyer des données en XML.
En XMPP je voyais plutôt le côté extensiblité et nouvelles possiblités par rapport à Nagios ou autre.
[^] # Re: gestion de parc
Posté par Frédéric . En réponse au journal Supervision et XMPP, why not ?. Évalué à 2.
[^] # Re: Buildconfig ?
Posté par Frédéric . En réponse au journal Performance des navigateur web: linux parent pauvre ?. Évalué à 2.
* Sunspider :
* firefox 3.5.5 : 5870.8ms
* firefox nigthly build 3.7a1pre : 3670.2ms
* Chromium 4.0.267.0 : 2251.6ms
* Midori 0.1.9-0 : 2325.2ms
* Epiphany 2.28.0 : 2382.2ms
* PeaceKeeper :
* firefox 3.5.5 : 430
* firefox nigthly build 3.7a1pre : 560
* Chromium 4.0.267.0 : planté
* Midori 0.1.9-0 : planté
* Epiphany 2.28.0 : planté
Firefox s'améliore mais le gagnant sous Sunspider est Chromium grâce à Google V8. Les autres browsers qui tournent avec webkit restent semblable à Chromium.
Sinon j'ai pas de Windows pour comparer...
[^] # Re: problème de résolution DNS ?
Posté par Frédéric . En réponse au message très lent sur internet. Évalué à 8.
[^] # Re: Rien ne sert de mesurer, il faut cartographier à temps.
Posté par Frédéric . En réponse au journal Earthmine, les licences de db comme obstacle. Évalué à 4.
Pour exploiter les données de Wikipedia, il existe http://dbpedia.org/About
[^] # Re: Le tout connecté
Posté par Frédéric . En réponse au journal Vous êtes plutôt applications web ou applications desktop/native ?. Évalué à 2.
C'est déjà le cas avec Google Chrome OS.
# Rsync.net et Amazon S3
Posté par Frédéric . En réponse au message Solution de backup online. Évalué à 1.
http://rsync.net/
http://aws.amazon.com/s3/
[^] # Re: Ce que j'en pense...
Posté par Frédéric . En réponse au journal Javascript côté serveur, intéressant ou pas ?. Évalué à 4.
[^] # Re: Un bout de temps que c'est utilisé !!! [NON LIBRE]
Posté par Frédéric . En réponse au journal Javascript côté serveur, intéressant ou pas ?. Évalué à 1.
http://en.wikipedia.org/wiki/Server-side_JavaScript
Après il me semble que Opera l'utilise également pour son truc Opera Unite.
[^] # Re: haxe
Posté par Frédéric . En réponse au journal Javascript côté serveur, intéressant ou pas ?. Évalué à 2.
A voir si ça vaut le coup.
[^] # Re: Digikam
Posté par Frédéric . En réponse au message Logiciel pour tagger et géotagger ses photos en utilisant IPTC et XMP. Évalué à 1.
# Amazon S3
Posté par Frédéric . En réponse au message Recherche sauvegarde en ligne. Évalué à 2.
Pour le chiffrement des données tu peux utiliser un script perso qui utilise gnupg ou bien duplicity comme dit plus haut.
Sinon si tu as énormément de données Amazon à ouvert en beta son service d'import/export, en gros tu leur envoie un disque amovible et ils te transfèrent tes données. Ça évite de passer plusieurs semaines à uploader ton bazzar...
Par contre tu payes en dollars US, un inconvéniant si tu stocke que quelques Giga ça te coûte plus cher en frais bancaire :)
# Asus eeePC 1005HA-M
Posté par Frédéric . En réponse au message bon netbook linux. Évalué à 2.
- Le driver pour la carte réseau (module atl1c) ne fonctionne qu'avec les dernières releases candidates du kernel, parfois lorsque je retire le câble RJ45 la machine freeze complètement sauf X où je peut encore bouger la souris.
- Le driver pour la carte wifi n'est pas encore très stable (module ath9k), lorsqu'il n'y a pas d'activité réseau, il se désassocie du point d'accès wifi tout seul, du coup je obliger de générer du trafic réseau pour éviter de perdre ma connexion.
Donc je remets à jour mon kernel depuis le dépôt git de temps de temps, les bugs finissent par disparaître au fur et à mesure... Sinon tout le reste fonctionne apparemment, je pense que ces bugs seront corrigés dans les prochaines releases du kernel.
Penser à garder la petite partition de type EFI car le BIOS mets en cache des trucs qui accélère le démarrage de la bécane.
# Piwik
Posté par Frédéric . En réponse au message Equivalent Google Analytics. Évalué à 3.
http://piwik.org/
Aucune idée pour le Flash par contre...
[^] # Re: C'est franchement ridicule
Posté par Frédéric . En réponse au journal Après la Dadvsi et Hadopi, bientôt la Loppsi 2, c'est la GUERRE !. Évalué à 2.
Tu crois vraiment que leur mouchard va s'installer sur une distrib Linux ? et si j'utilise OpenBSD 64 bits ou n'importe quel OS représentant une part infime du marché du desktop...
Bref, vraiment une débilité leur loi, une fois plus.
Au mieux, pour nous utilisateurs d'internet, tout le monde va se mettre a utiliser des solutions chiffrées, ce qui rendera tout leur système inopérant à moins qu'ils sortent une autre loi débile pour interdire l'utilisation de VPN ou tout autre protocole chiffré. Là se sont les entreprises qui vont se marrer, bref... une loi de plus a mettre a la poubelle.
[^] # Re: C'est franchement ridicule
Posté par Frédéric . En réponse au journal Après la Dadvsi et Hadopi, bientôt la Loppsi 2, c'est la GUERRE !. Évalué à 3.
C'est pas demain la veille que j'autoriserait un mouchard s'installer sur mon Linux... Si ça existera un jour, notre super gouvernement serait bien capable de te forcer à utiliser un OS propriétaire....
Ce qui me révolte c'est comment des politiques peuvent sortir des lois aussi débiles à l'heure actuelle. Il paraît que la France est en crise mais non, on enfonce le clou...
Aller tiens on va voir ce qu'ils font aux US en ce moment : [http://fr.readwriteweb.com/2009/05/18/a-la-une/democratie-ed(...)]
Le dernier paragraphe est intéressant à lire :
Au final, on trouve derrière les enjeux de l'eDemocratie, une certaine constance de la part des Etats-Unis et de la France qui proposent, chacun de leur coté, deux visions radicalement opposées de l’avenir de la démocratie : Libre et ouverte pour l’un, surveillées, contrôlée et verouillée pour l’autre, mais les deux pays ont au moins ce mérite d’être, chacun dans son genre, à l’avant garde de l’innovation. Open Source d’un coté, Hadopi et Loppsi de l’autre, les deux approches sont aujourd’hui observées par de nombreuses démocraties dans le monde qui se demandent où se site leur avenir et quel modèle adopter. Une rivalité vieille de plus de deux cents ans, finalement, mais avec des modèles qui divergent de plus en plus.
# C'est pas fini ! Après Hadopi la Loppsi
Posté par Frédéric . En réponse au journal [HADOPI] et maintenant, la surveillance des emails.... Évalué à 6.
Je vous laisse découvrir ce blog [http://www.jmp.net/index.php/internet/dangers] qui en parle beaucoup mieux que moi, notamment sur cet article : [http://www.jmp.net/index.php/internet/dangers/257-apres-lhad(...)]