Sébastien Koechlin a écrit 854 commentaires

Pour un CPU le supportant et un kernel remontant l'information, powertop peut te montrer le temps passé à chaque fréquence (P-states).

Les outils standards linux n’affichent pas le mode turbo, ça reste calé à la fréquence maximum "normale"

Chez moi, /proc/cpuinfo varie en fonction de la fréquence actuelle du processeur.

Si le journal n'est pas récupérable dans le cas d'un fsck, alors ce dernier peut le supprimer, et la partition est alors montée par le driver ext2.

A quel endroit vois-tu que la partition est ext2 ?

Je doute que systemd soit écrit comme un goret, ta vision de l'usage des assertions est loin d'être universelle, et beaucoup de monde considère que la présence d'assertions est justement la marque d'un logiciel réfléchis. Tout le fonctionnement d'ADA beaucoup utilisé dans les systèmes critiques est justement basé sur des assertions.

Dans le cas du logiciel en général, et tout particulièrement dans le cas d'init, on souhaite premièrement avoir un logiciel sans bug. C'est cette qualité entre autre qui fait le succès du kernel Linux (dans lequel il y a des assertions). Et la chasse aux bugs se fait bien plus facilement en remontant les anomalies au plus tôt et en validant les données par des contraintes plutôt que de les utiliser naïvement en espérant que ça passera. Une anomalie non traitée va très certainement provoquer d'autres problèmes un peu plus loin, qui vont être plus compliqués à diagnostiquer et à traiter.

La tolérance aux bugs est un autre point qui concerne tout particulièrement init comme tu l'indiques. Comme il est a mon avis impossible de traiter tous les cas tordus qui risquent de se produire, et qui ne sont pas forcément liés à des bugs de l'exécutable, il serait préférable d'avoir un mécanisme capable de reprendre en cas d'erreur, par exemple en re-lançant le programme a son point de départ ou à un point connu. Ces mécanismes sont déjà utilisés dans un certain nombre de logiciels tel que bind, apache, syslog-ng... Ils ne corrigent pas magiquement tous les bugs et les erreurs, mais permettent juste d'assurer la continuité de service.

Tu peux retourner du SVG plutôt que du HTML, s'il s'agit de ne changer que la couleur de diodes, c'est plutôt simple à faire.

De ma propre expérience c'est tout à fait vrai, des ralentissements (ressenti utilisateur) dès qu'on dépasse les 150%, et vu des pics à plus de 600% sans pour autant planter la machine.

Une charge importante, même bien au dessus de 6, ne plante pas une machine. Ce qui provoque un plantage, c'est généralement d'atteindre des limites comme la mémoire virtuelle disponible ou le nombre de processus; cas souvent mal gérés; et encore, ces cas ne plantent pas souvent la machine qui se contente de faire du ménage.

Il y a quand même deux points importants à noter:

1. Une charge importante a de gros impacts sur le temps de réponse; pour un serveur qui est censé répondre dans un délais raisonnable aux requêtes reçues, ou pour un bureau de travail, ça peut tout à fait devenir inacceptable. La machine n'est pas plantée pour autant.

2. Une charge importante peut être révélatrice d'une consommation de ressources en croissance qui va aboutir à un plantage de la machine. Par exemple sur une consommation excessive de mémoire, si la machine a beaucoup de swap, elle va passer par une phase de swap intensif qui va dégrader les performances, parfois pendant un moment.

Ceci étant du aux, système de file d'attente, de nice etc... ce qui est évident, mais ce principe est t il valable sur toutes les architectures ou seulement sur x86 ?? Est ce aussi le cas sur sparc, alpha, arm, rs6000, etc ??

Le comportement est il identique avec des machines multi-processeurs (physiques) pas simplement des cœurs dans un processeur unique ??

Si tu es sur GNU/Linux, on considérer que le calcul du loadavg est le même, donc homogène. Tu as quand même le problème du nombre de cœur, un loadavg de 1.2 sur une machine bi-core n'indique pas de problème (1.2 processus a exécuter, 2 cœurs disponibles), sur un monoprocesseur c'est peut-être un problème. L'hyperthreading vient compliquer l'interprétation des valeurs.

Si tu as un parc d'OS hétérogène, alors la comparaison n'est pas réellement possible. Certains OS comptent ou ne compte pas les taches dans différents états, bloqués sur certaines ressources... Certains vont distinguer les threads et les processus, d'autres pas. Certains vont aussi normaliser la valeur par rapport au nombre de processeur, afin qu'une valeur de 1 indique toujours une occupation complète de tous les CPU, quelque soit le nombre de CPU. Bref, c'est la foire.

Il y a un article intéressant à propos d'OpenID sur http://lwn.net/Articles/425946/

Personnellement, la possibilité de se connecter via Facebook ne me gène pas trop tant qu'il y a des alternatives.

Ce que je n'aimerais pas, c'est que mon mur ou mes "amis", ou une quelconque application FB se trouve gratifiés d'informations comme "Machin sera à Lyon du 24 au 35 mai", (qui se terminerait au tribunal au premier cambriolage); ou encore que mon compte Facebook soit utilisé alors que j'ai exprès choisi une autre méthode d'authentification.

Tu définis deux virtualHost différents; ce qui te permet d'héberger deux sites différents.

En général, il y a un ou deux trucs à modifier dans la configuration pour différencier les sites (configuration de la base de donnée, racine des répertoire, url canonique...)

C'est un peu le problème de Xen, on est obligé d'utiliser un noyau antique, et vu que le dernier kernel 2.6.37 commence tout juste à intégrer le support du Dom0; il va falloir attendre un bon moment pour que la nouvelle génération arrive dans nos distributions.

L'avantage d'un système comme LVM est justement d'éviter d'avoir à copier 20 ou 30 Go de données d'un fichier ou d'une partition.

Effectivement, on peut installer directement le système de fichier sur le disque virtuel, sans partitionnement. J'en ai parlé dans mon texte. Par contre les systèmes d'installation des distributions ne le proposent pas vraiment, ça devient acrobatique.

Effectivement, en toute logique la requête est re-préparée à chaque exécution, ce qui fait perdre le gain à ne compiler qu'une seule fois la requête.

En pratique au moins deux des deux SGBD les plus populaires compensent les erreurs des développeurs et les manques d'un certain langage de web dynamique de 3 lettres commençant par P en gérant un cache des dernières requêtes exécutés, ce qui évite d'avoir à recompiler la requête à chaque fois.

tmpfs utilise la mémoire, si celle-ci vient à manquer, alors les données vont être écrites sur le swap, en commençant par les zones utilisées le moins récemment. Les vieux fichiers qui trainent depuis un moment dans /tmp ont donc toutes les chances d'être éligibles.

On lit un peu tout et n'importe quoi sur la meilleur façon d'optimiser la durée de vie des batteries. Sur l'effet mémoire ou sur d'autres effets qui existent ou qui n'existent plus selon la technologie...

Je suis bien incapable de te dire s'il vaut mieux la laisser dans ou hors du portable, déchargé, un peu chargé, très chargé. Les études sérieuses sont rares.

Je fais quand même deux remarques:

1- La chaleur entraîne souvent des dégradations au niveau chimique; il vaut mieux l'éviter à mon avis avec une batterie qui fonctionne par des réactions chimiques. Mon portable (Panasonic Toughbook vendu pour 10h30 d'autonomie) vient avec un bouton "ECO" qui permet de limiter la charge maximale de la batterie à 80%; ce qui permet de limiter la chaleur. J'ignore si ce bouton prolonge réellement la durée de vie ou si c'est un effet marketing.

2- Une batterie est toujours composée de plusieurs éléments (ou cellules) parce que les réactions d'oxydo-réduction utilisés pour produire des électrons ne permettent pas de dépasser 2 ou 3 volts ( http://sbeccompany.fr/sciences/chimie/documents/Table_potent(...) ) on est obligé d'en utiliser plusieurs en série pour atteindre le voltage des batteries actuelles.
La charge d'une cellule est une science bien maitrisée, on sait évaluer la fin de la charge au courant qu'elle accepte et à sa température. Si la charge est trop importante, on dégage beaucoup de chaleur, et on abime l'élément.
Or les fabricants de batterie et ceux d'ordinateurs (ou GSM, Téléphone, APN...) ne se posent pas trop de question: dans toutes les batteries que j'ai vu, ils collent les éléments en série et la charge se fait de façon globale sur l'ensemble. Lorsque la batterie est neuve, ça fonctionne très bien; mais le vieillissement est accéléré par cette construction. Les éléments qui s'abiment le plus vite se chargent moins, ce sont les premiers à chauffer, ce qui accélère la dégradation.
Charger les éléments indépendamment les uns des autres demanderait d'embarquer beaucoup d'électronique dans la batterie, augmenterait le prix global de l'appareil ainsi que sa durée de vie; ce qui n'est absolument pas l'objectif des fabricants. Dans l'état actuel les batteries perdent la moitié de leur capacité en un an ou deux, temps au bout du quel le matériel est prévu pour être renouvelé.

La commande magique est de regarder si STDIN est un terminal, normalement elle ne renvoie vrai que si tu es dans un terminal:

$ tty
/dev/pts/4
$ echo $?
0

$ tty < /dev/null
not a tty
$ echo $?
1


Heu, a mon avis ça ne se passe pas au même niveau.

Dans le cas que tu cites, il s'agit pour Xorg de changer de carte graphique, or la question est pour une application de changer de serveur X.

X supporte déjà l'utilisation de plusieurs cartes graphiques, il lui manque probablement la possibilité d'ajouter et de supprimer des cartes graphiques à chaud. Dans ton cas, a aucun moment, les applications ne doivent changer de serveur X, on reste sur la même machine, connecté au même processus X; c'est la couche basse qui change.

Il faut que tu lances tes applications dans un serveur VNC, tu pourras alors ensuite te connecter dessus depuis n'importe où.

A ma connaissance, les applications ne peuvent pas migrer d'un serveur X à un autre.

UDP ne garantissant pas l'ordre de réception des paquets, je n'essayerais même pas.

Pour avoir des collisions, il faut partager le média entre plusieurs interfaces; pour cela il faut avoir un hub et non pas un switch, ce qui est quand même très rare de nos jours, surtout en 100Mbps.

Non, la taille de la FAT (table d'allocation des fichiers) ne dépends pas du nombre de fichiers, elle est fixée par la taille du média. Chaque secteur du média est représenté par un certain nombre de bits.

Au bout d'un moment, on en a mis deux, mais elles ont toujours une taille fixe.

Ce qui varie avec le nombre de fichier, c'est la taille occupée par les répertoires, mais a ma connaissance c'est le cas avec tous les systèmes de fichiers.

Les secteurs de réserve utilisés pour remapper les secteurs défectueux ne sont pas numérotés ni adressables, ils ne sont donc pas comptés.

"<pubDate>Mon, 18 Aug 2008 00:00:00 -0700</pubDate>"; un peu à la ramasse ce site.

Est-ce que la machine supporte le boot via réseau (PXE) ?
Ça pourrait faire des terminaux pour un serveur LTSP.

Oui, en fait ça regroupe deux points, c'est vrai que je n'ai pas détaillé:

1. Si on publie des enregistrements SPF et qu'on envoie via le serveur du FAI, on va avoir des soucis si ceux ci ne sont pas listés. Et généralement le FAI n'indique pas quels vont être les IP sortantes. Le fait que certains FAI utilisent des IP tournantes pour contourner les RBL n'arrange rien.

Ce qui amène au second point:

2. Parfois le FAI publie un enregistrement SPF que l'on peut alors inclure dans le notre (directive include:).

N'importe quoi.

Quel est l'intérêt d'insulter et de dénigrer les gens en prenant un ton condescendant ?

Ce n'est pas n'importe quoi. Tu expliques toi même quels sont les limites de cette solution.