Il est clair que l'on perd des contributeurs. J'explique ici pourquoi la plupart des boîtes demandent la cession de copyright sur leur bébé. J'ai mis longtemps à l'admettre, mais dans la plupart des cas, gagner 3 contributeurs externes ne vaut pas de perdre la main sur ta base de code.
Sauf clause spéciale dans ton contrat, tu n'as pas ton mot à dire sur le code produit dans le cadre de ton travail. Et même un peu plus... Si tu bosses sur un logiciel de CAO et que tu fais un autre logiciel de CAO sur ton temps libre qui pourrait concurrencer le premier attends toi à recevoir une lettre du service juridique. De même que si tu bosses pour un projet sous GPL et que tu y contribues le WE attends toi à ce que le copyright de ce code revienne tout de même à l'employeur.
As tu déjà créé ou participé à une boite qui développe du LL ?
Le modèle économique de Qt/MySQL est l'un des plus honnête et rationnel. Ta boite investie pour faire du logiciel libre, si la GPLte convient c'est tout bénef pour toi. Si tu veux faire du proprio tu casques une licence proprio. Et ca, ca n'est faisable que si tu gardes le copyright sur l´ensemble de la base du code.
Maintenant si MySQL/Qt change d'avis et décide de passer en proprio, il te reste les anciennes versions libres. À la communauté du LL de reprendre le bébé. Jusque ici elle avait tout eu gratis
La cession du copyright ce n'est pas fait par plaisir, c'est qu'autrement ta boite perd la possibilité de se retourner (un projet bloqué en GPLv2 seulement par exemple). Et même quand tu as la main sur toute la base du code, opensourcer ou changer de licence relève du parcours du combattant.
Investi plusieurs années de ta vie et de ton pognon pour créer une boite et tu changeras peut être d'avis. Si la FSF ou la fondation Apache demande la cession de copyright ce n'est pas pour rien ! KDE l'a compris dans la douleur.
Ca me tue les mecs a qui on donne des choses et qui trouvent encore le moyen de gueuler ! Tu peux forker Java si tu ne veux pas contribuer mainstream et garder ton copyright.
Mais tu sais, dans la vraie vie sur les projets importants, les contributeurs externes sont rares. Mysql table sur 6 patchs externes cette année. OpenOffice y'a pas plus de 10 commiters externes etc. Alors la communauté est plutôt gagnante dans le deal.
Toi qui ne manque pas de tout critiquer. Qu'à tu fais pour le LL aujourd'hui (et hier) ? Certains tentent de faire avancer les choses, même si on pourrait mieux faire, d'autres font la morale sur les forums. Tu es de quel coté ?
Je suis complètement d'accord sur la notion de facilité et du cercle vicieux.
Je prends une vision pragmatique de développeur/chef de projet. Tu as un choix a faire maintenant tu fais quoi ? (il n'y a pas de réponse unique)
Cela dit dans facilité tu as aussi la notion de maturité des frameworks. Récemment j'ai voulu faire un bot IRC pour générer des flux RSS/mail (il mange aussi des connexions Telnet et récupéré des metadata sur des sites comme youtube). Je me suis donné le choix entre Ruby et Python. Mais après avoir comparé les docs/examples des modules dans les différents langages je me finalement suis rabattu sur Java alors que j'aurais bien scripté... Moins de 500 lignes au final.
D'un point de vue encore plus personnel, je me fou de la soit disant "beauté" du langage. Si j'écris 5 lignes de code au lieu de 10 je suis content. Mais ce qui m'importe le plus c'est de pouvoir faire les choses (outils, libs etc.), comprendre aisément du code de quelqu'un d'autre, avoir une base de code maintenable sur la durée, quand je code un lib avoir des utilisateurs potentiels et ne pas sortir mon soft 3 ans après avoir épuisé les crédits.
Et par pitié n'assimile pas une techno a quelques uns de ses utilisateurs: "si y'a encore beaucoup de gens qui savent ce que c'est qu'un algo en java". Y'a un marché de dev Java important. Ca draine les déchets, c'est évident. Mais je pense pas régresser mentalement lorsque je passe du C au Java. Tout comme il serait bon de ne pas traiter d'imbéciles les mecs d'Apache, de Sun ou qui font des archis comme Yahoo, Ebay ou LinkedIn.
Dans l'informatique pro y'a 70% de boulets, faut bien qu'ils utilisent quelque chose. Tu n'y changeras rien (et ils ont une petite chance de faire moins de mal en Java qu'en C ou C++ :-) )
> Quand on parle de bonne techno, dans le même thread que java, ça a tendance à me faire sourire. (facile on est vendredi).
Tu remplaces Java par J2EE et je suis d'accord avec toi :-) Souvent quand on parle de Java le gens pensent J2EE ou Java 1.2. Depuis ca a un peu évolué dans le bon sens tant en perf qu'en fonctionalités.
> Quelles sont les qualités de java
Facile à utiliser, lib standard assez complète, bon écosystème, portabilité aisée. En général tu fais facilement ce que tu veux. Tu passes plus de temps à faire des choses fun que réinventer la roue en général.
Ce n'est pas LA solution, et je n'irais pas l'utiliser pour n'importe quoi.
> Qu'est qui fait que java est robuste ?
Java n'est pas "robuste". Mais d'expérience entre un programme écrit en C (voir commentaire de GPL) et un programme dans un langage de plus haut niveau, j'ai mon idée sur celui ou tu passes plus de temps à avoir un truc qui marche correctement (conception + debug). On parle de base de 50k à 1M de lignes de code hein, pas de projet du dimanche.
> des langages qui nous donnent des assurances sur les types par exemple (ocaml, haskell), ou qui font du distribué vraiment pas cher (erlang).
Par ce que malheureusement ce sont des langages difficilement accessibles et à l'écosysteme assez faible (les deux sont liés). Si tu veux être viable à long terme il faut pouvoir attirer des gens et autant que possible faire le moins de travail toi même.
Attention je n'ai jamais dit que Java c'était LE truc génial et inégalé. C'est un outil adapté à certains problèmes qui a l'avantage d'être mainstream (et avec OpenJDK on peut espérer voir des gens du LL débarquer).
Même si tu ne veux pas faire de Java, réjouis toi de l'ouverture de Hotspot. Ca doit juste être un des bouts de code les mieux optimisés au monde. Il y a aussi pas mal de projet réutiliser la JVM, et ses perfs, pour d'autre langage (ca fait un .Net portable).
Après si quelqu'un veut discuter technique je pense avoir le background C et Java pour apporter quelques réponses sur les perfs etc.
En pendant que tu réinventes les listes chaînées ou un mécanisme de d'introspection moi je suis en train en boire des margarita sur la plage.
Quand tu utilises de la bonne facon les bonne technos, le coût runtime est infime par rapport au gain de robustesse et de productivité. Par contre aucun langage n'empêche les mauvais codeurs/architectes de pondre des bouzes. D'ailleurs tu peux me donner des pointeurs sur tes contributions d'exceptions au logiciel libre ?
Exercice supplémentaire: Regarder comment fonctionnent les JVM. Comparer l'assembleur produit par gcc et hotspot.
Sans rentrer dans les détails c'est pour une config vraiment peu commune ou un des prérequis est d'être le moins intrusif possible. Idéalement il faudrait même pouvoir ajouter n'importe quelle machine au réseau sans être admin dessus.
Bosser avec des gens te fait apprendre beaucoup. Rencontrer des clients/whatever te permet de mieux comprendre ton écosystème et découvrir de nouveaux problèmes. Manger/aller a la machine a café avec tes collègues te permet de mieux les comprendre. Et tu peux même y prendre des décisions au lieu de faire du metawork en meeting. Ca te permet aussi de rencontrer des gens (que ce soit ton voisin de cubicle, la dernière stagiaire de la compta ou l'équipe de squash). La vie réelle c'est ca et ca te permet d'évoluer. Si tu préfères t'enfermer chez toi... Mais pour moi le télétravail non merci ! J'ai d'ailleurs fait la même réponse à une boite qui voulait me débaucher en télétravail.
Autrement on dirait que vous vous servez de votre caisse que pour aller au taf ! Perso c'est clairement pas aller bosser qui me coute le plus cher (en plus ca passe en frais réels). A vue de nez:
- 6000 kms/an pour aller au boulot
- 12000 kms/an pour une saison de ski
- 10000 kms/an pour une saison de DH
- 2000 kms/an en sorties sur la région
- Plus quelques broutilles pour les vacances, courses etc.
Là je ne parlait pas de Samba/CIFS mais de fuse d'une manière plus générale (Voir le deuxième paragraphe)
Typiquement si tu me donnes la possibilité de monter un glusterfs et/ou un hadoop DFS sous linux/mac/windows je serais très content ! J'ai pas suffisamment de temps pour faire le portage windows.
Par ce que si tu ne fais pas que du linux tu l'as dans l'os ? Typiquement fuse et un de ses modules répondaient fonctionellement à nos besoins mais on devait supporter des machines linux et windows.
Du coup on à un beau NFS sur un NAS qui va ramer du cul au lieu d'un joli système de fichier distribué pour les données temporaires plus un SAN pour le stockage permanent.
Automobile: Chiffre constructeurs dans des conditions optimales sur véhicule neuf
Avion: Chiffres réels
Pour exemple sur ma caisse, routière avec quelques poneys turbo mazout, données constructeurs: 4.6l, 5,9l et 8,2l. Quelques observations après 90000 bornes, volumes mesurés et non issus du calculateur:
- 9.7l sur le trajet pour aller au boulot (12 bornes de collines, 45km/h de moyenne parking compris)
- 7.5l de moyenne en montagne à 80km/h de moyenne
- Un moteur froid ca consomme à mort (cf ci dessus)
- Un diesel "moderne" en sous régime ca consomme à mort (et plus l'EGR s'encrasse plus ca consomme)
- Un passage de 205/16/55 en 225/17/45 rajoute 0.5l au 100
- La rapidité pour passer de 0 à 100 ne change pas grand chose à la conso sur un plein
- Entre 110km/h et 180km/h y'a 2l/100 de différence (la c'est du calculateur)
- Tu ne veux pas savoir ta consommation ni l'usure des pneus quand tu poses ta voiture sur circuit.
Bref évidement une voiture riquiqui récente avec un moteur tout aussi riquiqui consomme moins. Mais 3L/100 en condition réelles faut pas trop se toucher non plus. Reste à alléger les voitures et revenir à des tailles de montes moins ridicules pour faire tomber la conso facilement.
Note: une impreza STI à froid c'est dans les 17l/100; tout comme une alpha GT dans les bouchons de l'A8 :-/ Mais bordel qu'est ce que c'est bon à conduire en montagne^w^wsur circuit.
Ma critique c'est que tu as des objectifs de sécurité et dans hasard je vois pas mal de PRNG qui ne sont clairement fait que pour les simulations... Bref pour le moment ça ne sert pas a grand chose. Si ce n'est au pire de faire croire a une utilisateur qu'il peut utiliser ces générateurs de manière sure.
Et bien évidement pour tes objectifs GSL t'es totalement inutile. Pour le côté simulation il y a déjà des lib qui sont reconnues et auditées donc pas trop de besoins (sauf pour les générateurs parallèle).
Après il faut voir si il y a vraiment un besoin pour les CSPRNG et se borner a ça. Mais la il vaut mieux avoir du manpower compétent en cryptographie. Peux tu prouver que la façon dont tu initialises les PRNG ne les affaibli pas (théoriquement et implémentation) ? La faille d'OpenSSL^wDebian c'était une ligne commentée d'un code fait par des experts et modifiée par un maintainer...
Oui mais la ta simulation va prendre 1 mois au lieu d'une heure. C'est tout l'intérêt des différents PNRG et de leur propriétés: être très rapide en répondant aux spécifications. Les simulations reposant sur des PRNG consomment des volumes énormes de nombre aléatoires.
Cela dit tu n'as jamais fait de dd avec /dev/random comme source apparemment. Autrement tu saurais comment il se comporte quand le noyau est a cours d'entropie :-)
Ici on mélange tout et n'importe quoi comme déjà dit, et c'est dangereux.
Il faut différencier les CSPRNG des PRNG. Initialiser correctement un PRNG on s'en fou puisqu'on peut assez facilement trouver l'état interne, et donc tout les états suivants, du générateur à partir de sa sortie. De mémoire pour un mersenne twister c'est dans les 8Ko.
Au passage si quelqu'un à des références sur des PRNG parallèles (voir une jolie implémentation en java) ça m'intéresse. J'ai pas réussi a mettre la main sur des versions distribuées (sans contention après l'initialisation) et prouvées. La ce serait une contribution intéressante.
Les ACL sont tes amis, voir man acl/setfacl.
La partie intéressante est: " 1. The new object inherits the default ACL of the containing directory as its access ACL.".
Cela dit il faut aussi prendre en compte que la nature à horreur du vide.
Avoir les queues pleines ne signifie pas que l'on fait quelque chose d'utile. Il y a de la puissance on s'en sert. Plus c'est facile à utiliser et plus on charge le bouzin :-)
Posté par ckyl .
En réponse au journal Fedora@home.
Évalué à 1.
> Il n'ya pas que les grosses boites qui ont besoin de faire des simulations
Fournir un gros cluster totalement compatible, pour ce type d'entreprise est un argument décisif. Leurs garantir qu'ils auront accès à un cluster gratuitement, si ils se mettent à leurs distributions est un très bon argument dans la balance
Bref tu te contredis
> Néanmoins, pour le calcul des prévisions météo par exemple ce n'est pas un secret de polichinelle à première abord
Comment crois tu qu'ils vivent ? Si il n'y a que GFS pour fournir les sorties des runs, la methodologie et l'implementation il y a une raison.
Il y a aussi un problème de confiance. Quelle confiance as tu dans des calculs s'exécutant en environnement hostile ? Si tu fais un calcul c'est que ton activité dépend de son résultat.
> Prend l'exemple de la Grid community
Tu nous parlais d'entreprises.
> l'avenir est dans les calculs/traitement distribués. qu'on le veuille ou pas
C'est mon métier, merci. Pour les gens qui en ont besoin c'est aussi le passé et le présent.
Posté par ckyl .
En réponse au journal Fedora@home.
Évalué à 4.
Je connais aucune entreprise prête à laisser son code s'exécuter sur des machines non contrôlées. Rien que mixer les ressources de plusieurs départements ou utiliser les ressources de calcul d'un prestataire posent de gros problèmes.
On a voulu voir ce que ca donnait quand on allait jouer sur le terrain des autres. Implémentation des kernels NAS sur notre middleware faite par des stagiaires, c'est clairement en notre défaveur côté optimisation. Y'a un papier qui passe à IPDPS en mai avec les résultats. Grosso modo on est devant pour IS et pour FT on obtient les même perfs.
La majorité des applications qui tournent sur EGEE sont non communicantes. Des millier de job batch indépendants.
Vous pouvez vous battre autant que vous voulez vous avez tout les deux raisons. Pour le calcul numérique pur MPI va très vite. C'est un peu l'ASM du calcul parallèle. C'est merdique à utiliser, c'est vieux, c'est moche mais ca bastonne si c'est utilisé a bon escient. Pour toutes les applis ou on peut un minimum découper les données les grilles sont un bien meilleur investissement.
En ce qui concerne le calcul brute mono core, la techno on s'en fou, on a des benchs java ou on est devant du fortran...
Il y a des besoins pour les deux approches, le public n'est pas le même.
Bref chacun voit le monde selon dans quoi il travaille...
L'année prochaine on devrait pouvoir faire le 5000 ! À noter que ce ne sont pas des super calculateurs mais des ensemble de clusters. Il y a aussi la couche réseau à gérer.
Le problème est de faire scaler des applications parallèles fortement communicantes avec point de synchro. L'idée de nos jours c'est de réduire au maximum les communications et le partage de données (cf map/reduce, les architectures space based ou REST). Mais ce n'est pas applicable dans tout les cas.
Au fait, des applications sur 3000+ cores on le fait en java et ça tourne plutôt bien :-)
Une transmission 4x4 c'est marrant à conduire quand c'est pas monté sur ce que les parisiens appellent un 4x4. Ca consomme un poil plus, comme les BVA, et faut changer les 4 pneus en même temps.
Par contre ca permet des s'amuser en montagne par grand soleil, pluie ou neige. Tu chaines jamais et tu peux même regarder par la fenetre passager en courbe.
Merci aux ecolo-bobo de nous permettre d'acheter des vraies voitures aux prix des scenics turbomazout :-)
Cela dit la plupart des "4x4" ou SUV ne sont pas en transmission intégrale permanente.
Il y a beaucoup de cas ou tu peux faire du ménage dans ta mémoire. Par exemple tu peux maintenir un cache d'objet le plus gros possible et quand tu arrives au bout de la mémoire, ou une itération du GC, tu fais le ménage selon une politique donnée. Dans les cas simple tu utilises des weak references et autrement tu le fais a la main.
De même utiliser les assert pour vérifier les paramètres publiques est une erreur. Premièrement les assertions peuvent être activées ou... désactivées. Deuxièment dans beaucoup de langages il y a un contrat pour les méthode publiques qui est qu'elles doivent vérifier leurs arguments et remonter à l'appelant un exception bien définie si il n'est pas satisfait. Enfin terminer brutalement un thread, c'est ne pas permettre aux fonctions appelantes de faire le ménage pour se retrouver dans un état consistant.
[^] # Re: et le jre ?
Posté par ckyl . En réponse à la dépêche OpenJDK 6 passe le TCK. Évalué à 5.
Y'a eu une présentation assez intéressante à javaOne cette année sur comment combiner communauté open Source et développement drivé par une entreprise:
http://developers.sun.com/learning/javaoneonline/2008/pdf/TS(...)
(désolé il est tôt j'ai cliqué sur inutile au lieu de pertinent)
[^] # Re: et le jre ?
Posté par ckyl . En réponse à la dépêche OpenJDK 6 passe le TCK. Évalué à 1.
Sauf clause spéciale dans ton contrat, tu n'as pas ton mot à dire sur le code produit dans le cadre de ton travail. Et même un peu plus... Si tu bosses sur un logiciel de CAO et que tu fais un autre logiciel de CAO sur ton temps libre qui pourrait concurrencer le premier attends toi à recevoir une lettre du service juridique. De même que si tu bosses pour un projet sous GPL et que tu y contribues le WE attends toi à ce que le copyright de ce code revienne tout de même à l'employeur.
[^] # Re: et le jre ?
Posté par ckyl . En réponse à la dépêche OpenJDK 6 passe le TCK. Évalué à 10.
Le modèle économique de Qt/MySQL est l'un des plus honnête et rationnel. Ta boite investie pour faire du logiciel libre, si la GPLte convient c'est tout bénef pour toi. Si tu veux faire du proprio tu casques une licence proprio. Et ca, ca n'est faisable que si tu gardes le copyright sur l´ensemble de la base du code.
Maintenant si MySQL/Qt change d'avis et décide de passer en proprio, il te reste les anciennes versions libres. À la communauté du LL de reprendre le bébé. Jusque ici elle avait tout eu gratis
La cession du copyright ce n'est pas fait par plaisir, c'est qu'autrement ta boite perd la possibilité de se retourner (un projet bloqué en GPLv2 seulement par exemple). Et même quand tu as la main sur toute la base du code, opensourcer ou changer de licence relève du parcours du combattant.
Investi plusieurs années de ta vie et de ton pognon pour créer une boite et tu changeras peut être d'avis. Si la FSF ou la fondation Apache demande la cession de copyright ce n'est pas pour rien ! KDE l'a compris dans la douleur.
Ca me tue les mecs a qui on donne des choses et qui trouvent encore le moyen de gueuler ! Tu peux forker Java si tu ne veux pas contribuer mainstream et garder ton copyright.
Mais tu sais, dans la vraie vie sur les projets importants, les contributeurs externes sont rares. Mysql table sur 6 patchs externes cette année. OpenOffice y'a pas plus de 10 commiters externes etc. Alors la communauté est plutôt gagnante dans le deal.
Toi qui ne manque pas de tout critiquer. Qu'à tu fais pour le LL aujourd'hui (et hier) ? Certains tentent de faire avancer les choses, même si on pourrait mieux faire, d'autres font la morale sur les forums. Tu es de quel coté ?
[^] # Re: Bof
Posté par ckyl . En réponse à la dépêche OpenJDK 6 passe le TCK. Évalué à 7.
Je prends une vision pragmatique de développeur/chef de projet. Tu as un choix a faire maintenant tu fais quoi ? (il n'y a pas de réponse unique)
Cela dit dans facilité tu as aussi la notion de maturité des frameworks. Récemment j'ai voulu faire un bot IRC pour générer des flux RSS/mail (il mange aussi des connexions Telnet et récupéré des metadata sur des sites comme youtube). Je me suis donné le choix entre Ruby et Python. Mais après avoir comparé les docs/examples des modules dans les différents langages je me finalement suis rabattu sur Java alors que j'aurais bien scripté... Moins de 500 lignes au final.
D'un point de vue encore plus personnel, je me fou de la soit disant "beauté" du langage. Si j'écris 5 lignes de code au lieu de 10 je suis content. Mais ce qui m'importe le plus c'est de pouvoir faire les choses (outils, libs etc.), comprendre aisément du code de quelqu'un d'autre, avoir une base de code maintenable sur la durée, quand je code un lib avoir des utilisateurs potentiels et ne pas sortir mon soft 3 ans après avoir épuisé les crédits.
Et par pitié n'assimile pas une techno a quelques uns de ses utilisateurs: "si y'a encore beaucoup de gens qui savent ce que c'est qu'un algo en java". Y'a un marché de dev Java important. Ca draine les déchets, c'est évident. Mais je pense pas régresser mentalement lorsque je passe du C au Java. Tout comme il serait bon de ne pas traiter d'imbéciles les mecs d'Apache, de Sun ou qui font des archis comme Yahoo, Ebay ou LinkedIn.
Dans l'informatique pro y'a 70% de boulets, faut bien qu'ils utilisent quelque chose. Tu n'y changeras rien (et ils ont une petite chance de faire moins de mal en Java qu'en C ou C++ :-) )
[^] # Re: Bof
Posté par ckyl . En réponse à la dépêche OpenJDK 6 passe le TCK. Évalué à 10.
Tu remplaces Java par J2EE et je suis d'accord avec toi :-) Souvent quand on parle de Java le gens pensent J2EE ou Java 1.2. Depuis ca a un peu évolué dans le bon sens tant en perf qu'en fonctionalités.
> Quelles sont les qualités de java
Facile à utiliser, lib standard assez complète, bon écosystème, portabilité aisée. En général tu fais facilement ce que tu veux. Tu passes plus de temps à faire des choses fun que réinventer la roue en général.
Ce n'est pas LA solution, et je n'irais pas l'utiliser pour n'importe quoi.
> Qu'est qui fait que java est robuste ?
Java n'est pas "robuste". Mais d'expérience entre un programme écrit en C (voir commentaire de GPL) et un programme dans un langage de plus haut niveau, j'ai mon idée sur celui ou tu passes plus de temps à avoir un truc qui marche correctement (conception + debug). On parle de base de 50k à 1M de lignes de code hein, pas de projet du dimanche.
> des langages qui nous donnent des assurances sur les types par exemple (ocaml, haskell), ou qui font du distribué vraiment pas cher (erlang).
Par ce que malheureusement ce sont des langages difficilement accessibles et à l'écosysteme assez faible (les deux sont liés). Si tu veux être viable à long terme il faut pouvoir attirer des gens et autant que possible faire le moins de travail toi même.
Attention je n'ai jamais dit que Java c'était LE truc génial et inégalé. C'est un outil adapté à certains problèmes qui a l'avantage d'être mainstream (et avec OpenJDK on peut espérer voir des gens du LL débarquer).
Même si tu ne veux pas faire de Java, réjouis toi de l'ouverture de Hotspot. Ca doit juste être un des bouts de code les mieux optimisés au monde. Il y a aussi pas mal de projet réutiliser la JVM, et ses perfs, pour d'autre langage (ca fait un .Net portable).
Après si quelqu'un veut discuter technique je pense avoir le background C et Java pour apporter quelques réponses sur les perfs etc.
[^] # Re: Bof
Posté par ckyl . En réponse à la dépêche OpenJDK 6 passe le TCK. Évalué à 6.
Quand tu utilises de la bonne facon les bonne technos, le coût runtime est infime par rapport au gain de robustesse et de productivité. Par contre aucun langage n'empêche les mauvais codeurs/architectes de pondre des bouzes. D'ailleurs tu peux me donner des pointeurs sur tes contributions d'exceptions au logiciel libre ?
Exercice supplémentaire: Regarder comment fonctionnent les JVM. Comparer l'assembleur produit par gcc et hotspot.
[^] # Re: Pas de VFS
Posté par ckyl . En réponse au journal Monter un partage Samba sous Linux sans utiliser *VFS. Évalué à 1.
[^] # Re: Autre approche
Posté par ckyl . En réponse au journal Le deuxième poste de dépense des Français...... Évalué à 2.
Bosser avec des gens te fait apprendre beaucoup. Rencontrer des clients/whatever te permet de mieux comprendre ton écosystème et découvrir de nouveaux problèmes. Manger/aller a la machine a café avec tes collègues te permet de mieux les comprendre. Et tu peux même y prendre des décisions au lieu de faire du metawork en meeting. Ca te permet aussi de rencontrer des gens (que ce soit ton voisin de cubicle, la dernière stagiaire de la compta ou l'équipe de squash). La vie réelle c'est ca et ca te permet d'évoluer. Si tu préfères t'enfermer chez toi... Mais pour moi le télétravail non merci ! J'ai d'ailleurs fait la même réponse à une boite qui voulait me débaucher en télétravail.
Autrement on dirait que vous vous servez de votre caisse que pour aller au taf ! Perso c'est clairement pas aller bosser qui me coute le plus cher (en plus ca passe en frais réels). A vue de nez:
- 6000 kms/an pour aller au boulot
- 12000 kms/an pour une saison de ski
- 10000 kms/an pour une saison de DH
- 2000 kms/an en sorties sur la région
- Plus quelques broutilles pour les vacances, courses etc.
[^] # Re: Pas de VFS
Posté par ckyl . En réponse au journal Monter un partage Samba sous Linux sans utiliser *VFS. Évalué à 1.
Typiquement si tu me donnes la possibilité de monter un glusterfs et/ou un hadoop DFS sous linux/mac/windows je serais très content ! J'ai pas suffisamment de temps pour faire le portage windows.
[^] # Re: Pas de VFS
Posté par ckyl . En réponse au journal Monter un partage Samba sous Linux sans utiliser *VFS. Évalué à 0.
Par ce que si tu ne fais pas que du linux tu l'as dans l'os ? Typiquement fuse et un de ses modules répondaient fonctionellement à nos besoins mais on devait supporter des machines linux et windows.
Du coup on à un beau NFS sur un NAS qui va ramer du cul au lieu d'un joli système de fichier distribué pour les données temporaires plus un SAN pour le stockage permanent.
[^] # Re: ---------
Posté par ckyl . En réponse au journal Le pétrole, quelle salauperie !. Évalué à 3.
Avion: Chiffres réels
Pour exemple sur ma caisse, routière avec quelques poneys turbo mazout, données constructeurs: 4.6l, 5,9l et 8,2l. Quelques observations après 90000 bornes, volumes mesurés et non issus du calculateur:
- 9.7l sur le trajet pour aller au boulot (12 bornes de collines, 45km/h de moyenne parking compris)
- 7.5l de moyenne en montagne à 80km/h de moyenne
- Un moteur froid ca consomme à mort (cf ci dessus)
- Un diesel "moderne" en sous régime ca consomme à mort (et plus l'EGR s'encrasse plus ca consomme)
- Un passage de 205/16/55 en 225/17/45 rajoute 0.5l au 100
- La rapidité pour passer de 0 à 100 ne change pas grand chose à la conso sur un plein
- Entre 110km/h et 180km/h y'a 2l/100 de différence (la c'est du calculateur)
- Tu ne veux pas savoir ta consommation ni l'usure des pneus quand tu poses ta voiture sur circuit.
Bref évidement une voiture riquiqui récente avec un moteur tout aussi riquiqui consomme moins. Mais 3L/100 en condition réelles faut pas trop se toucher non plus. Reste à alléger les voitures et revenir à des tailles de montes moins ridicules pour faire tomber la conso facilement.
Note: une impreza STI à froid c'est dans les 17l/100; tout comme une alpha GT dans les bouchons de l'A8 :-/ Mais bordel qu'est ce que c'est bon à conduire en montagne^w^wsur circuit.
[^] # Re: initialisation
Posté par ckyl . En réponse au journal Sortie de la bibliothèque Hasard version 0.2. Évalué à 4.
Et bien évidement pour tes objectifs GSL t'es totalement inutile. Pour le côté simulation il y a déjà des lib qui sont reconnues et auditées donc pas trop de besoins (sauf pour les générateurs parallèle).
Après il faut voir si il y a vraiment un besoin pour les CSPRNG et se borner a ça. Mais la il vaut mieux avoir du manpower compétent en cryptographie. Peux tu prouver que la façon dont tu initialises les PRNG ne les affaibli pas (théoriquement et implémentation) ? La faille d'OpenSSL^wDebian c'était une ligne commentée d'un code fait par des experts et modifiée par un maintainer...
[^] # Re: GSL est vraiment pas mal
Posté par ckyl . En réponse au journal Sortie de la bibliothèque Hasard version 0.2. Évalué à 2.
Cela dit tu n'as jamais fait de dd avec /dev/random comme source apparemment. Autrement tu saurais comment il se comporte quand le noyau est a cours d'entropie :-)
[^] # Re: initialisation
Posté par ckyl . En réponse au journal Sortie de la bibliothèque Hasard version 0.2. Évalué à 3.
Il faut différencier les CSPRNG des PRNG. Initialiser correctement un PRNG on s'en fou puisqu'on peut assez facilement trouver l'état interne, et donc tout les états suivants, du générateur à partir de sa sortie. De mémoire pour un mersenne twister c'est dans les 8Ko.
Au passage si quelqu'un à des références sur des PRNG parallèles (voir une jolie implémentation en java) ça m'intéresse. J'ai pas réussi a mettre la main sur des versions distribuées (sans contention après l'initialisation) et prouvées. La ce serait une contribution intéressante.
[^] # Re: Bonne idée
Posté par ckyl . En réponse au journal Peerfuse, filesystem distribué. Évalué à 3.
La partie intéressante est: " 1. The new object inherits the default ACL of the containing directory as its access ACL.".
[^] # Re: bilan écologique : extrémement positif
Posté par ckyl . En réponse au journal Top500 : La rétrospective des 15 ans.. Évalué à 2.
Avoir les queues pleines ne signifie pas que l'on fait quelque chose d'utile. Il y a de la puissance on s'en sert. Plus c'est facile à utiliser et plus on charge le bouzin :-)
[^] # Re: Peut être une explication
Posté par ckyl . En réponse au journal Fedora@home. Évalué à 1.
Fournir un gros cluster totalement compatible, pour ce type d'entreprise est un argument décisif. Leurs garantir qu'ils auront accès à un cluster gratuitement, si ils se mettent à leurs distributions est un très bon argument dans la balance
Bref tu te contredis
> Néanmoins, pour le calcul des prévisions météo par exemple ce n'est pas un secret de polichinelle à première abord
Comment crois tu qu'ils vivent ? Si il n'y a que GFS pour fournir les sorties des runs, la methodologie et l'implementation il y a une raison.
Il y a aussi un problème de confiance. Quelle confiance as tu dans des calculs s'exécutant en environnement hostile ? Si tu fais un calcul c'est que ton activité dépend de son résultat.
> Prend l'exemple de la Grid community
Tu nous parlais d'entreprises.
> l'avenir est dans les calculs/traitement distribués. qu'on le veuille ou pas
C'est mon métier, merci. Pour les gens qui en ont besoin c'est aussi le passé et le présent.
[^] # Re: Peut être une explication
Posté par ckyl . En réponse au journal Fedora@home. Évalué à 2.
Les simulations sont importantes. Alors ajoute a ca une pile de procédures bien lourdes et le service juridique....
[^] # Re: Peut être une explication
Posté par ckyl . En réponse au journal Fedora@home. Évalué à 4.
[^] # Re: Cray
Posté par ckyl . En réponse au journal Top500 : La rétrospective des 15 ans.. Évalué à 2.
On a voulu voir ce que ca donnait quand on allait jouer sur le terrain des autres. Implémentation des kernels NAS sur notre middleware faite par des stagiaires, c'est clairement en notre défaveur côté optimisation. Y'a un papier qui passe à IPDPS en mai avec les résultats. Grosso modo on est devant pour IS et pour FT on obtient les même perfs.
[^] # Re: Cray
Posté par ckyl . En réponse au journal Top500 : La rétrospective des 15 ans.. Évalué à 3.
Vous pouvez vous battre autant que vous voulez vous avez tout les deux raisons. Pour le calcul numérique pur MPI va très vite. C'est un peu l'ASM du calcul parallèle. C'est merdique à utiliser, c'est vieux, c'est moche mais ca bastonne si c'est utilisé a bon escient. Pour toutes les applis ou on peut un minimum découper les données les grilles sont un bien meilleur investissement.
En ce qui concerne le calcul brute mono core, la techno on s'en fou, on a des benchs java ou on est devant du fortran...
Il y a des besoins pour les deux approches, le public n'est pas le même.
Bref chacun voit le monde selon dans quoi il travaille...
[^] # Re: Cray
Posté par ckyl . En réponse au journal Top500 : La rétrospective des 15 ans.. Évalué à 3.
Le problème est de faire scaler des applications parallèles fortement communicantes avec point de synchro. L'idée de nos jours c'est de réduire au maximum les communications et le partage de données (cf map/reduce, les architectures space based ou REST). Mais ce n'est pas applicable dans tout les cas.
Au fait, des applications sur 3000+ cores on le fait en java et ça tourne plutôt bien :-)
# Non !
Posté par ckyl . En réponse au journal Ror ne se porte plus très bien ? Quid des autres ?. Évalué à 1.
Non
http://qcon.infoq.com/sanfrancisco/tracks/show_track.jsp?tra(...)
http://jxh.bingodisk.com/bingo/public/presentations/JHoffman(...)
etc.
[^] # Re: idiot
Posté par ckyl . En réponse au journal Informatique durable. Évalué à 1.
Par contre ca permet des s'amuser en montagne par grand soleil, pluie ou neige. Tu chaines jamais et tu peux même regarder par la fenetre passager en courbe.
Merci aux ecolo-bobo de nous permettre d'acheter des vraies voitures aux prix des scenics turbomazout :-)
Cela dit la plupart des "4x4" ou SUV ne sont pas en transmission intégrale permanente.
[^] # Re: Vive les exceptions !
Posté par ckyl . En réponse au journal Qu'est-ce que bien gérer les erreurs dans ses programmes ?. Évalué à 2.
De même utiliser les assert pour vérifier les paramètres publiques est une erreur. Premièrement les assertions peuvent être activées ou... désactivées. Deuxièment dans beaucoup de langages il y a un contrat pour les méthode publiques qui est qu'elles doivent vérifier leurs arguments et remonter à l'appelant un exception bien définie si il n'est pas satisfait. Enfin terminer brutalement un thread, c'est ne pas permettre aux fonctions appelantes de faire le ménage pour se retrouver dans un état consistant.