Sébastien Koechlin a écrit 849 commentaires

Bon, alors calculons la conso de l'affichage de l'heure dans la FreeBox.

C'est un mécanisme à LED, dans lequel il faut faire passer 10 mA en moyenne (dans le cas du multiplexage, on fait passer plus, mais pas tout le temps). C'est du vert, donc la tension de chute est de 2,2 V. Comme il n'y a probablement pas de générateur de courant, on va partir d'une alimentation 3,3 V et considérer que la chute est perdue en chaleur (donc compté dans la consommation).

Disons qu'il y a en moyenne 18 segments allumés, la loi d'Ohms nous dit que P = U x I.

18 x 3,3 x 0.01 = 0,6 W

Si la Freebox reste allumée toute l'année, cela fait une consommation de 0,6 x 24 x 365 = 5256 W.h = 5.2 kW.h

D'après http://particuliers.edf.fr/article493.html le kW.h coute 0.1074, ce qui nous donne 0,56 ¤ par an.

Bon, avec la transformation, les pertes de toute part, on peut arrondir à 1¤. En utilisant un afficheur basse consommation, on peut réduire le coût énergétique de l'afficheur de moitié.

Elle fait combien votre facture électrique par an ?

En fait, ça existe.

Une partie des centrales hydroliques sont équipés de pompes. Lorsqu'on a trop de courant, on peut pomper de l'eau vers la réserve en hauteur; cette eau pourra à nouveau être utilisée pour produire de l'électricité lorsque cela sera nécessaire.

A ma connaissance le premier site équipé ainsi a été le Lac Blanc/Lac Noir en Alsace ( http://fr.wikipedia.org/wiki/Lac_Blanc_%28Vosges%29 http://fr.wikipedia.org/wiki/Lac_Noir_%28Vosges%29 ) en 1928.

Le problème est que le rendement d'une telle opération n'est franchement pas terrible.

C'est a peu près ce qu'il s'est passé le 4 novembre 2006.

L'électricité ne se stoque pas. Il faut en permanence adapter la production à la consommation. C'est une loi physique incontournable. Les tolérances d'écart entre les deux sont faibles.

La page de http://www.rte-france.com/htm/fr/accueil/coupure.jsp donne plus de détails.

Les seules centrales qui sont capables de s'adapter à un brusque changement de la demande sont les centrales hydroliques, en France elles ne représentent que 8% de la production électrique.

Si en moins de 2 minutes, la consommation électrique chute de 12%, EDF n'est pas capable de modifier sa production, des centrales nucléaires vont se mettre en sécurité, rejetant probablement plein de vapeur d'eau dans la nature pour évacuer la chaleur. Il va y avoir des coupures de courant un peu partout pour tenter d'adapter au plus vite production et consommation.

Le rétablissement de la production doit se faire sous controle, prends des heures; entrainant le déplacement de nombreuses personnes (pétrole), des coupures d'électricité entrainant des coûts importants dans l'industrie (matière gachée), du matériel électronique poluant à fabriquer claque à chaque coupure..

Le bilan écologique est probablement très négatif; l'impact de la coupure sur la population est loin d'être positif, le bilan économique pour les entreprises est largement négatif.

La seule prise de conscience qu'il risque d'y avoir de la part de la population, c'est que notre confort est finalement très lié à la disponibilité électrique et qu'il faudrait peut être augmenter notre capacité de production.

Tout couper pendant 5 minutes, c'est pas 5 minutes de répit pour la planête, c'est le meilleur moyen de faire exploser tout le réseau électrique.

Tous les mécanismes qui nécessitent de se passer la session sur un serveur centralisé ont plusieurs problèmes

Le premier est la performance. Si on veut enregistrer les données sur disque à chaque requête, il va sans dire qu'il faut mettre le minimum de données en session, c'est pourtant rarement l'objectif des développeurs lorsqu'ils écrivent une application, ils utilisent plutot la session comme cache des données utilisateur.

Lorsque les données sont en plus enregistré dans une base de donnée, particulièrement MySQL qui verrouille souvent au niveau de la table. L'enregistrement de plusieurs Ko de données est catastrophique.

Le partage NFS est aussi souvent utilisé; mais le verrouillage des fichiers n'est alors généralement pas géré.

Le second problème est la redondance. Si le serveur de session tombe, parce qu'il est trop chargé, ou parce qu'il y a un problème matériel sur la machine; le service est complètement coupé. On souhaite souvent avoir un mécanisme de secours, même si les sessions sont perdues, les gens doivent pouvoir en ouvrir une nouvelle. Les mécanismes à serveur unique fonctionnent mal dans ce cas. Les serveurs SQL peuvent être souvent installés en clusters, mais dans ce cas, le temps de traitement des requêtes est également augmenté; ce qui augmente les risques d'écroulement sous la charge.

La technique que j'utilise est le proxy avec affinité de session. Cela permet de distribuer en amont, avec un logiciel ou un équipement dédié, le routage de toutes les requêtes d'un même client vers le même serveur. Ainsi la session peu rester locale à l'application.

Un logiciel qui permet de faire cela est Pound http://www.apsis.ch/pound

Mais tu te crois vraiment plus fort qu'une équipe de développeurs, qui passent leurs temps à relire le code, le corriger, sortir des patchs, passer des tests ?

Ce n'est absolument pas les propos de l'auteur. La lecture des commentaires montre d'ailleurs qu'il est tombé dans un piège plutot simple. Ton commentaire à l'emporte pièce peut aussi énerver.

Ce que dit l'auteur, c'est simplement qu'il n'a pas installé de CMS pour des raisons de sécurité; pas qu'il est capable de faire mieux.

Lorsqu'on développe son propre code, on sait précisement comment il fonctionne, et lorsqu'il y a un trou, on est capable de le corriger.
Lorsqu'on installe un CMS, on se contente d'espérer que les correctifs de sécurité ne trainent pas trop après la découverte d'une faille.

J'ai utilisé et j'utilise plusieurs logiciels tout fait en PHP, et je n'ai pas encore trouvé le CMS sérieux dont tu parles. A chaque fois que je me plonge dans l'un d'eux, et que je regarde la liste des alertes de sécurité, je suis comme l'auteur de ce journal, encouragé à écrire moi même le plus possible de ce qui m'est nécessaire. Non pas parce ce que je pense qu'il y aura moins de trous de sécurité, mais parce que je serai capable de les corriger.

En prime, conscient du problème de sécurité, je m'astreints à respecter tout un tas de règles de codages et de paramétrage de PHP afin d'essayer de produire du code plus fiable, règle qui sont rarement utilisés dans les logiciels disponibles sur le net.

Ca dépends, normalement les cas anormaux sont éliminés par un lancer de trolld'exception.

Pour le reste, oui, ça oblige a faire quelque chose comme

fonction f(...) {
	entier resultat
	si( situation1 ) {
		resultat = 1
	} sinon si( situation2 ) {
		resultat = calcul compliqué
	}
	retourne resultat
}

Dans plusieurs cas, on trouve des solutions plus claires; mais le but est surtout d'éviter du code effroyable avec des sorties de boucle, des variables pas trop bien initialisées...

Plusieurs des règles que l'on peut imposer résultent d'un compromis. Comme tu l'as visiblement bien compris en rédigeant ce journal, on a besoin de bonnes pratiques, et lorsqu'on est une entreprise, on essaye de les imposer aux fournisseurs. Les bonnes pratiques sont rarement universelles; mais dans l'ensemble, on essaye de les choisir afin d'avoir le code le moins buggé et le plus maintenable possible.

En général, le jeune développeur qui débarque est complètement focalisé sur les performances; ensuite il y a un long travail pour lui faire comprendre que ce que l'on veut, c'est un code clair, simple et non buggé. S'il faut mettre un second serveur à coté à cause des performances, ça coûte toujours moins cher que coller trois hommes.mois pour résoudre les problèmes.

Oui, en faite, cette recommandation n'est pas à sa place pour deux raisons:

- L'idée derrière est qu'il faut imposer un certain nombre de règles de codage, cela ne se limite pas à l'indentation.

- La règle est discutable. D'après Linus par exemple, le code doit être indenté avec des tabulations, si vous ne pouvez pas voir correctement votre code dans un éditeur tout bête (ceux qui place les tabulations tous les 8 caractères), c'est que votre code est mal fichu et que vous ne maitrisez pas le découpage fonctionnel du code.

Au boulot, les normes de développement impose la tabulation; ainsi que pratiquement une centaines d'autres règles de bonne conduite (pas de catch d'exception vide, un seul return par fonction, pas de membre d'objet qui soit publique...)

Il n'y a pas de soucis avec le PCI, c'est une étape qui est en fait obligatoire.

Le bus AGP est en perte de vitesse, il va bientôt avoir disparu. En plus, si je me souviens bien, c'est en fait un bus PCI avec quelques améliorations ce qui fait que l'adaptation de l'interface n'est probablement pas très compliquée. Le plus gros avantage de l'AGP est qu'il permet d'adresser la RAM de l'ordinateur en passant par le MMU pour aller chercher des textures, une chose qui tue les performances et dont il vaut mieux se passer.

Le bus PCI Express est le bus que l'on trouve maintenant sur toute les cartes mères, et lui, est terriblement proche PCI. Le connecteur est différent; les données sont transmises en série par les couches basses; mais par contre, tout le fonctionnement de l'interface est exactement le même que le PCI. Il existe des circuits "ponts" qui sont vendu pour permettre la connexion rapide d'une puce PCI à un bus PCIe; si on a plus de temps, il suffit de modifier la partie interface de la puce, toute la logique peut être conservée.

L'ISA a été abandonné, et c'est tant mieux. Cet ancien bus est un cauchemar qui ne permet d'adresser qu'un unique méga-octet de mémoire, toutes les cartes doivent être configurées manuellement à l'aide de jumpers ou de programmes spécifiques pour ne pas se marcher dans les ports. Bref, on ne va pas loin.

La norme PCI est bien plus universelle et pratique. D'une part il y a un protocole qui permet aux cartes de se présenter et de réserver des ressources; ce qui fait que l'on se pose très peu de questions lorsqu'on branche une carte, le BIOS ou son équivalent se charge de faire une distribution dynamique des ressources nécessaires. D'autre part, les connecteurs sont bien plus dense et évitent d'avoir des cartes de 2 km de long comme c'était le cas avec le VLB.

En prime le PCI n'est pas limité au 8086 et ses descendants compatibles, cela permet d'utiliser les cartes sur les machines ayant une architecture différente.

Ca serait bien, lorsqu'on parle d'un bouquin, de donner son identifiant, à savoir, le numéro ISBN. C'est la clef qui est utilisé par tout le monde pour identifier un livre.

Je ne vois vraiment pas l'intérêt de re-héberger des choses comme l'iso ubuntu-6.10-desktop-i386.iso alors qu'il existe déjà un flux officiel fourni par Ubuntu sur lequel il y a bien évidement plus de monde ( http://releases.ubuntu.com/6.10/ )

Ceci est un exemple, je n'ai pas fais tout le tour de tous les fichiers fournis; mais diviser les trackers bittorrent est vraiment VRAIMENT une mauvaise idée.

Pourtant la cohabitation 32 - 64 bits ne pose en général aucun problème (en tout cas pas que j'ai rencontré).

C'est bien, je suis content pour toi.

La cohabitation pose des problèmes, j'ai même listé les principaux.

Comme les machines 64 bits sont maintenant devenues très courantes et que toutes les distributions sont obligées de tourner dessus, les développeurs et les packageurs ont fait ce qu'il fallait pour que cela se fasse sans douleur pour les utilisateurs.

Donc je répète: La solution du chroot était la solution qui me permettait de faire cohabiter les applications un peu lourdes à déployer au moment où j'ai installé la machine.

C'est généralement ce que l'on fait en environnement 64 bits; mais cela pose parfois des problèmes, en particulier avec les applications qui chargent des modules dynamiques.

Lorsque j'ai installé la machine, OpenOffice.org 2.0 ne tournait pas en environnement 64bits, c'était également le cas pour Firefox avec le plugin flash et le JDK.

Les erreurs classiques sont les grosses applis qui chargent des modules dynamiquement; les modules vont charger eux mêmes des bibliothèques... et parfois quelque part un nom de fichier est un peu trop codé en dur, et on se retrouvait avec des bouts de code en 64 bits.

Un autre problème est qu'il faut avoir toutes les bibliothèques 32 bits nécessaires, images, vidéo, son... une application comme OOo contient énormément de dépendances; et toutes ces dépendances ne sont pas forcément packagées ou conçues pour être déployées en environnement 64 bits, en cohabitation avec les version 64 bits.

Enfin il faut avoir un packet pour sa distribution ou alors se lancer dans la recompilation.

Pour l'instant j'ai installé ces trois logiciels en chroot. Quand j'aurai un OOo 64 bits, j'irai sur place pour l'installer et le tester; en attendant je ne peux pas me permettre de bloquer la dizaine d'utilisateurs qui l'utilisent tous les jours pour une durée indéterminée si je casse quelque chose, chose dont je risque de ne pas me rendre compte à distance.

C'est intéressant, parce que actuellement, j'ai une vingtaine d'utilisateurs qui font tourner OOo 2.0 dans une sous-machine i386, ce qui oblige à faire un chroot.

Par contre, je ne trouve pas de référence à cette version 64 bits, le site me renvoit vers http://wiki.services.openoffice.org/wiki/Porting_to_x86-64_%(...)
qui explique au début de la page qu'on en est encore à essayer de tout compiler:

"The x86-64 port is work in progress. It is not ready for use yet, but it compiles (with quite large set of patches), and performs basic operations. It is of no use for non-developers."

Dans le second lien Yahoo que tu donnes, on peut lire

"Je préférerais que l'on s'intéresse à l'apprentissage de bons réflexes et des effets néfastes d'une consommation excessive de vin sur la santé", a commenté le ministre de la Santé dans son discours de clôture.

Dans le second lien Yahoo que tu donnes, on peut lire

"Je préférerais que l'on s'intéresse à l'apprentissage de bons réflexes et des effets néfastes d'une consommation excessive de vin sur la santé", a commenté le ministre de la Santé dans son discours de clôture.

Ca tombe bien, y'a un site fait exprès pour les films qui sont tombés dans le domaine public et qui sont diffusés par bittorrent:

http://www.publicdomaintorrents.com/

Beaucoup de films ne sont pratiquement pas diffusés, si tu as un peu de place sur le disque, ça aidera pas mal.

Sinon, pour pas saisir les torrent un a un, j'utilise rTorrent qui scrute un repertoire et telecharge tous les torrents qui s'y trouvent.

C'est aussi le mode de fonctionnement du client historique bittornado.

btlaunchmany et btlaunchmanycurses scrutent un répertoire.

Si la machine dispose de suffisement de RAM et ne fait pas trop de choses par ailleurs, le cache disque de Linux fera exactement la même chose sans qu'il soit nécessaire de manipuler quoi que ce soit.

Un critère très important est la focale. Regarde à quelle distance tu peux installer ton projecteur du mur ou de l'écran.

Si tu n'as pas beaucoup de recul, un appareil mal adapté va te donner une toute petite image.

Ensuite si c'est destiné à être déplacé souvent, la facilité d'utilisation peut aussi entrer en compte. Quoi de plus pénible que de passer à chaque fois 15 minutes à chercher dans tous les sens pourquoi est-ce qu'il n'y a pas d'image.

J'ai acheté il y a un moment un NEC VT-47 ( http://www.nec-pj.com/products/vt/index47.html ) et je suis franchement très content. Il ne fait pas trop de bruit; il me donne une image qui prends tout le mur avec le recul dont je dispose, il corrige automatiquement la déformation trapézoïdale en fonction de l'inclinaison du projecteur, et il a un bouton correspondant à chacune des entrées pour ne pas passer 15 minutes à configurer.

La résolution n'est pas terrible, mais c'est un ancien modèle, et pour un film, ce n'est pas très génant.

S'il est prévu de pouvoir le désactiver, il ne doit pas être possible de contourner cela simplement de manière logiciel.

Il faut probablement désassembler le BIOS et écraser le code qui désactive le VT. Il doit y avoir une séquence caractéristique d'une dizaine d'octets qui permet de retrouver l'endroit où cela est fait.

Flasher ensuite le BIOS avec une version modifiée n'est peut-être pas trivial non plus.

Comme beaucoup de monde, je n'ai plus de montre, finalement ça ne sert à rien sinon à se stresser.

Bon, j'ai fais une légère approximation.

Les normes actuelles d'Unicode et par conséquent d'UTF-8, UTF-16 et UTF-32 ne définissent pas de code supérieur à U+10FFFF. Mais l'algo qui permet de représenter des caractères de valeur supérieur à U+007F utilisé en UTF-8 peut être étendu pour aller jusqu'à U+7FFFFFFF sans soucis (la limitation est artificielle), ce qui fait 2^31.

Absolument pas.

UTF-8 et UTF-32 sont tous les deux capables de contenir les mêmes caractères, à savoir environ les 2^32 premiers de la table unicode.

La seule différence entre UTF-8 et UTF-32, c'est que les caractères des pages basses consomment moins d'octets en UTF-8.