ckyl a écrit 3877 commentaires

T'es nouveau sur linuxfr ? Tu devrais savoir que les moules qui passent 10h par jour à troller sur tout sont bien placées pour donner des leçons à tout les devs et admins du monde.

Sont vraiment con ces gens qui savent pas savoir faire un 99.99999 sur 100 milliards de hits / jour sur du contenu dynamique rafraichi très régulièrement. Moi mon blog il fonctionne sans problème... Et puis comme je suis pas con, je passe pas du temps à développer des technos qui me servent en fait à rien dans mon métier (mais chut faut pas leur dire); du coup j'ai le temps d'aller sur linuxfr.

C'est un article qui peut être intéressant.

D'un côté a bisounours land on essai d'expliquer que les gens qui utilise Jira sont vraiment des mongols qui ont rien compris. De l'autre côté pas mal de gros projets libres ont décidé d'utiliser Jira (Apache, hibernate, codehaus, jboss, spring, hudson).

Si évidement c'est regrettable on peut aussi essayer de comprendre pourquoi, d'en tirer des leçons, ou de montrer qu'actuellement c'est une erreur. Ayant participé au choix de Jira comme BTS il y'a 2/3 ans, après avoir comparé les différents outils dispos. Je trouve intéressant de voir comme ca à évolué depuis le temps et de voir ce que peut offrir chaque solution.

J'ai pas suivi le dev de btrfs mais:
- Oracle n'a (avait) pas de système d'exploitation.
- Oracle vends ses produits à des clients sous linux.
- Oracle a l'air devoir besoin d'un système de fichier qui répond plus à ses besoins.
- Oracle, comme la plupart des entreprises contribuant, ne le fait pas pour l'amour de l'art mais par ce qu'ils ont du juger que ca leur coûterait moins cher de faire ca en mainstream plutôt que comme produit à eux. Ca peut être pour des raisons de cout de dev, de maintenance, de support de quelque chose non intégré ou autre.

Maintenant qu'ils ont Solaris, on verra bien. Les idées qu'ils ont en tete.

> Java va prendre du plomb dans l'aile, ce qui est peut-être une bonne nouvelle finalement?

Je suis déçu par cette décision qui n'est pas vraiment une nouvelle (ca fait juste des années que ca traine, et aucune raison pour que ca change maintenant surtout depuis que IBM s'est tiré d'harmony pour aller rejoindre son copain oracle sur OpenJDK (qui devrait fusionner avec JRockit). Mais il faut arrêter de rêver. Cette décision ne changera strictement rien. Tout ce que ca annonce, c'est que la réponse est officiellement non, alors que depuis quelques années c'était "oui peut être repassez dans six mois". Et si on regarde les VM qui sont utilisées dans le vrai monde, y'a pas des masses d'utilisateurs qui vont s'en offusquer...

Si la fondation Apache décide que le projet ne répond pas à ses critères. Le projet sera sorti de l'incubateur et n'intégrera pas la fondation Apache. Mais tu es certainement mieux placé que les membres de la fondation ou les commiters sur Wave pour analyser la situation !

Je ne vois pas en quoi offrir du code libre et céder son copyright à la fondation Apache sans rien demander en retour peut être un cadeau empoisonné... Les gens sont quand même vachement ingrat, tu leur offres un truc et ils trouvent quand même le moyen de critiquer...

Apache n'a rien a dépenser. La fondation ne fourni que de la logistique et du juridique.

Le projet suis le chemin classique. Il est donné à la fondation Apache qui l'accepte en tant que projet de l'incubateur Apache. Si ils font leur preuve du point de vue développement, utilisation et respect de la logistique de la fondation;,les projets de l'incubateur sont acceptés comme projet top level. Autrement bye bye. http://incubator.apache.org/incubation/Process_Description.h(...)

Après c'est à chaque projet de recruter ses développeurs comme n'importe quel projet libre.

Apache n'a rien a perdre comme temps ou comme argent ici (ou si peu). Les contributeurs sont libres de contribuer comme n'importe sur n'importe quel projet libre. Et si on considère que les devs vont perdre leur temps, j'ai envie de dire que la majorité des devs de logiciels libres perdent leur temps alors ;)

PS: Comment donner du code sous licence libre et sans contrepartie peut être un cadeau empoisonné ?

Je pense qu'il te manque une petite partie du puzzle.

Hudson est développé par Kohsuke Kawaguchi. Kohsuke en plus d'être un tueur qui ne doit pas souvent dormir, est un ancien employé de Sun. Il a commencé Hudson comme salarié de Sun, et Sun lui a même permis de bosser à temps plein dessus avant qu'il ne quitte le navire.

Je ne sais pas ce qui a été signé sur le projet, mais à priori tout le code qui a été pondu alors qu'il était chez Sun puis Oracle est sous copyright d'Oracle. Il est aussi possible que le nom Hudson et le projet Hudson soient à Oracle.


Bref ca n'a rien a voir avec le fait que le projet soit en Java. Si c'était un projet indépendant, il ferait ce qu'il veut.

Ou alors tu peux mensualiser, ou tu mets sur le compte quand tu reçois le joli papier te disant qu'on va te retirer de l'argent, ils préviennent...

1- T'as beau être mensualisé ca empêche pas le que quand tes impôts augmentent tu te fais salement rattraper à la fin de l'année et que t'as intêret à le prévoir.

2- C'est con d'être mensualisé. C'est quoi l'avantage a par perdre les intérêts sur ce que tu devras plus tard mais que tu préfères donner tout de suite...

J'ai pas essayé KissCount mais les logiciels simples comme HomeBank sont géniaux pour comprendre un peu ce qu'il se passe quand tu jongles entre quelques comptes pour avoir une vue globale facilement et pour voir l'évolution de ses dépenses par catégorie au fils du temps. Le rapport "passer 5 minutes par mois à importer ses QIF/OFX" sur "Je visualise facilement tout mes comptes, mes dépenses, la conso des voitures, le cout réelle de certaines activités etc." est très bon.

Bha oui puisque toute la base est dans le world qui ne compte pas en package...

Si tu veux je te fais un gros RPM qui contient toute la base d'une Fedora et j'aurais un système avec un seul paquet. Je te suis dans le raisonnement, mais autant rester réaliste.

T'es sur ? Par ce que quand on demande aux gens qui développent vraiment ils t'expliquent pourquoi ce qui te parait trivial depuis ta lunette de WC ne l' est pas vraiment. Genre on peut demander a Mike Melanson la: http://blogs.adobe.com/penguinswf/2010/01/solving_different_(...)

Ca explique aussi pourquoi, ils ont introduit un nouvel objet spécialement pour faire ça. C'est impossible d'utiliser l’accélération de la carte vidéo en supportant vraiment la spec de l'objet video...

Elle est petite ton install Debian qui tourne avec 30 paquets. Je veux bien voir la liste ;)

Donc en gros tu ne sais pas de quoi tu parles mais tu penses que c'est un mauvais choix ;)

Sérieusement, d'après le webalizer linuxfr n'a ni un traffic monstrueux, ni des tas de données non cachables. Si tu mets à genoux une machine de notre siècle avec ca c'est qu'il y a un soucis quelque part.

Tu parles de g1 ou des GC actuellement supportés ? J'ai pas vu de bench openDS sur G1 passer encore; si j'ai raté quelque chose je veux bien les sources.

Y'a vraiment des gens qui sont arrivés assez bas pour se faire des multis ? J'ai juste un compte de 2002 et pas du souvent dire du bien d'apple... Non, je me suis me répondu volontairement. La discussion du dessus correspondait exactement à ce que je disais dans mon commentaire.

Mais je n'espère plus vraiment voir une discussion plus évoluée que "C'est joli/C'est pas joli" ou "J'aime/J'aime pas" par des gens qui ont utilisé la chose plus de 10 TP. On peut refaire le monde autour d'un comptoir; ou simplement discuter des différentes solutions, qui existent vraiment, en essayant d'analyser en quoi chacune est plus ou moins adapté selon le contexte.
Ca me semble plus intéressant que de parler dans le vide de savoir si equals() c'est plus moche que ==. Par ce que même si tout le monde tombe d'accord, ca ne changera strictement rien.

http://www.oracle.com/technetwork/java/gc-tuning-5-138395.ht(...) Y'a carrément de quoi jouer. Simplement la taille des générations joue énormément. Ce sont les full collection qui font mal, le but c'est que ton appli arrive à se contenter au maximum de garbager les jeunes générations.

Et si tu utilises une update récente de Java 6 (de mémoire c'est arrivé en u14) tu as G1 qui est enfin un gc bien pensé et adapté aux contraintes des applis, au multicore et aux grosses heap: http://research.sun.com/jtech/pubs/04-g1-paper-ismm.pdf
D'ailleurs OpenDS en est très content il me semble et a participé à améliorer G1 depuis l'u14. G1 est prévu pour être le gc par défaut dans Java 7.

> mais généralement on lui reproche les mauvaise choses

C'est reparti. C'est toujours plus marrant de se tripoter pour savoir si a == b est plus beau que a.equals(b). Et puis discuter de choses triviales, finalement pas si importantes que ca, et qui ne changerons pas ; ca évite de se poser les vrais questions de savoir en quoi la techno nous aide ou pas à construire des choses qui fonctionnent, qui sont fiables, qui sont pérennes, qui sont maintenable, à quel coût en fonction du projet, des besoins et de son équipe. Mes deux cents, c'est que l'ingénierie logicielle c'est pas se tripoter pour savoir si on à le kiki tout dur en voyant son code... Et que le bon outil pour la tâche se défini selon beaucoup plus de critères que le simple nombre de caractères à taper en faisant un + plutôt qu'un .add().

PS: Vous pouvez discutez aussi longtemps que vous voulez. Le langage existe depuis 15 ans et vise la backward compatibilité absolue. Vous perdez totalement votre temps. Cherchez plutôt ce qu'il peut vous apporter; et si vous ne trouvez pas, oubliez le.

J'avais raté le second degré.

Mais marrant d'attaquer Java sur la documentation. On peut lui reprocher beaucoup de chose (mais généralement on lui reproche les mauvaise choses), mais c'est juste le langage le mieux documenté avec lequel j'ai bossé. Tu peux bosser sereinement, ca fait ce que ca dit et ca dit ce que ca fait. En général je préfère bosser avec d'autres langages, mais je regrette toujours la qualité de la doc de Java.

C'est juste la version longue en détaillant tout ce qu'il se passe, avec l'explication de pourquoi son code boggué explose et pourquoi tout est logique la dedans. Autrement ca se résume trivialement par une égalité de pointeur n'est pas une égalité de valeur.

Après tu penses ce que tu veux, et si t'as envie de t'autopersuader libre à toi. Mais puisqu'on est dans les avis à 3 sous, le mien c'est que pour trouver ca compliqué t'as pas du lire beaucoup de specs et ni essayé de décortiquer beaucoup de bout de code.

> Qui arriverait à vendre l'autoboxing comme une fonctionnalité plutôt qu'une mauvaise rustine visant à ne pas casser la compatibilité ?

Personne. Mais c'est pas incompatible avec ne pas raconter de conneries.

Non c'est simplement que tu ne comprends pas ce que tu fais.

1- Quand tu fais un new tu obtiens *toujours* un objet différent

System.out.println(new Integer(12) == new Integer(12)); => false

2- Quand tu fais System.out.println(a++ == b++) tu ne fais pas du *tout* ce que tu penses. Tu ne comprends donc pas le mécanisme d'autoboxing de Java
Integer a = new Integer(12); a++
Ca donne en Francais.

Pars d'un Integer, convertis le en int, ajoute lui un, convertis en Integer

Soit en bytecode:
0 new java.lang.Integer [16]
3 dup
4 bipush 12
6 invokespecial java.lang.Integer(int) [18]
9 astore_1 [a]
10 aload_1 [a]
11 invokevirtual java.lang.Integer.intValue() : int [21]
14 iconst_1
15 iadd
16 invokestatic java.lang.Integer.valueOf(int) : java.lang.Integer [25]
19 astore_1 [a]


3- Les versions objet des types primitif en Java sont immutable.

4- Il en découle que a n'est évidement plus le même objet quand tu fais ton a++. Il s'agit d'un nouvel objet créer par le valueOf

5- Rien n'empeche le valueOf d'optimiser ce qu'il retourne comme il le veut. La spec dit:
The result is an Integer object that represents the integer value specified by the string.


6- Pour optimiser la consommation mémoire, valueOf() utilise un cache d'entier pour certaines valeurs:

private static class IntegerCache {
private IntegerCache(){}

static final Integer cache[] = new Integer[-(-128) + 127 + 1];

static {
for(int i = 0; i < cache.length; i++)
cache[i] = new Integer(i - 128);
}
}


Bref la spec est entièrement cohérente et chaque fonctionnalité est orthogonale. Certains ne comprennent pas les mécanismes de base comme l'autoboxing ou les specs de certaines méthodes, c'est leur problème. Faut arrêter de cracher sur les technos par ce qu'on est pas compétent dessus... Java comme n'importe quel autre langage à des spécifications. Soit on code à l'arrache de manière empirique; soit on lit les specs et on comprend comment ca marche.


PS: Fait attention la JVM optimise aussi les strings. "toto" n'est pas du tout la même chose de new String("toto"). L'un te garanti l'unicité de l'objet pas l'autre.

C'est comme ca que fonctionne le contrôleur cpu des cgroups avec CFS.

Tu définis des cpu.shares dans pour chaque cgroup. Pour tout les cgroups du même niveau tu additionnes leur cpu.shares. Chaque groupe obtient la portion de sont cpu.shares / sommes(cpu.shares). Et tu itères le processus en descendant de la hiérarchie.

Tu peux donc dire des choses comme "L'ensemble de mes machines virtuelles n'utiliseras pas plus de 50% CPU si il y a contention sur l'accès au CPU et ma machine virtuelle X n'utilisera pas plus de 50% du temps CPU alloué aux machines virtuelles". Ce qui donnera donc 25% CPU au max donc si il y a contention entre un autre cgroup du niveau supérieur et un autre cgroup de machine virtuelle. Si il n'y a que des machines virtuelles qui veulent du CPU alors ma machine virtuelle donnée va récupérer 50% du CPU (50% de 100%). Mais aussi 50% si tu n'as que cette machine virtuelle mais qu'un autre cgroup du niveau supérieur veut du CPU.

C'est puissant mais bordélique selon ce que tu veux faire, par ce que ca devient rapidement facile de perdre l'idée globale de ce que ca fait en partie. Il n'y a pas moyen de faire quelque chose quand il n'y pas de contention. Donc si ton système est idle, la tache bouffera tout le CPU.

http://java.sun.com/docs/books/jls/third_edition/html/expres(...)

Je crois que c'est assez bien spécifié comme dans n'importe quel langage. Si tu supposes plus que la spécification alors c'est un PEBKAC comme dans n'importe quel langage.

> Et puis c'est pour du simple, pas question de faire un soft qui en tiendrait compte (d'ailleurs je ne vois pas l'intérêt de ça ? il me semblait qu'un des intérêts de cgroups était justement d'avoir ces conf possible point du vue système, sans que le dev de telle appli soit obligé de s'en pré-occuper).

Tu as des applis qui peuvent vouloir se limiter ou limiter leur processus fils automatiquement. Typiquement imagine un job scheduler. Le processus du scheduler est dans son cgroup et il créé un sous cgroup pour chaque job. Ca te permet de limiter la consommation CPU, mémoire, réseau ou d'attacher le job à un core donné. En cela les cgroups sont géniaux.

Bon dans le cas d'un job scheduler, tu peux te dire que tu peux faire la conf système et reposer sur des acquis. Mais quand tu veux faire un soft un peu plus généraliste ca devient un peu la guerre, entre l'interface via filesytem (c'est beaucoup plus pratique pour construire des applis stables et faire de la gestion d'erreur c'est bien connu...), le fait que c'est intégré différemment partout et souvent fait pour une bonne grosse conf statique root only, que la libcg est jeune, que tout est documenté plus ou moins à l'arrache de la doc noyaux jusqu'au outils de la libcg .

La techno est puissante, mais pour le moment ca reste jeune et bien linuxien dans l'esprit donc chiant à utiliser. Mais j'espère que c'est devenu mieux entre temps.

>> Cette fonctionnalité révolutionnaire a été un peu oubliée car la création des cgroup était manuelle
:))
> Enfin... la doc aujourd'hui est limpide.

Rassure moi c'est de l'ironie ?

C'est super comme concept, ca permet des trucs géniaux. Mais pour avoir implémenté un truc basé sur les cgroups y'a 3/6 mois c'est juste l'horreur. Tu passes une semaine au lieu d'une heure tellement la doc est pourrie, les fonctionnalités pas documentées, et la libcgroup jeune. Et ca devient encore plus drôle quand tu essayes de faire un soft qui s'auto-configure pour se limiter tout seul sans rien demander à l'utilisateur comme config système.

Je crois que je dois pas être le seul à le penser, quand on voit le code cgroup dans libvirt et comment il explose (ou explosait ? ) dans tout les sens.

Et comment on sait qu'un notaire online est de confiance ?