needs a écrit 329 commentaires

Tu déformes le journal en disant que "systemd est moins bon que SySVInit", il dit juste qu'une option par défaut ne lui convient pas (la belle affaire).

Tu as mal lut mon propos, ou j'ai mal compris le tient. Je concède que systemd est meilleur que SysVInit pour les mainteneurs d'une distribution. De part les retours que tu peux lire ici même et ailleurs sur internet, systemd est à la fois apprécié et décrié par les sysadmin. De même, systemd est source de nombreux problèmes pour les développeurs et utilisateurs lambda. Il existe des alternatives tout à fait valable à SysVInit, comme minit ou runit.

En quoi c'est le problème de systemd ? Upstart a un système pour rendre compatible avec ce que propose systemd.

C'est le problème de systemd car avant systemd il n'y avait pas à « être compatible avec systemd », et après systemd il faut « être compatible avec systemd ». Ou dit autrement, systemd casse un système qui était stable en redéfinissant le rapport entre les programmes utilisateurs et un système d'init, de force.

Tu peux donner des sources ? Quelles "programmes" ne fonctionnent plus en dehors de systemd ?

GNOME, KDE, tout les programmes qui utilisent udev, avahi et probablement d'autres. Sans compter les multiples bugs (comme pour tmux) qui forcent les développeurs a intégrer un « switch systemd » dans leur code, histoire de bien marquer au fer rouge la communauté.

Et si vraiment la communauté des utilisateurs de Linux n'en voulait pas, Devuan n'en serait toujours pas en beta alors que la première version était annoncé pour le printemps 2015.

Les utilisateurs n'ont pas tous les compétences, le temps, la motivation de maintenir une distribution (qui plus est basée sur Debian). Encore une fois, systemd est une avancé par rapport à SysVInit du point de vu des mainteneurs. C'est une régression du point de vue des développeurs et utilisateurs lambda. Devuan n'est d'ailleurs pas une alternative à systemd, c'est un fork de Debian sans systemd.

Encore une fois non. Dire que systemd a été poussé de force, c'est falacieux. Il n'a pas été poussé, il a été développé par Redhad. Redhat n'a pas été contraint, il en a fait le choix.

Systemd n'a pas été développé par Redhat en premier lieu, comme l'explique Lennart¹, il s'agit d'un projet personnel. Seulement puisque Lennart est un employé de Redhat (Et Kay Sievert de Novell) il a été plus facile d'intégrer systemd à Fedora, il en parle même dans le lien donné plus haut. Donc ce n'est pas fallacieux.

Ton programme, s'il utilise un système de logs, dbus ou udev ne dépend pas de systemd. Ces fonctionnalités sont des interfaces et systemd est une implémentation de ces interfaces.

Il ce trouve que si, car pour le moment systemd est le seul programme qui implémente toute ces interfaces, plutôt complexes. Il faut bien voir qu'avant ces interfaces étaient toutes implémentées par des programmes plus ou moins indépendant. Petit à petit ces programmes ont été intégrés à systemd. Elle vient de là la dépendance à systemd. Il faut aussi voir que c'est bien l'équipe de systemd (ou des personnes des mêmes employeurs) qui définit à la fois le standard² et l'implémentation de référence.

Il faut que tu m'expliques le lien entre la position de systemd sur un système et "la raison majeure de son adoption massive". Il a été adopté car il répondait à un besoin, pas parce qu'il se place à tel endroit dans la pile système.

systemd est un deuxième élément critique du système, le premier étant le noyau. Il ce place intentionnellement entre tout programmes utilisateur et le noyau, forçant son adoption ainsi que rendant plus difficile la mise en place d'alternatives. Est-ce plus clair ?

Au contraire, l'exemple est des plus convaincant. Dans les deux cas, on dispose d'un techno présente depuis des décennies. (…) Les choses ont énormément évoluées, les contraintes (en disque, en ram, en processeur, etc…) ne sont plus du tout les mêmes et les outils ont aussi évolués.

C'est vague et s'applique globalement à tous les programmes informatique. Non, ce n'est définitivement pas convaincant. De plus, plus de « disque, ram, processeur, etc… » n'est pas une raison pour faire des mauvais programmes et augmenter la complexité du système.

Et on essaie de la remplacer car, il faut le dire, une décennie en informatique, c'est une éternité.

L'age n'est pas un argument, et non, une décennie ce n'est pas une éternité, il ne faut pas exagérer.

---

¹: Quand bien même il précise que systemd dans ses premiers jours à reçut une collaboration de Key Sievert de Novell, il en vient assez vite à parler d'inclure systemd dans Fedora. Il ne cache pas ses objectifs, qui sont très certainement aussi ceux de son employeur.

²: DBus est contrôlé par RedHat, udev a été développé et maintenu en partie par Kay Sievert…

Je ne prétends pas répondre à la place de Grégoire G, ce serait malvenu, mais tu exagères son propos et tu lui fais dire ce qu'il n'a pas dit.

Mais ce n'est pas parce que Redhat n'est pas adapté à TON usage que c'est de la merde.

Il ne prétend pas que « c'est de la merde », il préfère Debian à RedHat, sans pour autant qualifier RedHat de « merde ».

Ben pour des serveurs, je trouve ça cool. Ca t'évite d'avoir des services non configuré qui vont être lancé automatiquement.

Il n'a pas dit le contraire. Il mentionne juste un cas précis, et tu en a fait une généralité.

Systemd, la source de tous les mots.

De même, il précise qu'il trouve systemd « pénible », et tu généralises sans fondement.

---

Systemd a apporté de nombreuses réponses à bon nombre de problème (il n'y a qu'à voir son adoption rapide par les distributions. Si c'était si inutile que ça, il n'y aurait pas eu tant d’engouement).

L'adoption de systemd n'est pas le résultat d'un consensus de la communauté des utilisateurs de Linux. Les paragraphes qui suivent devrait te convaincre.

Premièrement, il faut reconnaître que systemd est plus facile à utiliser que SysVInit pour les mainteneurs d'une distribution. Et c'est pourquoi il a été adopté, car ces sont précisément les mainteneurs qui ont le dernier mot sur les programmes par défaut d'une distribution.

Ce ne sont pas les utilisateurs (autant sysadmin, développeurs ou personne lambda) qui ont choisi systemd. Et il ce trouve que systemd est moins bon que SysVInit du point de vue utilisateur, comme le montre ce journal et de nombreux autres avant, ici ou ailleurs sur Internet.

Il faut aussi reconnaître que systemd à été poussé de force dans RedHat et Fedora, tout simplement car RedHat contrôle ces deux distributions. Cette migration a forcé certain programmes à être fortement dépendant de systemd, notamment car systemd est conçut comme un monolithe. Si tu dépends d'une fonctionnalités quelconque de systemd, alors tu dépends la totalité de systemd.

Rappelons aussi que systemd contient en autres udev, un système de logs, un gestionnaire de session, et gère une partie de dbus. Ainsi les programmes qui ont besoins de telles fonctionnalités doivent inclure du code pour pouvoir fonctionner sur un nombre croissant de distributions. Et comme maintenir plusieurs version d'un même code est difficile, certain programmes sont devenu simplement dépendant de systemd.

Un peu à la manière de pulseaudio qui ce place entre tout autre serveur son et le noyau, systemd ce place entre tout programmes utilisateurs et le noyau. C'est la raison majeure de l'adoption massive de systemd. Et c'est pourquoi le terme « forcé » est tout à fait approprié.

C'est encore une fois un cas typique qui montre qu'une adoption massive n'est en générale pas corrélé à la qualité technique.

---

Tiens, on va prendre un exemple : systemd et wayland. Systemd est sorti en 2010 et à déjà été adopté par la grande majorité des distributions. Wayland existe depuis 2008 et à encore pas mal de chemin à faire.

Wayland n'est pas aussi mature que systemd. Le contexte n'est pas le même, les programmes ont des finalités bien différentes. Bref, c'est comparer l'incomparable, cet exemple n'est pas convaincant.

Redhat, et systemd appportent beaucoup de problèmes. Je suis curieux de savoir lesquels sont résolus. Sincèrement, avec systemd, la plupart de mes machines sont devenues lente à l'extinction.

Je te seconde sur ce point avec un petit retour d’expérience personnelle. Depuis au moins 6 mois, lorsque j’éteins mon ordi (ArchLinux) il y a environ :

• 6 chances sur 8 qu'il reste allumé avec un écran noir, le rétro éclairage toujours allumé
• 1 chances sur 8 qu'un processus (lequel?) bloque l'extinction pendant 1m30, le délais maximum
• 1 chances sur 8 qu'il s'éteigne convenablement en moins de 10 secondes

J'en ai globalement rien à faire car mon ordi ayant plus de batterie, j'ai juste à débrancher le câble d'alimentation pour l'éteindre brusquement. Pour des raisons qui me sont obscure, mon ordi n'a jamais été très compatible avec les programmes de Lennart, à savoir pulseaudio, NetworkManager, journalctl et systemd.

Quand je vois la simplicité d'un fichier de config systemd pour l'immense majorité des cas (limite un unit file d'un daemon simple c'est 3 lignes, le nom du service, le binaire à lancer, et l'utilisateur) et les critiques style "mais ça casse mon script d'init de 1500 lignes pour mon usine à gaz ignoble", je dirais que c'est tout le contraire.

Il existe des systèmes d'initialisation on ne peut plus simple, comme runit, ou minit par exemple. La aussi c'est une histoire de moins de 10 lignes. Ce qui est important de comprendre, c'est que 10 lignes pour systemd et 10 lignes pour runit n'ont pas la même complexité lorsque l'on regarde le système dans son ensemble.

Systemd, c'est pas moins dans 270 000 ligne de C¹, dont 44 000 pour la gestion des services². Le code de minit ne dépasse pas les 1700 lignes, et celui de runit, 6500 (ou 3400 lorsque l'on ne compte pas la réimplantation partielle de la lib C³). C'est sans compter le fait que systemd définit plus de 60 services et bibliothèques⁴ qui sortent complètement du champs d'un système d'init.

Enfin systemd fait tout pour ce placer entre le noyau et un programme utilisateur. Ce qui ajoute un deuxième point critique au système, le premier étant le noyau (monolithique, lui aussi). Tout ceci montre que systemd est d'une complexité beaucoup plus grande que ce qui est nécéssaire, comme le montre les alternatives fonctionnelles. De plus cette complexité ce retrouve au cœur du système et envahit l'espace utilisateur. C'est pourquoi il est fallacieux de qualifier systemd de « simple », et présumer qu'une alternative est nécessairement complexe (« 1500 lignes »). La situation actuelle tend à montrer l'inverse, systemd étant complexe, et les alternatives en moyenne sont assez simples.

---

¹: En ne considérant que les fichiers du répertoire src.

²: Systemd étant un énorme monolithe, on ne peut pas séparer uniquement la partie du code qui gère les services. Ainsi, on obtient le chiffre de 44 000 lignes de code en ne comptant que le code dans src/core et src/systemctl.

³:runit/src $ cloc chpst.c runit-init.c runit.c runsv.c runsvchdir.c runsvctrl.c runsvdir.c runsvstat.c sv.c svlogd.c svwaitdown.c svwaitup.c utmpset.c

⁴:ls systemd/src | wc -l, qui donne 76. Résultat duquel il faut soustraire au moins trois fichiers, le Makefile, src/core et src/systemctl, plus une bonne demi-douzaine pour des dossiers qui ne définissent ni services, ni bibliothèques.

Systemd, ou comment ne pas encourager l'écriture d'applications au comportement propre. C'est sûr, ce gars a une vision à long terme pour linux…

Il y a une part de vérité. Si il y a un bug dans kdeinit, c'est pas dans systemd qu'il faut le corriger/le cacher.

Suite à ce journal je suis allé voir ce film pour me faire une idée, et j'ai beaucoup aimé. À la fin de la projection il y a eu une demi-heure de questions-réponses avec des membres de l'équipe (je crois), elle aussi très intéressante. Un film qui laisse le spectateur comme seul juge, au point qu'une personne a demandé à l'équipe quelle était la morale de leur film :)

AlsaCréations est un site en français connu de longue date pour la qualité de ses articles. Voici leur article sur le positionnement. Je t'invite aussi à jeter un coup d’œil aux flex-box, c'est très simple, plaisant à utiliser et résout bon nombre de problèmes de positionnement.

Non, je voulais bien dire déflationniste : le lundi une baguette coûte 1 Bt, le mardi elle coûte 0.9 Bt, etc. C'est de la déflation

Bien vu, j'ai confondu.

un Satoshi serait trop gros pour servir de monnaie (environ 0.2$)

Un Satoshi c'est BTC, alors que le milli-bitcoin c'est BTC. Si le bitcoin vaut 200$, le milli-bitcoin vaut 0.2$ et le Satoshi vaut 0.000002$. Pour qu'un Satoshi corresponde à 0.2$, il faudrait que le Bitcoin s'échange à 2 000 000$, ou dit autrement dans la page linkée plus haut :

As of August 2015, 1 US cent is worth approximately 4400 satoshi.

La structure du Bt (déflationnisme intrinsèque, coût réel du minage de plus en plus élevé, etc)

Tu voulais surement dire « inflationnisme intrinsèque » ? Puisqu'il y a un nombre limité de Bitcoins, et qu'un Bitcoin peut être perdu définitivement, il y aura de l'inflation sur le long terme.

ni pour devenir une vraie monnaie (valeur d'un Bt bien trop élevée, et subdivision du Bt trop grosse à terme).

Il suffit d'adopter une unité adéquate, comme le mili-bitcoin, ou le bit (micro-bitcoin). Sinon en quoi la subdivision du Bitcoin trop grosse est un problème ? Elle risque d'être justement trop petite ! Par exemple un Satoshi est la plus petite division possible d'un BTC (0.00000001 BTC), si une baguette de pain coûte 1 Satoshi, tu ne peux pas descendre plus bas et donc une demi baguette coûtera autant qu'une baguette complète.

Ah ouais. Remarque c'est vrai, du point de vue des couillons qui ont acheté du BTC à 1000€ pièce quand tout internet relayait le spam adéquat, il est plutôt sortant l'argent.

Je réagissais sur la comparaison entre Bitcoin et un système de Ponzi. « Un système de Ponzi est un montage financier frauduleux qui consiste à rémunérer les investissements des clients essentiellement par les fonds procurés par les nouveaux entrants. »¹ Bitcoin a beaucoup de défauts économiquement parlant. Notamment les early adopters et la limite artificielle de Bitcoin (21 000 000) qui garantie une inflation sur le long terme. Mais ce n'est pas un système de Ponzi car il n'y a pas d'argent entrant. Ce n'est pas comparable à ce qu'a fait Bernard Madoff par exemple.

¹ https://fr.wikipedia.org/wiki/Syst%C3%A8me_de_Ponzi, premier paragraphe.

Je ne pense pas être un expert de l'historique de Bitcoin, mais ce n'est à ma connaissance ni la première fois ni la dernière fois que ça arrive. De mémoire, ça c'était déja produit lors de l'introduction des ASIC avec la pool "asicminer". La pool s'était disloqué progressivement aprés l'annonce, comme celle là risque de le faire.

En quoi cela rend la chose moins grave ? De plus, 50% n'est qu'une barrière théorique, en réalité tout est question de probabilité. Par exemple la pool AntPool possède ~25% de hash rate, ça veux dire qu'elle a 1 chance sur 4 de réussir une modification de la blockchain. Ce qui est déjà beaucoup. Passé un temps, GHash.io avait dépassé les 50%, elle avait franchie le seuil « fatidique ». De l'aveux même de Satoshi Nakamoto, l'attaque des 50% compromet le système dans son entièreté.

Certains y voyait une nécessité pour des transactions rapide, d'autre y voyait une barrière a ne pas franchir car ça augmenterait drastiquement la taille de la blockchain au point de rendre impossible son utilisation sur des configurations modeste. Rien de critique la dedans.

Techniquement cet argument est faux, car les transactions sont organisées sous forme d'arbre, un arbre de Merkel plus exactement. Il suffit « d'élaguer » les branches qui sont trop grosse, voir même juste garder le hash de chaque blocks (c'est simplifié, mais c'est l'idée). Comme l'article le montre il y a beaucoup plus d'arguments technique pour l'augmentation de la taille des blocks que pour ne rien changer.

Ça doit faire maintenant plus d'un an que je ne suis plus le developpement de Bitcoin, et pourtant il y a un an il y avait déjà des discussions qui pullulaient sur le forum officiel sur la taille des blocks et l'interet de l'augmenter ou pas.

C'était le début du débat, et comme tu peux le voir, la situation n'a pas évoluée depuis.

ni la première fois ni la dernière fois que ça arrive

Bref, rien de nouveau sous le soleil.

Donc oui pour moi ça sent le FUD assez fortement.

Je n'arrive pas à te comprendre, est-ce-que pour toi ça sent le FUD juste parcequ'il n'y a rien de nouveau sous le soleil ? Montre en quoi les arguments de Mike Hearn sont fallacieux pour montrer que c'est du FUD.

mais la plupart est pure FUD sur des détails connus depuis longtemps comme les pools de Hong Kong.

Ce ne sont pas des détails, lorsqu'une pool a le pouvoir de modifier la blockchain (attaque des 50%), il y a de quoi s'inquiéter ! Lorsque le développement est trusté par des personnes malhonnêtes, c'est très alarmant. Ce qu'il fait là dans son article est une synthèse de l'état de actuel, ne crois-tu pas ?

Son action a surtout l'air d'une bonne grosse opération de spéculation. Le type revend tous ses bitcoins et prêche l'apocalypse, fait baisser massivement le cours et disparait juste après… Ou miraculeusement le cours remonte, juste après la tempête médiatique.

On parle bien de Mike Hearn, un développeur full time de Bitcoin depuis 2014. En quoi cela remet il en cause le contenu de son article ? Ou sont tes arguments ? Car là c'est bien toi qui spécule, et qui FUD.

Il est très difficile de dire si Bitcoin était avant tout une sorte d'arnaque financière élaborée ou une expérience logicielle, avant de devenir l'autre

Puisque l'unique créateur n'a pas gagné un seul centime en revendant ses Bitcoins¹, ont peut clairement conclure que Bitcoin n'a pas été conçut comme une arnaque financière en premier lieu. Qu'il le soit devenu par la suite est en effet très difficile à analyser.

¹ Et de part son anonymat, il n'a pas probablement pas gagné un seul centime de manière indirecte.

Bitcoin a toujours eu pour but de rentabiliser l'investissement de ceux qui s'y sont mis en premier (ou des nouveaux intermédiaires se jetant dans le bain)

Les early adopters ont été très avantagés, néanmoins je ne pense pas que c'était le but qu'avait Satoshi Nakamoto, car il n'a pas dépensé pas le moindre de ses bitcoins. De plus, éviter que les premiers arrivés soient les plus avantagé n'est pas chose facile. Satoshi était très certainement conscient du problème, mais si ce problème n'a pas été réglé c'est parcequ'il n'a probablement pas trouvé de solution satisfaisante. Bitcoin reste une innovation et une expérience et c'est - je pense - sa principale raison d'être.

en résumé, un système de Ponzi moderne (on y revient quand même toujours à lui quand même, quand on analyse Bitcoin).

Non, rien à voir. Dans Bitcoin, il n'y a pas d'argent entrant. La seul manière d'ajouter de l'argent au système est en le minant (il est créé). Là ou l'on retrouve un pseudo système de Ponzi est lorsque l'on regarde les liens entre les mineurs et le prix du Bitcoin. Les mineurs ont besoins qu'il y ait une demande suffisante pour que leurs dépenses soient couvertes par la vente de leurs Bitcoins fraîchement minés. Et cette demande vient des nouveaux arrivants. Mais la comparaison s'arrête là. Même si tous les mineurs font faillite, les bitcoins déjà présent dans le système ne disparaîtront pas.

Bémol tout de même, malgré les articles alarmant sur Bitcoin, du monde continue d'y croire (le cours a descendu mais de très peu par rapport à ce qu'il devrait être quand plus personne n'y croit)

Il faut relativiser, la part de la population mondiale utilisant le Bitcoin est très très faible. De plus, le prix du Bitcoin dépend d'innombrable facteurs, il faut le regarder sur la durée.

Le minage en pool est un immense problème car ça « centralise » le minage. Et c'est un problème par rapport à l'attaque dite « des 50% » (même si en pratique il suffit de moins pour pouvoir changer la blockchain).

Les ASICs sont aussi un problème, car ils sont beaucoup trop efficace par rapport à un processeur ou une carte graphique. Ainsi les personnes qui veulent gagner de l'argent en minant sont beaucoup plus puissantes que celles qui veulent juste participer au système.

L'ambiance sur /r/bitcoin est ultra malsaine, c'est 90% de postes de marketing pour faire croire que Bitcoin va remplacer le système monétaire actuel. Et ainsi inciter les gens à « investir » dans le Bitcoin. Rien que maintenant le subreddit est spammé de postes non argumentés pour mitiger les effets de cet article.

Le débat sur la taille des blocks est complètement insensé. Comme l'article le montre très bien, augmenter la taille des blocks est la solution logique au problème. Mais puisque les développeurs veulent avant tout gagner de l'argent, ils prennent la solution qui vas dans ce sens (sur le court terme), ignorant tous les arguments techniques. Ils faut voir comme c'est un dialogue de sourd, il y a vraiment une cassure nette entre la communauté et les développeurs. Un peu comme en politique, entre la population et les politiciens.

Il y a aussi le problème des early-adopters, des wallets en ligne qui, encore une fois, centralisent un petit peu plus le Bitcoin… Quand une entreprise annonce qu'elle c'est fait volée tout ses Bitcoin, tu peux jamais être sur qu'ils se soient pas volé eux-même.

Son article est bien détaillé. Je ne sais pas si quelqu'un a un avis contrastant ou concordant ? Plus d'explications ?

Je suis donc totalement d’accord avec lui.

On peut aussi utiliser true pour ignorer une erreur :

mkdir data || true

J'ai découvert récemment qu'il est possible de jouer des vidéos YouTube avec VLC. Essayez la commande suivante par exemple :

vlc https://www.youtube.com/watch?v=yVpbFMhOAwE

Pour ceux qui ont une petite configuration, VLC est généralement plus fluide que Flash et HTML5.

Il existe même une extension pour Firefox qui ouvre VLC lorsque vous cliquez sur un lien youtube :)

Une autre position est de dire que même si dieu il y a, dieu n'intervient pas (ou ne peut intervenir) dans l'univers qu'il a créé lors du Big Bang. La question de l'existence de dieu serait donc sans importance.

Notons que si dieu peut intervenir et modifier l'univers selon sa volonté, alors tout l'effort scientifique pour comprendre l'univers est inutile puisque que les lois peuvent être modifiées à tout moment. Dieu pourrait jouer avec nous et nous rendre fou !

En informatique (et mathématiques), le premier théorème d’incomplètude de Gödel nous dit qu'une théorie (un ensemble finit d'axiomes et de règles de déduction) ne pourra jamais décrire l'ensemble des vérités. Ou dit plus grossièrement, il existera toujours des énoncés vrais que l'on pourra pas démontrer (en mathématiques du moins).

D'ailleurs il me semble que récemment il a été démontré que plus l'énoncé vrai est long, moins il a de chance d'être démontrable. Ou dit autrement, la densité d'énoncés vrai indémontrable tend vers 1 quand la longueur des énoncés tend vers l'infini.

Donc même si les mathématiques semblent échapper au contrôle de dieu, il y aura toujours des choses vraies, mais inexplicables. N'est-ce pas un signe que l'existence de dieu est sans importance ? ;)

Oula, j'ai l'impression que tu te leurres…

En tout cas, de ce que j'ai vu en fac, j'ai rien appris de nouveau et les probas utiles ont les avait déjà fait en terminale S ;)

Cela m'étonnerait vraiment que tu ais appris cela au hasard du web. Vraiment comprendre cela ne vient pas gratuitement, cela demande un effort conséquent

Il existe de très bon livres, auto-didacte ce n'est pas uniquement avec internet.

Alors je ne comprends pas comment tu peux te dire autodidacte. Les plus grands sont juchés sur des épaules de géants. Sur linuxfr, on pense être le géant.

À part la calculabilité j'ai vraiment rien appris en fac. J'ai tout appris sur internet/livre en lisant beaucoup et surtout en pratiquant. Je mentionnais juste le parcours car on me demandais quel cursus j'avais fait.

Reste à voir si dans 1 an ils ne font pas marche arrière…

Les navigateurs sont plus ou moins équivalent sur la performance JS et du moteur de rendu pour la plupart des sites webs. Les extensions qui pouvaient changer le navigateur en profondeur pour ses besoins personnel est un avantage évident qu'avait Firefox sur Chrome et IE, pourquoi l'enlever ? Les raisons évoquées ci-dessus ne me convainc pas…

Si TreeStyleTab n'est plus possible dans les prochaines versions de Firefox, je vais être obligé d'utiliser une ancienne version compatible :(

Je m'auto-réponds pour préciser encore une chose.

J'utilise %d pour obtenir la valeur mais comme le montre Benoît Sibaud plus haut, il faut lire un long unsigned au lieu d'un simple int.

Puisque je renvois -1 pour signaler la non-éxistence d'une clé je dois en fait retourner un long long unsigned. Seulement long long unsigned n'est pas possible en C89 et donc il faut trouver un autre moyen.

Ici j'utilise une structure pour stocker le résultat.

#include <stdlib.h>
#include <stdio.h>
#include <string.h>

struct meminfo_entry {
    char key[32];
    long unsigned value;
};

static int meminfo(char *key, struct meminfo_entry *entry)
{
    FILE *file;

    file = fopen("/proc/meminfo", "r");

    while (fscanf(file, " %31[^:]: %lu%*[^\n]\n",
                  entry->key, &entry->value) == 2) {
        if (!strcmp(entry->key, key))
            return fclose(file), 1;
    }

    return fclose(file), 0;
}

int main(void)
{
    struct meminfo_entry entry;

    if (meminfo("HugePages_Free", &entry))
        printf("meminfo(%s) = %lu\n", entry.key, entry.value);
    if (meminfo("VmallocTotal", &entry))
        printf("meminfo(%s) = %lu\n", entry.key, entry.value);
    if (!meminfo("Invalid_Key", &entry))
        printf("\"Invalid_Key\" doesn't exist\n");

    return EXIT_SUCCESS;
}

Et une dernière pour la route :

fscanf("%*[^\n]\n") ne marche dans le cas ou il reste juste \n, car %*[^\n] vas échouer et donc le \n restant ne sera pas vidé. L'astuce ici consiste à mettre un espace devant le premier spécificateur de conversion: " %31[^:]: %lu%*[^\n]", de cette manière tout les espaces, saut de lignes et autre tabulations sont passé.

On peut cependant laisser le \n restant pour bien montrer ce que l'on souhaite faire : aller à la ligne suivante.

Exemple sans gestion d'erreur en C:

#include <stdlib.h>
#include <stdio.h>
#include <string.h>

static int meminfo(char *key)
{
    FILE *file;
    char _key[32];
    int val;

    file = fopen("/proc/meminfo", "r");

    while (fscanf(file, "%[^:]: %d%*[^\n]\n", _key, &val) == 2)
        if (!strcmp(key, _key))
            return fclose(file), val;

    return fclose(file), -1;
}

int main(void)
{
    printf("meminfo(SwapFree) = %d\n", meminfo("SwapFree"));
    printf("meminfo(Invalid_Key) = %d\n", meminfo("Invalid_Key"));
    return EXIT_SUCCESS;
}

Compile avec gcc -o test -ansi -pedantic -Wall -Werror -O test.c.

Exemple de résultat sur ma machine :

$ ./test 
meminfo(SwapFree) = 265068
meminfo(Invalid_Key) = -1

Voici un peu d'explications concernant le fscanf("%[^:]: %d %*[^\n]\n") :

• "%[^:]:": Lis tant que tu ne trouves pas : et stockes ce que tu lis dans le char* donné en paramètre. Enlève le : restant.
• "%*[^\n]\n" : Lis tant que tu ne trouves pas \n et ignores ce que tu lis. Enlève le \n restant. (En gros « vas à la ligne suivante »)

En C++ tu devrais pouvoir t'en sortir avec << et l'API de stream.h, mais je connais pas très bien comment ça fonctionne ;)

Un décalage de bits est bien plus efficace qu'une multiplication ou une division par une puissance de 2.

Dans ce cas précis, le compilateur optimise et remplace une division par deux ou une multiplication par deux par un décalage de bit.