Je n'ai aucune idée si mes baragouinages auraient une quelconque valeur lors d'un conflit juridique dans un tribunal français.
T'inquiète pas, c'est le cas d'un certain nombre de licences. Quand tu vois que l'un des avantages de la troisième version de la GPL c'est d'être en accord avec les lois, on peut se demander ce que protège réellement les versions précédentes (notamment hors USA). J'ai cité RABL, mais tu as la beerware aussi ou les caritatiware (vim) qui sont assez rigolo et qui n'ont probablement pas de grande force légale. Mais ce qu'il faut comprendre c'est qu'en France, ton code est protégé par le droit d'auteur. Esnuite c'est à toi de céder ou non certains droits soit au cas par cas sur demande (tu peut donner le droit à Zenitram de réutiliser sans pour autant le donner à d'autre) soit de manière générique via une licence. Le seul risque c'est que tu créer une obligation qui soit illégale. Si tu le fait, je pense que l'obligation en question est réputée non-écrite et c'est comme si elle n'existait pas. L'autre risque c'est que ta licence ai des trous (genre tivoisation ou cas particulier non pris en compte), ça c'est un risque que tu as tout autant avec la GPL et c'est comme tout, il vaut mieux 2 lignes qui soient un peu générales et qui se comprennent bien que des pavés de 500 pages pleins de cas particuliers et de vices potentiels.
Si quelqu'un de plus compétent que moi sur le sujet veut me reprendre au vol je serais content d'en apprendre plus mais je crois que je ne dis pas (trop) de conneries. Je sais pas si je suis clair par contre.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Ben oui c'est désintéressé. Les licences libres sont là pour protéger les libertés des utilisateurs (regarde tous les discours, toutes les licences, etc sur le libre). L'objectif c'est que l'utilisateur garde le contrôle de sa machine et de ce qui s'exécute dessus. Dans les faits pour un grand nombre de logiciels ça ne change pas grand chose parce que c'est publié publiquement, mais rien ne m'empêche de prendre les sources de gcc et de linux, d'y faire des modifications de dingue (réécriture en rust et api des appels système en rust aussi) et de ne rien partager. Si j'en suis le seul utilisateur la question ne se pose pas. Ensuite je peux les installer que sur les ordinateurs de mes amis et leur donner un lien vers les sources juste pour eux.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Il me semble que la majeure partie du travail d'intel consiste à rendre les changements d'état (quelque soit le niveau de sommeil) les plus rapides possibles. Le fait que le cache soit vidé ne me semble pas si gênant que ça car c'est déjà ce qui se produit lorsque l'on fait travailler plusieurs tâches.
L'idée globale de Matthew Garret c'était de dire qu'il ne faut pas manuellement choisir la fréquence, mais plutôt laisser ondemande choisir le meilleur.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
En résumé, la seule façon logique d'utiliser un processeur est de le faire fonctionner aussi rapidement que possible afin de lui permettre de passer le plus de temps possible en état de sommeil, situation dans laquelle la fréquence et la tension sont au minimum. La seule façon logique.
Matthew Garrett
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Si tu parle de plus de 4Gio tu parle de logiciels qui utilisent plus de mémoire que la plus puissantes des machines que j'utilise. Je ne sais pas si c'est ridicule ou pas, je ne sais pas si les applications qui prennent tant de mémoire sont monnaies courantes ou pas (moi je n'en ai jamais rencontrée). J'ai travaillé surtout sur des systèmes distribués où l'on a 4Gio par nœud.
Bref le GC marche bien pour la plupart des besoins simples, par contre il faut savoir quand on va tapper ses limites et désigner en conséquence (et c'est un truc qu'on essai de faire assez tôt sinon tu pleures pendant longtemps). En Java les solutions sont assez crado mais ca se fait.
Je suis tout à fait d'accord.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Il faut mettre ça en balance avec la fragmentation de la mémoire que peuvent produire les langages où l'on gère manuellement la mémoire. C'est aussi une dette qui va augmenter la pression sur la gestion de la mémoire. Une fois que le full-gc est passé, on a éliminé cette dette (on compact la mémoire). Pour un programme qui gère manuellement sa mémoire c'est bien plus compliqué.
Grosso modo quand on programme il faut connaître le modèle de mémoire et il y a un tas de technique pour réduire la pression sur la gestion de la mémoire. Java ou le C++ ne font pas exception, C++ va exploser si ça arrive (mais ça peut être insidieux et très difficile à debugguer) alors que Java va être lent (mais ça peut être insidieux et très difficile à debugguer).
Oui, les référence faibles aident la chose et permettent de faire du référence counting uniquement. Mais cela complexifie le travail du dèv. est cela rapproche (non ce n'est pas la même chose, je n'ai pas dit cela) de la gestion manuelle.
C'est un peu plus sophistiqué que du comptage de références ou du moins il y a un peu plus de possibilités. Tu parle des weak références, mais les soft référence peut aussi être très pratiques.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Avec MAT tu peut voir chaque objet en sachant qui le référence. Il ne permet pas directement de savoir comment il a était alloué par exemple si tu fait :
Tu ne pourra pas faire grand chose (c'est pas non plus un cas que j'ai rencontré). Il se base sur un dump de la mémoire et ne donne donc qu'une image à un moment donné de l'état du programme, c'est suffisant dans tous les cas que j'ai rencontré). Sinon je pense que ça deviens plus compliqué et qu'il faut regarder s'il n'y a pas des alternatives à la jconsole qui soit plus performant et donnent plus d'informations (Oracle à fourni des outils récemment qui vont dans cette direction je crois mais je n'ai pas regardé plus en détail).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
On sait tous que le full-gc commence par un stop-th-world, mais tu semble affirmer que la situation empire avec le temps. C'est faux, elle est au pire cas juste avant le full-gc une fois ce dernier déclenché tu repars sur une bonne base. L'objectif principal des garbage collector c'est de rendre tout ça aussi court et prédictible que possible.
Le reboot c'est quand tu ne réfléchis pas. « Nullifier » c'est quand tu y as réfléchis. La fuite mémoire en java cela se résous à coup de nullification sur les objets de longue durée.
Je n'ai presque jamais connu de cas où il était nécessaire de nullifier et l'utilisation de références faibles à presque supprimé la totalité des cas d'utilisation (en fait mis à part si tu écris des structures de données je n'en vois pas l'usage).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Merci, d'avoir enlevé le contexte de mon post. Je répondais à un mensonge éhonté. Le 15 ans est la pour mentionner que les ramasse-miettes pour le C/C++ ce n'est pas une histoire nouvelle. Cela existe depuis longtemps, très longtemps.
J'ai peut être mal compris ta phrase. Qu'il y ai eu révolution ou pas en 15 ans (la différence entre révolution et évolution peut subtile). Les techniques ont largement évoluées et les performances avec. Ta phrase laisse penser que ça existe depuis 15 ans et que depuis c'est stable et performant. C'est comme tout c'est une technique qui évolue. Le plus évolué que je connaisse c'est G1 et il offre des possibilités qui n'ont rien avoir avec ce qui se faisait il y a quelques temps.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Donc, au bout du compte, tu développes longuement en te reposant sur le garbage. Et à la fin, très fréquemment, tu te rends compte que le système laggue monstrueusement après quelques heures/jours d'utilisation parce que le GC à de plus en plus de mal sans aide.
C'est faux. Ce que tu décris c'est un code qui fait de la fuite mémoire écris par des développeurs qui s'imaginent que le gc supprime les fuites mémoire ce qui est faux. Un gc récent ne pause pas ce genre de problème. Par exemple en Java, tu sais qu'après un full-gc tu repars d'une mémoire propre. Si tu as ce genre de problème de performance c'est que quelque part tu garde des références vers des objets que le gc ne pourra donc jamais désallouer. Tu peut régler ça avec des reboot ou en nullifiant les références en question si tu n'a pas le temps de réfléchir au problème, mais en réalité c'est un problème de fuite mémoire, pas de garbage collector.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Ben disons que les gens ont compris que ça sert à rien, donc pas courant, oui.
Par les gens, tu entends ceux qui font du C, du C++, du Vala et du rust (plus d'autres), il reste tout de même les quelques personnes qui font du Java, du python, du perl, du ruby, du PHP, du C#, du go, de l'ocaml et du js qui n'ont pas compris. Si c'est d'une telle évidence, ça fait encore un paquet de monde d'horizon très divers qui se fourvoient.
Je ne me risquerais pas à dire que l'un ou l'autre ne fonctionne pas. Ce serait totalement idiot et ferrait preuve d'une mauvaise foie sans limite tant les exemples sont nombreux pour montrer que l'usage d'un garbage peut très bien fonctionner, que la gestion manuelle de la mémoire aussi ainsi que d'autres variantes (comme les pointeurs intelligents du C++, je n'ai pas compris pourquoi ce n'est pas de ça dont il a était question immédiatement).
De plus tu parle des garbages collectors comme si l'état de l'art n'avait pas évolué depuis 1995 c'est totalement faux, il existe différentes familles de garbage collector (la plus connue étant les gc générationnels) et plusieurs continues d'évoluer. G1 qui est le gc officiel de Java7 est extrêmement sophistiqué et n'a aucun rapport avec ce que l'on pouvait trouver il y a quelques années.
Mais tout ça te passe bien au dessus, non seulement tu parle de choses que tu ne connais pas, mais surtout que tu ne souhaite pas connaître. Le problème ce n'est pas que tu semble ignorant en la matière¹, mais que tu répand celle-ci avec fierté.
[1] : j'espère que tu es simplement ignorant parce que sinon c'est volontairement du FUD et de le désinformation
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Je ne suis pas d'accord avec le fait que l'architecture est entièrement dé-corrélée du langage.
Tu répond à qui là ? Parce que ce n'est pas ce que j'ai écris, ni ce que j'ai sous-entendu. J'ai dis que des fois le langage porte des contraintes sur l'architecture, mais que ce n'est pas le cas dans tes arguments. Avoir un gros binaire qui fait tout c'est aussi mauvais (d'un point de vu architectural) en C qu'en rust.
Si tu écris ton logiciel dans un langage qui a une notion de propriété de la mémoire forte, tu n'as pas forcément besoin de séparer les composants dans différents processus, parce que la séparation de privilèges a lieue déjà au niveau du langage d'une certaine manière.
C'est faux.
La séparation en processus n'est pas faites que pour la sécurité. C'est fait pour améliorer la testabilité, la gestion des erreurs etc
La séparation des privilèges se fout éperdument du langage que tu utilise.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Tu rentre dans un troll sur les systèmes d'init avec un troll sur les langages et tu te plains, c'est du foutage de gueule.
systemd souhaite utiliser les API du noyau, elles sont en C, il a donc choisi d'utiliser du C (et un langage qu'il connaît bien).
Donc, à mon avis quand on code en C, on a tout intérêt à coder de manière modulaire et de séparer les privilèges dans différents contextes de sécurités, en utilisant les mécanismes de l'OS sous-jacent.
Alors que quand on écris du ruby, écrire un bon gros script d'un million de lignes qui réinvente la roue ce n'est pas un problème ? Tu mélange 2 choses totalement séparée, l'architecture et le langage utilisé. Une architecture est bonne ou mauvaise indépendamment du langage (en fait le langage peut donner des facilité d'architecture ou non, mais ce n'est pas ce dont tu parle).
Si tu as des arguments contre l'architecture de systemd parles-en, zenitram a juste dis que troller sur le langage (ce que tu fais) c'est puéril (et il a raison).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
En effet la demande est dupliquée, mais je trouve tout de même le code plus court (ça c'est factuel) et plus lisible¹ (on vois tout de suite que la boucle sert uniquement à valider la saisie sans avoir à parcourir l'ensemble de la boucle.
Par contre, je suis d'accord que ce n'est pas optimal, on a pas de boucle qui rend vraiment la sémantique en question.
Personnellement sans m'en faire une règle inviolable, j'évite au maximum les break et les return multiples. Ils peuvent facilement rendre un code illisible car ce sont des sauts qui ne portent pas de sémantique (contrairement à un foreach par exemple). De plus d'un point de vu maintenabilité, ils multiplient les points de sorties (du coup ajouter des traitements à la fin peu devenir plus délicat). AMHA la taille du code et la complexité cyclomatique peuvent être de bonnes métriques pour essayer de choisir (je dis pas de les suivre aveuglément juste que ça aide à choisir).
[1] ça dépend largement de la taille de la boucle (et c'est subjectif), mais si une boucle devient trop grande j'essaie de sortir son corps (ou une partie de son corps dans une méthode séparée)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Moi ça ne m'a pas laissé sur ma faim, mais au contraire, je me demande si tout est raisonnable!?
Le travail a déjà commencé. S'ils l'annonce c'est pas qu'ils sont sûr d'y arriver, mais c'est qu'ils en ont quand même une petite idée. On en parlait déjà à la sortie de Debian 7
D'ailleurs ça donne un lien intéressant sur l'avancé du travail : http://clang.debian.net/ On voit que 90% de paquets sont déjà prêts.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Avec des si on peut en faire des choses. Par exemple on peut dire que c'est lui qui réalise l'installation sur toutes les machine du monde (c'est dans ses cordes).
Mais en vrai les internautes ne font pas parti d'un même réseau d'entreprise administré via un quelconque gestionnaire de parc informatique, ils se paluche leur installation locale ou utilise une installation distante si elle est facile d'accès (via du web donc).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Certes, mais comparer le nombre d'étapes avant le test d'un logiciel déjà installé, même sur une machine distante, à celui d'un logiciel non installé est fallacieux.
L'un des tests est en O(n+m) avec n le nombre d'action lors de l'installation de la webapp et m le nombre de machines sur le quel on l'utilise, l'autre est en O(j*m) avec j le nombre d'actions pour l'installer et m le nombre de machines sur le quel on l'utilise. D'après toi la quelle de ces 2 fonctions croit le plus rapidement ?
C'est rigolo parce que cette fois l'argument bateau « ouai mais le natif c'est rapide » ne tiens pas, au contraire la démo mange moins de mémoire que LibO sur ma machine cliente (je ne sais pas pour le serveur, mais comme je crois que c'est entièrement en js).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Après, le coup d'itérer sur des structures contiguës en mémoire, moi c'est clairement pas toujours le cas, je manipule beaucoup des structures qui ressemblent un peu au QList (des tableaux de pointeurs sur des objets) par exemple.
C'est donc un tableau (de pointeurs et pas d'objet). Si tu as un accès par index c'est que tu as des données séquentielles, sinon c'est que tu a une surcouche qui te cache la complexité de ton appel.
Si tu as une autre forme de structure le parcourt séquentiel n'a pas forcément de sens (comme sur un ensemble) et tu as des accès autrement (comme dans le cas d'une liste chaîner). Le seul cas où ça a du sens d'utiliser un indexe, c'est quand tu ne traite pas toutes ta structure (tu veux éviter de passer sur les premiers éléments, comme dans certains tris, ou si tu ne parcourt pas l'ensemble de la structure) ou quand tu veut utiliser cet index comme résultat pour un traitement ultérieur (mais dans ce cas il faut pas l'appeler i).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Incohérence de la demande
Posté par barmic . En réponse au journal Aidez moi à choisir mes licences !. Évalué à 5.
T'inquiète pas, c'est le cas d'un certain nombre de licences. Quand tu vois que l'un des avantages de la troisième version de la GPL c'est d'être en accord avec les lois, on peut se demander ce que protège réellement les versions précédentes (notamment hors USA). J'ai cité RABL, mais tu as la beerware aussi ou les caritatiware (vim) qui sont assez rigolo et qui n'ont probablement pas de grande force légale. Mais ce qu'il faut comprendre c'est qu'en France, ton code est protégé par le droit d'auteur. Esnuite c'est à toi de céder ou non certains droits soit au cas par cas sur demande (tu peut donner le droit à Zenitram de réutiliser sans pour autant le donner à d'autre) soit de manière générique via une licence. Le seul risque c'est que tu créer une obligation qui soit illégale. Si tu le fait, je pense que l'obligation en question est réputée non-écrite et c'est comme si elle n'existait pas. L'autre risque c'est que ta licence ai des trous (genre tivoisation ou cas particulier non pris en compte), ça c'est un risque que tu as tout autant avec la GPL et c'est comme tout, il vaut mieux 2 lignes qui soient un peu générales et qui se comprennent bien que des pavés de 500 pages pleins de cas particuliers et de vices potentiels.
Si quelqu'un de plus compétent que moi sur le sujet veut me reprendre au vol je serais content d'en apprendre plus mais je crois que je ne dis pas (trop) de conneries. Je sais pas si je suis clair par contre.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Destinataire Share Alike
Posté par barmic . En réponse au journal Aidez moi à choisir mes licences !. Évalué à 5.
Ben oui c'est désintéressé. Les licences libres sont là pour protéger les libertés des utilisateurs (regarde tous les discours, toutes les licences, etc sur le libre). L'objectif c'est que l'utilisateur garde le contrôle de sa machine et de ce qui s'exécute dessus. Dans les faits pour un grand nombre de logiciels ça ne change pas grand chose parce que c'est publié publiquement, mais rien ne m'empêche de prendre les sources de gcc et de linux, d'y faire des modifications de dingue (réécriture en rust et api des appels système en rust aussi) et de ne rien partager. Si j'en suis le seul utilisateur la question ne se pose pas. Ensuite je peux les installer que sur les ordinateurs de mes amis et leur donner un lien vers les sources juste pour eux.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Incohérence de la demande
Posté par barmic . En réponse au journal Aidez moi à choisir mes licences !. Évalué à 3.
Tu as le sentiment que c'est un juriste qui a écris le RABL ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pourquoi les constructeurs augmentent le nombre de points de fonctionnement tension/fréquence?
Posté par barmic . En réponse au journal Amélioration des performances graphiques du noyau 3.12. Évalué à 2.
Il me semble que la majeure partie du travail d'intel consiste à rendre les changements d'état (quelque soit le niveau de sommeil) les plus rapides possibles. Le fait que le cache soit vidé ne me semble pas si gênant que ça car c'est déjà ce qui se produit lorsque l'on fait travailler plusieurs tâches.
L'idée globale de Matthew Garret c'était de dire qu'il ne faut pas manuellement choisir la fréquence, mais plutôt laisser ondemande choisir le meilleur.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: la réponse est évidente
Posté par barmic . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. Évalué à 1.
Oui, merci c'est ce que l'on appel l'allocation sur la pile, mais la taille de la pile est limitée et bien plus petite que le tas (http://stackoverflow.com/questions/10482974/why-is-stack-memory-size-so-limited).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pourquoi les constructeurs augmentent le nombre de points de fonctionnement tension/fréquence?
Posté par barmic . En réponse au journal Amélioration des performances graphiques du noyau 3.12. Évalué à 3.
https://linuxfr.org/news/gestion-de-l%C3%A9nergie-se-d%C3%A9p%C3%AAcher-de-ne-rien-faire
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: la réponse est évidente
Posté par barmic . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. Évalué à 2.
Un peu quand même sinon c'est que tu alloue assez peu de mémoire.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: la réponse est évidente
Posté par barmic . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. Évalué à 3.
Si tu parle de plus de 4Gio tu parle de logiciels qui utilisent plus de mémoire que la plus puissantes des machines que j'utilise. Je ne sais pas si c'est ridicule ou pas, je ne sais pas si les applications qui prennent tant de mémoire sont monnaies courantes ou pas (moi je n'en ai jamais rencontrée). J'ai travaillé surtout sur des systèmes distribués où l'on a 4Gio par nœud.
Je suis tout à fait d'accord.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: la réponse est évidente
Posté par barmic . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. Évalué à 2.
Il faut mettre ça en balance avec la fragmentation de la mémoire que peuvent produire les langages où l'on gère manuellement la mémoire. C'est aussi une dette qui va augmenter la pression sur la gestion de la mémoire. Une fois que le full-gc est passé, on a éliminé cette dette (on compact la mémoire). Pour un programme qui gère manuellement sa mémoire c'est bien plus compliqué.
Grosso modo quand on programme il faut connaître le modèle de mémoire et il y a un tas de technique pour réduire la pression sur la gestion de la mémoire. Java ou le C++ ne font pas exception, C++ va exploser si ça arrive (mais ça peut être insidieux et très difficile à debugguer) alors que Java va être lent (mais ça peut être insidieux et très difficile à debugguer).
C'est un peu plus sophistiqué que du comptage de références ou du moins il y a un peu plus de possibilités. Tu parle des weak références, mais les soft référence peut aussi être très pratiques.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: J'en pense que
Posté par barmic . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. Évalué à 2.
Avec MAT tu peut voir chaque objet en sachant qui le référence. Il ne permet pas directement de savoir comment il a était alloué par exemple si tu fait :
Tu ne pourra pas faire grand chose (c'est pas non plus un cas que j'ai rencontré). Il se base sur un dump de la mémoire et ne donne donc qu'une image à un moment donné de l'état du programme, c'est suffisant dans tous les cas que j'ai rencontré). Sinon je pense que ça deviens plus compliqué et qu'il faut regarder s'il n'y a pas des alternatives à la jconsole qui soit plus performant et donnent plus d'informations (Oracle à fourni des outils récemment qui vont dans cette direction je crois mais je n'ai pas regardé plus en détail).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: la réponse est évidente
Posté par barmic . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. Évalué à 3.
On sait tous que le full-gc commence par un stop-th-world, mais tu semble affirmer que la situation empire avec le temps. C'est faux, elle est au pire cas juste avant le full-gc une fois ce dernier déclenché tu repars sur une bonne base. L'objectif principal des garbage collector c'est de rendre tout ça aussi court et prédictible que possible.
Je n'ai presque jamais connu de cas où il était nécessaire de nullifier et l'utilisation de références faibles à presque supprimé la totalité des cas d'utilisation (en fait mis à part si tu écris des structures de données je n'en vois pas l'usage).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: J'en pense que
Posté par barmic . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. Évalué à 2.
La JVM possède tout ce qu'il faut pour ça aussi.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: la réponse est évidente
Posté par barmic . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. Évalué à 2.
J'ai peut être mal compris ta phrase. Qu'il y ai eu révolution ou pas en 15 ans (la différence entre révolution et évolution peut subtile). Les techniques ont largement évoluées et les performances avec. Ta phrase laisse penser que ça existe depuis 15 ans et que depuis c'est stable et performant. C'est comme tout c'est une technique qui évolue. Le plus évolué que je connaisse c'est G1 et il offre des possibilités qui n'ont rien avoir avec ce qui se faisait il y a quelques temps.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: la réponse est évidente
Posté par barmic . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. Évalué à 3.
C'est faux. Ce que tu décris c'est un code qui fait de la fuite mémoire écris par des développeurs qui s'imaginent que le gc supprime les fuites mémoire ce qui est faux. Un gc récent ne pause pas ce genre de problème. Par exemple en Java, tu sais qu'après un full-gc tu repars d'une mémoire propre. Si tu as ce genre de problème de performance c'est que quelque part tu garde des références vers des objets que le gc ne pourra donc jamais désallouer. Tu peut régler ça avec des reboot ou en nullifiant les références en question si tu n'a pas le temps de réfléchir au problème, mais en réalité c'est un problème de fuite mémoire, pas de garbage collector.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: la réponse est évidente
Posté par barmic . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. Évalué à 4.
Bien sûr la R&D sur les gc s'est arrêté en 1995…
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: la réponse est évidente
Posté par barmic . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. Évalué à 4.
Par les gens, tu entends ceux qui font du C, du C++, du Vala et du rust (plus d'autres), il reste tout de même les quelques personnes qui font du Java, du python, du perl, du ruby, du PHP, du C#, du go, de l'ocaml et du js qui n'ont pas compris. Si c'est d'une telle évidence, ça fait encore un paquet de monde d'horizon très divers qui se fourvoient.
Je ne me risquerais pas à dire que l'un ou l'autre ne fonctionne pas. Ce serait totalement idiot et ferrait preuve d'une mauvaise foie sans limite tant les exemples sont nombreux pour montrer que l'usage d'un garbage peut très bien fonctionner, que la gestion manuelle de la mémoire aussi ainsi que d'autres variantes (comme les pointeurs intelligents du C++, je n'ai pas compris pourquoi ce n'est pas de ça dont il a était question immédiatement).
De plus tu parle des garbages collectors comme si l'état de l'art n'avait pas évolué depuis 1995 c'est totalement faux, il existe différentes familles de garbage collector (la plus connue étant les gc générationnels) et plusieurs continues d'évoluer. G1 qui est le gc officiel de Java7 est extrêmement sophistiqué et n'a aucun rapport avec ce que l'on pouvait trouver il y a quelques années.
Mais tout ça te passe bien au dessus, non seulement tu parle de choses que tu ne connais pas, mais surtout que tu ne souhaite pas connaître. Le problème ce n'est pas que tu semble ignorant en la matière¹, mais que tu répand celle-ci avec fierté.
[1] : j'espère que tu es simplement ignorant parce que sinon c'est volontairement du FUD et de le désinformation
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mon opinion sur systemd
Posté par barmic . En réponse à la dépêche Entretien avec François Tigeot, développeur DragonFly BSD. Évalué à 4.
Tu répond à qui là ? Parce que ce n'est pas ce que j'ai écris, ni ce que j'ai sous-entendu. J'ai dis que des fois le langage porte des contraintes sur l'architecture, mais que ce n'est pas le cas dans tes arguments. Avoir un gros binaire qui fait tout c'est aussi mauvais (d'un point de vu architectural) en C qu'en rust.
C'est faux.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mon opinion sur systemd
Posté par barmic . En réponse à la dépêche Entretien avec François Tigeot, développeur DragonFly BSD. Évalué à 10.
Tu rentre dans un troll sur les systèmes d'init avec un troll sur les langages et tu te plains, c'est du foutage de gueule.
systemd souhaite utiliser les API du noyau, elles sont en C, il a donc choisi d'utiliser du C (et un langage qu'il connaît bien).
Alors que quand on écris du ruby, écrire un bon gros script d'un million de lignes qui réinvente la roue ce n'est pas un problème ? Tu mélange 2 choses totalement séparée, l'architecture et le langage utilisé. Une architecture est bonne ou mauvaise indépendamment du langage (en fait le langage peut donner des facilité d'architecture ou non, mais ce n'est pas ce dont tu parle).
Si tu as des arguments contre l'architecture de systemd parles-en, zenitram a juste dis que troller sur le langage (ce que tu fais) c'est puéril (et il a raison).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: j'ai arrêté, ça marche pas.
Posté par barmic . En réponse au sondage Les commentaires et vous ? . Évalué à 5. Dernière modification le 26 octobre 2013 à 22:00.
En effet la demande est dupliquée, mais je trouve tout de même le code plus court (ça c'est factuel) et plus lisible¹ (on vois tout de suite que la boucle sert uniquement à valider la saisie sans avoir à parcourir l'ensemble de la boucle.
Par contre, je suis d'accord que ce n'est pas optimal, on a pas de boucle qui rend vraiment la sémantique en question.
Personnellement sans m'en faire une règle inviolable, j'évite au maximum les
breaket lesreturnmultiples. Ils peuvent facilement rendre un code illisible car ce sont des sauts qui ne portent pas de sémantique (contrairement à unforeachpar exemple). De plus d'un point de vu maintenabilité, ils multiplient les points de sorties (du coup ajouter des traitements à la fin peu devenir plus délicat). AMHA la taille du code et la complexité cyclomatique peuvent être de bonnes métriques pour essayer de choisir (je dis pas de les suivre aveuglément juste que ça aide à choisir).[1] ça dépend largement de la taille de la boucle (et c'est subjectif), mais si une boucle devient trop grande j'essaie de sortir son corps (ou une partie de son corps dans une méthode séparée)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Objectifs envisagés pour Debian 8
Posté par barmic . En réponse à la dépêche Debian 7.2 et futur gel de Debian 8.0. Évalué à 8.
Le travail a déjà commencé. S'ils l'annonce c'est pas qu'ils sont sûr d'y arriver, mais c'est qu'ils en ont quand même une petite idée.
On en parlait déjà à la sortie de Debian 7
D'ailleurs ça donne un lien intéressant sur l'avancé du travail : http://clang.debian.net/ On voit que 90% de paquets sont déjà prêts.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: La démo de WebODF
Posté par barmic . En réponse au journal Owncloud documents. Évalué à 3.
Avec des si on peut en faire des choses. Par exemple on peut dire que c'est lui qui réalise l'installation sur toutes les machine du monde (c'est dans ses cordes).
Mais en vrai les internautes ne font pas parti d'un même réseau d'entreprise administré via un quelconque gestionnaire de parc informatique, ils se paluche leur installation locale ou utilise une installation distante si elle est facile d'accès (via du web donc).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: La démo de WebODF
Posté par barmic . En réponse au journal Owncloud documents. Évalué à 4.
Et c'est utilisé par au moins 30 applications… (sic)
Dommage qu'il soit concurrencé par klik, runz et autopackage au moins.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: La démo de WebODF
Posté par barmic . En réponse au journal Owncloud documents. Évalué à 3.
L'un des tests est en O(n+m) avec n le nombre d'action lors de l'installation de la webapp et m le nombre de machines sur le quel on l'utilise, l'autre est en O(j*m) avec j le nombre d'actions pour l'installer et m le nombre de machines sur le quel on l'utilise. D'après toi la quelle de ces 2 fonctions croit le plus rapidement ?
C'est rigolo parce que cette fois l'argument bateau « ouai mais le natif c'est rapide » ne tiens pas, au contraire la démo mange moins de mémoire que LibO sur ma machine cliente (je ne sais pas pour le serveur, mais comme je crois que c'est entièrement en js).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Méthode moyenageuse
Posté par barmic . En réponse au sondage Les commentaires et vous ? . Évalué à 0.
T'induire, non ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Code auto-documente
Posté par barmic . En réponse au sondage Les commentaires et vous ? . Évalué à 2.
C'est donc un tableau (de pointeurs et pas d'objet). Si tu as un accès par index c'est que tu as des données séquentielles, sinon c'est que tu a une surcouche qui te cache la complexité de ton appel.
Si tu as une autre forme de structure le parcourt séquentiel n'a pas forcément de sens (comme sur un ensemble) et tu as des accès autrement (comme dans le cas d'une liste chaîner). Le seul cas où ça a du sens d'utiliser un indexe, c'est quand tu ne traite pas toutes ta structure (tu veux éviter de passer sur les premiers éléments, comme dans certains tris, ou si tu ne parcourt pas l'ensemble de la structure) ou quand tu veut utiliser cet index comme résultat pour un traitement ultérieur (mais dans ce cas il faut pas l'appeler i).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)