JGO a écrit 2437 commentaires

Toutes mes excuses à Zylabon, j'avais mal compris sa phrase et là je suis bien un imbécile.

Je moinse les commentaires inutiles. Un commentaire de premier niveau contenant uniquement un lien sans indication du contenu et dont j'ai des raisons de penser qu'il est sans rapport avec la dépêche, je trouve ça inutile.

En quoi est-ce que cela fait de moi un imbécile ?

Note que je n'ai pas dit qu'ils auraient dû choisir autre chose, j'ai demandé à l'auteur d'expliquer ce qui a motivé son choix. Il a répondu en disant que c'était le langage qu'il connait, et c'est une bonne réponse.

ok merci j'avais mal interprété.

Et Python (ou Ruby, ou autre Perl) ne mange pas plus de ressources qu'un déploiement PHP

Je compare cozycloud (python) à owncloud (php), deux logiciels ayant le même niveau de fonction :

• commentaires de la dépêche cozycloud : ça ne s'installe pas avec 256 Mo, les fonctionnalités sont limitées avec 512 Mo, l'auteur utilise 1024 Mo pour avoir toutes les extensions.
• commentaire du journal owncloud : apparemment ça marche dès 256 Mo.

Ça pourrait être que cozycloud est mal codé et bouffe trop de mémoire pour rien, mais en l'occurrence aucun commentaire ne critique la qualité du code, alors que les problèmes liés au déploiement sont critiqués : nécessité de compiler un module avec gcc ; nombre d'appliquettes affichées sur la page d'accueil.

on peut embaucher des imbéciles qui feront des scripts pas plus pourris que les autres.

L'argument est valable pour un environnement d'entreprise, mais pour un projet de passionné comme Poche, il était libre de son choix. Je retiens l'argument du déploiement pour Poche, qui doit être installable par un particulier louant un serveur mutualisé ou virtuel aux caractéristiques limitées.

Bon je sais pas insérer une image, le lien est : http://pix.toile-libre.org/?img=1376038310.png

Je suis comme toi, la feuille de style par défaut m'est inutilisable.

La meilleure que j'ai trouvé pour la mise en valeur des nouveaux messages est cascade-alternative, met en valeur les nouveaux messages avec un fond gris foncé.

On lit des tas de trucs méchants concernant PHP (Why PHP sucks et suivre les liens du paragraphe Other Anti-PHP Sites). Vu la taille de la base de code disponible, on peut comprendre que dans de nombreux cas où on étend un programme existant, il n'y ait pas le choix. Mais pour un code entièrement nouveau, il y avait de nombreux frameworks possibles. Par exemple très récemment, on découvrait sur linuxfr cozycloud, tout jeune logiciel web en python, concurrent d'un plus ancien logiciel en PHP (owncloud). D'où ma question : qu'est-ce qui a motivé le choix du langage dans le cas de poche ?

Le site web est joli, très coloré. Quel dommage que l'application soit en noir et blanc.

Envisagez-vous :

• un système de catégories/tags ? Une fois que j'aurai des centaines d'articles il va falloir les organiser.
• l'intégration d'un moteur de recherche ? (Je sais c'est gros un moteur de recherche et c'est pas votre projet, mais en termes de fonctionnalités j'ai déjà ça sur mon ordinateur de bureau pour les articles que je garde avec l'extension Scrapbook de Firefox : 1) le moteur intégré à Scrapbook et 2) recoll, interface Qt / moteur xapian. Si je veux pouvoir passer au nuage, il faut que ce soit à équivalence de fonctionnalités.)
• un système pour exporter mes données (lisible par l'humain et/ou de façon utilisable par d'autres applications) ?

La dépêche dit que le texte et les images sont téléchargées sur mon serveur. Pourtant quand je lis une nouvelle sur le site de démonstration (par exemple Attaqué par un requin, il réplique au taser, login poche/poche), l'image (le maitre-nageur) provient d'un autre domaine. Pouvez-vous expliquer ?

Merci pour la dépêche et pour l'application, ce sera très utile. J'hésite un peu à installer. Je ne veux pas dépendre d'entreprises extérieures et je suis content que POCHE me permette d'éviter cela, mais mes compétences en bases de données sont limitées et j'ai peur qu'une upgrade future se passe mal. Qu'avez-vous prévu pour garantir la pérennité des données au cours des migrations ?

Boot to gecko : https://github.com/mozilla-b2g

Noter que gonk n'est pas un noyau linux à part avec un site web comme on pourrait s'y attendre. Il n'a même pas un répertoire séparé. Son code est dispersé dans différents répertoires et il faut faire un grep sur les fichiers pour retrouver ses morceaux (lire cette discussion, en particulier la réponse de Gregor Wagner, ingénieur chez Mozilla).

Oups en effet, toutes mes confuses.

si la demi-vie est longue, alors les déchets sont faiblement radioactifs.

Oui à concentration faible, mais certains déchets ont une concentration très élevée et sont donc à la fois très actifs ET à demi-vie longue. Voir Déchet à haute activité et à vie longue. Ils chauffent aussi pas mal, ce qui explique que les valeurs de diffusion soient tabulées à quelques centaines de degrés. Mais sinon je suis d'accord avec toi que les migrations dans le verre sont raisonnables.

Il reste l'aléa géologique, par exemple le site allemand de la Mine d'Asse a un problème de remontées d'eau (normal pour une mine de sel, mais pourquoi alors avoir choisi une mine de sel ?), au point qu'il est envisagé d'extraire tous les barils pour les mettre ailleurs. Il faut espérer que ce choix de site est le genre d'erreurs qu'on ne commet qu'une seule fois.

J'ai essayé d'installer phctool sur ma machine (i7-2600K, linux-3.10.4, gentoo). Le code est dans les dépôts, ça compile le module (sys-power/phc-intel-0.3.2.12.1-r5) et les outils utilisateurs (sys-power/phctool-0.5.2.2-r2). J'arrive à insérer le module (rmmod -f acpi_cpufreq mperf processor && modprobe hpc-intel mperf processor), mais l'application utilisateur me dit processeur non reconnu. Je n'ai donc pas plus de chance que toi pour la tension.

Quant au changement de fréquence, il est probable que tu utilises déjà le gouverneur « ondemand » sans le savoir (c'est du moins le cas sur une Debian 7.1 fraichement installée sur mon netbook de test), donc la fréquence est déjà aussi basse que possible en l'absence de charge.

Au cas où, le script référencé (en option) qui détecte les messages Maildir en double.

#!/bin/sh
# Renvoie le messageid d'un message Maildir,
# à fins de déduplication

case $# in
        1) file=$1
        ;;
        *) echo -e "Message-id of a maildir message.\n Syntax: messageid.sh FILE\n"
        ;;
esac

id=$(grep --no-messages --no-filename --colour=never --max-count 1 "^Message-I[dD]: " $file | sed "s/^.* //")
echo $id $file

#!/usr/bin/perl

use v5 ;
use strict ;

######################
# User configuration #
######################
my $temporary_file = "/tmp/list_findduplicate_md5" ;

# can be any of the control sum programs from coreutils:
# cksum, sha1sum, sha224sum, sha256sum, sha384sum, sha512sum, md5sum
# could be sha3 as well the day GNU decides to add it to coreutils.
my $hash_program = "md5sum" ;
#my $hash_program = "/usr/local/bin/messageid.sh" ;
# program must display the name of the file after its sum.
# When using cksum only the crc32 sum is used, not the byte count.

########
# Main #
########
sub help {
  my $help_string="
Syntax : ./findduplicate.pl
Will list files in current directories and subdirectories,
and display the location of the files which are duplicates,
based on their hash calculated by ${hash_program}.

Author: XXXXXXXXXXXX, <xxxxxxxxxxxx\@xxxxxxx>
Date: 19 May 2013
" ;
  print $help_string ;
  exit (0) ;
}

help() unless ($#ARGV == -1) ;

my ($line) ;
my (@params) ;
my ($formersum,  $currentsum) ;
my ($formername, $currentname) ;
my ($count) = 0 ;
my ($s1, $s2) ;

# Fichier contenant les sommes de contrôle de tous
# les fichiers du répertoires et des sous-répertoires,
# classées par ordre alphabétique de la somme de contrôle
system ("find . -type f -exec ${hash_program} \"{}\" \";\" | sort > ${temporary_file}") ;
open INPUT, "<", $temporary_file ;
$formersum = "" ;
while ($line = <INPUT>) {
  # Dans cette boucle on lit une somme de contrôle
  # depuis le fichier, et on compare à la précédente.
  # C'est ce qui définit un fichier dupliqué.
  chomp $line ;
  @params = split / /, $line ;
  $currentsum  = $params[0] ;
  $currentname = $params[$#params] ;
  #print "##${formersum} -- ${currentsum}**\n" ;
  if ("${formersum}" eq "${currentsum}") {
    $s1 = -s ${formername} ;
    $s2 = -s ${currentname} ;
    # Dans le cas où on utilise messageID.sh, on peut
    # avoir des fichiers dupliqués de taille différente.
    # Par convention on écrit le plus petit en premier.
    # Dans les autres cas (md5, crc32), les fichiers
    # détectés comme dupliqués ont nécessairement la
    # même taille, la première comparaison étant alors
    # toujours vraie.
    #
    if ($s1 <= $s2) {
    print "diff -u ${formername} ${currentname}\n" ;
    } else {
    print "diff -u ${currentname} ${formername}\n" ;
    }
    #print "mv ${formername} dup/\n" ;
    $count = $count + 1 ;
  }
  $formersum = $currentsum ;
  $formername = $currentname ;
}
if ($count == 0) {
  print "No duplicates found\n" ;
}
#elsif ($count == 1) {
#  print "One duplicate found\n" ;
#} else {
#  print "$count duplicates found\n" ;
#}

# On the target system, asks for enter
# Useful on a specific machine where the script
# is run from a graphical menu and must wait for
# user to read the results before existing.
#
#print "Press Enter to exit\n" ;
#<> ;

__END__```

Changement de la fréquence : :en:Dynamic frequency scaling

cpufreq existe toujours, dans le noyau c'est contrôlé par les paramètres d'ACPI (documentation). Si tu utilises un noyau de distribution c'est très probablement activé.

L'utilitaire cpufreq-info donne la liste des fréquences supportées par ton processeur et le gouverneur utilisé. Il existe plusieurs gouverneurs : performance (fréquence au max), powersave (fréquence au min), ondemand (choix dynamique par le noyau en fonction de la charge) et userspace (fréquence choisie par l'utilisateur). Tu peux changer le gouverneur ou directement choisir la fréquence avec cpufreq-set. Note qu'il y avait eu une étude de faite qui avait montré qu'en général mettre la fréquence au minimum n'économisait pas d'énergie ; en effet il est plus efficace que le processeur fasse ce qu'il a à faire très rapidement (fréquence élevée) puis entre en état de veille, plutôt que de devoir rester éveillé plus longtemps à basse fréquence. Pour ta charge spécifique faut tester.

Anciennement il y avait aussi le « CPU Throttling » (documentation) qui allume/éteint le processeur avec un certain rapport cyclique (p.ex. 50 % du temps) mais sur mon proc. récent ce n'est pas supporté.

Changement de la tension : :en:Dynamic voltage scaling

Il existe des patches : http://www.eecg.toronto.edu/~tamda/csc2228/ Mais apparemment rien dans la branche principale du noyau.

À échelle géologique il faut prendre en compte la diffusion des radionucléides dans le verre.

En utilisant la formule de : Katsuhiko Nonaka et al, Self-Diffusion of Na and Cs in Simulated Nuclear Waste Glass. Materials Transactions, Vol. 43, No. 4 (2002) pp. 654 to 659. www.jim.or.jp/journal/e/pdf3/43/04/654.pdf

On obtient :
²²Na : D=4,29·10⁻²⁰ m²/s (à 428 K) (τ ²²Na ≈ 8,3 ms)
²²Na : D=1,38·10⁻¹⁶ m²/s (à 574 K)

¹³⁷Cs : D=1,53·10⁻²² m²/s (à 713 K) (τ ¹³⁷Cs ≈ 2004,6 s)
¹³⁷Cs : D=1,71·10⁻²¹ m²/s (à 758 K)

On calcule l'avancée du front de diffusion par mouvement brownien en appliquant la loi de la diffusion de la matière : d ∝ √(D·t)

Soit après 100 000 ans (×365,25×86400 s) ²²Na migre d ≈ 368 µm à 428 K, et ≈ 2 cm à 574 K.

Cela reste assez faible, notamment pour ces isotopes à vie courte. (J'ai juste pris des valeurs dans le papier qui est sorti en premier.) Mais si un radionucléide à vie longue a un coefficient de diffusion similaire, migrer 2 cm ça pourrait commencer à faire beaucoup. Pour comparaison la diffusion dans l'argile :

Masaki Tsukamoto et al. Diffusion of Radionuclides in Compacted Bentonite : Results from Combined Glass Dissolution and Migration Tests. MRS Proceedings, volume 353 (1994). http://dx.doi.org/10.1557/PROC-353-291

(À 90 °C)
²³⁸Pu : 2·10⁻¹⁴ m²/s (τ ≈ 2,76571·10⁹ s)
²³⁴U : 5·10⁻¹² m²/s (τ ≈ 245 000 ans)
¹²⁵Sb : 2·10⁻¹² m²/s (τ ≈ 1,07654·10⁶ s)

Il s'agit de déchets à vie longue, donc ici 100 000 ans est une valeur de temps adaptée.
d ²³⁸Pu ≈ 25 cm
d ¹²⁵Sb ≈ 2,5 m
d ²³⁴U ≈ 4 m
Conclusion, si ces radionucléides touchent l'argile c'est foutu.

[Valeurs de demi-vie récupérées depuis Kalzium. J'espère que votre navigateur/polices supportent unicode.]

Dans une optique descriptive plus que normative, le wiktionnaire définit le mot :wikt:fr:crypter. Les notes mentionnent la polémique autour du mot et sont intéressantes à lire.

« chiffrer un contenu sans connaitre la clef », ce qui n'a aucun sens.

Cela rappelle le chiffrement homomorphique. Ce sont des systèmes qui permettent de travailler sur des données sans connaitre la clef de déchiffrement. Exemple d'application, un ordinateur dans une banque qui pourrait effectuer des opérations sur les comptes (ajout et retrait de valeur) sans avoir à connaitre le montant des comptes (meilleure séparation des privilèges). Également cela évite de déchiffrer/re-chiffrer en permanence pour réaliser des opérations simples (addition, multiplication) et permet donc de réduire la charge sur un ordinateur travaillant sur une base de données chiffrée.

Il te faut un stockage qui soit sûr pendant des milliers d'années…

Il pourra y avoir des fuites et ces fuites rentrent dans la catégorie accident. Le fait que seuls des accidents imprévisibles occasionnent la pollution fait que la pollution est presque impossible à calculer à l'avance, surtout en l'absence de données réelles (il y a 2 sites fermés et 4 sites actifs au monde et aucun accident enregistré, voir la liste sur Wikipédia à Deep geological repository#Repository sites).

Ce n'est certainement pas une raison pour l'ignorer et tout ramener au CO2.

J'utilise les seuls chiffres disponibles, qui sont ceux du CO2. Si tu connais les évaluations de pollutions nucléaires pour la fabrication des biens de consommation, donne le lien, on fera le calcul pour les appareils mentionnés.

Et les déchets, ils comptent pour du beurre ? :-o

L'impact des déchets ultime est négligeable en l'absence d'accident (ce qui serait grave ce serait une contamination de l'eau par le matériau nucléaire, en revanche le simple effet des rayonnements est faible de l'autre côté des murs de béton). Il n'existe pas beaucoup de données chiffrées sur les accidents de stockage (voir sur Wikipédia Accidents involving radioactive waste), en tout cas bien moins de données que pour les accidents d'exploitation. Dans tous les cas les accidents étant rares et graves, ils sont difficiles à utiliser pour faire une moyenne. La seule chose quantifiable est l'impact environnemental du retraitement (en TBq dans les boues rejetées).

De façon générale l'impact environnemental hors CO2 est difficile à comparer car chaque type de pollution a un mode d'action différent. Par exemple l'installation d'un barrage de production détruit un écosystème (il y a des associations écologistes qui se battent contre les barrages). La production de panneaux solaires est tout aussi polluante que celle des produits électroniques décriés dans cette conversation. Quant au charbon il rejette des métaux lourds dans l'atmosphère.

Pour comparer il faudrait un échelle internationale de « grammes équivalent plomb » renseignée pour toutes les activités humaines. C'est ce qui existe pour le CO2 et c'est pour ça qu'on peut faire ces comparaisons. Mais même avec ça, c'est quoi le pire : 1 TBq ou 1 kg de plomb dans le lac ?

Gradient existe en français mais est la quantité numérique (définition cnrtl) ou vectorielle (wiktionnaire, ton lien). Le résultat en termes de couleur peut se comprendre pa métonymie, mais c'est plus probablement ici un anglicisme qu'une figure de style. Le plus simple en français c'est « dégradé » mais en termes de peinture on utilise aussi camaïeu (peinture) (en particulier dans le cas où la teinte est la même, le peintre ne jouant que sur le mélange avec le blanc et le noir).

Quelqu'un a réussi à faire fonctionner la barre latérale (de Symphony) sous linux ? La copie d'écran pus haut est sous OS privateur ; j'ai installé le paquet sous linux et rien du tout.

Il faut arrêter avec cet argument.

Mon argument est que la structure des couts est différente. Un serveur virtuel coute plus cher par mois mais n'a pas le cout annuel de l'achat et du remplacement du matériel. Et la différence de prix n'est pas si grande.

Quand je regarde autour de moi, je vois qu'aujourd'hui dans un foyer, tout le monde à son propre PC.

En ce qui me concerne j'ai zéro PC à la maison et l'auto-hébergement me couterait plus cher (en comptant l'abonnement internet). Chacun son cas particulier.

et qu'en plus ce pc fasse office de serveur web/mail/xmpc/…

Si tu as de applications de type domotique c'est sûr que tu gagnes à avoir un client léger connecté en permanence. Je n'ai pas cet usage, en revanche j'ai des applications à distance où je gagne à avoir un serveur virtuel : 1) échanger des photos avec ma famille dans d'autres pays, or avec un serveur virtuel dans leur pays (la France) c'est nettement plus rapide pour eux ; 2) quand je partirai en vacances, je veux utiliser le serveur comme tunnel ssh pour me connecter à ma machine derrière un NAT au travail (et utiliser la connexion pour l'accès aux abonnements de revues spécialisées). [Et, en plus, ça fait serveur mail.]

Si tu as besoin de stocker des To de vidéos c'est sûr que louer un serveur va couter cher, mais ce n'est pas le besoin qui était évoqué ici. Chacun son besoin, en ce qui me concerne je n'ai pas d'ordinateur / connexion internet à la maison (je n'aurais pas le temps d'utiliser de toute façon, et je moule bien assez au bureau) et ma solution d'un serveur virtuel pour rester en contact avec ma famille (owncloud pour quelques Go de photos) est plus économique que de louer une ligne ADSL pour avoir le plaisir de m'auto-héberger chez le FAI (pourri) qui dessert mon domicile.