Olivier Jeannet a écrit 1400 commentaires

Je ne connais pas assez Apache et MySQL pour en être sûr, mais pour préserver ta mémoire Flash, tu dois pouvoir limiter les logs que font ces programmes (Apache en particulier, encore qu'il ne logue que s'il y a accès, donc si Apache est peu sollicité, c'est pas un pb). MySQL écrit forcément dès que tu fais des requêtes Insert/Update/Delete, par contre je ne sais pas ce qu'il logue. Ça doit être facile à voir en essayant.

Sinon avec 512 M de RAM tu peux monter un disque tmpfs et mettre les logs dedans, ça peut servir (et copier les logs sur disque dur avant extinction/reboot, si c'est utile de les garder).

J'ai quasiment le même matériel que toi, une carte mère Via Epia M9000 qui contient un processeur C3 (core Ezra) à 933 MHz ; j'ai par contre un disque dur de portable. Je m'en sers comme magnétoscope numérique, avec une carte d'acquisition. J'en parle un peu sur cette page : http://oje.rio-verde.net/epia_linux_pvr/ .

Je pense que plus d'une distribution peut convenir. Recherche du côté des distributions compactes pour clé USB. J'avais même trouvé une image qui tenait sur un petit disque SSD de 64 Mo (c'était compressé). Pour la durée de vie du disque Flash, il suffit de vérifier qu'aucun programme n'écrit en permanence sur le disque. Même si syslog écrit toutes les heures, ce n'est rien, le nombre d'écritures supporté par les cartes Flash modernes est très important, et en général il y a wear-leveling (répartition des écritures, transparente, pour éviter d'utiliser toujours les mêmes endroits).

Je confirme ce que tu écris. J'ai participé au développement d'applications de télédéclaration pour le ministère de l'Agriculture, dans une grosse SSII, et on utilise Mantis. Je l'ai trouvé pratique (couleurs pour les gravités et les états) et facile à prendre en main. Une équipe entièrement dédiée à la validation fournissait les bugs, et l'équipe de développement recevait des courriels et "n'avait plus qu'à" épurer sa page de bugs, à la suite de quoi l'équipe de validation recevait un message et pouvait retester. On avait parfois droit à quelques aller-retours avec les remarques de plusieurs intervenants et divers attachements.

Il y avait un léger couplage avec le CVS, car dans la raison de chaque commit on incluait le numéro du bug Mantis. Pratique pour la tracabilité et ça évitait quelques doublons ou régressions.

NB : pas « encodage UTF-8 » mais « codage UTF-8 », merci.

mais ensuite ? Qui dit que quand tout est centralisé le vote n'est pas truqué dans une certaine marge

On peut consulter les votes non seulement dans le journal, mais aussi sur le site du ministère de l'intérieur (par exemple pour la commune de Montrouge à la présidentielle de 2007 : http://www.interieur.gouv.fr/sections/a_votre_service/result(...) ). Il me paraît difficile de truquer les résultats entre le dépouillement (avec plusieurs traces papier, sans compter les souvenirs des participants) et la parution des chiffres au ministère de l'intérieur, ça se verrait vite.

On peut donner le résultat exact dès 20h à la télé (seul but du vote électronique à mon avis, syndrome "star'ac")

Je ne crois pas que ce soit le seul but. Pour avoir participé déjà 2 fois à un dépouillement, j'ai pu voir que ça demandait une organisation précise, et que souvent ils manquent de volontaires pour s'en occuper (on me demande à chaque fois, quand je vais voter). Ça mobilise plusieurs employés de mairie et élus locaux, et ça prend pas mal de temps (les gens étaient libérés vers 22h si ma mémoire est bonne).

Cela dit, je trouve cela très bien organisé, et un beau système : le vote est secret, et le dépouillement public. Le dépouillement est effectué 2 fois, chaque lot de bulletins étant traité par 2 groupes différents, et chaque personne est doublée (celle qui lit le bulletin à voix haute, et celle qui coche sur la feuille de décompte en confirmant). Je vous encourage à le faire au moins une fois, chacun doit contribuer au fonctionnement de la démocratie.

J'ai parfois des problèmes avec mon clavier (qui n'a pas changé depuis des années), il se met à émettre une touche en continu, et je n'arrive pas toujours à l'arrêter (parfois en appuyant sur d'autres touches, voire sur CTRL-C, dans un terminal). Avant de faire ça, les 3 voyants du clavier clignotent, généralement (Caps Lock, Num Lock, Scroll Lock). La solution qui marche le mieux est de déconnecter le clavier et de le reconnecter.

Dans les logs noyau (/var/logs/messages) je retrouve ce genre de ligne (il s'agit d'un clavier PS/2) :
kernel: input: AT Translated Set 2 keyboard on isa0060/serio0
Le phénomène me paraît entièrement aléatoire, je n'ai pas encore réussi à identifier une raison particulière.

Et au sujet de la différence, un delta couvre toutes les x précédentes versions ? ou existe-t-il x delta suivant la version installée ?

Il me paraîtrait assez fastidieux d'avoir des deltas entre chaque version, et ça compliquerait aussi la mise à jour. Un delta couvre à mon avis la différence entre le paquet de départ (à la sortie de la distrib) et le paquet actuel. Pour avoir utilisé des SuSE, quelque soit la durée entre 2 mises à jours, YAST n'a toujours téléchargé qu'un seul delta, avec un nom simple.

Dans ce cas il n'y a jamais de technologie en logiciel ?
Tu ne trouves pas ça une peu abéerrant ?

Il n'y a pas souvent de changement de technologie, en effet.
Je pense que le passage des langages procéduraux à des langages objets peut s'assimiler à une nouvelle technologie, mais ce n'est sûrement pas le cas d'un changement d'algorithme. Quoique j'aurais tendance à parler de "nouveaux principes de développement" et de "nouveaux langages" plutôt que de technologies.

Pour la virtualisation, c'est une technique de plus pour pratiquer l'abstraction vis-à-vis du matériel (je simplifie).

Le passage des tubes à vide aux transistors est un changement technique majeur, les outils utilisés sont complètement différents, les matériaux sont différents ; il s'agit bien d'une nouvelle technologie.

(NB: tu ne peux pas mettre d'accent sur un "e" avant une consonne doublée, car l'effet de ces consonnes est de le transformer du point de vue prononciation en "è")

PulseAudio est bien une nouvelle technologie de serveur de son

Eh bien non ; tu es sans doute déjà trop habitué à l'emploi américain du terme, car ta phrase n'est pas exacte. PulseAudio s'y prend différemment (avec des algorithmes différents) qu'un autre serveur de son, même si c'est astucieux, il ne s'agit pas d'une "technologie".
Celui qui a inventé le QuickSort n'a pas dit "mon programme utilise une nouvelle technologie", même si ce nouvel algorithme est très astucieux et efficace.

Une nouvelle technologie a par exemple été le passage des tubes à vide aux transistors, ou des transistors aux circuits gravés (la technologie actuelle).

Simple remarque de langage, dans la dépêche on a utilisé "technologie" à la place de "technique". Les américains adorent utiliser ce mot et l'emploient partout, allant presque jusqu'à dire "Bubble Sort Technology" :-)
Je ne détaille pas, c'est mentionné aussi sur http://fr.wikipedia.org/wiki/Technique , et on peut lire sur la page "Technologie" : « La technologie désigne en premier lieu l'étude, ou encore la science des techniques. »

Ça me paraît bizarre ton adresse "192.168.1.0" en premier dans ton /etc/resolv.conf, vu qu'il ne s'agit d'aucune adresse réelle (pas d'équipement qui y correspond).
Et surtout, soit tu mets l'adresse des DNS de ton FAI (ici tu as mis 2 fois la même, ce qui ne sert à rien), soit tu mets l'adresse de ton modem-routeur (s'il fait relais DNS). Comme je te le disais, normalement tu n'as rien à faire, le client DHCP de ton Linux va s'occuper de le faire (cela fait plusieurs distributions que je n'ai rien à faire côté Linux, juste à dire de se connecter via DHCP).

Pour revenir à ce que tu disais dans ta question initiale, si tu choisis d'utiliser une IP fixe, il faut alors que tu précises une adresse de serveur DNS dans /etc/resolv.conf (que ce soit l'adresse du modem-routeur s'il fait relais DHCP, ou l'adresse du DNS de ton FAI), vu que le client DHCP ne sera pas là pour s'en occuper.

Je me connecte sur mon serveur SSH ou SFTP (qui est chez moi) depuis le boulot, et je n'ai aucun délai. Ah oui, tu devrais pouvoir désactiver la résolution de nom de ton serveur FTP ou SSH (pour ma part je le laisse activé), auquel cas peu importe qu'un DNS soit spécifié ou accessible.

Parlons français (mon dada), cf http://linuxfr.org/comments/137074.html#137074

Sinon on peut parler de conversion (et convertir), c'est simple et aussi bien.

Si tu as configuré ton routeur/modem ADSL comme serveur ou relais DNS (je crois que c'était pas défaut chez moi), il suffit d'avoir la ligne nameserver 192.168.1.1 dans ton /etc/resolv.conf (c'est le cas chez moi, mais je n'ai jamais édité à la main ce fichier, c'est le client DHCP qui s'en est occupé).

J'ai aussi configuré le serveur DHCP de mon modem/routeur pour qu'il m'attribue toujours la même IP, en restreignant la plage à une seule adresse (192.168.1.2 tout simplement).

C'est marrant mais c'est un faux connu.

il y a un peu plus rapide pour la partie getty : une fois que tu as collé ton URL dans le fichier "Links" (dans la Konsole) , dans le getty, tu tapes wget $(cat Links).

J'ai eu le même problème que toi. C'est complètement nul que l'option "-after-date" (synonyme de "--newer") ne prenne pas la date de modification !

Je ne sais plus comment j'ai trouvé (mon man ne le mentionne pas), il faut utiliser l'option --newer-mtime.

Je fais comme ça pour gérér des sauvegardes différentielles (tu parles d'incrémentales mais tu te trompes je pense, en tous cas si on en croit Wikipedia http://fr.wikipedia.org/wiki/Sauvegarde#Sauvegarde_diff.C3.A(...) ) :

La sauvegarde totale :
LC_ALL=C date -R >perso/.lastbackup.date
tar cfj $MYBACKUP perso

La sauvegarde différentielle :
LC_ALL=C tar --newer-mtime "`cat perso/.lastbackup.date`" -cjf $MYBACKUP perso

Noter l'utilisation de LC_ALL=C pour gérer les dates sans ambiguïté (on peut aussi choisir de mettre la date au format ISO, je pense, à la place).

C'est bizarre ton histoire. Sur ma "vieille" Mandrake 10.2 (noyau 2.6.11-6mdk) qui date de mars 2005, lspci me retourne 00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74), et je n'ai eu aucun problème.

Je vais appuyer ce qui a été dit par d'autres.
Si tu veux garder un accès réseau avec des débits et des latences correctes quand tu fais du P2P, il FAUT que tu règles ton client P2P pour avoir le débit max d'upload en-dessous (genre 10%) de celui de ta ligne ADSL. Chez moi, j'ai environ 100 ko/s en upload par l'ADSL, et je configure le débit max de bittorrent à 75 ko/s pour l'upload; la marge importante permet aussi de garder du débit pour l'envoi de courriel.

Ça permettra non seulement de continuer à naviguer de façon relativement fluide, et aussi de garder un temps de ping correct (donc une réactivité correcte du réseau).

Si tu as plusieurs machines qui font du P2P, il faut que la somme des débits max en upload de tes clients P2P soit inférieur au débit max de ta ligne ADSL.

Il faut aussi être conscient du fonctionnement du protocole TCP, qui implique que quand tu as un débit constant dans un sens, il y a aussi un débit dans l'autre sens, pour les paquets d'acquittement. Grosso modo si tu télécharges à 64 ko/s, il y a environ 2-3 ko/s de trafic en sens inverse. Ce qu'il se passe si tu autorises l'upload sans limite (ça sera celle max possible donc), c'est qu'il n'y aura plus de place pour les paquets de retour du trafic descendant, donc ce dernier va être ralenti (de pas mal).

Dommage, il ne va rester pour les "décideurs" que le magazine 01 Informatique, qui à mon avis est beaucoup plus "pipeau" que LMI.
J'étais également un fan de François Cointe :-) .

« qui pallie aux défauts actuels » => "qui pallie les défauts actuels".
On remédie à quelque chose, mais on pallie quelque chose.

« encodage vidéo » => "codage vidéo" (ou transcodage éventuellement) ; avant, on disait aussi compression vidéo.

J'oubliais de dire que parmi ces 4 opérations, les 2 dernières ne sont pas effectuées à chaque fois, et de très loin, puisque l'écriture (qui demande éventuellement un déplacement de la tête) n'est faite qu'en mémoire dans un premier temps, dans le cache du noyau. C'est au bout du délai de synchronisation (5 s par défaut) ou quand le cache est plein qu'il est "flushé" sur le disque d'un coup (lors du sync). Ca se voit sur une grosse copie, le voyant du disque clignote fortement sur la lecture, puis toutes les 5 secondes il devient complètement allumé pendant un certain temps, lors du "sync".

mv se contente de répéter autant de fois qu'il le faut les 4 opérations : [..] lecture d'un bloc

heu, si chaque fichier était vraiment lu bloc par bloc (et avec l'attente d'un tour), le système serait très lent. D'une part la commande mv (tout comme cp) lit plusieurs blocs d'un coup, et d'autre part le disque et le système font du pre-fetch / read-ahead pour accélérer les opérations, précisément pour améliorer une éventuelle lecture bloc par bloc.

Mes copies ou déplacements de fichiers (avec cp ou mv) se font toujours à peu près à la vitesse nominale du disque. L'utilisation d'un dd n'accélère rien chez moi.

Avoir using_dma = 1 (on) est suffisant, le paramètre IO_Support ne joue pas beaucoup à ma connaissance (voire pas du tout).
De plus, le résultat du test de lecture de hdparm me semble tout à fait honorable : Timing buffered disk reads: 78 MB in 3.04 seconds = 25.68 MB/sec. Donc ce n'est pas l'accès brut à ton disque qui pose problème, ça doit être au-dessus (le système de fichiers, peut-être).

Bonne réponse; petite remarque, tu as juste écrit "STDIN" au lieu de "STDOUT", je pense que les connaisseurs auront corrigés d'eux-mêmes (peut-être pas les débutants).

Je dirais que quand Blender a sa sortie dans une console, il fait bien un "flush" à chaque fin de ligne, tandis que quand la sortie est dans un fichier, ce n'est pas le cas.

Ce comportement n'est peut-être pas dans Blender directement, mais peut-être dans l'implémentation dans la libc (à vérifier). Je crains qu'il n'y ait pas de solution à ton problème.

Personnellement, je redirige plutôt dans cet ordre : blender >out.txt 2>&1 mais je ne sais pas si ça change quelque chose.
Note que tu peux aussi faire un blender 2>&1 | tee out.txt.