DerekSagan a écrit 613 commentaires

Je suis en train de jouer avec logstash, c'est carrément cool pour chercher quelque chose dans whatmille fichiers sur whatmille serveurs.

Par contre… une fois qu'on a une entrée/ligne de log je vois pas du tout comment la visualiser dans son contexte = avec les entrées qui suivent et qui précédent dans le même fichier de log ou avec les entrées qui suivent et qui précèdent pour un même type de serveur.

Je dis pas que c'est pas possible, juste que je trouve pas.

Pour dire ça tu dois pas vraiment avoir développé avec Qt.

Juste 3 exemples du fait que Nokia n'a "rien fait":

• QtCreator est une vraie tuerie et un compromis assez unique sur le marché entre ergonomie productive et simplicité.

• Le travail de modularisation qui a abouti à Qt5 a rendu possible le fait qu'on soit maintenant en support Windows + MacOSX + Linux + Android + iOS. Certes ça a surtout été fait parce que Nokia avait une stratégie multi-OS sur ses téléphones qui n'a pas été payante du tout (du coup je cite pas comme un grand gain les OS Nokia en train de s'éteindre, ni Blackberry 10), mais la contribution à Qt elle reste même quand la stratégie est partie.

• QML comme le disait Albert, mais aussi ce qui a été nécessaire pour y aboutir (perso je suis pas fan QML mais je vois ce qui est venu avec), comme la fort sympathique intégration C++/Navigateur apportée par QtWebkit.

Je continue à préférer noyau plombé. ;-)

J'ai trouvé la même erreur sur ce site d'ayatollahs de passionés: http://www.additifs-alimentaires.net/E131.php

Si c'est ta source, il est possible que ce soit en partie vrai car en 2001 la Norvège est entrée dans l'EEE à défaut de l'UE et ça l'a peut-être amené à autorisé cet additif alimentaire.

Cela dit l'interdiction par les USA et le Canada d'un produit nommé "machin patenté" sent quand même la guerre commerciale. Il y aurait pas par hasard une production uniquement en Europe, genre comme la carte à puce tant que les Américains n'ont pas eu racheté Gemplus ?

(je dis ça sans avoir cherché, si c'est faux, je suis désolé pour le FUD)

Et c'est quoi l'utilité d'un site web qui te signale que les carottes de ton AMAP sont composées à 100% de carotte ?

Surtout que justement le fichage des compositions d'aliments nécessite des aliments dont la composition est relativement stable d'un approvisionnement à l'autre, du coup ça se prête qu'à l'industriel…

Ta carotte 100% carotte elle a pas le même contenu en sel ou en vitamine C d'une fois sur l'autre.

Je trouve cette photo de fruits sectionnés à vif sur toute leur largeur absolument insoutenable.

Oh il n'y a pas que l'alimentation, la respiration aussi.
Le dioxygène par exemple provoque l'apparition de radicaux libres, qui sont extrêmement cancérigène.

Actuellement mon travail n'est pas mis en ligne.

Ah ok, donc il y a un point de blocage supplémentaire à l'utilisation que l'absence de la marque des produits. ;-)

Ça veut dire plein d'autres choses aussi par exemple:
* http://en.wikipedia.org/wiki/Target_hardening -> blindé
* http://en.wikipedia.org/wiki/Hardening_%28botany%29 -> aoûté
* etc.

Mon préféré c'est celui-ci:
* http://en.wikipedia.org/wiki/Radiation_hardening -> plombé

Je comprends pas pourquoi on dit pas un noyau plombé du coup.
;-)

Bon, mais durci c'est probablement la meilleure traduction, celle qui conserve le sens métallurgique et/ou militaire et qui a le mérité d'être simple, clair, et pas mal usité à ce sens-là.

Oui, c'est ce que je veux dire par là:

et même au-delà si tu as suffisament d'io, qu'elles sont petites, et qu'elles sont au même endroit sur le disque (ça marche pour un redolog par exemple, absolument pas par contre pour du random un peu partout), parce que tu laisses l'os les agréger, grâce à la libaio.

Oui mais quand on parle de perfs brutes sur une base de données, en général sur le serveur qu'on teste il n'y a que le sgbd qui écrit, et sur un disque dédié (genre les logs systèmes sont sur un autre disque).

La limite théorique pour n disques en raid 0 strippés c'est n fois la limite d'un disque. Genre 200 iops pour 2 sata 7200. En pratique faut vachement bien tunner la taille des stripe selon le paramétrage du sgbd (ou du filesystem), en alignant avec la taille des blocks en particulier. https://www.google.fr/search?q=redo+log+stripe+size

Sur un disque 7200 rpm tu montes à peine à 100 write/s. C'est la limite du disque pas du filesystem. Tu peux vérifier ici.

Si tu fais un fsync à chaque fois que tu veux le D de ACID sur un filesystem, tu prends minimum 2 io (les données et les méta-données) donc t'as au mieux 50 fsync/s.

Pour faire mieux il faut écrire dans un seul fichier de taille constante pour pas modifier ses métadonnées et remplacer fsync par la libaio (comme toutes les bases de données cherchant à faire de la perf le font, justement) et là tu monteras à 100 write/s avec des grosses io, et même au-delà si tu as suffisament d'io, qu'elles sont petites, et qu'elles sont au même endroit sur le disque (ça marche pour un redolog par exemple, absolument pas par contre pour du random un peu partout), parce que tu laisses l'os les agréger, grâce à la libaio.

Si tu fais plus, c'est soit que t'as un disque plus performant, soit que tu n'as pas le D de ACID (pour des raisons soft genre ni fsync ni attente via la libaio, ou pour des raisons hard genre ton disque est mal configuré et acquitte les écritures avant de les faire), soit que tu as modifié les lois de la physique. Par comparaison avec les write/s pures du disque, ce que le filesystem peut faire de mieux c'est ne pas les dégrader.

J'ai préféré "Un gestionnaire de fenêtres, c’est trop user-friendly, je fais tout à la console !"

C'est à la fois exactement vrai et exactement le contraire.

Par exemple ta superbe pirouette intellectuelle "la garantie d'écriture avec de bonne performance est assuré par les FS depuis longtemps" … "les FS protège surtout leurs métadonnées".

T'arrives presque à te rendre compte que ton raisonnement est faux. La garantie d'écriture des données avec de bonnes performances n'est pas assurée. Ou au moins aussi lentement que pour une base de données quand elle assure la même chose.

J'utilise mfc110.dll

Pour résister à un kill -9 et (plus encore) à une coupure de courant il faut que l'écriture ai été faite physiquement sur une mémoire persistante (disque…) avant de rendre la main à l'application qui a terminé une transaction (lors d'un commit s'il y a des commits). Pour chaque transaction.

Ça se fait avec fsync, msync ou les équivalent de la libaio si on utilise les i/o asynchrones Linux.

Ça ne dépend pas du type de base de données ou de stockage (même fichier voire accès disque direct (raw device)). Et en général c'est le facteur limitant lors d'écritures.

C'est exactement le D de ACID. Donc tu t'en fiches peut-être de ACI mais manifestement pas de D.

Ben tu écris sur disque toutes les heures, c'est persisté mais t'as pas le D de ACID tout le temps.

C'est rigolo tous les trucs que tu crois et que tu dis sur les filesystems et qui en fait son faux.

C'est d'ailleurs pour ça qu'on utilise des bases de données d'ailleurs (sql ou pas).

Le 1er et le 3ème lien google "postgresql hint" répondent assez bien à "pourquoi il y en a pas?" et "comment qu'on fait alors?":
* http://wiki.postgresql.org/wiki/OptimizerHintsDiscussion
* http://blog.2ndquadrant.com/hinting_at_postgresql/

C'est logique, ce sont des Américains.

Moi je dis, heureusement que Digia est là (entre autres).

Je viens de lire les supports des conférences 2012, et à mon avis, quand les supports de celles de cette année seront en ligne, ça méritera largement une deuxième dépêche…
:-)

Je ne veux pas spécialement abandonner OpenVpn mais ça m'intéresse de regarder ce qui se fait de nouveau. Merci je vais regarder Tinc.

Il y a-t-il un utilisateur de Combine qui peut nous donner des exemples concrets ?
Parce que le lien d'exemples ci-dessus ne donne que des exemples où awk od cut et sort (voire join) suffisent.

Moui, si les avions volaient en ligne droite et ne respectaient pas les routes aériennes ça se saurait.
Bon mais 12000 c'est quand même un peu large.