gnumdk a écrit 7498 commentaires

[root@arch /]# dbus-monitor --system
Failed to open connection to system bus: Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory
[root@arch /]# systemctl 
Failed to get D-Bus connection: No connection to service manager.
[root@arch /]# journalctl -D /var/run/log/journal/|grep 3.6.2-1-ARCH
Oct 22 13:44:27 arch kernel: Linux version 3.6.2-1-ARCH (tobias@T-POWA-LX)...012

Franchement, arrête de raconter n'importe quoi alors que tu n'as absolument jamais vérifier ce que tu avances depuis le début.

Mais qu'est ce que tu attends toi le génie de l'informatique pour aller apprendre à tous ces connards de dev comment faire leur travail ?

J'avais pas compris ton délire sur les indexes, c'est vraiment n'importe quoi… Les indexes journal, ils répondent à 99,9999999999999999999999999% des cas sauf le tiens…

Tu m'appelles le jour ou tu cherches dans tes logs sur un autre critère sur ceux fournit par journal… Après tu utilises grep pour faire du filtrage plus fin.

Donc on a O(log(n)) suivit de 0(n) sur le résultat précédent ce qui n'a rien à voir!

Bref, depuis le début, tu te branles la nouille et tu nous faire perdre du temps, va coder si t'es si bon que ca et que t'as tous compris aux problèmes d'init et de logs… Vivement de voir ton magnifique travail…

Mais de quoi tu parles, t'en a pas marre de raconter n'importe quoi ?

O(log(n)) c'est tout le temps, y'a pas d'indexeur dans journald…

Debian is really dying, la preuve ;)

http://www.donarmstrong.com/posts/bug_reporting_rate/

Mais que se passe t-il en cas de bugs ou autres imprévus m'obligeant à avoir
recours aux fichiers binaires ?

Si tu as configuré systemd pour "forwarder" tes logs vers syslog, la question ne se pose même pas.

Journal: O(log(n))
Grep sur fichier texte: O(n)

CQFD

Les logs de journalctl sont compressé par défaut donc tu gagnes (certe rien) pour le log courant :p

Journal récupère les infos en O(log(n)), alors que grep nécessite de tout parser… O(n), c'est surtout cela qui est important.

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/media-sound/amarok/amarok-2.6.0.ebuild?view=markup

En plus tu racontes n'importe quoi, amarok utilise mysql aussi sous Gentoo…

Et tu me fais dire des conneries, c'est akonadi qui a un support sqlite non officiel, pas amarok…

C'est vrai que ce n'est pas comme si Clementine c'était le code de Amarok 1.4… Je veux bien que les devs d'amarok soit des pros de l'optimisation des requetes SQL mais faut pas pousser non plus…

De plus, non, ma capture d'écran prouve qu'on doit utiliser Amarok avec MySQL…

Une explication d'un dev d'Amarok sur pourquoi ils ont abandonné sqlite…
http://amarok.kde.org/blog/archives/812-mysql-in-amarok-2-the-reality.html

The first problem is performance. Although for people with small collections it performs fairly well, people with large collections that switched to the MySQL or PostgreSQL backends in A1 would report enormous speed gains when operations performing complex or many queries were performed, such as adding many entries to the playlist, scanning files, or filtering/searching in the collection.

http://reflets.info/ogm-ou-la-science-contre-la-democratie-jean-pierre-berlan/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+refletsinfo+%28Reflets%29

Effectivement, j'ai confondu avec Akonadi… Mais je parlais pas de postgres au départ ;)

Es-ce que ça vous va comme exemple pour comprendre ce que je veux dire ?

Et tu sais quelle taille ca prend d'indexer plusieurs Go de fichiers texte? Pourquoi on irait perdre de l'espace disque stupidement comme ca…

Et si tu coches pas, alors amarok lance un mysql configuré sur ton $HOME.

C'est un peu l'inverse, amarok 1 n'avait que sqlite.

Amarok 2 supporte MySQL et Postgres de manière officiel et le backend Qt/SQLite est totalement non supporté par les devs.

Ce sont eux qui font des dégats que les vieux croutons doivent réparer.

Et le jour ou le vieux crouton par à la retraite, elles s’aperçoivent qu'elles ont 20 ans de retard…

Or ces sociétés ont souvent des scripts, des outils, des programmes même codés maison et qui
utilisent la puissance de l'init traditionnel pour fonctionner (processing turing complet,
prise en charge des variables d'environnement, init prévisible, logs dans des fichiers plats
etc.)

Ca tombe bien, systemd a un mode de compatibilité sysvinit… Mais bon, un script d'init rc qui fonctionne entre deux versions d'une distribution sans modification, c'est déjà pas gagné, surtout sur des gros logiciels.

Je n'ai pas vraiment de vision sur ces sociétés, je n'en connais que trois. Mais les trois que
je connais (en l’occurrence leurs sysadmin) ne veulent pas de systemd

Cool, ben il va falloir que ces boites pensent à les foutre à la porte alors, parce que bon, les vieux croutons qui refusent d'apprendre parce qu'ils ont toujours fait comme cela, en informatique, on sait ce que ca donne…

C'est exactement pour cela que personne ne sérieux ne penserai à utiliser sqlite pour avoir des vraies performances… Suffit de voir la différence de rapidité au niveau de la gestion des collections entre Amarok (mysql) et Clementine (sqlite).

On peut parfaitement normer et indexer un fichier texte.

Quelle bonne idée, je vais installer beagle sur un serveur!

La place ? Les logs chez moi ne font même pas 50Mo

Et t'as déjà fait des recherches dans des logs sur autre chose que ton pc personnel avec grep et compagnie ? Réponse: ca rame comme la mort, tu peux facilement attendre 5 minutes pour t'apercevoir que ton grep ne renvoie rien et recommencer pour 5 minutes de grattage de disque supplémentaires.

Avec journald, les recherches sont rapides et c'est pour cela que le format binaire est intéressant.

Bon, vu que tu n'as pas trouvé, je vais te donner la réponse: pour des raison de performance…

Les fichiers textes c'est tellement bien qu'autour de moi tout le monde utilise un logiciel propriétaire pour faire des recherches dans ses logs: splunk.

D'ailleurs si quelqu'un connait un équivalent de splunk libre et bien foutu, je prend.

Je sais pas, faudrait demander aux devs de MySQL pour leur db sont pas directement des fichiers textes avec les requêtes SQL ;)

Non, tu n'as pas compris, j'ai dit: xinetd est un truc à part qui n'est pas intégré au système d'init. Donc tu as deux façons de lancer un même service qui peuvent en plus rentrer en conflit.

En gros, tu te pleins qu'on redéveloppe des trucs déjà existant? Tu devrais arrêter le logiciel libre tout de suite, ce un principe de base: "Si je code un truc qui répond mieux au besoin, alors il remplacera la concurrence"

tu as aussi des gens qui laissent les utilisateurs faire les updates sans mot de passes via
packagekit

C'est le comportement par défaut de apper sous ArchLinux.

Tu ne dois pas bien comprendre comment fonctionne journald…Si systemd ne control pas le lancement des applications, alors la recherche sera aussi pourri qu'avec .xsesssion-errors.