BlueWhisper a écrit 51 commentaires

Les tests unitaires sont en général vraiment difficiles à programmer. En soi, le système et déjà compliqué. Par exemple intuitivement on pense que les minutes ont 60 secondes (et paf, voilà la seconde intercalaire)

En plus, il y a évidemment les "particularités régionales".

Mais si tu te sens la volonté de programmer un test unitaire, je suis sûr que les développeurs t'en seront reconnaissants :-)

Merci pour ton partage d'expérience.

Pour le streaming du DVB par RTP (UDP multicast), je recommande DVBlast, qui fonctionne vraiment bien tout en étant vraiment léger.

Je l'ai utilisé pour streamer tout un channel (splitté par PID) de DVB-T sur un LAN, qui était ensuite retransmis/transcodé par différentes machines.

Euh, elle sont au contraire très soumises au droit d'auteur... Les conditions sont souvent assez restrictives.

C'est ce que le serveur répond (en effet, cela ne marche pas avec cette adresse), une erreur des belges ou du FBI?

$ dig @85.255.112.1 www.dns-ok.be             

; <<>> DiG 9.8.1 <<>> @85.255.112.1 www.dns-ok.be
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29814
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;www.dns-ok.be.         IN  A

;; ANSWER SECTION:
www.dns-ok.be.      30  IN  A   193.190.192.222

;; AUTHORITY SECTION:
rpz.dcwg.org.       30  IN  NS  localhost.

;; ADDITIONAL SECTION:
localhost.      3600    IN  A   127.0.0.1

;; Query time: 100 msec
;; SERVER: 85.255.112.1#53(85.255.112.1)
;; WHEN: Wed Feb 15 11:18:31 2012
;; MSG SIZE  rcvd: 98

La version suisse (dns-check.ch) fonctionne correctement par contre.

Avec un mauvais serveur:

Using domain server:
Name: 85.255.112.1
Address: 85.255.112.1#53
Aliases: 

dns-ok.be has address 193.190.192.222
dns-ok.be has IPv6 address 2001:6a8:3c80::222

Avec un bon:

dns-ok.be has address 193.190.198.221
dns-ok.be has IPv6 address 2001:6a8:3c80::221

Il suffit d'aller sur les adresses ip pour voir la différence. (notons qu'ils ont même pensé au gens comme moi ayant de l'IPv6)

Je pense que de l'internet "décentralisé" c'est un joli oxymore. Au final, il y aura toujours un câble où les connexions de plusieurs utilisateurs passeront. (et les ondes ne sont qu'un remplacement à petite échelle)

Par contre, pour les services qui y sont présents, je pense que ça dépendra plutôt de l'effort de contrôle qui est ou sera fait par les gouvernements pour les contrôler.

Cela coûte cher de développer quelque chose de décentralisé et "difficile à cibler". De plus, cela demande de la recherche, et donc il faut qu'il y ait une "carotte" qui motive ce développement.

A mon avis, si on écrit des commentaires soit contenant de l'humour, soit intéressants, ils sont bien notés. (et c'est mon critère)

En particulier, les "calimeros", je trouve ça pas très intéressant...

Je pense qu'avant de dire qu'il manque des précisions, il faut simplement lire le document! Je ne vais quand même pas le copier-coller dans le journal!

J'utilise virtio, j'ai (du moins tenté) de faire les choix pour avoir les meilleures performances possibles, tant sur l'hôte que dans la vm.

Les configurations du kernel sont dans le SVN, je vois pas vraiment ce que je peux faire de plus.

Je confirme, c'est une excellente solution.

Par contre je n'ai jamais réussi à utiliser xpl-perl (il ne sait pas décoder les valeurs de mes sondes). Pour ma part, j'utilise heyu, avec un bête script python, pour logger dans zabbix:

import subprocess,re
regexp_temp = re.compile("hu ([^ ]+) .*Temp ([.0-9-]+)C \((.+)\)")
regexp_rh = re.compile("hu ([^ ]+) .*RH ([.0-9]+)% \((.+)\)")

pipe = subprocess.Popen("heyu monitor", shell=True, bufsize=1024, stdout=subprocess.PIPE).stdout

def submit(sensor, key, value):
    cmd='zabbix_sender -z localhost -k heyu.{sensor}[{key}] -o {value} -s     domotique'.format(sensor=sensor, key=key, value=value)
    subprocess.call(cmd, shell=True)

while True:
    line = pipe.readline().strip()
    m_temp = regexp_temp.search(line)
    m_rh = regexp_rh.search(line)
    if m_temp:
        submit(m_temp.groups()[2], "Temp", float(m_temp.groups()[1]))
    elif m_rh:
        submit(m_rh.groups()[2], "RH", float(m_rh.groups()[1]))
    else:
        print "Unknown: ", line.strip()

PS: je sais qu'il est possible de faire plus "optimal" (ne pas lancer un zabbix-sender à chaque fois, mais pour les 3 sondes que j'ai, c'est suffisant.

toutes les versions des logiciels utilisés

Lequel en particulier? Pour ce qui est du kernel, j'utilise le 3.1. Le reste est mentionné dans la figure 16.

le type de container pour le FS ... de fait sur KVM par exemple si tu utilises du Qcow ou du Qcow2 tu n'as pas le même résultat

J'utilise directement un partition disque. (C'est mentionné soit en annexe du rapport, soit dans les fichiers de configuration dans le SVN)

Merci pour tes commentaires.

Tu as essayé de comprendre pourquoi les résultats en temps cpu des benchs Xen variaient autant (figure 1 en particulier) ? Voir plus loin pourquoi il était beaucoup plus mauvais ?

Je soupçonne que la grande variance et les mauvais résultats peut-être liée à des questions de scheduling de l'hyperviseur, mais je ne connais pas de moyens précis pour obtenir ces informations.

Quelle version de Xen utilises tu ?

Celle fournie avec le kernel. Je n'ai pas sous la main le numéro de version des outils en userland, mais je ne crois pas que cela influence les résultats.

Concernant la présentation, c'est assez difficile de présenter de façon lisible des résultats qui peuvent être très différents, et le public visé est plutôt du type universitaire. J'avais également une contrainte de longueur de rapport, ce qui fait que j'ai dû être bref.

Enfin, sur le fond, il aurait sûrement été intéressant de savoir précisément pourquoi certains benchmarks étaient plus efficaces sur vm que sur le master (mais je ne sais pas si ça rentrait dans le temps du projet).

Pour l'instant la question a été mise de côté. C'est prévu d'étudier plus précisément ceci, si les résultats sont reproductibles avec du matériel plus moderne et avec des meilleures librairies plus optimisées (MKL).

Dans la licence que j'ai acceptée, il est écrit:

2.4 Benchmarking.  You may use the Software to conduct internal
performance testing and benchmarking studies, the results of
which only You may publish or publicly disseminate, provided that
VMware has reviewed and approved of the methodology, assumptions
and other parameters of your testing and studies.  Please contact
VMware at benchmark@vmware.com to request such review.  For VMware
Workstation and Fusion benchmarks, You may publish or publicly
disseminate the results without VMware’s prior review and approval.

J'ai donc utilisé VMware Workstation (sans installer X11, et en stoppant l'interface graphique) pour éviter le problème.

Il faut lire l'article de base:

The SFC will grant a new license, but on one condition - not only must you provide the source code to Busybox, you must provide the source code to all other works on the device that require source distribution.

En fait, c'est apparemment cette exigence de la SFC qui les gène. D'où l'idée que d'écrire un clone de Busybox les "aiderait" à violer les autres licenses...

Oui. Vraisemblablement c'est suffisant pour ton cas.

Dans le cas idéal, il est judicieux d'utiliser les built-in exceptions lorsque c'est possible, et pour les autres de définir plusieurs classes d'exceptions (c'est plus facile de choisir le traitement à réserver à chaque exception si on a un bloc except pour chaque type d'exception.)

Surtout, ne pas "bricoler". Ta définition du problème correspond à des exceptions, donc il faut les utiliser.

Il est possible de définir tes propres exceptions.

Concrètement, tu peux mettre les arguments que tu veux au constructeur, ce qui te permet de transmettre, notamment, le message.

Je pense que ce que tu veux dire par "plus uniforme", c'est du point de vue de la vectorisation?

En fait, les GPU sont essentiellement vectoriels (>= 32 opérations identiques simultanées sur des float), et les CPU moins (AVX: 8 opérations sur des floats, 4 avec les SSE*). Bien sûr, ces chiffres ont plutôt tendance à augmenter avec le temps, ce qui peut (peut-être) amener à une uniformisation.

Sans vouloir troller, pour le code général, je pense que si les gens écrivaient du code mieux vectorisable par le compilateur, on gagnerait déjà pas avant de devoir utiliser quelque chose comme CUDA. Notamment en évitant les if dans les boucles, et en utilisant le mot clé restrict (__restrict__ en C++) lorsque c'est approprié.

Et puis surtout, si dans 2 ans le contrôleur du NAS pête, même si aucun disque n'est touché, comment fait-on pour les remonter ailleurs et récupérer les données ? (je ne connais pas ce matériel, je ne dis pas que c'est impossible, mais ça n'est pas forcément trivial sans un contrôleur RAID identique)

Les qnap (en tout cas le Pro 459 II et le Pro 859 Pro+) utilisent le raid software Linux, pas de problème en cas de pépin, cela se monte sur n'importe quel ordinateur:

[~] # cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath] 
md0 : active raid5 sda3[0] sdd3[3] sdc3[2] sdb3[1]
  2925580800 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]
  bitmap: 6/233 pages [24KB], 2048KB chunk

Soit:

N = le plus petit nombre ne pouvant être défini par une phrase de moins de 100 mots

Oups... je viens de le définir (et en moins de 100 mots :-)

Séibé = CIB = Cat In Black

Je pense que cela serait un bon ajout. ça éviterait d'avoir à chaque fois 2^n options...

Sinon pour répondre à la question du sondage: ça dépend quand c'est "demain"... À terme, on aura bien tôt ou tard tout utilisé ce qui est fossile... la question c'est plutôt, est-ce qu'on attendra jusqu'à la fin?

Quelques détails supplémentaires seraient bienvenus... Qu'as tu essayé? quels ont été les résultats?

Je ne connais pas les init-scripts de ubuntu, au pire on peut le faire à la main. La base c'est:

kexec -l <kernel> --append='...'
kexec -e

Pour mon info, quel est l'intérêt d'utiliser kexec dans ton cas précis? (excepté gagner quelques secondes pour éviter le bios/grub)

Pour une fois que j'allais répondre à un sondage... :-)

Conseil: essaie d'éviter de faire la même erreur que j'ai fait, qu'on a tous fait, de vouloir réinventer la roue.

LFS ça marche, mais c'est vraiment lent. Il vaut mieux utiliser une distribution déjà existante, quitte à personnaliser.

Pour du léger:
- OpenEmbedded est bien et (relativement) facile à prendre en main.
- Gentoo avec emerge --root=/mon_futur_root permet de construire une gentoo sans portage, compilateur, etc.

Je suis tombé dessus il y a quelque temps, pas testé...

http://digitizer.sourceforge.net/

Ces conclusions me rappelle un travail de management que j'avais du faire. On s'intéressait au cas des OIN, et en particulier de l'OpenInventionNetwork.

Hypothèse qu'on aurait dû trouver d'après les idées des profs: "c'est pour favoriser l'innovation".

Au final, on a pu démontrer que c'était plutôt pour pouvoir mieux se défendre avec des brevets communs... l'art d'enfoncer des portes ouvertes...