> Et puis 100 000 dollars, bien que ça soit intéressant pour le projet Apache, ça ne représente rien pour Microsoft.
100 000 dollars c'est l'équivalent d'un ingénieur par an.
Ce que fera l'ASF de ce pognon ca les regardes et je me fais pas trop de soucis, ce sont des grands garcons qui font des choses concrètes au lieu de se masturber sur les ML. Les projets sont autonomes dans Apache, donc je ne vois pas comment ce pognon pourrait changer quoi que ce soit.
> C'est vraiment n'importe quoi ce papier. C'est à croire que tout réinventer sans arrêt est quelque chose de désirable.
Pour commencer, l'avis d'un mec qui est l'auteur (entre autre) de: Unix, Plan 9, UTF-8, Inferno, et le premier système de fenêtrage pour Unix pourrait recevoir un poil plus de respect. Si il avait suivit ton raisonnement il y a 30 ans tu ferais quoi maintenant ?
Donc d'après toi on reste à Unix pour les 50 années à venir ?
> Je dis simplement que pour des gros codes coté serveur, comme ceux pour ebay ou yahoo, avoir un java compilé serait tout aussi bien.
> Ils gagneraient en performance
Java est compilé... Seulement la compilation se fait en JIT (et peut avoir lieu plusieurs fois selon les besoins). Fait tourner tes applis avec l'option "-Xint" (mode interprété) pour voir ce que ca donne quand le code n'est pas compilé. A partir des nightly build de Sun tu peux même utiliser "-XX:+PrintOptoAssembly" pour récupérer le code assembleur produit par HotSpot. Tu peux t'amuser a comparé le binaire produit par Hotspot et pas GCC sur du code équivalent c'est assez intéressant.
A priori, le faire en JIT te permet en plus de compiler pour un CPU précis, en ayant des informations sur les prédictions de branches etc.
Tu as des preuves de ce que tu avances ou juste des lieux communs ?
> de la compatibilité binaire inter-plateforme qui marche d'ailleurs plus ou moins bien
Gni ? Tu peux développer ?
> Par ailleurs, les boites que tu donnes n'ont certainement pas un serveur en frontal mais toute une ferme.
Si tu savais :-)
D'ailleurs sur les gros sites la scalabilité est de loin plus importante que la performance. Mais on y pense tout de même.
Mais concrètement pour des sites web tu as le choix entre: PHP, Perl, Python, Ruby, Java, .Net. Et on ose parler des perfs de Java.... C'est encore plus marrant quand on voit la différence de perf entre Ruby et JRuby.
> Or je ne suis pas sur que cela soit une très bonne idée d'un point de vue sécurité et performance d'avoir du code binairement portable. Pour un serveur, autant recompiler son code...
Va falloir expliquer ca à des petites startups tel que yahoo, ebay, linked-in, amazon ou orbitz avant que leurs sites grossissent et qu'ils aient des problèmes.
Autant J2EE est une bouze, autant une utilisation rationnelle de Java marche plutôt bien.
> Gni ? En quoi un développeur qui possède les compétences ne peut rejoindre la liste des developpeurs core de PHP, Ruby, Python, Perl, etc et participer aux décisions ?
Si tu es compétent tu peux aussi postuler chez Microsoft et participer aux décisions :-)
> En tant que langage de programmation, Java est très bien supporté par gcj. Ce qui pêche au niveau du libre, ce sont les bibliothèques et la vm. gcj+gnu classpath peine franchement à faire tourner des exemples basiques en java 5.0.
En meme temps c'est 100% la faute des implémentations libres !
Tu peux contribuer à l'évolution du langage, de la VM et de la bibliothèque standard par le biais du JCP. En général les implémentations libres arrivent même à avoir accès au TCK gratos. Les JSR ressemblent beaucoup aux groupes de travail de l'IETF.
Après si GNU arrive 10 ans après la bataille et sans les moyens humains pour faire le boulot. Bin c'est de la faute de GNU. Si tu veux une implémentation libre tu bosses dessus...
Pour .Net le problème est différent puisqu'il n'y a pas d'équivalent du JCP à ma connaissance (et ce n'est pas dans la culture Microsoft). Mais pour C# c'est exactement le même problème qu'avec C, C++ or fortran. On implémente à partir des specs .|
Tu pourras bidouiller du hardware d'ici quelques mois. Les portables Dell sont d'incroyablement mauvaise qualité (clavier, charnière ecran, prise de jeu générale, écran vraiment bof).
Quand tu as un remplacement à J+1 c'est pas important. Pour un laptop perso... Les laptop Dell c'est vraiment du jetable, moche et lourd.
> En XML il faut toujours ecrire le parseur, ici rien a faire !
Autant je suis d'accord avec toi pour le reste. Autant cette affirmation est fausse. Tu as au moins une dizaine d'implémentations qui te font le mapping automatique XML vers langage Objet (idem pour les DB). Pour les perfs c'est autre chose.
Les deux solutions semblent complémentaires. XML beaucoup plus généraliste et puissant. Protocol Buffer offre beaucoup moins de fonctionalités qu'XML puisqu'il cible mieux ses utilisateurs potentiels. Il est donc plus concis et rapide en déportant les traitements possibles en XML de la lib vers le code utilisateur.
C'est une bonne chose d'avoir une nouvelle alternative puisque la plupart des gens utilisent du XML pour tuer une mouche. Et donc la valeur ajouté par forcement significative.
> Et dire qu'on se plaignait de le lourdeur d'Emacs...
Effectivement. Encore plus que la lourdeur c'est surtout qu'eclipse est pas du tout conçu pour fonctionner avec des fichiers seuls (pas de projet).
Un bon éditeur XML ca serait pas du luxe, quand je vois le nombre de mecs qui éditent du XML avec vim et se tapent 25 essais d'exécution alors qu'un éditeur validant permet de régler le truc en 5 secondes.
> Pour le XPath qui est plus parlant, ça dépend vraiment des gens.
Tu peux faire des trucs bien moches avec toutes les technos.
Reste que six mois après tu comprends encore assez facilement ce que l'expression suivante fait.
my $nodeset = $job_xml->find('//*/child/child[statu=\'REGRESSION\']/className/text()');
foreach my $node ($nodeset->get_nodelist) {
print "\t", "NEW ", XML::XPath::XMLParser::as_string($node), "\n";
}
Si tu peux formater en CSV; alors CSV ou XML sont plus ou moins équivalents. Cela dit il est plus facile de rajouter des attributs ou des éléments à un fichier XML en gardant tes outils qu'en CSV. De même tu peux représenter beaucoup plus de concept. Bref tout est question de dosage en fonction des objectifs et contraintes que tu as.
Eclipse marche vraiment pas mal. Que ce soit pour l'édition de XSD ou de fichier plus classiques.
Le problème c'est que beaucoup de gens semblent utiliser XML pour stocker trois valeurs qui serait tout aussi bien en CSV.
L'interet d'XML c'est les outils qu'il y a autour et qu'ils sont facile à modifier. Pas de parser a réinventer, XPath, XQuery, XSLT, Xinclude, pas mal d'API pour la serialization automatique etc. C'est pas parfait mais ca fait gagner un temps fou de développement et pour faire évoluer les fichiers. Pour des fichiers de conf c'est plus douteux, mais au moins ca permet d'avoir une complétion "universelle".
Par contre si c'est pour faire communiquer deux processus proprio avec des contraintes de performance alors ca vaut peut être le coût de réinventer la roue. Et c'est la que se place "Protocol Buffers".
Récemment j'ai fait des stats sur les résultats des test unitaires et fonctionnels des 10 000 derniers builds d'un projet. Chaque résultat d'un build est stocké dans un ou plusieurs fichier XML, et le schema a évolué 3/4 fois. Apres 10 minutes d'XSLT j'avais tout reformaté en un gros fichier CSV, uploadé ca sur un cluster Hadoop DFS et commencé a sortir des stats avec Pig.
Je n'ai réinventé aucun outil. Du logiciel qui pond le fichier, à celui qui le transforme. Et une expression XPath reste toujours plus parlante qu'une série de grep | cut | awk | cut | sort | uniq. Et franchement, y'a plus intéressant à faire que de la manipulation de fichier dans l'informatique !
> non merci, c'est suffisamment écœurant, et j'ai pas envie de faire partie des "gens" qui ont fait en sorte que l'histoire se répète.
Tu ne fais pas parti des gens qui font l'histoire tout cours. Juste des pleureurs de l'internet.
Hormis cracher sur tout le monde sur linuxfr tu fais quoi ? Je réitère mon invitation du thread sur OpenJDK 6 à nous montrer tes contributions sous licence GPL. Après t'être permis de dénigrer tant de monde, la moindre des choses serait d'avoir des choses à montrer. Et ca n'excuserait en rien ton comportement. Allez, avec un peu de chance t'es même sur PACA comme ca tu pourras me les montrer en vrai.
Tu es le bienvenu, mais essayes, ici du moins, de perdre les mauvaises habitudes qui font loi chez MS.
LOL PTDR
https://linuxfr.org/~Sam_from_MS/ regarde bien la date de création du compte et tu peux aussi voir l'historique des trolls journaux. Sont marrants ces jeunes quand même !
En général quand une boite choisie un modèle de double licence c'est pour ne pas qu'une boite concurrente puisse faire la même chose; les forcer à passer par toi. En gros tu veux éviter qu'un intégrateur se fasse le pognon tout seul alors que c'est toi qui développe.
Si ton business model ne prévoit pas ça, alors soit une simple GPL suffit soit tu fais du LGPL/BSD.
J'ai choisi cet exemple au hasard pour montrer que l'écosystème d'un langage est aussi très important. Clairement Perl n'a rien à prouver de ce point de vue là.
Une migration de VCS c'est ultra couteux en temps. Là l'avantage c'est qu'on ne change rien pour les devs qui n'ont pas à se soucier des branches. Bref actuellement tout le monde est content de la solution.
Et effectivement l'intégration de git dans eclipse/netbeans/idea actuellement c'est vraiment pas ça. C'est de toute façon un facteur bloquant pour migrer.
"svn merge" ne sait merger que des commits sans se souvenir si ils ont déjà été mergé ou non. C'est une commande qui ne devrait pas être destiné à l'utilisateur final.
svnmerge.py on l'a testé pendant un bon moment. Ca marche pas mal pour garder des branches tirées du trunk à jour. Par contre pour merger une branche de devel dans le trunk en fin de développement il est très souvent à l'ouest (sans compter que svnmerge demande pas mal d'itérations pénibles). En gros sur une vingtaine d'intégrations de branche il en a réussi une seule parfaitement. Je ne compte pas les branches ou il y a des déplacement de fichiers, la ca ne peut pas marcher.
Pour le diff/patch à la main pour intégrer une branche, ca va souvent plus vite quand tu vois que svnmerge commence à perdre les pédales si tu n'as pas de solutions de secour.
Pour ce qui est de SVK non je n'ai pas testé. git-svn répond totalement à mon besoin:
1- Les utilisateurs/développeurs lambda peuvent toujours utiliser SVN et tout les outils liés. On ne veut pas d'un VCS distribué.
2- Je travaille quotidiennement avec une dizaine de branches. Avoir 10 working copies est compliqué à gérer . Il doit y avoir bijection working copy <=> projet dans l'IDE. Quand tu créer/ferme des branches plusieurs fois par semaine la manipulation commence à être lourde. C'est aussi consommateur d'espace. 10x377Mo pour SVN contre 1x397Mo pout git-svn !
3- J'ai le confort d'avoir des branches privées si nécessaire. Il est très facile d'exporter une branche privée sur le serveur SVN si un autre développeur à besoin de ma branche.
4- Le mapping branche SVN vers branche git est trivial. Ainsi quand svnmerge.py s'est vautré merger une branche c'est: git co -b SVN_remotebranch remotebranch ; git co master ; git merge SVN_remotebranch. Je n'ai jamais vu git-svn se planter.
Note que je n'utilise pas git et je ne vois pas d'intérêt aux DVCS sauf cas particuliers. Mes critiques contre svn/svnmerge viennent de mon expérience.
Cette semaine j'ai encore mergé cinq branches vers le trunk, veilles de 2 semaines à 6 mois. Peut être que chez vous ca marche, mais pour moi non. Et dans tout les cas, svnmerge ne peut pas marcher si tu déplaces un fichier.
Bref j'étais pas convaincu il y a six mois. Mais maintenant je checkout directement via git-svn tout les projets.
> Suivi des opérations de Merge (merge tracking) (implémentation non complète)
J'ai pas encore testé la 1.5 mais c'est une très mauvaise nouvelle.
C'est LA lacune de SVN. Impossible de gérer des branches, ca foire à chaque fois et on fini par faire un diff/patch à la main.
La seule façon de merger des branches sur un serveur subversion que j'ai trouvé c'est d'utiliser git-svn (qui envoi du paté)...
Mina est 100x overkill mais j'avais envie de jouer avec. Si utiliser des libs c'est du bloat...
> la résitance au changement (utiliser java plutôt qu'un langage que je suppose moins connu).
C'est con c'était le but et j'ai tout de même écrit une version python.
> Après si tu préfère maintenir un truc de 5000 lignes de code plutot qu'un truc de 500
Ca fait 500 lignes de code pour prendre ses entrées sur X chan IRC, telnet et parser régulièrement l'output XML du serveur d'intégration continue; dispatcher ces infos sur différents planet en fonction de la config chaque planet poussant les infos sur des flux RSS ou sur IRC.
> Mais je vois pas la portée de l'argument
Mon argument c'est qu'un langage a beau être 10x mieux sur le papier si les libs autour ne suivent pas, alors ce n'est pas un bon choix. Il faut que les libs soit nombreuses, de bonne qualité et bien documentées.
> utiliser des langages plus "ésotériques" permet de faire à priori un tri extrémement rapide sur les candidats
Non. Ca te fais prendre des universitaires qui n'y connaissent pas forcément grand chose en ingénierie logiciel :-)
Mon interprétation personnelle est la suivante. Java à atteint son seuil de pénétration depuis un moment. Ils ne font pas d'argent sur J2SE, c'est destiné aux end users et il y a des implémentations de BEA et d'IBM tout aussi performantes.
Java n'a jamais réussi à pénétrer sur le Desktop (il y a des raisons techniques la) alors qu"on voit du mono débarquer ! Et il suffit de voir les réactions ici pour comprendre ce que pense la communauté du LL sur la stack Java.
Bref ca ne leur coutera pas plus cher, je ne pense pas qu'ils attendent d'énormes contributions hormis des portages vers des archi exotiques, et ils ont une chance de gagner des utilisateurs.
On peut noter que l'évolution de Java est depuis longtemps ouvert à la communauté (JCR/JCP). Ce qui a mal été compris est la volontée de Sun de n'avoir sous le nom Java que des implémentations qui passent le TCK (souvenez vous de la VM de microsoft). C'est la même stratégie que la mofo, si vous voulez notre nom alors vous respectez nos règles.
En dehors du JDK, la politique à la mode chez Sun c'est d'offrir des implémentation de référence des specs libres, et d"en tirer des versions supportées. On peut citer: glassfish (serveur J2EE), OpenDS (directory service), OpenSSO, Hudson (_LE_ serveur d'integration continue) etc.
C'est le mouvement général de Sun depuis quelques années. Rien qu'a voir le nombre de bloggers qu'ils mettent pour faire leur com. Après Sun a toujours changé d'avis tout le temps :-)
[^] # Re: hugh
Posté par ckyl . En réponse au journal Microsoft donne 100000 dollars à la fondation Apache. Évalué à 4.
100 000 dollars c'est l'équivalent d'un ingénieur par an.
Ce que fera l'ASF de ce pognon ca les regardes et je me fais pas trop de soucis, ce sont des grands garcons qui font des choses concrètes au lieu de se masturber sur les ML. Les projets sont autonomes dans Apache, donc je ne vois pas comment ce pognon pourrait changer quoi que ce soit.
Pour rappel http://www.apache.org/foundation/how-it-works.html
[^] # Re: En effet, c'est pire que la java trap
Posté par ckyl . En réponse au journal Pourquoi Mono/C# est une folie. Évalué à 1.
Vouloir ce que l'on a aujourd'hui pour demain, c'est pas très ambitieux ni motivant.
[^] # Re: En effet, c'est pire que la java trap
Posté par ckyl . En réponse au journal Pourquoi Mono/C# est une folie. Évalué à 2.
http://research.google.com/people/r/
C'est pas le respect qui étouffe certains ici :-/ Il te reste une bonne vingtaine d'années pour compléter ton CV à la hauteur du monsieur...
[^] # Re: En effet, c'est pire que la java trap
Posté par ckyl . En réponse au journal Pourquoi Mono/C# est une folie. Évalué à 3.
Pour commencer, l'avis d'un mec qui est l'auteur (entre autre) de: Unix, Plan 9, UTF-8, Inferno, et le premier système de fenêtrage pour Unix pourrait recevoir un poil plus de respect. Si il avait suivit ton raisonnement il y a 30 ans tu ferais quoi maintenant ?
Donc d'après toi on reste à Unix pour les 50 années à venir ?
[^] # Re: En effet, c'est pire que la java trap
Posté par ckyl . En réponse au journal Pourquoi Mono/C# est une folie. Évalué à 2.
Non ca c'est le passé et le présent. J'espère bien que ca sera pas le futur. Ca commence a être lassant depuis le temps.
http://herpolhode.com/rob/utah2000.pdf est devenu plus vrai chaque année :-/
[^] # Re: GNU et saint, et Microsoft diabolique ?
Posté par ckyl . En réponse au journal Pourquoi Mono/C# est une folie. Évalué à 3.
Ironie.
> Je dis simplement que pour des gros codes coté serveur, comme ceux pour ebay ou yahoo, avoir un java compilé serait tout aussi bien.
> Ils gagneraient en performance
Java est compilé... Seulement la compilation se fait en JIT (et peut avoir lieu plusieurs fois selon les besoins). Fait tourner tes applis avec l'option "-Xint" (mode interprété) pour voir ce que ca donne quand le code n'est pas compilé. A partir des nightly build de Sun tu peux même utiliser "-XX:+PrintOptoAssembly" pour récupérer le code assembleur produit par HotSpot. Tu peux t'amuser a comparé le binaire produit par Hotspot et pas GCC sur du code équivalent c'est assez intéressant.
A priori, le faire en JIT te permet en plus de compiler pour un CPU précis, en ayant des informations sur les prédictions de branches etc.
Tu as des preuves de ce que tu avances ou juste des lieux communs ?
> de la compatibilité binaire inter-plateforme qui marche d'ailleurs plus ou moins bien
Gni ? Tu peux développer ?
> Par ailleurs, les boites que tu donnes n'ont certainement pas un serveur en frontal mais toute une ferme.
Si tu savais :-)
D'ailleurs sur les gros sites la scalabilité est de loin plus importante que la performance. Mais on y pense tout de même.
Mais concrètement pour des sites web tu as le choix entre: PHP, Perl, Python, Ruby, Java, .Net. Et on ose parler des perfs de Java.... C'est encore plus marrant quand on voit la différence de perf entre Ruby et JRuby.
[^] # Re: GNU et saint, et Microsoft diabolique ?
Posté par ckyl . En réponse au journal Pourquoi Mono/C# est une folie. Évalué à 4.
Va falloir expliquer ca à des petites startups tel que yahoo, ebay, linked-in, amazon ou orbitz avant que leurs sites grossissent et qu'ils aient des problèmes.
Autant J2EE est une bouze, autant une utilisation rationnelle de Java marche plutôt bien.
[^] # Re: Mouais
Posté par ckyl . En réponse au journal Pourquoi Mono/C# est une folie. Évalué à 3.
Si tu es compétent tu peux aussi postuler chez Microsoft et participer aux décisions :-)
[^] # Re: Et ?
Posté par ckyl . En réponse au journal Pourquoi Mono/C# est une folie. Évalué à 6.
En meme temps c'est 100% la faute des implémentations libres !
Tu peux contribuer à l'évolution du langage, de la VM et de la bibliothèque standard par le biais du JCP. En général les implémentations libres arrivent même à avoir accès au TCK gratos. Les JSR ressemblent beaucoup aux groupes de travail de l'IETF.
Après si GNU arrive 10 ans après la bataille et sans les moyens humains pour faire le boulot. Bin c'est de la faute de GNU. Si tu veux une implémentation libre tu bosses dessus...
Pour .Net le problème est différent puisqu'il n'y a pas d'équivalent du JCP à ma connaissance (et ce n'est pas dans la culture Microsoft). Mais pour C# c'est exactement le même problème qu'avec C, C++ or fortran. On implémente à partir des specs .|
[^] # Re: Bon bon bon
Posté par ckyl . En réponse au journal Pourquoi Mono/C# est une folie. Évalué à 5.
[^] # Re: sans rapport
Posté par ckyl . En réponse au journal 4 postes à pourvoir à l'INRIA pour travailler sur Grid'5000. Évalué à 2.
Ca c'est un cluster de prod de l'unité de sophia antipolis. Et oui la page semble a jour. Pourquoi ?
[^] # Re: Un portable DELL?
Posté par ckyl . En réponse au journal Un pc portable ≠ eee. Évalué à 3.
Quand tu as un remplacement à J+1 c'est pas important. Pour un laptop perso... Les laptop Dell c'est vraiment du jetable, moche et lourd.
[^] # Re: Pour avoir travaillé 1 an à Google
Posté par ckyl . En réponse au journal Google offre un format de donnée sous licence Apache. Évalué à 4.
Autant je suis d'accord avec toi pour le reste. Autant cette affirmation est fausse. Tu as au moins une dizaine d'implémentations qui te font le mapping automatique XML vers langage Objet (idem pour les DB). Pour les perfs c'est autre chose.
Les deux solutions semblent complémentaires. XML beaucoup plus généraliste et puissant. Protocol Buffer offre beaucoup moins de fonctionalités qu'XML puisqu'il cible mieux ses utilisateurs potentiels. Il est donc plus concis et rapide en déportant les traitements possibles en XML de la lib vers le code utilisateur.
C'est une bonne chose d'avoir une nouvelle alternative puisque la plupart des gens utilisent du XML pour tuer une mouche. Et donc la valeur ajouté par forcement significative.
[^] # Re: Personnelement, je ne trouve pas le xml lisible
Posté par ckyl . En réponse au journal Google offre un format de donnée sous licence Apache. Évalué à 3.
Effectivement. Encore plus que la lourdeur c'est surtout qu'eclipse est pas du tout conçu pour fonctionner avec des fichiers seuls (pas de projet).
Un bon éditeur XML ca serait pas du luxe, quand je vois le nombre de mecs qui éditent du XML avec vim et se tapent 25 essais d'exécution alors qu'un éditeur validant permet de régler le truc en 5 secondes.
> Pour le XPath qui est plus parlant, ça dépend vraiment des gens.
Tu peux faire des trucs bien moches avec toutes les technos.
Reste que six mois après tu comprends encore assez facilement ce que l'expression suivante fait.
my $nodeset = $job_xml->find('//*/child/child[statu=\'REGRESSION\']/className/text()');
foreach my $node ($nodeset->get_nodelist) {
print "\t", "NEW ", XML::XPath::XMLParser::as_string($node), "\n";
}
Si tu peux formater en CSV; alors CSV ou XML sont plus ou moins équivalents. Cela dit il est plus facile de rajouter des attributs ou des éléments à un fichier XML en gardant tes outils qu'en CSV. De même tu peux représenter beaucoup plus de concept. Bref tout est question de dosage en fonction des objectifs et contraintes que tu as.
[^] # Re: Personnelement, je ne trouve pas le xml lisible
Posté par ckyl . En réponse au journal Google offre un format de donnée sous licence Apache. Évalué à 4.
Le problème c'est que beaucoup de gens semblent utiliser XML pour stocker trois valeurs qui serait tout aussi bien en CSV.
L'interet d'XML c'est les outils qu'il y a autour et qu'ils sont facile à modifier. Pas de parser a réinventer, XPath, XQuery, XSLT, Xinclude, pas mal d'API pour la serialization automatique etc. C'est pas parfait mais ca fait gagner un temps fou de développement et pour faire évoluer les fichiers. Pour des fichiers de conf c'est plus douteux, mais au moins ca permet d'avoir une complétion "universelle".
Par contre si c'est pour faire communiquer deux processus proprio avec des contraintes de performance alors ca vaut peut être le coût de réinventer la roue. Et c'est la que se place "Protocol Buffers".
Récemment j'ai fait des stats sur les résultats des test unitaires et fonctionnels des 10 000 derniers builds d'un projet. Chaque résultat d'un build est stocké dans un ou plusieurs fichier XML, et le schema a évolué 3/4 fois. Apres 10 minutes d'XSLT j'avais tout reformaté en un gros fichier CSV, uploadé ca sur un cluster Hadoop DFS et commencé a sortir des stats avec Pig.
Je n'ai réinventé aucun outil. Du logiciel qui pond le fichier, à celui qui le transforme. Et une expression XPath reste toujours plus parlante qu'une série de grep | cut | awk | cut | sort | uniq. Et franchement, y'a plus intéressant à faire que de la manipulation de fichier dans l'informatique !
[^] # Re: C'est pas ici mais sur bsdfr.org qu'il faut poster
Posté par ckyl . En réponse au journal OpenBSD 4.4 entre en Beta. Évalué à 6.
Tu ne fais pas parti des gens qui font l'histoire tout cours. Juste des pleureurs de l'internet.
Hormis cracher sur tout le monde sur linuxfr tu fais quoi ? Je réitère mon invitation du thread sur OpenJDK 6 à nous montrer tes contributions sous licence GPL. Après t'être permis de dénigrer tant de monde, la moindre des choses serait d'avoir des choses à montrer. Et ca n'excuserait en rien ton comportement. Allez, avec un peu de chance t'es même sur PACA comme ca tu pourras me les montrer en vrai.
[^] # Re: Un succès par rapport à quoi ?
Posté par ckyl . En réponse au journal OpenSuSE : déjà un succès ?. Évalué à 3.
LOL PTDR
https://linuxfr.org/~Sam_from_MS/ regarde bien la date de création du compte et tu peux aussi voir l'historique des trolls journaux. Sont marrants ces jeunes quand même !
[^] # Re: amusant
Posté par ckyl . En réponse au journal Générateur de graphes d'appels de fonctions. Évalué à 2.
[^] # Re: et le jre ?
Posté par ckyl . En réponse à la dépêche OpenJDK 6 passe le TCK. Évalué à 2.
En général quand une boite choisie un modèle de double licence c'est pour ne pas qu'une boite concurrente puisse faire la même chose; les forcer à passer par toi. En gros tu veux éviter qu'un intégrateur se fasse le pognon tout seul alors que c'est toi qui développe.
Si ton business model ne prévoit pas ça, alors soit une simple GPL suffit soit tu fais du LGPL/BSD.
[^] # Re: Bof
Posté par ckyl . En réponse à la dépêche OpenJDK 6 passe le TCK. Évalué à 2.
J'ai choisi cet exemple au hasard pour montrer que l'écosystème d'un langage est aussi très important. Clairement Perl n'a rien à prouver de ce point de vue là.
[^] # Re: Merge
Posté par ckyl . En réponse à la dépêche Subversion (SVN) 1.5 est disponible. Évalué à 3.
Et effectivement l'intégration de git dans eclipse/netbeans/idea actuellement c'est vraiment pas ça. C'est de toute façon un facteur bloquant pour migrer.
[^] # Re: Merge
Posté par ckyl . En réponse à la dépêche Subversion (SVN) 1.5 est disponible. Évalué à 6.
svnmerge.py on l'a testé pendant un bon moment. Ca marche pas mal pour garder des branches tirées du trunk à jour. Par contre pour merger une branche de devel dans le trunk en fin de développement il est très souvent à l'ouest (sans compter que svnmerge demande pas mal d'itérations pénibles). En gros sur une vingtaine d'intégrations de branche il en a réussi une seule parfaitement. Je ne compte pas les branches ou il y a des déplacement de fichiers, la ca ne peut pas marcher.
Pour le diff/patch à la main pour intégrer une branche, ca va souvent plus vite quand tu vois que svnmerge commence à perdre les pédales si tu n'as pas de solutions de secour.
Pour ce qui est de SVK non je n'ai pas testé. git-svn répond totalement à mon besoin:
1- Les utilisateurs/développeurs lambda peuvent toujours utiliser SVN et tout les outils liés. On ne veut pas d'un VCS distribué.
2- Je travaille quotidiennement avec une dizaine de branches. Avoir 10 working copies est compliqué à gérer . Il doit y avoir bijection working copy <=> projet dans l'IDE. Quand tu créer/ferme des branches plusieurs fois par semaine la manipulation commence à être lourde. C'est aussi consommateur d'espace. 10x377Mo pour SVN contre 1x397Mo pout git-svn !
3- J'ai le confort d'avoir des branches privées si nécessaire. Il est très facile d'exporter une branche privée sur le serveur SVN si un autre développeur à besoin de ma branche.
4- Le mapping branche SVN vers branche git est trivial. Ainsi quand svnmerge.py s'est vautré merger une branche c'est: git co -b SVN_remotebranch remotebranch ; git co master ; git merge SVN_remotebranch. Je n'ai jamais vu git-svn se planter.
Note que je n'utilise pas git et je ne vois pas d'intérêt aux DVCS sauf cas particuliers. Mes critiques contre svn/svnmerge viennent de mon expérience.
Cette semaine j'ai encore mergé cinq branches vers le trunk, veilles de 2 semaines à 6 mois. Peut être que chez vous ca marche, mais pour moi non. Et dans tout les cas, svnmerge ne peut pas marcher si tu déplaces un fichier.
Bref j'étais pas convaincu il y a six mois. Mais maintenant je checkout directement via git-svn tout les projets.
# Merge
Posté par ckyl . En réponse à la dépêche Subversion (SVN) 1.5 est disponible. Évalué à 3.
J'ai pas encore testé la 1.5 mais c'est une très mauvaise nouvelle.
C'est LA lacune de SVN. Impossible de gérer des branches, ca foire à chaque fois et on fini par faire un diff/patch à la main.
La seule façon de merger des branches sur un serveur subversion que j'ai trouvé c'est d'utiliser git-svn (qui envoi du paté)...
[^] # Re: Bof
Posté par ckyl . En réponse à la dépêche OpenJDK 6 passe le TCK. Évalué à 3.
framework = bibliothèque :-)
https://rome.dev.java.net/
https://pircbot.dev.java.net/
http://code.google.com/apis/youtube/overview.html
http://mina.apache.org/
Mina est 100x overkill mais j'avais envie de jouer avec. Si utiliser des libs c'est du bloat...
> la résitance au changement (utiliser java plutôt qu'un langage que je suppose moins connu).
C'est con c'était le but et j'ai tout de même écrit une version python.
> Après si tu préfère maintenir un truc de 5000 lignes de code plutot qu'un truc de 500
Ca fait 500 lignes de code pour prendre ses entrées sur X chan IRC, telnet et parser régulièrement l'output XML du serveur d'intégration continue; dispatcher ces infos sur différents planet en fonction de la config chaque planet poussant les infos sur des flux RSS ou sur IRC.
> Mais je vois pas la portée de l'argument
Mon argument c'est qu'un langage a beau être 10x mieux sur le papier si les libs autour ne suivent pas, alors ce n'est pas un bon choix. Il faut que les libs soit nombreuses, de bonne qualité et bien documentées.
> utiliser des langages plus "ésotériques" permet de faire à priori un tri extrémement rapide sur les candidats
Non. Ca te fais prendre des universitaires qui n'y connaissent pas forcément grand chose en ingénierie logiciel :-)
[^] # Re: Pourquoi ?
Posté par ckyl . En réponse à la dépêche OpenJDK 6 passe le TCK. Évalué à 9.
Mon interprétation personnelle est la suivante. Java à atteint son seuil de pénétration depuis un moment. Ils ne font pas d'argent sur J2SE, c'est destiné aux end users et il y a des implémentations de BEA et d'IBM tout aussi performantes.
Java n'a jamais réussi à pénétrer sur le Desktop (il y a des raisons techniques la) alors qu"on voit du mono débarquer ! Et il suffit de voir les réactions ici pour comprendre ce que pense la communauté du LL sur la stack Java.
Bref ca ne leur coutera pas plus cher, je ne pense pas qu'ils attendent d'énormes contributions hormis des portages vers des archi exotiques, et ils ont une chance de gagner des utilisateurs.
On peut noter que l'évolution de Java est depuis longtemps ouvert à la communauté (JCR/JCP). Ce qui a mal été compris est la volontée de Sun de n'avoir sous le nom Java que des implémentations qui passent le TCK (souvenez vous de la VM de microsoft). C'est la même stratégie que la mofo, si vous voulez notre nom alors vous respectez nos règles.
En dehors du JDK, la politique à la mode chez Sun c'est d'offrir des implémentation de référence des specs libres, et d"en tirer des versions supportées. On peut citer: glassfish (serveur J2EE), OpenDS (directory service), OpenSSO, Hudson (_LE_ serveur d'integration continue) etc.
C'est le mouvement général de Sun depuis quelques années. Rien qu'a voir le nombre de bloggers qu'ils mettent pour faire leur com. Après Sun a toujours changé d'avis tout le temps :-)
Mais rien que pour Hudson, merci khosuke et Sun !