NOULARD Eric a écrit 44 commentaires

l'auteur parle de formations de relaxation ou de poterie, je ne pense pas que de telles formations puissent entrer dans les cases d'une certification

Ben bien sûr que si il existe des formations de tourneurs, de céramistes, il existe aussi les DMA, etc… La liste des métiers d'art a même été mise à jour très récemment.

De nombreuses filières artistiques ou artisanale crée ou ré-instaure des diplômes pour que ces filières soient reconnues au même titre que celle d'ingenieur en informatique. Ce sujet m'intéresse beaucoup car je suis ingénieur en informatique depuis plus de 15 ans et j'ai entamé le chemin de la reconversion et mon droit à la formation professionnelle n'est pas si simple à faire valoir que ce soit via le CPF ou le CIF.

Personnellement pour le sous-titrage j'ai un peu utilisé AegisSub: http://www.aegisub.org/ que j'ai
trouvé assez efficace/fonctionnel. Ceci dit j'ai sous-titré des choses courtes (< 15 minutes) donc
pas des films entiers.

Des comparaisons d'utilisation du Xeon Phi commencent tout juste, certaines seront présentés bientôt publiquement, pour ceux que ça intéresseraient: http://www.lfbs.rwth-aachen.de/content/781, puis regarder le programme du second jour.

Je pense plutôt qu'EDF emploie des ingénieurs, que ceux-ci savent ce qu'ils font

Le fait qu'ils savent ce qu'ils font ne présume en rien qu'on ne peut pas faire mieux autrement. La recherche est faite pour découvrir des choses qu'on ne sait pas encore faire ou qu'on a pas encore imaginé pouvoir faire. Je respecte le travail et l'intelligence des ingénieurs d'EDF mais je pense que tant qu'on ne pose pas de question ouverte on a pas de réponse ouverte. J'ai beaucoup de mal à croire qu'on ait déjà sérieusement chercher à répondre cette question au ingénieurs d'EDF:
Jusqu'à quel point peut-on décentraliser la production?

et que ce n'est pas pour rien qu'on est dans un modèle centralisé : c'est ce qui permet de mieux répartir et distribuer l'énergie (qui n'est pas homogène) car tout le monde ne pompe pas 16A en même temps

Sauf qu'EDF/ERDF a bien l'intention d'installer son compteur/espion/régulateur Linky et tirer partie d'une régulation distribuée. A la différence de la production distribuée (qui pourrait tout aussi bien se réguler) ici c'est la consommation qui est régulée par le compteur. On sera pas tant centralisé que ça n'est-ce pas?

D'ailleurs EDF n'aime pas du tout la concurrence sur ce terrain, voir l'exemple de l'affaire BluePod vs EDF ou cet autre article sur ce sujet.

Alors distribué ou centralisé? Je propose qu'on envisage ces solutions dans des programmes de recherche aux questions plus ouvertes que celles qu'on pose d'habitude aux ingénieurs EDF.

de se passer de batteries (le lithium est en quantité limitée sur terre, et l'extraction des composants est polluante et énergivore, de même que leur retraitement)

En France la solution à ce problème est assez simple il suffit de se raccorder au réseau électrique et de demander un raccordement en "supposé auto-consommé" ce type de raccordement permet de ne pas avoir de batterie. En fait tu consommes ce que tu produis et l'excédent produit par sur le réseau (pour d'autres consommateurs donc), EDF ne rachète pas le surplus mais le consomme et ton compteur tourne dans les 2 sens.

de se passer de neodyme pour l'aimant (même combat…)

Cette partie là est probablement plus difficile ensuite il faut évidemment voir la quantité consommée. Je n'ai rien contre consommer du pétrole, ce qui est probablématique c'est l'accélération de la quantité consommée.

que le rapport puissance/coût de l'équipement (sans neodyme) soit intéressant par rapport à l'investissement du même argent ailleurs, par exemple dans les économies d'énergies (isolation des logements, etc.)

C'est très juste l'énergie la plus rentable est celle qu'on ne consomme pas bien-entendu. Quand on a un projet de petit éolien cette question est très vite soulevé car on ne produira pas ce qu'on est habitué à consommer, donc il faut dans le même temps réduire/stabiliser sa conso.

C'est utile pour comparer différents modèles d'éoliennes, et également (surtout, en fait) pour connaitre son rendement par rapport a l'énergie investie dans les matériaux qui la constituent (énergie grise).

Je suis d'accord bien sûr, le coût financier ET énergétique de fabrication (et de recyclage d'ailleurs) sont à prendre en compte.

J'ai vu quelques études sur de petites éoliennes avec un rendement "gris" négatif. En d'autres termes, l'éolienne elle même n'est pas forcément écologique car sa construction et mise en place a demandé plus d'énergie qu'elle ne peut en produire sur sa durée de vie estimée.

… et ça m'intéresse beaucoup aurais-tu les références de ces études?

Parles-tu de petites éoliennes industrielles ou auto-construites ?

Ce qui intéresse au final c'est la puissance disponible, pas le rendement.

100% d'accord avec ça.

Certaines éoliennes sont adaptés pour les vents faibles, d'autres pour les vents moyens ou forts. Pareil pour les hélices.

Oui bien sûr on doit aussi vérifier si c'est raisonnable d'installer une éolienne à tel ou tel endroit car, par exemple, si la zone est proche d'arbres hauts ou de bâtiment l'éolienne risque d'attraper beaucoup de turbulence, de produire moins mais surtout de risquer la casse ou une usure prématurée à cause des turbulences qu'elle doit avaler.

Par exemple si il y a des éoliennes vraiment de partout

Bon je suis bien d'accord que dans un environnement fini rien n'est inépuisable sauf peut-être les idées qu'on peut avoir. Pour préciser mon point de vue, le vent est inépuisable si on l'utilise raisonnablement et les champs industriels d'éolienne qui vise à produire autant qu'une centrale fossile sont à mon avis une erreur. L'éolien se prête bien à la production décentralisé tout en permettant de tirer partie du réseau électrique existant donc ce n'est pas nécessaire, du tout, de recouvrir la terre d'éolienne pour subvenir à un grand nombre de besoins.

Je ne souhaite pas non plus influencer l'évolution de la biosphère :-)

Je me réponds à moi-même parce que j'ai écris une ânerie.

Évidemment le critère important pour le vent n'est pas tant qu'il soit gratuit mais surtout qu'il est "inépuisable" au contraire d'autres ressources énergétique.

Pour les images y'a aussi çelles-la mais c'est pas libre…

Cela augmente tout de même le rendement par rapport à des pales fixes ?

Juste une petite remarque à propos du rendement d'une éolienne. Je suis toujours surpris de ce qualificatif pour une éolienne (ou pour un chauffe-eau solaire). Le vent est gratuit donc ça me parait assez peu important de le gaspiller. Autant le rendement d"une chaudière à bois ou gaz ou fioul ma parait intéressant autant pour une éolienne…

En revanche, je pense que le prix de revient de l'éolienne, sa robustesse à l'usure, sa facilité de maintenance, sa facilité et/ou son coût initial de fabrication sont des critères importants.

En gros fabriquer une éolienne qui rend 80% de l'énergie captée mais coûte 10 fois plus cher et tombe 3 fois plus en panne qu'une éolienne qui aurait un rendement de 40% est probablement une mauvaise éolienne.

Bref vous aurez compris mon propos le rendement [énergétique] d'une éolienne ne me parait pas être un bon critère.

Les éoliennes industrielles mettent leur pales en drapeau, et se bloque (avec un frein) pour éviter une usure mécanique inutile.

Oui c'est d'ailleurs une des faiblesses des éoliennes industrielles car la mise en drapeau est faite via un contrôle électronique susceptible de panne. Le problème étant que si le contrôle tombe en panne la génératrice peut s'emballer puis possiblement flamber

Il existe aussi des éoliennes personnelles auto-construites (type Piggott) qui ont une régulation purement mécanique et qui de plus vont simplement délester l'énergie excédentaire sur une résistance dont la capacité est plus grande que la capacité de production de l'éolienne. En gros c'est un bon gros grille-pain de quelques centaines de Watt voire quelques kW.

J'ai participé à la construction de 2 de ces éoliennes avec l'association Tripalium c'était très intéressant cf http://www.p-plum.fr/?Une-eolienne-auto-construite-a.

On a le droit de la consommer directement ? Je croyais que c'était interdit, qu'en France il fallait obligatoirement revendre l'électricité à EDF (quitte à la racheter ensuite, si on consomme).

Ouhla heureusement que non, d'ailleurs tant que ton système de production n'est pas relié au réseau je ne vois pas bien qui pourrait venir te demander des comptes. C'est un peu différents des "carburants" sur lesquels il y a des taxes (TIPP) mais pour l'électricité ce serait le diable de ne pas pouvoir consommer ce que tu produis. Un peu comme si on t'empêchait de cultiver des tomates pour les manger !!

Je pense que tu as tout à fait raison quant au fait que considérer qu'il existe UNE vérité ou qu'un point de vue puisse être UNIVERSELLEMENT bon est tout simplement ne pas accepter la différence de culture ou de point de vue qui existe entre les gens, les pays ou même entre différentes époques. En résumant, je ne pense pas que ce soit possible ou souhaitable de faire une synthèse consensuelle mondiale et intemporelle pour un logiciel comme GCompris.

Maintenant, je ne me permettrais très certainement pas de dire que ma façon de voir les choses est la bonne, mais je ne suis pas certain du tout de vouloir endosser pour moi la façon qu'ont d'autres personnes de voir la vie, ou l'éducation des enfants etc… Je suis évidemment prêt à les respecter, tant qu'elle ne viennent pas interférer avec ma vie personnelle. En gros, les convictions personnelles et/ou religieuses engagent ceux/celles qui les prennent et pas ceux/celles qui y sont confrontés.

Donc, en offrant la possibilité d'activer/désactiver des activités, en offrant intrinsèquement, via un logiciel libre le fait de pouvoir le modifier et faire des versions dérivées me paraît être amplement suffisant. Donner les moyens de choisir me paraît être extrêmement important, faire des choix subjectifs et non-techniques me parait tout simplement pas être le chemin que je prendrais, car je m'engagerais alors dans un choix qui n'est pas le mien, voire qui est en contradiction avec le mien.

Évidemment tout ceci n'est que mon avis :-]

Ben l'ennuyeux c'est que personnellement je pense que la liberté ne s'achète pas plus qu'elle ne devrait se vendre. Donc même si l'initiative semble bonne le concept m'ennuie beaucoup. Je suis en retard de ma cotisation APRIL...et j'hésite.

A vue de nez ça ressemble (en fonctionnalités) à [au moins] un autre outils libre
récemment devenu un projet Eclipse: PapyrusUML: http://www.papyrusuml.org/

Est-ce qu'il existe des comparaisons?

Juste une remarque.
Comme vous semblez utiliser CMake comme outils de build.
Essayer CPack pour construire des paquets binaires,
une fois que les règles d'install sont OK, un coup
de

cpack -G RPM devrait construire un RPM
cpack -G DEB un paquet debian
cpack -G TGZ une archive binaire dans un TGZ etc...

ça dépend des outils installés sur la machine de dév
et de quelques variables CPACK_xxx à rajouter dans le CMakeLists.txt
principal mais ensuite c'est assez simple.
cf: http://www.cmake.org/Wiki/CMake:Packaging_With_CPack#Using_CPack_with_CMake

Vu merci.

Est-ce qu'il existe une liste de projets/applications qui utilisent 0MQ?
J'ai cherché sur le le site de 0MQ
(enfin jusqu'à qu'il ne réponde plus ??linuxfr-isé??)
sans succès?

Je serai particulièrement intéressé par des utilisations avec une archi. broker-less.
(j'irais évidemment poser la question sur le site 0MQ dès qu'il sera revenu à lui :-)

Pour ma culture, une bête question,
agentless si je comprends bien, ça veut dire que sur les machines que tu veux inventorier
tu n'as pas d'agent spécialisé pour faire l'inventaire, est-ce bien ça?

Si oui quels moyens as-tu pour accéder à ces machines? telnet, ssh, snmp etc...??

Exact je ne connaissais pas l'urllib,
à noter que ça existe aussi en Python 2.5 (peut-être même 2.3 à vérifier.
Et du coup on peut faire ça en 2 lignes!!
import urllib
urllib.urlretrieve('http://download.savannah.gnu.org/releases-noredirect/tsp/dte(...)


mes try{}finally{} le rendent plus robuste
d'accord avec ça le problème que ça me pose c'est que tu es obligé de les mettre...

Pour ce genre de cas je préfère le shell mariné de grep sed awk et autres commandes facilement scriptables ;-)
on est sur la même longueur d'onde je monte souvent a sed et shell afin d'arriver plus awk :-).

Mais bon, je dois avouer qu'un bon petit script python fait du bon boulot également, ceci avec le coté riche de Java et le côté Quick & Dirty du shell et ses amis scriptables.

Alors là je te remercie pour ton exemple.
On voit que Java et Python ont des librairies standards de
suffisamment haut niveau pour faire des choses rapidement mais....

On voit aussi que tu as un peu triché en essayant de dissimuler
le fait que Java est un langage compilé. Ce qui fait
que ton programme tel quel ne fonctionne pas alors
que tu peux copier/coller mon exemple python et tu verras que
ça marche.

Dans ton exemple il manque

- une classe englobante
<code class getIt { ...
}

au passage si j'appelle la classe d'un nom différent que le nom
de fichier ça me compliquera l'exécution....

- une méthode
public static void main(String[] args)
pour cette classe qui permettra l'exécution du programme

- des catchs parce que le finally seul ne semble pas plaire à mon compilo java C'est d'ailleurs très bien que Java force la gestion des erreurs mais c'est précisemment ce que j'aime éviter de faire quand je prototype

Je rajoutes à ça, qu'il faut:

a) compiler javac getIt.java
b) executer java getIt

Bref Java ET Python sont très expressifs et ont une librairie standard fourni, mais Python est un langage de script plus souple pour prototyper.
Résultat un fichier Java d'environ 27 lignes (pour que ça reste lisible)
que je dois compiler+exécuter contre un fichier de 10 lignes en python
que je peux exécuter tel quel et/ou copier coller dans l'interpréteur.

Je persiste, Java c'est très bien mais pour du prototypage ça vaut
pas un clou :-)

Réapprendre un nouveau langage nécessite forcément un certain
de démarrage j'ai trouvé celui de python acceptable.

Pour le debugger:

- python inclut le module pdb [http://docs.python.org/library/pdb.html]

- il existe aussi pydb [http://bashdb.sourceforge.net/pydb/] qui permet l'utilisation de DDD (à vérifier je ne suis pas utilisateur)

- comme python est interprété, l'interpréteur est déjà en lui-même un outil d'analyse très intéressant

Pour ce qui est du ré-apprentissage de l'API, ben évidemment ça peut prendre du temps, mais je trouve que ça va assez vite, car la doc de l'API est bonne.
Ensuite je pense qu'on gagne énormément de temps quand on utilise des API de haut niveau dont l'équivalent en C serait énormément plus verbeux. Par exemple récupérer un fichier sur un serveur en http:
import httplib

dlSavannah = httplib.HTTPConnection('download.savannah.gnu.org')
dlSavannah.request("GET","/releases-noredirect/tsp/dtest/what_is_dtest.pdf")
response = dlSavannah.getresponse()
f=open("what_is_dtest.pdf","w")
f.write(response.read())
f.close()
dlSavannah.close()


Il faudrait évidemment rajouter la gestion des erreurs, mais même comme ça
écrire l'équivalent en C, bon courage et même si tu prends la lib qui va bien
(curl [http://curl.haxx.se/libcurl/c/libcurl-tutorial.html] par exemple)

Je me permets un commentaire vu que:
- j'aime beaucoup Python
- j'en fait pas mal en ce moment
- j'ai programmé 5 ans ou +
(ou je programme encore) en C, C++, Java, Fortran, Perl, Shell etc...

A chaque fois que j'ai fait du Python (comme en ce moment) c'était pour prototyper rapidement et éventuellement garder une appli. qui ne nécessite pas de perfo démoniaque (sinon je fait du C/C++ voire Java).

Eh bien à chaque fois je n'ai pas été déçu et je suis quasiment certain que je n'aurais pas été plus vite en utilisant d'autres langages que je pratique pourtant plus souvent que Python (C, C++ et dans une moindre mesure Java).

Je pense que le seul truc qui pourrait me faire changer d'avis serait un autre langage interprété et dynamique comme Ruby ou peut-être Groovy [http://groovy.codehaus.org/] mais surement pas un langage compilé comme C/C++/Java

Le cycle de compilation+exécution est trop pénible et la dynamicité des langages compilés que je connais est trop faible pour faire des choses très dynamiques
(même avec l'introspection Java).

Par exemple DTest (Distributed Test) un petit outil qui permet de lancer des exécutables
sur différentes machines via une connexion SSH et coordonner [de façon sommaire] leur exécution et ainsi que ce qu'ils affichent sur leur sorties standard, une intro là:
[http://download.savannah.gnu.org/releases-noredirect/tsp/dte(...)]

Ca fait 1700 lignes de python (dont ~400 de commentaires) et ça m'a pris au total cumulé une quinzaine de jours.

J'aurai été incapable de faire ça aussi rapidement en C/C++/Java.