nud a écrit 906 commentaires

Je n'ai pas vraiment d'opinion sur journald, cependant:

Parce que Lennart n'a toujours pas comprit l'intérêt d'Unix. L'interface texte toussa …

Ben en fait, pour les besoins de la cause, tous les outils pour interagir avec les journaux ont une interface texte "machine-friendly".

Si l'esprit d'unix se résume à l'interface texte, il n'est pas question du stockage. En l'occurence, avec journald tu peux utiliser l'outil associé qui te retourne une suite de lignes de log, de la même façon que zgrep/zcat te permettent de retourner des lignes de log avec syslog, juste de façon plus rapide.

Et, soit dit en passant, l'argument du format texte robuste n'est plus vraiment recevable à partir du moment où il est compressé, ce qui est le plus souvent le cas pour les logs après rotation.

Sauf que maildir est encore un format très différent, qui n'est pas comparable aux syslogs: une entité (un mail) par fichier, des méta-données encodées dans le nom du fichier sur le disque, et, de surcroît, une normalisation très forte et très complexe des opérations que l'on peut réaliser sur un dossier mbox.

Le format mbox, qui contient plein de messages dans le même fichier, est beaucoup plus similaire à la situation des syslogs: plein d'entités dans le même fichier et un nom qui n'a aucune signification particulière et sur lequel on fait (majoritairement) du append-only.

Tu peux aussi stocker ton index dans un autre fichier, c'est ce que les serveurs imap (genre dovecot ou cyrus) font déjà avec les fichiers mbox. Il faut juste détecter les modifications de ton fichier texte pour actualiser ton index quand c'est nécessaire.

C'est juste que sqlite est un exemple particulièrement mal choisi, tu aurais pu parler directement des mbox :p

L'index binaire est stocké dans le même fichier que le "texte" (qui au final est juste un ensemble de strings C dumpées telles quelles dans un fichier binaire), c'est donc de facto un fichier binaire.

Vu que c'est redhat qui pousse dans cette direction ils ont peut-être quelque chose dans les cartons.

Et Nemiver ça sent le pâté? Par contre oué, le vala c'est la plaie à déboguer (déjà le "compilateur" est plein de bugs et les gusses derrière vala ne comprennent rien à la compatibilité ascendante), je comprends pas pourquoi tant de gens dans Gnome qui utilisent ça.

La RFC 6752 "Issues with Private IP Addressing in the Internet" est semble-t-il de circonstance.

Sauf que biodégradable ou non il va finir dans la poubelle, et donc dans l'incinérateur. Je doute que quiconque ne mette les plastiques biodégradables dans leur compost.

C'est un cycle court, donc ce n'est pas considéré comme polluant dans la mesure où le maïs de l'année suivante va emprisonner la même quantité de CO2. C'est le même raisonnement qui est appliqué quand on dit que les pellets de bois ne sont pas polluants par opposition au mazout (qui est un cycle très long): tu ne libères pas du nouveau carbone dans l'atmosphère.

Du reste, si ton maïs passe par une phase "plastique" à courte durée de vie, il finira de toute façon dans l'incinérateur avec les autres déchets. Mais effectivement c'est un cycle court donc c'est moins polluant que du plastique à base de pétrole.

Les liens symboliques c'est à faire en dernier recours quand même, car on se trompe vite dans les droits (un -a manquant derrière le cp et c'est foutu) et ça peut causer des dysfonctionnements assez folklo à débugger. Il faut commencer par les usual suspects (voir plus bas) avant de chipoter.

Inutile sur un PC de bureau de séparer /var. Ne séparez plus non plus /usr, c'est chercher des misères avec udev.

Tu peux procéder avec du -sh /* | sort -h et aller récursivement dans les dossiers qui ont une taille suspecte (tu peux aussi utiliser baobab si tu as Gnome, et il y a sans doute un équivalent KDE)

Typiquement, ton espace disque est bouffé par:

• Les archives de ton gestionnaire de paquets. Commence par un pt-get clean ou équivalent.
• Des logs, en particulier si un événement s'est produit et a rempli le disque. Une fois j'ai eu un disque rempli par des logs qui me prévenaient que mon disque était presque plein toutes les 5 secondes… jusqu'à ce qu'il n'y ait plus de place pour écrire les logs. Idem avec postfix.log si tu as un problème de relai de mail.
• Des gros fichiers temporaires dans /tmp (sauf si tmpfs), genre une iso téléchargée avec Firefox et autres joyeusetés du genre.

Commence par vérifier cela avant de perdre ton temps avec baobab.

Certes. Mais est-ce dans ce cas bien légal vis-à-vis de la législation européenne ?

Ah les joies du plein emploi…

J'ai été surpris par ce nouveau connecteur et l'absence de port USB. Il me semblait en effet qu'en Europe les smartphones devaient obligatoirement être équipés d'un port micro-usb pour le chargeur, mais apparemment donner un adaptateur avec le smartphone est suffisant (ce qui est con vu que du coup on perd l'avantage du chargeur universel, sauf à se balader toujours avec l'adaptateur).

Après faut voir aussi les droits sur l'univers BSG, le design des appareils, tout ça.

tout dépends de ce qu'on entend par "installer",

make vs make install.

Compiler quelque chose n'impose pas de l'installer, par contre cela impose d'installer toutes les dépendances de compilation. C'est le problème mentionné ici: le mainteneur de lfs ne veut pas installer systemd mais la fusion lui impose d'installer les dépendances de compilation de celui-ci, qui comprennent la libdbus.

Après il pourrait probablement installer la libdbus sans installer le dbus complet, comme c'est déjà le cas sur une debian serveur par exemple.

systemd dépend de la libdbus car il propose une "activation dbus" similaire à l'activation par socket, mais utilisant un nom dbus. Si on avait un autre mode d'IPC de type bus répandu il dépendrait probablement de la lib idoine pour fournir également une activation paresseuse pour ce protocole d'IPC.

Tu n'as pas bien suivi.

la fusion nous oblige à installer systemd

Non, la fusion oblige juste à compiler systemd, mais udev reste fonctionnellement indépendant.

les dev de Dbus avaient plus ou moins promis que la fusion n'empêcherait pas l'usage de Dbus sans systemd

Non, On peut toujours utiliser dbus sans systemd… Le problème est ici udev, qui est compilé avec systemd, qui nécessite la libdbus.

Gnome (et sa galaxie d'applications) qui va nécessiter systemd

Non, Gnome utilise juste de certaines interfaces dbus simples implémentées par systemd et qui pourraient être implémentées par d'autres démons de la même façon (genre org.freedestktop.hostname1). On ne peut pas même parler de dépendance: si tu n'as pas de démon qui implémente cette interface tu peux juste pas changer ton hostname depuis la GUI.

les gars de LFS ont déjà fait un script pour compiler Dbus sans systemd

Non, dbus a pas besoin de systemd, c'est udev qui a été fusionné, pas dbus.

Sauf que systemd est idéalement placé pour se rendre compte que le service disparaît au moment où il disparaît. Idem s'il bloque. Il reçoit le sigchld, il contrôle le socket, bref, il est où il faut pour ça.

Les services externes de monitoring (mon, monit, god et consorts) ne font que du polling, donc si tu vérifies tes services une fois toutes les 5 minutes tu cours le risque de rester avec un service down pendant 4:59 au pire des cas. Systemd peut réagir immédiatement.

J'attends la sortie de wheezy justement pour pouvoir utiliser systemd sur des serveurs, justement pour avoir cette surveillance qui fonctionne bien mieux avec systemd qu'avec mon.

Juste car c'est le même auteur, tu peux tout à fait faire tourner ces petits programmes triviaux sans systemd, certaines distro le font. Ça utilise probablement un .so commun mais ça marche aussi avec sysvinit.

la tentative de dépendance obligatoire dans GNOME.

Ce point a déjà été discuté précédemment. Gnome ne dépend pas de systemd, mais il dépend d'interfaces D-Bus diverses (genre org.freedesktop.hostname1) spécifiées au sein de freedesktop.org, et qui sont pour l'instant uniquement implémentées par des petits utilitaires fournis par systemd. Ces interfaces sont triviales (vraiment) et peuvent être implémentées facilement par un autre outil.

Il s'agit juste de déplacer la maintenance des outils spécifiques aux distros au sein des distros au lieu de les garder au niveau de l'upstream, car de toute façon les outils upstream (system-tools-backend) ne supportaient que redhat, debian et opensuse.

Note que la distinction PC vs Mac n'a plus vraiment de sens, de nos jours c'est plutôt PC livré avec Windows vs PC de marque Apple livré avec MacOSX.

Non je suis le pape et j'attends ma sœur.

Non, c'est à côté