Il y a quelque chose que j'ai du mal a comprendre c'est que d'après la description la formation porte sur des choses très hétéroclites qui n'ont qu'une seule chose en commun: le logiciel libre.
La compétence logiciel libre si elle est intéressante, ne me semble pas se suffire en elle même, ce n'est pas ce que l'on recherche quand on embauche. C'est une compétence complémentaire sur les compétences de base qui peut faire la différence.
D'après les objectifs de la page d’accueil on à l'impression que vous annoncez autant former des devs, des admins, des dsi, des gestionnaires de projet, des consultants etc. J'ai du mal à voir comment on peut former des personnes compétentes à tout ces postes dans une même formation.
Le forfait Chrono n'existe plus depuis le 01/02/2012. Reste à savoir ce qu'ils feront des clients en Chrono, si Prixtel gardera sa grille tarifaire pendant quelques temps ou si le passage sur Modulo sera fait de force.
Dans tout les cas, c'est une mauvaise nouvelles pour les utilisateurs de voix et pour ceux qui voulait payer leur consommation plutôt qu'un forfait. Il ne reste plus que Free sur ce segment.
Et oui c'est dommage mais personne ne veut s’aligner de près ou de loin avec le forfait à 2€. Le seul concurrent qui avait une offre similaire (Chrono 2x plus cher sur la voix, 10x plus cher sur les SMS) vient de lâcher l'affaire. Du coup si t'accroches pas le réseau Orange chez toi, l'arrivée de Free est une mauvaise nouvelle ;)
Ca prend le même temps de lire http://wiki.apache.org/solr/SimpleFacetParameters ou le chapitre de Solr Enterprise Search. Sauf qu'en lisant les deux premiers tu as toutes les infos pour pouvoir faire quelque chose de ce dont on te parle, alors qu'avec le tutorial c'est joli mais tu peux rien en faire. Donc du coup tu devras quand même lire les deux ressources précédentes...
Ton tutorial il ne t'a pas mis le doigt sur quelque chose où tu aurais pu rater. Si tu voulais cette fonctionnalité tu serais forcement tombé dessus. Et techniquement il sert à rien. Bref ca fait beaucoup de bruit pour rien... Si tu veux juste parler du faceting tu peux diviser sa taille par 10 et virer toute la pseudo technique.
Le truc c'est que t'en a pas besoin puisque tu vas pas t'en servir, et que les infos seront de toutes façon beaucoup trop légères pour faire quoi que ce soit de concret. Et le jour où tu voudras vraiment développer quelque chose qui tourne autours de la recherche free text, tu arriveras au niveau de l'article en quelques dizaines de minutes.
Les articles ça peut être sympa pour faire découvrir des choses qui pourraient passer inaperçues auprès des gens qui en ont besoin. Dans le domaine dont on parle ici, tu ne peux ni passer à côté de la techno, ni avoir plus d'information que les docs déjà existantes. Donc l’intérêt est assez limité.
Après, pour moi, les articles me permettent de piquer un peu ma curiosité. Lire un article sur Lucene avec un peu de code de démo peut me donner envie de regarder un peu plus sérieusemen
J'arrive pas à comprendre. Si t'as besoin de faire une fonctionnalité de recherche tu t'y intéresseras. Sinon je vois pas pourquoi perdre du temps sur un truc qui est inutile pour toi.
Tu choisis tes technos en fonction de tes besoins. De toute facon dans un article de mag, t'auras pas grand chose d'autre que des trivialités à te mettre sous la dent.
Cependant, je suis preneur des bouquins de référence ;-)
Est ce qu'il y a besoin de maintenir une seconde base de données.
Oui. T'as besoin d'un index pour chercher. Et cet index doit être conçu pour la recherche. Le concept de base, c'est de dénormaliser toutes tes infos pour tout mettre dans des documents à plat (un peu comme tu les affiches).
Quel charges ça représente en plus pour l'infrastructure (pas uniquement la ressources CPU et mémoire, mais aussi le stockage).
Très très variable en fonction des fonctionnalités que tu utilises et des détails d'implémentation. L'idée générale c'est que ca scale bien, que pouvoir chercher dans une information prend pas beaucoup de place, pouvoir ré-afficher l'information prend plus de place, et que ça bouffe de la RAM si tu veux que tu ais un tant soit peu de perf.
C'est pour ca que la plupart des solutions viennent maintenant sous forme d'API REST (Solr, Elastic Search, Compass). Ces solutions clés en main suffisent à 99% des besoins, et n'impliquent que peu de couplage entre la techno utilisée pour implémenter le search et les codes clients. Les concepts sont génériques et je ne vois rien qui serait spécifique à un langage. C'est juste de la glue entre tes interfaces exposées et l'outil que tu utilises.
Il faut avoir une bonne raison pour descendre à la couche du dessous (Lucene) et réinventer une bonne partie de la plomberie.
Pour Solr et Lucene y'a deja moulte documentation et deux bouquins de référence très bon.
Pour être parti de 0 y'a pas longtemps, et avoir monté un service un tant soit peu plus compliqué que ce dont il y a besoin pour la plupart des sites web; je pense que les ressources existantes sont amplement suffisantes pour arriver a être productif très rapidement.
Le journaliste précise bien que les constructeurs sont bien heureux du tout électronique dans leurs voitures neuves, car les réparations sont plus chers, et qu'on ne peut plus les effectués soit même.
Les consommateurs sont bien heureux aussi par ce que maintenant y'a plus aucune raison de pas faire le diag toi même vu que tu peux souvent te payer le logiciel pour le prix de 3/4 passages à la valise chez le constructeur et que les mecs savent rien faire d'autre que lire betement le code d'erreur. Limite si t'apprends pas à la plupart des mecs des concessions comment fonctionne ta voiture...
Et au passage tu reactives les fonctions bridées electroniquement gratos ou pour le prix d'un pauvre commodo.
D'ailleurs c'est dommage qu'il n'y ait pas de projet libre dans un état avancé sur le sujet.
Je doute qu'un logiciel qui aille dans cette direction (vouloir utiliser parallèlement différente versions de la même bibliothèque) puisse aller bien loin sans causer une vague de suicide chez les développeurs.
Bien sur que si. C'est même ce que demande les développeurs.
C'est un cas très courant. La plupart des applications d'entreprises sont des gros assemblages de modules, dont chacun dépend de pas mal de choses. Et c'est très difficile de synchroniser tout le monde sur des versions identiques de lib. Par ce que tout les modules développés en interne n'évoluent pas forcement à la même vitesse, par ce que tu es dépendant de projet tiers, ou par ce que tu as une bonne raison d'utiliser une version précise.
On ne déclare pas des dépendances pour le plaisir et surtout pas sans une concertation avec l'ensemble de l'équipe.
Avec ton équipe oui. Le problème c'est que le bundle final c'est un assemblage du boulot de 3..20 équipes qui bossent chacune sur une fonctionnalité.
De même tu te retrouves souvent à intégrer des modules qui n'ont pas été développé avec un produit donné en vue. Par exemple je développe une lib interne pour un produit 1 et d'un seul coup le produit 2 l’intègre aussi. Rien ne te dit que produit 1 et produit 2 sont d'accord sur les versions de lib.
Mais pour ce genre de méthodes, peut être que OSGi/iPjoo pourrait faire l'affaire
C'est l'idée oui. Ce que tu voulais à la base c'est avoir accès à une interface, tout ce qu'il faut pour implémenter cette interface ca devrait être caché et isolé pour n'avoir aucun impact sur le reste du monde.
Mais on pratique actuellement on y va plus à la hache qu'autre chose.
Soit il y a une solution viable (soft2 est correct avec la version 1 ou soft1 est correct avec la version 2) et tu peux la forcer. Soit y'a pas de solution à ton problème.
Non, je n'ai pas perdu mon temps. Je connais ce que j'inclus et je le maîtrise. Trop de dépendances ? Ok, on prend une lib plus légère.
Gère un projet un tant soit peu important avec qui à 10 ans d'historique et on en reparle. De même pour faire un système d'intégration continue, gérer à la main c'est tout réinventer.
Une fois que tu as tes builds en place, et que tu développes en testant alors les erreurs d'assemblage qui pourraient se produire tu les détectes immédiatement (autrement y'a un problème dans les tests). Si tu le fais à la main, tu ne vas pas pouvoir intégrer de manière agressive dès le début de ton projet, donc tu détecteras ces problèmes très très tard.
Maven à des milliards des défauts mais la tu reproches un truc qui touche n'importe quel gestionnaire de dépendance.
Après si tu bosses sur une appli constituée d'un seul module qui dépend de 10 JAR externes, et qui produit un seul JAR qui n'est consommé par aucun autre des tes produits; effectivement tu peux le faire à la main.
Bien sur que si. Si un soft1 en version X dépend d'un soft2 en version Y à Z ce n'est pas du tout la même chose qu'un soft2 en version supérieur à Y. Mais en général tout le monde se fou de faire les dépendances correctement (être strict à aussi des inconvénients) et ca pète à runtime par ce que tu te retrouves avec la version Z. La faute ne revient pas à l'outil mais au mec qui à ecrit le pom.
Il cache énormément de choses qu'il vaudrait mieux maitriser
T'as exactement les mêmes problèmes pour le faire à la main. Sauf que dans 90% des cas, ca marche très bien avec la version automatique. T'as juste perdu ton temps pour rien.
C'est aussi bête que de dire que le boulot fait par les gestionnaires de paquets et les packageurs ne sert à rien. Ca marche mieux pour eux par ce qu'ils construisent une configuration figée.
Tout à fait d'accord mais quand tu codes une appli en C/C++, il est quand même rare, me semble-t-il, de lier avec deux versions d'un même composant sans qu'il ne se passe de collision.
J'ai du mal à voir la pertinence de la comparaison.
Et t'es sur que c'est pas simplement des pom mal maintenus ? Si la version n+1 pète la compat et qu'un dit log4j >= n et l'autre log4j >= n+1 bha tu te retrouves avec n+1 par ce que c'est ce que les gens qui ont écrit les pom ont demandé... à tord.
Maven c'est une bonne idée; très mal réalisée (la conf est complètement stupide). Mais faut pas l'accuser de n'importe quoi.
Après le vrai problème; qui existe dans tout les langages mais qui est exacerbé en Java du fait de la réutilisation massive de nombreux composant non inclus dans le runtime, c'est comment avoir deux versions de la même lib en parallèle dans la même appli.
Si tu écris du code concurrent qui n'est pas concurrent bin oui t'auras des problèmes... Autrement c'est prévu à la base que l'ordre et la durée d'exécution ne sont pas détermiste; et tu as prévu tes données et ton flow d'execution pour.
Avoir un GC ou pas ne change rien à l'affaire. Sauf qu'un bout de tes fils d'execution peut s'arreter un peu plus longtemps que ce que tu avais imaginé. Mais ca pourrait être causé par autre chose qu'un GC. Soit ton code est correct soit il est buggé et la pause ne fait que le mettre en évidence.
Oui enfin avoir des temps de réponse déterministes ça peut aussi être utile pour un serveur. Ce qui ne veut pas dire que c'est impossible avec un GC mais que ça demande des technos pointues disponible dans peu de langage et d'architecturer correctement ses applis.
Si tout le monde s'en battait sérieux dans les serveurs Azul ferait pas son beurre avec son pauseless GC et des armées d'ingé passeraient leur temps à essayer de voir ce qu'on arrive à faire.
A confirmer par quelqu'un qui s'y connait mieux que moi sur "où" est crée la pile par défaut du thread, mais je peux t'assurer que lorsqu'on créé un nombre élevé de thread, il faut commencer à jouer sur la taille de leur stack
Le seul problème c'est l'exhaussion de ton espace d'addressage. À chaque fois que tu créés un thread, une memory area (un bout de l'espace d'adressage de ton process) est créé pour contenir la stack. Quand la somme de ces zones mémoire dépasse la taille de ton espace d'adressage (module la fragmentation) bin ca marche plus. Tu peux voir ca comme quand tu fais un mmap.
Du coup quand tu joues avec la taille de la stack c'est juste pour réussir à faire rentrer toutes les zones dans l'espace d'addressage.
plus que la doc c'est deja savoir penser et creer un algo.
Oui enfin à partir du moment ou on apprend à quelqu'un à créer un algo il faudra qu'il saute le pas à un moment de toute façon. C'est nécessaire pour implémenter, et même si tu restes dans le côté 100% académique toute la littérature est en anglais. Ce n'est que reculer pour mieux sauter.
sans avoir à le traduire dans un langage
Ah bon ce n'est pas un langage ? Il ne me semble pas que ce soit du langage naturel ni même un CNL...
D'après kmail, j'ai 407 000 messages toujours accessibles dans une arborescence à plusieurs niveaux.
Soit en moyenne 112 messages par jour ouvré... Soit beaucoup trop pour avoir des choses intéressantes et utiles dedans. Et aussi beaucoup trop pour ne pas perdre son temps en les ayant lu.
Tu veux dire que ce n'est jamais arrivé qu'un mec décide de ne plus rien glander ? On peut aussi tenter l'inverse ? Au bout de 8 mois n'importe quel employé compétent sait si un employeur convient ou pas, pas besoin de lui laisser la possibilité de démissionner unilatéralement. Pourquoi l'un a une porte de sortie et pas l'autre ?
En France le rapport employé/employeur et aussi débile que locataire/bailleur. Tu as des lois qui protègent à outrance les employés/locataires, mais qui du coup se retournent largement contre ceux qu'elles sont censées protéger.
[^] # Re: But §
Posté par ckyl . En réponse à la dépêche Le Master Ingénierie du Logiciel Libre (I2L) change et se dirige vers l'apprentissage. Évalué à 2.
C'est justement ce qui me surprend. Je vois mal comment on peut apporter des bases solides sur autant de problématiques et corps de métier.
# But §
Posté par ckyl . En réponse à la dépêche Le Master Ingénierie du Logiciel Libre (I2L) change et se dirige vers l'apprentissage. Évalué à 3.
Il y a quelque chose que j'ai du mal a comprendre c'est que d'après la description la formation porte sur des choses très hétéroclites qui n'ont qu'une seule chose en commun: le logiciel libre.
La compétence logiciel libre si elle est intéressante, ne me semble pas se suffire en elle même, ce n'est pas ce que l'on recherche quand on embauche. C'est une compétence complémentaire sur les compétences de base qui peut faire la différence.
D'après les objectifs de la page d’accueil on à l'impression que vous annoncez autant former des devs, des admins, des dsi, des gestionnaires de projet, des consultants etc. J'ai du mal à voir comment on peut former des personnes compétentes à tout ces postes dans une même formation.
[^] # Re: oui mais non
Posté par ckyl . En réponse au journal On devrait manger ce qu'on donne à notre chien. Évalué à 10.
Tu ne penses pas t'avancer un peu vite quand tu ne sais pas les besoins de la personne à qui tu parles ?
J'admire toujours les gens qui donnent avec certitude leur solution sans connaître le problème.
[^] # Re: Pas besoin de ça : ils ont déjà au moins un excellent forfait !
Posté par ckyl . En réponse au journal [Free mobile] L'argumentaire en béton d'Orange. Évalué à 3.
Le forfait Chrono n'existe plus depuis le 01/02/2012. Reste à savoir ce qu'ils feront des clients en Chrono, si Prixtel gardera sa grille tarifaire pendant quelques temps ou si le passage sur Modulo sera fait de force.
Dans tout les cas, c'est une mauvaise nouvelles pour les utilisateurs de voix et pour ceux qui voulait payer leur consommation plutôt qu'un forfait. Il ne reste plus que Free sur ce segment.
[^] # Re: Pas besoin de ça : ils ont déjà au moins un excellent forfait !
Posté par ckyl . En réponse au journal [Free mobile] L'argumentaire en béton d'Orange. Évalué à 5.
Prixtel vient de l’arrêter celui là. Et maintenant ta consommation te couterait 24.90€ chez Prixtel...
http://www.prixtel.com/particulier/offre-telephone-mobile
Et oui c'est dommage mais personne ne veut s’aligner de près ou de loin avec le forfait à 2€. Le seul concurrent qui avait une offre similaire (Chrono 2x plus cher sur la voix, 10x plus cher sur les SMS) vient de lâcher l'affaire. Du coup si t'accroches pas le réseau Orange chez toi, l'arrivée de Free est une mauvaise nouvelle ;)
[^] # Re: LinuxMag
Posté par ckyl . En réponse à la dépêche Nouveau moteur de recherche interne à LinuxFr.org. Évalué à 1.
Ca prend le même temps de lire http://wiki.apache.org/solr/SimpleFacetParameters ou le chapitre de Solr Enterprise Search. Sauf qu'en lisant les deux premiers tu as toutes les infos pour pouvoir faire quelque chose de ce dont on te parle, alors qu'avec le tutorial c'est joli mais tu peux rien en faire. Donc du coup tu devras quand même lire les deux ressources précédentes...
Ton tutorial il ne t'a pas mis le doigt sur quelque chose où tu aurais pu rater. Si tu voulais cette fonctionnalité tu serais forcement tombé dessus. Et techniquement il sert à rien. Bref ca fait beaucoup de bruit pour rien... Si tu veux juste parler du faceting tu peux diviser sa taille par 10 et virer toute la pseudo technique.
[^] # Re: LinuxMag
Posté par ckyl . En réponse à la dépêche Nouveau moteur de recherche interne à LinuxFr.org. Évalué à 1.
Le truc c'est que t'en a pas besoin puisque tu vas pas t'en servir, et que les infos seront de toutes façon beaucoup trop légères pour faire quoi que ce soit de concret. Et le jour où tu voudras vraiment développer quelque chose qui tourne autours de la recherche free text, tu arriveras au niveau de l'article en quelques dizaines de minutes.
Les articles ça peut être sympa pour faire découvrir des choses qui pourraient passer inaperçues auprès des gens qui en ont besoin. Dans le domaine dont on parle ici, tu ne peux ni passer à côté de la techno, ni avoir plus d'information que les docs déjà existantes. Donc l’intérêt est assez limité.
[^] # Re: LinuxMag
Posté par ckyl . En réponse à la dépêche Nouveau moteur de recherche interne à LinuxFr.org. Évalué à 1.
J'arrive pas à comprendre. Si t'as besoin de faire une fonctionnalité de recherche tu t'y intéresseras. Sinon je vois pas pourquoi perdre du temps sur un truc qui est inutile pour toi.
Tu choisis tes technos en fonction de tes besoins. De toute facon dans un article de mag, t'auras pas grand chose d'autre que des trivialités à te mettre sous la dent.
Ils sont sur la page d’accueil du projet.
http://lucene.apache.org/solr/
[^] # Re: LinuxMag
Posté par ckyl . En réponse à la dépêche Nouveau moteur de recherche interne à LinuxFr.org. Évalué à 2.
Oui. T'as besoin d'un index pour chercher. Et cet index doit être conçu pour la recherche. Le concept de base, c'est de dénormaliser toutes tes infos pour tout mettre dans des documents à plat (un peu comme tu les affiches).
Très très variable en fonction des fonctionnalités que tu utilises et des détails d'implémentation. L'idée générale c'est que ca scale bien, que pouvoir chercher dans une information prend pas beaucoup de place, pouvoir ré-afficher l'information prend plus de place, et que ça bouffe de la RAM si tu veux que tu ais un tant soit peu de perf.
[^] # Re: LinuxMag
Posté par ckyl . En réponse à la dépêche Nouveau moteur de recherche interne à LinuxFr.org. Évalué à 2.
C'est pour ca que la plupart des solutions viennent maintenant sous forme d'API REST (Solr, Elastic Search, Compass). Ces solutions clés en main suffisent à 99% des besoins, et n'impliquent que peu de couplage entre la techno utilisée pour implémenter le search et les codes clients. Les concepts sont génériques et je ne vois rien qui serait spécifique à un langage. C'est juste de la glue entre tes interfaces exposées et l'outil que tu utilises.
Il faut avoir une bonne raison pour descendre à la couche du dessous (Lucene) et réinventer une bonne partie de la plomberie.
[^] # Re: LinuxMag
Posté par ckyl . En réponse à la dépêche Nouveau moteur de recherche interne à LinuxFr.org. Évalué à 2.
Pour Solr et Lucene y'a deja moulte documentation et deux bouquins de référence très bon.
Pour être parti de 0 y'a pas longtemps, et avoir monté un service un tant soit peu plus compliqué que ce dont il y a besoin pour la plupart des sites web; je pense que les ressources existantes sont amplement suffisantes pour arriver a être productif très rapidement.
[^] # Re: Ma liste perso
Posté par ckyl . En réponse au journal Le téléphone portable idéal du libriste. Évalué à 3.
Les consommateurs sont bien heureux aussi par ce que maintenant y'a plus aucune raison de pas faire le diag toi même vu que tu peux souvent te payer le logiciel pour le prix de 3/4 passages à la valise chez le constructeur et que les mecs savent rien faire d'autre que lire betement le code d'erreur. Limite si t'apprends pas à la plupart des mecs des concessions comment fonctionne ta voiture...
Et au passage tu reactives les fonctions bridées electroniquement gratos ou pour le prix d'un pauvre commodo.
D'ailleurs c'est dommage qu'il n'y ait pas de projet libre dans un état avancé sur le sujet.
[^] # Re: Mes idéaux
Posté par ckyl . En réponse au journal Votre langage idéal ?. Évalué à 2.
Bien sur que si. C'est même ce que demande les développeurs.
C'est un cas très courant. La plupart des applications d'entreprises sont des gros assemblages de modules, dont chacun dépend de pas mal de choses. Et c'est très difficile de synchroniser tout le monde sur des versions identiques de lib. Par ce que tout les modules développés en interne n'évoluent pas forcement à la même vitesse, par ce que tu es dépendant de projet tiers, ou par ce que tu as une bonne raison d'utiliser une version précise.
Avec ton équipe oui. Le problème c'est que le bundle final c'est un assemblage du boulot de 3..20 équipes qui bossent chacune sur une fonctionnalité.
De même tu te retrouves souvent à intégrer des modules qui n'ont pas été développé avec un produit donné en vue. Par exemple je développe une lib interne pour un produit 1 et d'un seul coup le produit 2 l’intègre aussi. Rien ne te dit que produit 1 et produit 2 sont d'accord sur les versions de lib.
C'est l'idée oui. Ce que tu voulais à la base c'est avoir accès à une interface, tout ce qu'il faut pour implémenter cette interface ca devrait être caché et isolé pour n'avoir aucun impact sur le reste du monde.
Mais on pratique actuellement on y va plus à la hache qu'autre chose.
[^] # Re: Mes idéaux
Posté par ckyl . En réponse au journal Votre langage idéal ?. Évalué à 4.
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Transitive_Dependencies
Soit il y a une solution viable (soft2 est correct avec la version 1 ou soft1 est correct avec la version 2) et tu peux la forcer. Soit y'a pas de solution à ton problème.
Gère un projet un tant soit peu important avec qui à 10 ans d'historique et on en reparle. De même pour faire un système d'intégration continue, gérer à la main c'est tout réinventer.
Une fois que tu as tes builds en place, et que tu développes en testant alors les erreurs d'assemblage qui pourraient se produire tu les détectes immédiatement (autrement y'a un problème dans les tests). Si tu le fais à la main, tu ne vas pas pouvoir intégrer de manière agressive dès le début de ton projet, donc tu détecteras ces problèmes très très tard.
Maven à des milliards des défauts mais la tu reproches un truc qui touche n'importe quel gestionnaire de dépendance.
Après si tu bosses sur une appli constituée d'un seul module qui dépend de 10 JAR externes, et qui produit un seul JAR qui n'est consommé par aucun autre des tes produits; effectivement tu peux le faire à la main.
[^] # Re: Mes idéaux
Posté par ckyl . En réponse au journal Votre langage idéal ?. Évalué à 2.
Bien sur que si. Si un soft1 en version X dépend d'un soft2 en version Y à Z ce n'est pas du tout la même chose qu'un soft2 en version supérieur à Y. Mais en général tout le monde se fou de faire les dépendances correctement (être strict à aussi des inconvénients) et ca pète à runtime par ce que tu te retrouves avec la version Z. La faute ne revient pas à l'outil mais au mec qui à ecrit le pom.
T'as exactement les mêmes problèmes pour le faire à la main. Sauf que dans 90% des cas, ca marche très bien avec la version automatique. T'as juste perdu ton temps pour rien.
C'est aussi bête que de dire que le boulot fait par les gestionnaires de paquets et les packageurs ne sert à rien. Ca marche mieux pour eux par ce qu'ils construisent une configuration figée.
J'ai du mal à voir la pertinence de la comparaison.
[^] # Re: Mes idéaux
Posté par ckyl . En réponse au journal Votre langage idéal ?. Évalué à 2.
Et t'es sur que c'est pas simplement des pom mal maintenus ? Si la version n+1 pète la compat et qu'un dit log4j >= n et l'autre log4j >= n+1 bha tu te retrouves avec n+1 par ce que c'est ce que les gens qui ont écrit les pom ont demandé... à tord.
Maven c'est une bonne idée; très mal réalisée (la conf est complètement stupide). Mais faut pas l'accuser de n'importe quoi.
Après le vrai problème; qui existe dans tout les langages mais qui est exacerbé en Java du fait de la réutilisation massive de nombreux composant non inclus dans le runtime, c'est comment avoir deux versions de la même lib en parallèle dans la même appli.
[^] # Re: pour moi
Posté par ckyl . En réponse au journal Votre langage idéal ?. Évalué à 2.
Si tu écris du code concurrent qui n'est pas concurrent bin oui t'auras des problèmes... Autrement c'est prévu à la base que l'ordre et la durée d'exécution ne sont pas détermiste; et tu as prévu tes données et ton flow d'execution pour.
Avoir un GC ou pas ne change rien à l'affaire. Sauf qu'un bout de tes fils d'execution peut s'arreter un peu plus longtemps que ce que tu avais imaginé. Mais ca pourrait être causé par autre chose qu'un GC. Soit ton code est correct soit il est buggé et la pause ne fait que le mettre en évidence.
[^] # Re: pour moi
Posté par ckyl . En réponse au journal Votre langage idéal ?. Évalué à 3.
Oui enfin avoir des temps de réponse déterministes ça peut aussi être utile pour un serveur. Ce qui ne veut pas dire que c'est impossible avec un GC mais que ça demande des technos pointues disponible dans peu de langage et d'architecturer correctement ses applis.
Si tout le monde s'en battait sérieux dans les serveurs Azul ferait pas son beurre avec son pauseless GC et des armées d'ingé passeraient leur temps à essayer de voir ce qu'on arrive à faire.
[^] # Re: Oui, mais
Posté par ckyl . En réponse à la dépêche Quelques aspects de la sécurité qui n'ont rien a voir avec le « Sandboxing ». Évalué à 3.
Si ca t'intéresse c'est fait dans cette fonction là: http://www.koders.com/c/fid9B67C6313A774473B77A39EBA3A1A7315754326C.aspx?s=queue#L336 et plus particulièrement là: http://www.koders.com/c/fid9B67C6313A774473B77A39EBA3A1A7315754326C.aspx?s=queue#L483
[^] # Re: Oui, mais
Posté par ckyl . En réponse à la dépêche Quelques aspects de la sécurité qui n'ont rien a voir avec le « Sandboxing ». Évalué à 5.
Le seul problème c'est l'exhaussion de ton espace d'addressage. À chaque fois que tu créés un thread, une memory area (un bout de l'espace d'adressage de ton process) est créé pour contenir la stack. Quand la somme de ces zones mémoire dépasse la taille de ton espace d'adressage (module la fragmentation) bin ca marche plus. Tu peux voir ca comme quand tu fais un mmap.
Du coup quand tu joues avec la taille de la stack c'est juste pour réussir à faire rentrer toutes les zones dans l'espace d'addressage.
[^] # Re: Objectifs du langage ?
Posté par ckyl . En réponse à la dépêche Linotte, la programmation en français en version 1.6. Évalué à 2.
Oui enfin à partir du moment ou on apprend à quelqu'un à créer un algo il faudra qu'il saute le pas à un moment de toute façon. C'est nécessaire pour implémenter, et même si tu restes dans le côté 100% académique toute la littérature est en anglais. Ce n'est que reculer pour mieux sauter.
Ah bon ce n'est pas un langage ? Il ne me semble pas que ce soit du langage naturel ni même un CNL...
# --linkdest
Posté par ckyl . En réponse au journal Synchroniser deux répertoires rdiff-backup. Évalué à 3.
Pourquoi rdiff-backup consommerait moins qu'un "rsync --linkdest" ?
[^] # Re: Maildir et/ou mailBox ?
Posté par ckyl . En réponse au sondage De quelle année date le plus vieux message dans votre client Email?. Évalué à 10.
Soit en moyenne 112 messages par jour ouvré... Soit beaucoup trop pour avoir des choses intéressantes et utiles dedans. Et aussi beaucoup trop pour ne pas perdre son temps en les ayant lu.
[^] # Re: Non, l'argentique n'est pas mort...
Posté par ckyl . En réponse au journal Industrie de la photographie en péril.. Évalué à 5.
Oui et les codeurs qui préfèrent la qualité utilisent Vi. T'as bien fait de poster ca un trolldi...
[^] # Re: Je pense que tu es mal barré pour ton activité future
Posté par ckyl . En réponse au journal Contexte de ma démarche aux prud'hommes et conseil aux nouveaux patrons relatif au code du travail. Évalué à 2.
Tu veux dire que ce n'est jamais arrivé qu'un mec décide de ne plus rien glander ? On peut aussi tenter l'inverse ? Au bout de 8 mois n'importe quel employé compétent sait si un employeur convient ou pas, pas besoin de lui laisser la possibilité de démissionner unilatéralement. Pourquoi l'un a une porte de sortie et pas l'autre ?
En France le rapport employé/employeur et aussi débile que locataire/bailleur. Tu as des lois qui protègent à outrance les employés/locataires, mais qui du coup se retournent largement contre ceux qu'elles sont censées protéger.