Dans ce cas, un lien sur zulip serait intéressant. Ce qui le serait encore plus, c'est de développer le pourquoi tu ne comprend pas l'intérêt de discord (moi non plus je pige pas, mais bon, je suis vieux, j'utilise encore irc qui n'a toujours l'history qu'en draft pour la v3…)
Ouai, en gros haskell est juste à l'ouest: plus lent malgré le parallélisme, et bouffe le double de ram.
Ton message était censé promouvoir haskell, ou l'enfoncer?
Oh, d'un point de vue pragmatique, j'ai toujours un argument perso: je peux installer un OS sur moins de 50 gigs de stockage (avec, ou sans, la partition /home).
Sous windows, de ce que je vois au boulot (j'ai pas creusé, je suis plus ingé, on ne me demande plus de résoudre la racine des problèmes, juste les symptomes) il vaut mieux prévoir 150 gig pour la partoche système. Ca a un impact sur le coût du PC, l'air de rien… Je ne parle pas de la RAM ni du reste, hein. D'ailleurs, si j'en parlais, je dirais que je peux installer un OS complet et moderne sur 20 gigs de stockage sans le /home :)
Une autre raison: dans wiNdows il y a forcément un haine. Bon, ça, c'est fait, moi je suis plus la, salut …
Et du coup tu fais ça a chaque fois? Même si je comprend ton opinion (c'est moche, ils bossent pas pour rien) ils font un service gratos (vous êtes le produit) et promeuvent (sans le vouloir?) le LL.
Ma foi, je suis bien incapable de trouver un meilleur business model pour le libre.
Tu as oublié le plus important: pas d'installation, et pas de pré-requis dans la base de registre.
Franchement, la compilation… les utilisateurs s'en contre-branlent!
Il me semblait avoir compris que le terme portable du commentaire précédent avait un sens très différent que celui admis parmi les linuxiens
Je me souviens de mon passé de windowsien. Pour moi, une appli portable était… ben, un truc portable entres OS. Mais bon, j'étais déjà un codeur.
En fait, ici, le terme idéal serait: «une appli transportable» parce que c'est de ça qu'on parle. Pour être transportable, une appli ne doit pas nécessiter de traces dans le système sur lequel elle est utilisée. J'ai dit: nécessiter, ça veut dire que ça doit marcher sans installateur, mais pas forcément que ça ne doit pas laisser de traces (ça, c'est l'idéal, mais c'est techniquement impossible si l'OS décide d'espionner)
Je pense personnellement qu'il y a un sérieux problème en informatique: les soit-disant ingénieurs, qui sont plus des in-gêneurs, semblent faire leur maximum pour empêcher les gens d'utiliser leurs outils.
Evidemment ça ne concerne pas les gens qui obéissent aux ordres… quoique…
Aujourd'hui sur la route, ou c'était peut-être hier, j'ai entendu le type (titre: gouverneur je crois?) de la banque centrale française répondre au journaliste un truc du genre "ce qu'il faudrait avec les impôts, ce n'est ni les baisser, ni les monter, mais de la stabilité, parce que c'est la stabilité qui induit la confiance". Un truc dans ce goût la. Le monsieur m'a choqué (positivement) par son pragmatisme (et son objectivité apparente).
Je pense que cette idée n'est pas conne: la stabilité serait effectivement une bonne idée. Que ce soit pour les finances (son sujet, son problème) ou pour la sécurité informatique (le problème dont on parle, ici).
Si les interfaces pouvaient être constantes sur plus d'une décennie, je crois que ça mènerait à une bien meilleure amélioration de la sécurité informatique, ainsi qu'a une amélioration de la performance. Pourquoi? Parce qu'alors on passerait moins de temps a former les gens sur les trucs de base, pour se concentrer sur ce qui est important, et les gens, dont je fait partie, perdraient moins leur repères et seraient donc plus entraînés a repérer les irrégularités.
En gros, je crois que les principaux responsables de l'insécurité (et je ne le savait pas il y a 15 minutes) sont les gens qui produisent les OS. Si on… ah, c'est vrai, je ne suis plus dev de métier… si ils faisaient leur job pour la sécurité, alors ils arrêteraient de changer ces putain d'IHM tous les ans! Aussi con que ça puisse paraître, OUI, C'EST LIÉ!
Je suis d'accord sur le fait que wikipedia n'est pas, ou plutôt ne devrais pas, être une référence centrale, et les choses peuvent exister en dehors. (j'ai failli pondre un mur de texte, mais je partais hors sujet, donc je vire :))
Le problème n'est pas "c'est connu donc on garde" ou "ce n'est pas connu donc on vire", mais plutôt "moi [personne avec un certain pouvoir], qui passe sur une page aléatoire, ne connaît pas le sujet, donc je marque pour que ça soit viré". Wikipedia vise à être une encyclopédie, du coup je trouve ce type de comportement dommageable. Apparemment, je ne suis pas le seul d'ailleurs: j'ai été mis au courant via IRC avant même de lire DLFP (que je lis de moins en moins souvent, j'admets) et en dehors de moi, un certain nombre de personnes semblent avoir réagi assez vivement.
Mon sentiment au final, c'est que le wikipedia francophone est… peu (pour ne pas dire pas) crédible, à cause de son manque clair de contenu, et le zèle qui a été discuté ici est une possible cause de ce manque de contenu: il est plus facile d'améliorer du contenu que de le créer "from scratch", hors le fameux bandeau génère une suppression automatique, historique inclus apparemment (selon ce que j'ai compris des dires de Thomas Debesse) ce qui implique de refaire tout le boulot à chaque fois qu'il y a un suppression.
Pour un dev, c'est l'équivalent de git rebase pour virer le contenu produit par d'autres… et je peux clairement comprendre que ça génère de vifs sentiments d'incompréhension.
Après, en soit, c'est leur projet. Si on est pas content, yakaforker, je sais bien. Je ne suis pas sûr que ça soit super productif, par contre, compte tenu de l'ambition (que j'ai compris, mais si ça se trouve je suis juste à côté de la plaque) du projet.
Pour aboutir a une conclusion, il faudrait connaître le ratio d'articles a bandeaux qui ont effectivement causé une discussion.
Ici, elle ne s'est produite que parce que Xonotic est LOIN d'être un projet inconnu, et pourtant il a déjà été viré de wikipedia, ce qui montre justement le problème.
En fait, ne pas connaître xonotic pour un amateur de FPS libre reviens a ne pas connaître wesnoth pour un amateur de TBS libre: c'est impossible. Il est bien plus représentatif que, par exemple, red-eclipse, sauerbraten (je suis pas sûr que le contenu soit libre) ou uebergame (je ne serais pas surpris que personne ici ne connaisse ce jeu).
A titre personnel je n'aime pas xonotic, et n'ai jamais vraiment aimé Nexuiz (logique). N'empêche que je connais ces projets depuis des années, sans être un expert dans le domaine.
Je ne crois pas que faire de la suppression de masse pour tester la réactivité des contributeurs soit une bonne chose: il est très probable que les-dits contributeurs aient autre chose à foutre qu'ergoter sur un article de la wikipedia française, compte tenu de la qualité moyenne (très, très faible, comparé à la version anglaise). Ce genre de comportement me semble plutôt contre productif: combien de personnes qui ont initialement crée et maintenu l'article vont être écoeurées par ce bandeau stupide venu d'une personne qui fait dans le zèle administratif (et ne connais rien au sujet, manifestement)?
En fait, je me demande bien d'où viens l'idée que le développement ou le travail "ensemble" ça marche mieux.
Je suis entièrement convaincu par le libre, pas de souci la dessus, mais le communautarisme… me convainc beaucoup moins.
Les communautés ont toujours (de ce que j'ai vu) un ensemble de règles, plus ou moins (psycho-)rigides, à tort ou a raison (on trouve les deux dans la nature, parfois même ensemble), un fort biais historique (un leader charismatique du passé aura plus d'influence que quelqu'un qui s'implique pour de vrai, tout de suite, maintenant, peu importe le degré de compétences) et… bref, ça me semble pas aider.
Oui, je pense que les projets ont besoin de rigidité, et pouvoir être aidé par la communauté est très bénéfique dans bien des situations, mais quand une communauté est mourante, si personne n'a réussi a fork la communauté avant, c'est le projet entier qui risque de passer par un coma profond, qui peut durer des années, et mener soit à la mort, soit à un vivotage du projet.
N'empêche, je ne comprend pas ce centrage sur le communautarisme. Un projet est libre s'il respecte un certain nombre de libertés, qui me semble bien définit et accepté dans le cadre du logiciel… et pourtant nombre de gens veulent y ajouter des contraintes (pas d'argent, pas d'usage militaire, etc etc etc) et c'est ce contre quoi zenitram s'insurge, à raison, à chaque fois (en tout cas c'est comme ça que le comprend, je me trompe peut-être, je n'ai jamais été versé dans la communication et la sociabilité).
Pour moi, l'important c'est que le projet soit libre. Les conditions essentielles pour ça, n'incluent en aucun cas la communauté. Par exemple, j'utilise un logiciel du nom de pree qui est basiquement pstree écrit en go, je crois. Je n'arrive même pas a retrouver son code source, il n'est pas sur cette machine. Il n'a qu'un seul auteur, et 0 contributeurs à ma connaissance, c'est une personne de nixers.net qui l'a codé après une de mes discussions. Il n'a pas de communauté, de fait, puisque quasi personne ne l'utilise (a moins que ça ait changé depuis, on sait jamais) mais ça reste un logiciel libre.
Moi, même si un soft ne fournit que des tarballs avec le code a chaque version, je le considère libre, si cette tarball respecte les 4 libertés. La communauté, c'est un plus, mais juste ça: un plus, un bonus, un truc dont on peut se passer. Même si je me doute que ça ne plaira pas a tout le monde de lire ça…
Dans les autres domaines, le libre me semble nettement moins respecté, typiquement les "assets" libres… rien que le terme montre a quel point leurs auteurs se prennent pour les rois (j'aurai bien une histoire au sujet d'un trou du cul qui voulait devenir chef à sortir, mais c'est plus fun à l'oral) n'ont quasiment jamais les sources, au lieu de ça on a quasi systématiquement juste les .obj, les .md5, les .mp3 et autres, finaux.
Je pense qu'il serait de meilleur effet d'essayer de trouver une méthodologie efficace pour tous les métiers pour contribuer et bénéficier (parce que bon, c'est le plus important l'air de rien) au libre, plutôt que d'ergoter pendant 150 ans sur des conneries genre la présence d'une communauté.
Ben oui, comme d'hab non?
Ca ne me semble pas rare d'avoir des projets qui incluent des sections avec du code sous autres licences. Ca ne les empêche pas d'utiliser des licences libres.
Du coup, j'ai mis "inutile" a ton message, parce que ta réponse ne donne aucun élément en faveur de l'idée que BRL-CAD ne serait pas libre (ou le serait). Bref: ta réponse ne me semble apporter aucun élément.
Tout celà pour dire que bien souvent un langage donné va permettre de faire des choses dans un certain contexte […]
Je répond a ce paragraphe, pas juste a cette citation.
Je n'ai également aucune connaissance sur Rust ou Zig… en tout cas, je ne considère pas le fait d'avoir entendu parler de ces langages et de leurs objectifs comme une connaissance (et encore moins une compétence!).
Bref, maintenant que j'ai explicité mon contexte personnel, commençons.
Pour commencer, l'article originel ne dit pas que Zig est plus sûr que Rust: il dit que Zig est plus sûr que les sections unsafe de Rust, notamment grâce à la présence d'outils plus développés.
Vu que Zig est, de ce que j'ai lu, (sans jamais prêter trop d'attention) comparable à un fork du C, il ne serait pas étonnant qu'en effet, les outils C y soient adaptés, par exemple coccinelle qui n'est pas utilisable en C++, non plus (et celui-la vraiment, j'aimerai bien: je connais quelques jeux codés en C++ qui bénéficieraient d'un bon gros refactoring, et l'outil sert justement à ça).
Zig et Rust ont beau être «de la même génération» il n'empêche que l'un est un héritier (Zig) tandis que l'autre est un langage construit de zéro (si l'on exclue les décennies d'expériences, bien sûr).
En gros, la ou C++ et Zig sont des évolutions du C, Rust est un langage nouveau, qui n'a pas été conçu pour tourner sur du bare-metal, contrairement au C. C'est à dire, je crois savoir que Rust à été conçu pour améliorer les perfs et la maintenance de Firefox au 21ème siècle, alors que C aurait lui été conçu dès le départ (c'est à dire fin du 20ème, il y a plus de 50ans) pour construire un système d'exploitation.
Il y a donc (à ma connaissance) 2 grosses variables à prendre en compte:
le but. Créer un OS, ça implique créer un kernel, quoiqu'en dise GNU. Et un kernel, c'est quand même pas mal de code "pas sécurisé" (d'autres diraient "bas niveau", ce qui me semble un peu moins… mesquin. A défaut de meilleur mot. Je suis claqué, désolé.). Le C possède la capacité intrinsèque d'intégrer de l'assembleur, par exemple, et il arrive que ça soit utile (c'est un peu comme goto… on évite, mais rester dogmatique a parfois des effets pires);
l'âge du capitaine. C, le "capitaine" de Zig, a 50 ans, et un éco-système qui a été développé pendant ces 50 ans, également. Zig, de ce que j'ai lu reste plus «dans les clous» que C++, il me semble donc très possible qu'il bénéficie encore plus de tout cet écosystème que C++. Je ne sais pas à quel point Rust est compatible avec, mais je doute que la compatibilité soit élevée.
Bon, en lisant un peu, je me dis que des utilisateurs de lisp pourraient ne pas être d'accord avec l'auteur par contre:
Here are two monstrosities I found in the code:
// The way to make these readable is to create a variable for each dereference,
// but that's annoying so in some places I got lazy.
// ew
(*(*closure.as_ptr()).upvalues.as_ptr().offset(i as isize)) = upvalue;
// ewwwwww
let name = (*(*(*ptr.cast::<ObjBoundMethod>().as_ptr()).method.as_ptr())
.function
.as_ptr()).name;
J'imagine que l'abus de parenthèses ne gêne pas tout le monde? :)
Bon, je m'arrête à la lecture du 1er tier, je pense que, globalement, l'article est intéressant (je m'arrête parce que je suis rincé, je finirai peut-être plus tard, en plus ce message est déjà bien assez long), et soulève des points intéressants, notamment le fait que des langages «pas sûrs» soient plus appropriés pour du code bas niveau.
Ca semble enfoncer une porte ouverte, mais je reconnaît que cette évidence m'avait un peu échappé… et du coup les questions qui me viennent, c'est: que penser, spécifiquement, de Redox et du fait que Linux accepte l'usage de Rust dans certaines sections du projet (les pilotes, bien que j'imagine qu'ils doivent utiliser le principe du sablier pour être appelables par le noyau)?
PS: il faut vraiment que je prenne plus le temps d'écrire sans anglicisme, l'exercice m'est étonnamment difficile…
En fait, je me demande quels sont les critères pour ajouter un soft sur framalibre, vu que par exemple brl-cad n'y est pas :)
Il y a aussi le problème de trouver des choses, les quelques tags sont quand même un peu flous, par exemple "création" mélange allègrement CAO (librecad), MAO (i-score semble être de ça), dessin artistique "raster" (mypaint)… alors que ce sont des domaines très différents.
Et ça peut s'automatiser via PXE (histoire de compléter) mais ce n'est pas forcément simple à faire à la main, et je ne connais pas d'outils pour le faire autrement.
une certaine habitude de transparence et pourrait donc contribuer […] avec la même identité
J'ai justement l'impression que c'est l'un des endroits ou le bat blesse, pour le coup, avec cette histoire de sources primaires ou secondaires… si tu contribuais avec des identités différentes, il ne serait pas possible de faire le lien entre le "toi" du xonotic (ou unvanquished, ou je ne sais quel autre projet, peu importe) et le "toi" de linuxfr, ce qui te permettrait donc d'être une source secondaire au lieu de primaire.
'fin bref, je trouve concrètement qu'il serait pertinent de demander a ceux qui font des bandeaux qui mènent à la suppression automatique de faire un minimum d'effort, et de prouver qu'ils l'on fait: après tout, on parle ici de détruire des informations, ce n'est pas un acte sans conséquence.
Et à priori, n'importe qui peut émettre ce type de bandeau. Quand on y réfléchit un peu (certes, grâce à un problème posé) c'est vraiment pas génial comme système. Le problème ne s'est vraiment jamais posé depuis toutes ces années d'existence de wikipedia?
Je comprend pas, la?
Justement cet article indique:
Most functions and methods need to be declared twice in C++ (one in the header, and one in the implementation file). This isn't needed in Rust, reducing the line count.
Du coup, le problème des headers auquel je faisais allusion ne peux exister en rouille?
les auteurs ont réalisé une analyse, une synthèse, une explication ou une évaluation
Une évaluation, pour moi, ça peut être un truc aussi con que donner un score (ça évalue, un score). Les explications, ça peut j'imagine inclure comment faire pour installer, non? Notamment pour héberger un serveur…
L'analyse, que tu sembles privilégier par-dessus tout, n'est qu'un seul des cas cités.
Après, le reste du passage est compliqué:
Ces documents sont utilisables dans Wikipédia lorsqu'ils sont publiés et sont l'œuvre de spécialistes reconnus
Comment on identifie et reconnaît un expert des jeux? Vidéo? Libres? Ce n'est pas simple, parce que les jeux vidéo libres sont une niche. Mais du coup, les niches doivent être dégagées de wikipedia.fr?
Justement, mon point était de montrer que même en ne se foulant pas on trouvais des trucs.
Mais, ok, je vais me fouler alors (pas trop non plus, ça serait dommage d'avoir un accident de travail en moulant sur dlfp), en utilisant des références dont certaines que je connais, parce qu'étant un joueur de jeux libre depuis plus de quelques années. Sans être un expert, j'ai joué à une tétrachiée de jeux libres notamment grâce à Debian, nombre d'entre eux ne sont plus présents dans le répo, d'ailleurs. Bref, d'autres sources:
https://forum.freegamedev.net/viewtopic.php?f=53&t=1955 je ne peux malheureusement pas lire, je suis derrière le proxy du taf… ce site est un site dédié aux jeux libres, qui dispose aussi d'un wiki et d'un blog. Xonotic sera évidemment sur le wiki, pour le blog je ne sais pas (je suis bloqué).
je crois bien que le le bottin des jeux linux est plutôt connu, et est également dédié, comme son nom l'indique, aux jeux vidéo sous linux.
Phoronix est maintenu par un journaliste professionnel pour le coup. Est-ce que ça non plus ça ne qualifie pas?
Evidemment, j'ai fait ces recherches en m'aidant de mes connaissances (limitées hein) des sites qui parlent des jeux vidéo, sous linux. Quelqu'un qui ne s'intéresse pas à ce sujet ne connaîtra pas forcément ces mots clé, et c'est bien ce type de personne que j'ai simulé avec la recherche google.
Comme expliqué plus haut, personne ne veut supprimer cet article. C'est juste une application semi-automatique des règles.
Ben… la personne qui a mis le bandeau, elle ne savait pas que ça entraînerai la suppression de la page? Elle a mis le bandeau par erreur, peut-être?
En fait, lire ton commentaire m'aide un peu à comprendre comment fonctionnent les complotistes. Pour cela, je te remercie, sans ironie.
Si tu le dis. Le sous-entendu est assez peu flatteur quand même. Tu dis que je n'ai rien lu, et il est vrai que je n'ai pas tout lu, mais tu ne sembles pas avoir noté que j'ai cité wikipedia.fr directement, sur leur définition des sources secondaires?
Ou alors wikipedia n'est pas a jour elle-même sur ses propres règles?
Mais du coup, wikipedia n'est pas censé demander des sources?
Je veux dire, un contributeur à un projet (donc avec parti pris) ne peut-il pas au moins demander la source d'une affirmation?
Parce que s'il est vrai que toi tu ne peux prouver à cause de conflit d'intérêt, n'en va-t-il pas de même pour ce vandale?
D'autant plus si les historiques de git sont supprimés, il va être très difficile de trouver une source quelconque…
on te répondra même que la RAM ne coûte plus chère depuis des lustres
A quoi il est facile de répondre que la SRAM coûte toujours une blinde, elle, et qu'on ne peux pas la changer ou l'augmenter sans changer le CPU ;)
Je soupçonne que ce soit pour laisser le temps aux adeptes de rouille de lever le pied qui code pour aller boire un café
Il y a des headers dans rust? Vraie question, je pensais que ce langage utilisais des modules. Ici je taclais C et C++ pour le coup :D
Et sinon, ça ne sert pas à aller prendre un café.
J'ai du mal comprendre alors, mais le ton me semblait plutôt négatif à l'encontre des DCs lors de la lecture.
Et ça me rassure que tu sois plus ou moins d'accord, tout en disant plus ou moins que tu ne l'es pas :)
Honnêtement, un informaticien de bureau d'étude (dev, admin…) qui ne vois pas le problème devrais vraiment retourner au lycée, pour prendre des cours de philosophie et de français, les deux matières qui à mon époque essayaient de développer le sens critique des élèves (qui n'en avaient souvent pas grand chose à faire, certes).
Un exemple "très récent" du problème du je-m-en-foutisme pour moi est quand je me suis aperçu qu'une installation minimale de Debian via l'installateur ne peux pas démarrer si la VM ne dispose pas d'au moins 250 Megs de RAM. Une fois bien démarrée, la machine n'en consommait même pas 60… la raison?
L'initrd ne rentre pas. Pourtant à l'install j'ai bien sélectionné l'option pour n'avoir que les pilotes nécessaires…
Avant ça, il me fallait moins de 150 megs, il me semble. D'ailleurs, si quelqu'un à des pointeurs qui expliquent comment en pratique il serait possible de faire un initrd minimal, pour un système "moderne" (debian stable, c'est pas non plus si moderne que ça je suppose) ça m'intéresse.
De la même manière, j'ai remarqué pendant un temps qu'utiliser de l'édition de liens dynamique avec glibc6 ajoute "magiquement" 750Kio de ressources dédiées à une application, qui autrement n'en consommerait potentiellement que 4Kio, ce qui peut être vérifié en utilisant un liage statique ou, tout bêtement, muslc (dynamique ou pas, ça ne change rien de ce côté avec cette lib).
Je vois avec plaisir que ça à changé, ps -orss,vsz,comm --sort=rss indique mes processus les plus légers à 60Kio, c'est nettement mieux (il y a un ordre de grandeur d'écart quand même, ça m'intrigue ça, ils ont corrigé un bug sévère chez gcc ou quoi?).
Si je prend juste les 22 processus que sont runit, runsvdir, runsv et svlogd, avant ça aurait donné environ 140Mio de conso "gratuite". Si je regarde la totalité de la ram actuellement utilisée sur ma machine, c'est à dire 291Mio, et que je regarde ce que ça donnerai hypothétiquement, ça ferait grosso merdo 30% ("( 291 + 140 ) / 291"). C'était beaucoup.
Maintenant, ça ne fait plus "que" 3%. Ca reste non négligeable pour des processus qui ne font virtuellement que dalle (j'avais regardé la ram que bouffe systemd aussi: il dépassait le mega de RSS si je me souviens bien, mais son avantage est que son poids n'est que très peu impacté par le nombre de daemons, contrairement à mon archi basée sur runit qui y est plus sensible, mais j'avais caculé qu'il me faudrait une 30aine de démons gérés par runsv+glibc en dynamique pour que ça soit rentable, si ma mémoire est bonne: ça date, donc c'est pas sûr).
Du coup, ce qui est agaçant, c'est que même pas ça ne concerne que le développement applicatif (qui a l'excuse de devoir modifier ses interfaces en permanence je suppose), le gâchis de ressources: même le développement système qui devrais justement se faire le plus léger possible, par exemple pour stocker plus de VMs par machine physique, gâche des quantités de ressources importantes (une fois mis à l'échelle en multipliant les instances, ce qui est, je crois, la méthode moderne?).
Alors évidemment il ne faut pas non plus sur-optimiser, et ces quelques kilo par processus semblent négligeables comparé aux ressources disponibles sur des machines modernes… mais je crois que c'est la mauvaise façon de voir si un système est performant.
Pour moi, ce qu'il faut regarder ce n'est pas la ressource disponible, mais bien les ressources utilisées par le processus et, si possible, les bibliothèques qu'il charge: ça permets de se donner idée du bloat. Dans le cas de glibc6, selon ce que je vois, la, sur mon portable (avec lequel je n'écrit pas ce message) c'est que des processus qui ne devraient consommer qu'une seule page (4Kio) de ram, en consomment 15 fois plus. La conclusion évidente est que glibc, même si ça c'est méchamment amélioré (vraiment une super surprise ça) reste bien bloatée.
J'imagine qu'il faut aussi voir l'évolution de la conso en ressources d'un logiciel lors de son cycle de vie.
Evidemment, tout ça, ça prend du temps, et le client s'en fout "un peu"… si ce n'est pas le client qui s'en fout, alors ça sera le commercial ou le patron. Ou le développeur (parce que bon, c'est facile de rejeter la faute sur les autres échelons, mais ce n'est pas toujours taper sur les bons).
A vérifier, mais je crois que les vieilles salopes ont une licence libre sur leurs albums, ce qui semble corroboré par wikipedia:
Le "combo" a toujours refusé d'être inscrit à la SACEM, toute sa musique est en téléchargement libre sur le web et est libre de droit.
Il faudrait quand même vérifier sur jamendo, peut-être sur les fichiers d'il y a longtemps (à l'époque ou ce site n'était pas ce qu'il est devenu), parce que les archives à télécharger sur le site officiel n'ont pas de licence, et sont donc de ce fait non libres.
Je dois avoir d'autres trucs dans ce style, mais effectivement ce n'est pas la norme, la norme étant plutôt de l'ordre du -NC.
Je suis bien d'accord, il y a un sérieux problème de ce point de vue, et ça ne se limite pas à la "musique d'écoute": le problème est plutôt très très criant dans les jeux vidéos libres.
Par exemple si on prend unvanquished ou red-eclipse, tout est sous licence libre. Super. Mais trouver les modèles, qu'ils soient faits avec blender, maya, autocad ou peu importe quoi, est hyper compliqué, la plupart du temps ils sont "perdus".
C'est dommage, parce que ça permettrais de facilement régénérer les modèles compilés pour un format plus efficace, augmenter ou diminuer le nombre de vertexes ou d'os pour optimiser en faveur du temps de rendu ou de l'esthétique, ou, tout simplement, hé bien, de faire une oeuvre dérivée, ce qui est un peu l'un des principaux intérêts.
[^] # Re: Beating C with 80 lines of Haskell
Posté par freem . En réponse au lien When Zig is safer and faster than Rust. Évalué à 2.
c'est plus clair, merci :)
[^] # Re: Zulip
Posté par freem . En réponse au lien Appel à l'aide pour migrer une communauté hors de Discord. Évalué à 4.
Dans ce cas, un lien sur zulip serait intéressant. Ce qui le serait encore plus, c'est de développer le pourquoi tu ne comprend pas l'intérêt de discord (moi non plus je pige pas, mais bon, je suis vieux, j'utilise encore irc qui n'a toujours l'history qu'en draft pour la v3…)
[^] # Re: Beating C with 80 lines of Haskell
Posté par freem . En réponse au lien When Zig is safer and faster than Rust. Évalué à 4.
Ouai, en gros haskell est juste à l'ouest: plus lent malgré le parallélisme, et bouffe le double de ram.
Ton message était censé promouvoir haskell, ou l'enfoncer?
[^] # Re: Pourquoi tant de haine ?
Posté par freem . En réponse au journal Wayland dans windows 10 et 11. Évalué à 8. Dernière modification le 10 mars 2023 à 00:09.
Oh, d'un point de vue pragmatique, j'ai toujours un argument perso: je peux installer un OS sur moins de 50 gigs de stockage (avec, ou sans, la partition /home).
Sous windows, de ce que je vois au boulot (j'ai pas creusé, je suis plus ingé, on ne me demande plus de résoudre la racine des problèmes, juste les symptomes) il vaut mieux prévoir 150 gig pour la partoche système. Ca a un impact sur le coût du PC, l'air de rien… Je ne parle pas de la RAM ni du reste, hein. D'ailleurs, si j'en parlais, je dirais que je peux installer un OS complet et moderne sur 20 gigs de stockage sans le /home :)
Une autre raison: dans wiNdows il y a forcément un haine. Bon, ça, c'est fait, moi je suis plus la, salut …
[^] # Re: Source de confiance
Posté par freem . En réponse au lien Windows XP/Vista/7 Compatible App Packages, Adding To The App Directory. Évalué à 2.
Et du coup tu fais ça a chaque fois? Même si je comprend ton opinion (c'est moche, ils bossent pas pour rien) ils font un service gratos (vous êtes le produit) et promeuvent (sans le vouloir?) le LL.
Ma foi, je suis bien incapable de trouver un meilleur business model pour le libre.
[^] # Re: Source de confiance
Posté par freem . En réponse au lien Windows XP/Vista/7 Compatible App Packages, Adding To The App Directory. Évalué à 2.
Tu as oublié le plus important: pas d'installation, et pas de pré-requis dans la base de registre.
Franchement, la compilation… les utilisateurs s'en contre-branlent!
[^] # Re: Source de confiance
Posté par freem . En réponse au lien Windows XP/Vista/7 Compatible App Packages, Adding To The App Directory. Évalué à 2. Dernière modification le 09 mars 2023 à 23:54.
Je me souviens de mon passé de windowsien. Pour moi, une appli portable était… ben, un truc portable entres OS. Mais bon, j'étais déjà un codeur.
En fait, ici, le terme idéal serait: «une appli transportable» parce que c'est de ça qu'on parle. Pour être transportable, une appli ne doit pas nécessiter de traces dans le système sur lequel elle est utilisée. J'ai dit: nécessiter, ça veut dire que ça doit marcher sans installateur, mais pas forcément que ça ne doit pas laisser de traces (ça, c'est l'idéal, mais c'est techniquement impossible si l'OS décide d'espionner)
[^] # Re: Étiquettes
Posté par freem . En réponse au lien Windows XP/Vista/7 Compatible App Packages, Adding To The App Directory. Évalué à 2.
Je pense personnellement qu'il y a un sérieux problème en informatique: les soit-disant ingénieurs, qui sont plus des in-gêneurs, semblent faire leur maximum pour empêcher les gens d'utiliser leurs outils.
Evidemment ça ne concerne pas les gens qui obéissent aux ordres… quoique…
Aujourd'hui sur la route, ou c'était peut-être hier, j'ai entendu le type (titre: gouverneur je crois?) de la banque centrale française répondre au journaliste un truc du genre "ce qu'il faudrait avec les impôts, ce n'est ni les baisser, ni les monter, mais de la stabilité, parce que c'est la stabilité qui induit la confiance". Un truc dans ce goût la. Le monsieur m'a choqué (positivement) par son pragmatisme (et son objectivité apparente).
Je pense que cette idée n'est pas conne: la stabilité serait effectivement une bonne idée. Que ce soit pour les finances (son sujet, son problème) ou pour la sécurité informatique (le problème dont on parle, ici).
Si les interfaces pouvaient être constantes sur plus d'une décennie, je crois que ça mènerait à une bien meilleure amélioration de la sécurité informatique, ainsi qu'a une amélioration de la performance. Pourquoi? Parce qu'alors on passerait moins de temps a former les gens sur les trucs de base, pour se concentrer sur ce qui est important, et les gens, dont je fait partie, perdraient moins leur repères et seraient donc plus entraînés a repérer les irrégularités.
En gros, je crois que les principaux responsables de l'insécurité (et je ne le savait pas il y a 15 minutes) sont les gens qui produisent les OS. Si on… ah, c'est vrai, je ne suis plus dev de métier… si ils faisaient leur job pour la sécurité, alors ils arrêteraient de changer ces putain d'IHM tous les ans! Aussi con que ça puisse paraître, OUI, C'EST LIÉ!
[^] # Re: Finalement, le débat..
Posté par freem . En réponse au journal si on ne fait rien, Xonotic va disparaitre de wikipedia FR. Évalué à 3.
Je suis d'accord sur le fait que wikipedia n'est pas, ou plutôt ne devrais pas, être une référence centrale, et les choses peuvent exister en dehors. (j'ai failli pondre un mur de texte, mais je partais hors sujet, donc je vire :))
Le problème n'est pas "c'est connu donc on garde" ou "ce n'est pas connu donc on vire", mais plutôt "moi [personne avec un certain pouvoir], qui passe sur une page aléatoire, ne connaît pas le sujet, donc je marque pour que ça soit viré". Wikipedia vise à être une encyclopédie, du coup je trouve ce type de comportement dommageable. Apparemment, je ne suis pas le seul d'ailleurs: j'ai été mis au courant via IRC avant même de lire DLFP (que je lis de moins en moins souvent, j'admets) et en dehors de moi, un certain nombre de personnes semblent avoir réagi assez vivement.
Mon sentiment au final, c'est que le wikipedia francophone est… peu (pour ne pas dire pas) crédible, à cause de son manque clair de contenu, et le zèle qui a été discuté ici est une possible cause de ce manque de contenu: il est plus facile d'améliorer du contenu que de le créer "from scratch", hors le fameux bandeau génère une suppression automatique, historique inclus apparemment (selon ce que j'ai compris des dires de Thomas Debesse) ce qui implique de refaire tout le boulot à chaque fois qu'il y a un suppression.
Pour un dev, c'est l'équivalent de
git rebasepour virer le contenu produit par d'autres… et je peux clairement comprendre que ça génère de vifs sentiments d'incompréhension.Après, en soit, c'est leur projet. Si on est pas content, yakaforker, je sais bien. Je ne suis pas sûr que ça soit super productif, par contre, compte tenu de l'ambition (que j'ai compris, mais si ça se trouve je suis juste à côté de la plaque) du projet.
[^] # Re: Finalement, le débat..
Posté par freem . En réponse au journal si on ne fait rien, Xonotic va disparaitre de wikipedia FR. Évalué à 2.
Pour aboutir a une conclusion, il faudrait connaître le ratio d'articles a bandeaux qui ont effectivement causé une discussion.
Ici, elle ne s'est produite que parce que Xonotic est LOIN d'être un projet inconnu, et pourtant il a déjà été viré de wikipedia, ce qui montre justement le problème.
En fait, ne pas connaître xonotic pour un amateur de FPS libre reviens a ne pas connaître wesnoth pour un amateur de TBS libre: c'est impossible. Il est bien plus représentatif que, par exemple, red-eclipse, sauerbraten (je suis pas sûr que le contenu soit libre) ou uebergame (je ne serais pas surpris que personne ici ne connaisse ce jeu).
A titre personnel je n'aime pas xonotic, et n'ai jamais vraiment aimé Nexuiz (logique). N'empêche que je connais ces projets depuis des années, sans être un expert dans le domaine.
Je ne crois pas que faire de la suppression de masse pour tester la réactivité des contributeurs soit une bonne chose: il est très probable que les-dits contributeurs aient autre chose à foutre qu'ergoter sur un article de la wikipedia française, compte tenu de la qualité moyenne (très, très faible, comparé à la version anglaise). Ce genre de comportement me semble plutôt contre productif: combien de personnes qui ont initialement crée et maintenu l'article vont être écoeurées par ce bandeau stupide venu d'une personne qui fait dans le zèle administratif (et ne connais rien au sujet, manifestement)?
[^] # Re: Zenitram ne va pas être content (à raison)
Posté par freem . En réponse au journal Annuaire projets libres. Évalué à 2.
TL;DR: +1!
En fait, je me demande bien d'où viens l'idée que le développement ou le travail "ensemble" ça marche mieux.
Je suis entièrement convaincu par le libre, pas de souci la dessus, mais le communautarisme… me convainc beaucoup moins.
Les communautés ont toujours (de ce que j'ai vu) un ensemble de règles, plus ou moins (psycho-)rigides, à tort ou a raison (on trouve les deux dans la nature, parfois même ensemble), un fort biais historique (un leader charismatique du passé aura plus d'influence que quelqu'un qui s'implique pour de vrai, tout de suite, maintenant, peu importe le degré de compétences) et… bref, ça me semble pas aider.
Oui, je pense que les projets ont besoin de rigidité, et pouvoir être aidé par la communauté est très bénéfique dans bien des situations, mais quand une communauté est mourante, si personne n'a réussi a fork la communauté avant, c'est le projet entier qui risque de passer par un coma profond, qui peut durer des années, et mener soit à la mort, soit à un vivotage du projet.
N'empêche, je ne comprend pas ce centrage sur le communautarisme. Un projet est libre s'il respecte un certain nombre de libertés, qui me semble bien définit et accepté dans le cadre du logiciel… et pourtant nombre de gens veulent y ajouter des contraintes (pas d'argent, pas d'usage militaire, etc etc etc) et c'est ce contre quoi zenitram s'insurge, à raison, à chaque fois (en tout cas c'est comme ça que le comprend, je me trompe peut-être, je n'ai jamais été versé dans la communication et la sociabilité).
Pour moi, l'important c'est que le projet soit libre. Les conditions essentielles pour ça, n'incluent en aucun cas la communauté. Par exemple, j'utilise un logiciel du nom de
preequi est basiquementpstreeécrit en go, je crois. Je n'arrive même pas a retrouver son code source, il n'est pas sur cette machine. Il n'a qu'un seul auteur, et 0 contributeurs à ma connaissance, c'est une personne de nixers.net qui l'a codé après une de mes discussions. Il n'a pas de communauté, de fait, puisque quasi personne ne l'utilise (a moins que ça ait changé depuis, on sait jamais) mais ça reste un logiciel libre.Moi, même si un soft ne fournit que des tarballs avec le code a chaque version, je le considère libre, si cette tarball respecte les 4 libertés. La communauté, c'est un plus, mais juste ça: un plus, un bonus, un truc dont on peut se passer. Même si je me doute que ça ne plaira pas a tout le monde de lire ça…
Dans les autres domaines, le libre me semble nettement moins respecté, typiquement les "assets" libres… rien que le terme montre a quel point leurs auteurs se prennent pour les rois (j'aurai bien une histoire au sujet d'un trou du cul qui voulait devenir chef à sortir, mais c'est plus fun à l'oral) n'ont quasiment jamais les sources, au lieu de ça on a quasi systématiquement juste les .obj, les .md5, les .mp3 et autres, finaux.
Je pense qu'il serait de meilleur effet d'essayer de trouver une méthodologie efficace pour tous les métiers pour contribuer et bénéficier (parce que bon, c'est le plus important l'air de rien) au libre, plutôt que d'ergoter pendant 150 ans sur des conneries genre la présence d'une communauté.
[^] # Re: [HS] Framalibre le fait très bien
Posté par freem . En réponse au journal Annuaire projets libres. Évalué à 0.
Ben oui, comme d'hab non?
Ca ne me semble pas rare d'avoir des projets qui incluent des sections avec du code sous autres licences. Ca ne les empêche pas d'utiliser des licences libres.
Du coup, j'ai mis "inutile" a ton message, parce que ta réponse ne donne aucun élément en faveur de l'idée que BRL-CAD ne serait pas libre (ou le serait). Bref: ta réponse ne me semble apporter aucun élément.
[^] # Re: Ca me fait penser un peu à ce que j'ai vécu à un moment avec Python .....
Posté par freem . En réponse au lien When Zig is safer and faster than Rust. Évalué à 4.
Je répond a ce paragraphe, pas juste a cette citation.
Je n'ai également aucune connaissance sur Rust ou Zig… en tout cas, je ne considère pas le fait d'avoir entendu parler de ces langages et de leurs objectifs comme une connaissance (et encore moins une compétence!).
Bref, maintenant que j'ai explicité mon contexte personnel, commençons.
Pour commencer, l'article originel ne dit pas que Zig est plus sûr que Rust: il dit que Zig est plus sûr que les sections
unsafede Rust, notamment grâce à la présence d'outils plus développés.Vu que Zig est, de ce que j'ai lu, (sans jamais prêter trop d'attention) comparable à un fork du C, il ne serait pas étonnant qu'en effet, les outils C y soient adaptés, par exemple coccinelle qui n'est pas utilisable en C++, non plus (et celui-la vraiment, j'aimerai bien: je connais quelques jeux codés en C++ qui bénéficieraient d'un bon gros refactoring, et l'outil sert justement à ça).
Zig et Rust ont beau être «de la même génération» il n'empêche que l'un est un héritier (Zig) tandis que l'autre est un langage construit de zéro (si l'on exclue les décennies d'expériences, bien sûr).
En gros, la ou C++ et Zig sont des évolutions du C, Rust est un langage nouveau, qui n'a pas été conçu pour tourner sur du bare-metal, contrairement au C. C'est à dire, je crois savoir que Rust à été conçu pour améliorer les perfs et la maintenance de Firefox au 21ème siècle, alors que C aurait lui été conçu dès le départ (c'est à dire fin du 20ème, il y a plus de 50ans) pour construire un système d'exploitation.
Il y a donc (à ma connaissance) 2 grosses variables à prendre en compte:
Bon, en lisant un peu, je me dis que des utilisateurs de lisp pourraient ne pas être d'accord avec l'auteur par contre:
J'imagine que l'abus de parenthèses ne gêne pas tout le monde? :)
Bon, je m'arrête à la lecture du 1er tier, je pense que, globalement, l'article est intéressant (je m'arrête parce que je suis rincé, je finirai peut-être plus tard, en plus ce message est déjà bien assez long), et soulève des points intéressants, notamment le fait que des langages «pas sûrs» soient plus appropriés pour du code bas niveau.
Ca semble enfoncer une porte ouverte, mais je reconnaît que cette évidence m'avait un peu échappé… et du coup les questions qui me viennent, c'est: que penser, spécifiquement, de Redox et du fait que Linux accepte l'usage de Rust dans certaines sections du projet (les pilotes, bien que j'imagine qu'ils doivent utiliser le principe du sablier pour être appelables par le noyau)?
PS: il faut vraiment que je prenne plus le temps d'écrire sans anglicisme, l'exercice m'est étonnamment difficile…
# [HS] Framalibre le fait très bien
Posté par freem . En réponse au journal Annuaire projets libres. Évalué à 3.
En fait, je me demande quels sont les critères pour ajouter un soft sur framalibre, vu que par exemple brl-cad n'y est pas :)
Il y a aussi le problème de trouver des choses, les quelques tags sont quand même un peu flous, par exemple "création" mélange allègrement CAO (librecad), MAO (i-score semble être de ça), dessin artistique "raster" (mypaint)… alors que ce sont des domaines très différents.
Mais bon: oui, framalibre est pas mal :)
[^] # Re: debian preseed et autres
Posté par freem . En réponse au message Debian réplication, kvm → tar / → machine physique ?. Évalué à 3.
Et ça peut s'automatiser via PXE (histoire de compléter) mais ce n'est pas forcément simple à faire à la main, et je ne connais pas d'outils pour le faire autrement.
[^] # Re: le petit bout de la lorgnette
Posté par freem . En réponse au journal si on ne fait rien, Xonotic va disparaitre de wikipedia FR. Évalué à 6.
J'ai justement l'impression que c'est l'un des endroits ou le bat blesse, pour le coup, avec cette histoire de sources primaires ou secondaires… si tu contribuais avec des identités différentes, il ne serait pas possible de faire le lien entre le "toi" du xonotic (ou unvanquished, ou je ne sais quel autre projet, peu importe) et le "toi" de linuxfr, ce qui te permettrait donc d'être une source secondaire au lieu de primaire.
'fin bref, je trouve concrètement qu'il serait pertinent de demander a ceux qui font des bandeaux qui mènent à la suppression automatique de faire un minimum d'effort, et de prouver qu'ils l'on fait: après tout, on parle ici de détruire des informations, ce n'est pas un acte sans conséquence.
Et à priori, n'importe qui peut émettre ce type de bandeau. Quand on y réfléchit un peu (certes, grâce à un problème posé) c'est vraiment pas génial comme système. Le problème ne s'est vraiment jamais posé depuis toutes ces années d'existence de wikipedia?
[^] # Re: mouai
Posté par freem . En réponse au lien La chasse au gaspillage dans le cloud et les data centers. Évalué à 2.
Je comprend pas, la?
Justement cet article indique:
Du coup, le problème des headers auquel je faisais allusion ne peux exister en rouille?
[^] # Re: le petit bout de la lorgnette
Posté par freem . En réponse au journal si on ne fait rien, Xonotic va disparaitre de wikipedia FR. Évalué à 6.
Pas eu le temps d'éditer pour ajouter ça:
Une évaluation, pour moi, ça peut être un truc aussi con que donner un score (ça évalue, un score). Les explications, ça peut j'imagine inclure comment faire pour installer, non? Notamment pour héberger un serveur…
L'analyse, que tu sembles privilégier par-dessus tout, n'est qu'un seul des cas cités.
Après, le reste du passage est compliqué:
Comment on identifie et reconnaît un expert des jeux? Vidéo? Libres? Ce n'est pas simple, parce que les jeux vidéo libres sont une niche. Mais du coup, les niches doivent être dégagées de wikipedia.fr?
[^] # Re: le petit bout de la lorgnette
Posté par freem . En réponse au journal si on ne fait rien, Xonotic va disparaitre de wikipedia FR. Évalué à 5. Dernière modification le 02 février 2023 à 15:45.
Justement, mon point était de montrer que même en ne se foulant pas on trouvais des trucs.
Mais, ok, je vais me fouler alors (pas trop non plus, ça serait dommage d'avoir un accident de travail en moulant sur dlfp), en utilisant des références dont certaines que je connais, parce qu'étant un joueur de jeux libre depuis plus de quelques années. Sans être un expert, j'ai joué à une tétrachiée de jeux libres notamment grâce à Debian, nombre d'entre eux ne sont plus présents dans le répo, d'ailleurs. Bref, d'autres sources:
J'ai trouvé la grande majorité de ces liens avec cette recherche. Et dire que le plus gros est en français…
Oh, il y a aussi:
Phoronix est maintenu par un journaliste professionnel pour le coup. Est-ce que ça non plus ça ne qualifie pas?
Evidemment, j'ai fait ces recherches en m'aidant de mes connaissances (limitées hein) des sites qui parlent des jeux vidéo, sous linux. Quelqu'un qui ne s'intéresse pas à ce sujet ne connaîtra pas forcément ces mots clé, et c'est bien ce type de personne que j'ai simulé avec la recherche google.
Ben… la personne qui a mis le bandeau, elle ne savait pas que ça entraînerai la suppression de la page? Elle a mis le bandeau par erreur, peut-être?
Si tu le dis. Le sous-entendu est assez peu flatteur quand même. Tu dis que je n'ai rien lu, et il est vrai que je n'ai pas tout lu, mais tu ne sembles pas avoir noté que j'ai cité wikipedia.fr directement, sur leur définition des sources secondaires?
Ou alors wikipedia n'est pas a jour elle-même sur ses propres règles?
[^] # Re: le petit bout de la lorgnette
Posté par freem . En réponse au journal si on ne fait rien, Xonotic va disparaitre de wikipedia FR. Évalué à 4.
Mais du coup, wikipedia n'est pas censé demander des sources?
Je veux dire, un contributeur à un projet (donc avec parti pris) ne peut-il pas au moins demander la source d'une affirmation?
Parce que s'il est vrai que toi tu ne peux prouver à cause de conflit d'intérêt, n'en va-t-il pas de même pour ce vandale?
D'autant plus si les historiques de git sont supprimés, il va être très difficile de trouver une source quelconque…
[^] # Re: Une dépêche ?
Posté par freem . En réponse au journal si on ne fait rien, Xonotic va disparaitre de wikipedia FR. Évalué à 4.
Mais du coup on te rétorqueras que c'est fait pour la page wikipedia.fr et donc source non éligible :D
[^] # Re: mouai
Posté par freem . En réponse au lien La chasse au gaspillage dans le cloud et les data centers. Évalué à 2.
A quoi il est facile de répondre que la SRAM coûte toujours une blinde, elle, et qu'on ne peux pas la changer ou l'augmenter sans changer le CPU ;)
Il y a des headers dans rust? Vraie question, je pensais que ce langage utilisais des modules. Ici je taclais C et C++ pour le coup :D
Et sinon, ça ne sert pas à aller prendre un café.
[^] # Re: mouai
Posté par freem . En réponse au lien La chasse au gaspillage dans le cloud et les data centers. Évalué à 3.
J'ai du mal comprendre alors, mais le ton me semblait plutôt négatif à l'encontre des DCs lors de la lecture.
Honnêtement, un informaticien de bureau d'étude (dev, admin…) qui ne vois pas le problème devrais vraiment retourner au lycée, pour prendre des cours de philosophie et de français, les deux matières qui à mon époque essayaient de développer le sens critique des élèves (qui n'en avaient souvent pas grand chose à faire, certes).
Un exemple "très récent" du problème du je-m-en-foutisme pour moi est quand je me suis aperçu qu'une installation minimale de Debian via l'installateur ne peux pas démarrer si la VM ne dispose pas d'au moins 250 Megs de RAM. Une fois bien démarrée, la machine n'en consommait même pas 60… la raison?
L'initrd ne rentre pas. Pourtant à l'install j'ai bien sélectionné l'option pour n'avoir que les pilotes nécessaires…
Avant ça, il me fallait moins de 150 megs, il me semble. D'ailleurs, si quelqu'un à des pointeurs qui expliquent comment en pratique il serait possible de faire un initrd minimal, pour un système "moderne" (debian stable, c'est pas non plus si moderne que ça je suppose) ça m'intéresse.
De la même manière, j'ai remarqué pendant un temps qu'utiliser de l'édition de liens dynamique avec glibc6 ajoute "magiquement" 750Kio de ressources dédiées à une application, qui autrement n'en consommerait potentiellement que 4Kio, ce qui peut être vérifié en utilisant un liage statique ou, tout bêtement, muslc (dynamique ou pas, ça ne change rien de ce côté avec cette lib).
Je vois avec plaisir que ça à changé,
ps -orss,vsz,comm --sort=rssindique mes processus les plus légers à 60Kio, c'est nettement mieux (il y a un ordre de grandeur d'écart quand même, ça m'intrigue ça, ils ont corrigé un bug sévère chez gcc ou quoi?).Si je prend juste les 22 processus que sont runit, runsvdir, runsv et svlogd, avant ça aurait donné environ 140Mio de conso "gratuite". Si je regarde la totalité de la ram actuellement utilisée sur ma machine, c'est à dire 291Mio, et que je regarde ce que ça donnerai hypothétiquement, ça ferait grosso merdo 30% ("( 291 + 140 ) / 291"). C'était beaucoup.
Maintenant, ça ne fait plus "que" 3%. Ca reste non négligeable pour des processus qui ne font virtuellement que dalle (j'avais regardé la ram que bouffe systemd aussi: il dépassait le mega de RSS si je me souviens bien, mais son avantage est que son poids n'est que très peu impacté par le nombre de daemons, contrairement à mon archi basée sur runit qui y est plus sensible, mais j'avais caculé qu'il me faudrait une 30aine de démons gérés par runsv+glibc en dynamique pour que ça soit rentable, si ma mémoire est bonne: ça date, donc c'est pas sûr).
Du coup, ce qui est agaçant, c'est que même pas ça ne concerne que le développement applicatif (qui a l'excuse de devoir modifier ses interfaces en permanence je suppose), le gâchis de ressources: même le développement système qui devrais justement se faire le plus léger possible, par exemple pour stocker plus de VMs par machine physique, gâche des quantités de ressources importantes (une fois mis à l'échelle en multipliant les instances, ce qui est, je crois, la méthode moderne?).
Alors évidemment il ne faut pas non plus sur-optimiser, et ces quelques kilo par processus semblent négligeables comparé aux ressources disponibles sur des machines modernes… mais je crois que c'est la mauvaise façon de voir si un système est performant.
Pour moi, ce qu'il faut regarder ce n'est pas la ressource disponible, mais bien les ressources utilisées par le processus et, si possible, les bibliothèques qu'il charge: ça permets de se donner idée du bloat. Dans le cas de glibc6, selon ce que je vois, la, sur mon portable (avec lequel je n'écrit pas ce message) c'est que des processus qui ne devraient consommer qu'une seule page (4Kio) de ram, en consomment 15 fois plus. La conclusion évidente est que glibc, même si ça c'est méchamment amélioré (vraiment une super surprise ça) reste bien bloatée.
J'imagine qu'il faut aussi voir l'évolution de la conso en ressources d'un logiciel lors de son cycle de vie.
Evidemment, tout ça, ça prend du temps, et le client s'en fout "un peu"… si ce n'est pas le client qui s'en fout, alors ça sera le commercial ou le patron. Ou le développeur (parce que bon, c'est facile de rejeter la faute sur les autres échelons, mais ce n'est pas toujours taper sur les bons).
[^] # Re: Et Jamendo ?
Posté par freem . En réponse à la dépêche Des pistes pour découvrir de la musique libre. Évalué à 3.
A vérifier, mais je crois que les vieilles salopes ont une licence libre sur leurs albums, ce qui semble corroboré par wikipedia:
Il faudrait quand même vérifier sur jamendo, peut-être sur les fichiers d'il y a longtemps (à l'époque ou ce site n'était pas ce qu'il est devenu), parce que les archives à télécharger sur le site officiel n'ont pas de licence, et sont donc de ce fait non libres.
Je dois avoir d'autres trucs dans ce style, mais effectivement ce n'est pas la norme, la norme étant plutôt de l'ordre du -NC.
[^] # Re: Dogmazic / Musique Libre (libre diffusion)
Posté par freem . En réponse à la dépêche Des pistes pour découvrir de la musique libre. Évalué à 3.
Je suis bien d'accord, il y a un sérieux problème de ce point de vue, et ça ne se limite pas à la "musique d'écoute": le problème est plutôt très très criant dans les jeux vidéos libres.
Par exemple si on prend unvanquished ou red-eclipse, tout est sous licence libre. Super. Mais trouver les modèles, qu'ils soient faits avec blender, maya, autocad ou peu importe quoi, est hyper compliqué, la plupart du temps ils sont "perdus".
C'est dommage, parce que ça permettrais de facilement régénérer les modèles compilés pour un format plus efficace, augmenter ou diminuer le nombre de vertexes ou d'os pour optimiser en faveur du temps de rendu ou de l'esthétique, ou, tout simplement, hé bien, de faire une oeuvre dérivée, ce qui est un peu l'un des principaux intérêts.