Ça me parait pas très concluant non plus comme division. Je pense qu'il y a une grande part des gens qui font de l'informatique pour leur métier, mais qui voient surtout que ça apporte des emmerdes, qu'on leur crie dessus quand ça ne marche pas, qu'on leur dit à longueur de temps qu'ils sont un cout financier, de façon direct ou indirect. La passion est peut être parti depuis longtemps, ou le temps. Et depuis quelques temps, j'ai le sentiment que l'informatique bouge de plus en plus vite, ne serais que parce qu'il y a un influx d'ingénieurs, une accélération de l'échange d'idée, et des moyens en plus.
Donc il y a peut être des gens qui ont peur de pas réussir à suivre, peur de ce que ça va apporter, et le changement par nature fait peur aux gens, c'est un mécanisme ancré dans notre subconscient. Il suffit de voir que beaucoup de choses ont commencé quand un journaliste a lancé l'idée d'une apocalypse qui vient, ce qui est quand même le summum du fear mongering. De voir que ça a provoqué des réactions disproportionnés pour un sujet technique comme celui la. Et que les gens relaient des informations sans vérifier si c'est vrai ou pas ( l'exemple de systemd et des logs binaires par exemple ). Les gens répètent ce qui confortent leurs peurs pour la propager, car c'est plus rassurant de pas être seul à paniquer.
Un autre exemple, le blog de iguru, totalement non fondé et basé sur des affirmations péremptoires non vérifiables, mais qui alimentent la paranoia.
Ensuite, encore une fois, tout le monde rentre pas dans ce cadre, et y a plein de gens avec un avis plus mesuré, mais masqué par les autres.
Ça dépend comment tu veux les utiliser. Pour limiter les processus en terme de ressources, non, tu as déjà des logiciels existants, tu peux le faire à la main. Systemd automatise cette partie et l'unifie au niveau de la configuration.
Pour ce qui est d'utiliser le tracking des processus, tu peux le faire à la main, mais c'est vite chiant. Donc openrc et systemd peuvent le faire pour toi.
Et le fait que les devs de cgmanager et de systemd se sont réunis pour trouver une solution il y a 2 mois à Dusseldorf pour discutter interopérabilité ( une info qu'on ne relaye pas assez, bien sur, ç'est moins vendeur pour un journal )
Non, parce que NetBSD n'a pas les même performances que linux et
parce qu'il n'a pas le même support (autant matériel que
logiciel).
Certes, mais on peut pas avoir le beurre et l'argent du beurre. La compatibilité a un cout humain, et le temps que tu passes à tester et à vérifier que rien ne casse, c'est du temps que tu passes pas à optimiser et à coder pour du nouveau hardware.
Un exemple stupide. Tu codes ton unix like avec l'infra video du moment, et en l'espace de 5 ans, tout change et il te faut de la 3d partout. Si tu t'occupes de la compatibilité, alors tu va maintenir 2 couches. Si tu t'en fout, alors tu va t'occuper que de la dernière. Et tu va passer plus de temps à rendre la dernière rapide/propre/etc que si tu avais que la moitié ou 75% du temps.
Bien sur, ça n'explique pas tout pour netbsd, mais ça explique une partie.
Et peut être qu'une innovation rapide mais chaotique et cahoteuse à la Linux marche mieux pour avoir le support du hardware et des perfs, ce qui ensuite attire plus de gens, dans un cercle vertueux.
Et en effet, des boites comme IBM, HP, RH font leur beurre sur les demandes de stabilité.
C'est un gros pâté, mais les exemples que je donnent sont vers 75% du texte. l'exemple de bind est facile à piger, mais il arrive sans doute peu en pratique sur une petite installation.
Tu as aussi mon exemple de apache et de sympa ( qui arrive plus souvent ). Ensuite, peut être que tu as accepté le fait que les bugs arrivent, ou que ça marche pas de temps en temps sans savoir pourquoi. D'autres non.
Non, sinon j'aurais dit "je trouve tel truc mieux que /etc/default".
Déjà, /etc/default est pourri car ça reste du shell. Ce qui veut dire que soit tu te limites à la syntaxe FOO="truc" et c'est plus du shell, soit tu mets du vrai shell (genre $() pour lire un truc dynamiquement) et la, ça devient difficile à parser par des outils automatisés (genre ansible/puppet, etc). Ensuite, la flexibilité d'un coté implique la lourdeur de l'autre, je peux comprendre que certains préfèrent la syntaxe de /etc/default pour divers raisons.
Ensuite, avec /etc/default, tu es quand même dépendant de ce que la personne qui a écrit le script a choisi d'utiliser. Par exemple, tu peux souvent pas surcharger proprement la ligne de commande complète du service que tu veux lancer, il te faut lire et trouver la version spécifique du paramètre que tu va utiliser. Paramètres non documentés upstream, bien sur, au contraire des options de démarrage. Parfois, c'est le contraire, tu as juste les options et tu peux faire presque ce que tu veux, sauf si ce que tu veux, c'est d'utiliser un programme avant (chroot foo, nsenter foo, runcon foo).
Donc non, je parle pas de /etc/default. C'est un mécanisme vite limité par rapport à ce que systemd propose et ce que j'utilise. Mais si tu as pas de souci avec et que tu penses que c'est suffisant, pas de souci pour moi.
Alors si tu lances bash -x /etc/init.d/blabla start , c'est pas le daemon que tu examine, mais son script d'init. Le daemon va pas forcement t'afficher grand chose en plus par magie. Et faire ça va avoir des effets de bords comme importer l'environnement de root dans celui du daemon, en fonction du script, ce qui va perturber le debuggage.
utiliser un truc en dev pour de la prod est typiquement une
mauvaise idée.
Systemd a maintenant 4 ans. Y a une branche stable v208 qui est largement stabilisé depuis longtemps. Tu peux me dire quel soft n'est pas en dev dans le libre ?
Et c'est pas aussi à ça que sert le freeze de Debian, à trouver les bugs pour avoir un logiciel utilisable en prod ?
Ce qui m'intéresse, c'est ce qu'il se passe lorsqu'il ne
fonctionne pas.
Il rajoute un message d'erreur dans les logs, comme à peut prêt tout les logiciels du monde. Et il y a assez de résultats sur "debug systemd" pour que la doc ne soit pas un souci. Est ce que tu peux détailler par exemple ce qui t'a manqué quand tu as eu un souci, à part le temps de lire avant ( chose que tu peux faire dès maintenant au lieu de poster sur linuxfr, par exemple )
Non, j'ai trouvé ça aussi comme une grosse simplification, surtout parce que je me retrouve plus dans le barbu hacker avec du bagage technique, et pourtant, je rentre pas dans la case "defend sysvinit".
Ensuite, c'est un essai, le mec a quand même eu une réflexion avec laquelle je suis d'accord sur certains points, même si je pense qu'une autre approche est nécessaire pour comprendre le débat. ( genre, je penche de plus en plus à des problématiques d'ordre social et communautaires plus profondes vis à vis du web, d'educations des gens, et de mythologie du libre ).
Alors moi, j'apprécie déjà d'avoir des trucs plus facile à écrire que les scripts d'init. J'ai par exemple fait mon script pour lancer un serveur irc en perl en 5 minutes juste en le lancant en premier plan. J'ai pas mis très longtemps non plus pour lancer prosody dans docker, bien moins que de faire marcher docker en premier lieu.
J'aime aussi beaucoup journalctl -u, au point que je me perde un peu quand je me retrouve sur des Centos 6 ( on s'habitue vite à la completion et au rangement )
Et j'ai surtout bien aimé de pouvoir mettre un bout de config via /etc/systemd/monservice.d/foo.conf, ça me parait plus perenne pour contourner un bug que l'ancienne façon, ou je devait copier et refaire le script.
Red hat a aussi d'autres contraintes. La ou le fait de rajouter un paquet dans Debian implique pas grand chose sur le long terme, le fait de rajouter un paquet dans RHEL implique d'avoir une vérification des licenses ( et des brevets ), le fait de faire un audit sommaire et/ou poussé de sécurité ( en fonction du paquet, de la criticité, etc ), le fait de s'assurer que le support soit capable de répondre ( donc des formations, de la doc ), d'avoir de la doc, parfois traduite. Et le fait d'avoir des ressources internes pour tester et corriger les bugs. Et faire évoluer aussi le projet.
Et tout ces gens ( car oui, c'est des humains ) ont un cout. Donc les clients ont du poids, mais surtout parce qu'ils payent pour faire le boulot, et avoir des gens est le principal poids bloquant dans le libre, car des idées, on en a tous des tonnes :)
C'est aussi l'occasion d'avoir les mains libres. Bien que je pense que les gens sous estiment les ressources pour faire un fork, je comprends aussi la position visant à avoir au moins un endroit pour rassembler les gens pas contents. Ensuite, je pense que malgré les efforts louables, et au vue de certaines personnalités qui viennent tourner autour du fork, j'ai peu d'espoir dans le dit fork.
Mais Debian va réussir à se débarrasser d'une partie de sa communauté ( genre tout les gens qui ont poussés les gens à partir du projet ces dernières semaines ), et ça ne peux pas être plus mal.
En pratique, upstart n'etait pas compatible inittab non plus et y a eu 0 personnes qui ont ralés pour ubuntu et rhel6.
En pratique aussi, rajouter un outil qui lit inittab et qui donne une unité systemd, ç'est assez trivial, je penche pour une après midi de boulot. Le fait que personne ne se charge de le faire depuis 4 ans laisse penser que ça intéresse pas grand monde en pratique.
Ah Joerg Reisenweber , aka doc_scrutinizer. Un mec incapable de garder son calme bien longtemps et de ne pas se lancer au mieux dans des diatribes sur irc, au pire de commencer à insulter les gens.
Il est sans doute compétent d'un point de vue technique, mais du peu que j'ai vu sur le canal du projet openmoko au fil des ans, il m'a pas donné envie de contribuer, plutôt de fuir
Dans le même genre, j'ai vu un autre Joerg bien connu venir sur leur irc, le renommé développeur de cdrtools, visiblement encore vexé par cdrkit ( en 2006 ).
Je m'attends à tout moment de voir ESR débarquer avec un tshirt "Theo for président" pour conseiller le projet sur la manière de rassembler une communauté saine ou les insultes ne volent pas.
Je pense que j'ai déjà dit tout ce que j'avais à dire sur le sujet, mais la position de Roger Leigh me parait relativement déconnecté de la réalité.
Il y a un grand nombre de personnes de Debian qui viennent du monde universaitaire, et un grand nombre de papiers académiques qui utilisent Debian comme base. Il y a des expérimentations comme Debian Gnu/Hurd et Debian kfreebsd, des portages sur des architectures expérimentales et/ou inutilisés. J'ai même vu des gens tentaient de porter minix avec Debian comme base.
De part son cycle de release, Debian est en effet pas la plus adapté à une quelconque expérimentation, vu qu'il n'y a pas de possibilités rapides de mises à jour des paquets en dehors de la sécurité. mais ça ne change pas le fait que ça reste une distribution qui est utilisé pour ça.
Des projets comme netbsd et freebsd innovent bien plus ( il suffit de voir libxo, pf, capciscum et tout un tas de trucs du même genre ).
Donc sa position me parait juste démagogique, et cherche à faire peur sans donner de vrais problèmes qui pourrait être corriger à temps.
De plus, qualifier systemd d'expérimental alors que c'est poussé dans RHEL 7/Centos 7, que le projet existe depuis plus de 4 ans, qu'il est présent en option dans la dernière stable ( et qu'il marche sans souci, au contraire de selinux qui est la depuis des années dans Debian sans vrai support ), et tout ça sans donner le moindre argument, c'est assez dur de le prendre vraiment au sérieux, car soit il est vachement partial ( ce qui est pas étonnant venant d'un mainteneur de sysvinit ), soit il a l'air d'ignorer la réalité que je viens d'énoncer.
C'est un peu une constante dans certaines critiques, c'est de ressortir des choses que tout le monde sait quand on regarde un peu, mais d'appliquer ça à systemd pour faire peur aux masses ignorantes.
Je pense que le fork est légitime et je leur souhaite du courage car ils vont en avoir besoin, je suis déjà passé par la, donc je m'estime qualifier pour dire "la, ils vont dans le mur" et y a un certain nombre de points qui me disent que ça va être dur pour eux. Et ce genre d'attitude vis à vis de l'expérimentation est mauvaise, surtout vu que Devuan vise à moderniser l'infra de contributions ( en utilisant par exemple, github, en passant via jenkins, etc ). Autant dire que si des dissensions internes arrivent en semaine 1, je suis pas sur que la communauté grandisse de manière constructive ( encore une fois, je pourrais donner des exemples ).
je sais, même déjà à l'époque de UT99, c'était compliqué. Le faire tourner 3/4 ans après, il fallait ressortir les vielles libs dans un chroot.
Je suis d'accord pour dire que c'est un souci, je suis juste pas d'accord pour dire que systemd est le premier exemple, et donc ralé sur ça spécifiquement sur systemd, c'est faire preuve de mauvaise foi. Et accuser spécifiquement lennart alors qu'il ne fait que suivre la voie tracée par les codeurs noyaux et tout le reste de l'écosystème depuis des années, c'est simplement n'importe quoi. Des gens utilisent ça pour se donner un argument de respectabilité illusoire auprés des nouveaux venus. Et c'est un peu comme les gens du mouvement gamergate qui parle d'éthique dans le journalisme dans le jeu video d'un coup, alors que c'est un souci depuis des années ( exemple connu, Marc Lacombe aka Marcus ayant quitté Gameone à cause des pressions d'Infogramme sur la redaction ), et certains s'en servent pour se donner une image présentable pour juste se défouler et attaquer les gens. C'est moindre dans le libre, mais on retrouve quand même au moins un mec qui fait parti des 2 mouvements ( aka MikeeUSA, aka Gregory Smith, etc ).
mais si c'était tellement un souci pour le libre, les gens utiliseraient Netbsd, Centos ou ce genre d'OS qui promettent une compatibilité plus longue. Si c'était un souci suffisamment important, les gens ne rejetteraient pas la LSB comme contraignante mais l'adopteraient. Ou on aurais plus de tests automatisés d'ABI/API via http://ispras.linuxbase.org/index.php/ABI_compliance_checker . moins de gens à se jeter sur ruby/go/node etc et la catastrophe d’écosystème pas ultra mature et stabilisé.
Et ce qu'on voit plutôt, c'est que les devs veulent les nouvelles versions des libs ( Google Chrome et RHEL 6 pour ne citer que cet exemple, gcompris qui avait besoin d'un gtk récent et les discussions de son auteur ici il y a une paire d'année ).
C'est que ça fait chier de garder la compatibilité alors qu'on peut juste faire un code dump sur ruby.
Je confirme, mais visiblement, c'est un temps que Kaane a du soit oublier, soit ne pas connaitre, car ça remonte quand même à longtemps ( facile 7 à 10 ans ).
j'ai pas besoin de certaines fonctions de la glibc, je fait pas un foin car elles sont disponible, car je sais que trop de modularité a un cout. J'ai pas besoin de 90% des paquets dispo dans ma distributions, et ça prends du temps pour calculer les dépendances, et pareil, je demande pas à les virer spécialement pour moi.
C'est pareil ici. C'est bien joli de croire que le libre s'écrit tout seul, mais c'est pas le cas. A un moment, tu te dit que plutot que faire 2 fois le travail, tu va le faire qu'une fois, et tant pis si il y a des choses dont les gens ont "pas besoin", car ce qui est rare, c'est le temps de contribution, pas les besoins utilisateurs. Donc on optimise pour réduire les "couts" en terme de temps sur le contributeur, pas l'utilisateur de la contribution la plupart du temps ( j'écarte le cas plus complexe ou il y a plusieurs contributeurs chainés dans la chaine de de production vers l'utilisateur final ).
Nan mais c'est Kaane aussi. Il va te dire "tel truc trunk marche pas sans ça", et rien que le fait qu'il soit pas foutu d'utiliser le bon terme ( trunk, c'est pour svn, pas git ) montre qu'il maitrise pas vraiment le sujet.
Ensuite, tu va lire le code source, tu va voir que udevd utilise encore un socket netlink ( genre dans worker_new, http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udevd.c#n174 ), et la, tu as compris qu'il a du prendre sans doute du faire une faute dans un grep et qu'il conclue à la vavite.
Jamais il va pointer vers du code, ou ce genre de choses, faut toujours passé du temps à double vérifier ses affirmations, car ça a l'air sérieux, mais en pratique, non. Suffit de voir les dépêches sur systemd d'il y a 1 ou 2 ans, ou j'ai quand même passé un bon paquet de temps à expliquer les choses, car ce genre de comportement est à mon sens toxique pour la communauté, car ça masque les critiques légitimes en les recouvrant de bullshit.
( 2006, pour les gens qui veulent pas cliquer ). Et pour les gens qui veulent pas cliquer aussi, on voit GKH poser la question de "pourquoi on va supporter les trucs que les créateurs refusent de supporter plus longtemps".
Autre exemple ? Iptables, et notamment des projets approchants comme ipset, etc. Tu mets à jour ta distro, et il te faut une version plus à jour de tel ou tel truc interne.
Des APIs exposés sous la forme de chemin dans le système de fichier, y en a des tonnes. Le changement de pilote pour les disques IDE et le renommage des noms de disques qui a suivi ( hda/sda ) est un exemple de trucs qui a du casser des scripts. Les changements dans /sys aussi.
Le monde s'est pas arrêté de tourner pour autant. Découvrir juste aujourd'hui le problème des ABI/API c'est juste avoir été sous un igloo depuis longtemps.
Et le mail de Lennart prévient à l'avance qu'il va falloir s'adapter au changement. Je pense avoir lu sur lwn que l'idée est de déprécier l'interface au bout de ~2 ans, ce qui laisse largement le temps de pouvoir faire des mises à jours, donc on est loin des suppositions de "on va devoir mettre à jour le jour de la sortie".
Ceci dit, wheezy a forcé un support obligatoire des tags LSB dans les scripts d'init. C'est aussi une source d'erreur potentiel, et j'ai vu 0 personnes en parler et/ou raler et/ou demander un GR sur le sujet.
Bien sur qu'il y a des trucs qui ne vont pas marcher, comme par exemple, un script interactif au boot ( mais qui n'aurait pas marcher sans doute en wheezy non plus ). Maintenant, d'une part, y a encore quelques mois avant la release de jessie, et il y a encore quelques mois après la release. Et si le souci, c'est que Debian release trop vite, on peut difficilement dire que ç'est la fate à systemd.
Car des changements, y en a a toujours. L'exemple que je donne sans arrêt, c'est apache 2.4, mais je peux aussi donner les versions majeurs de php au moment de php4 et je peux te dire que du code php, c'est autrement plus long à fixer que 3/4 scripts d'inits.
Donc perso, je pige pas le fait de se focaliser sur systemd et d'idéaliser complétement le reste en occultant les pétages réguliers de la compatibilité par divers upstreams.
C'est amusant, car je voulais justement voir si le souci qu'on trouve sur upstart ( https://rachelbythebay.com/w/2014/11/24/touch/ ) serait géré par systemd. J'ai rien vu sur le fait d'avoir une gestion à ce niveau, mais si ça crashe pas, ça veut rien dire.
Les différentes fondations sont pas ouvertes à tous. Par exemple, apache a un processus spécifique avant d'être accepté, qui requiert d'avoir des commiteurs de sociétés différentes, qui impose de suivre une gouvernance et un processus à part, etc.
Ça impose aussi la license parfois, ou le sujet. Et je pense que la fondation décide ou va l'argent, pas toi.
Sur la traduction via des fichiers .po, tu oublies des points. D'une part, installer un éditeur n'est pas extrêmement compliqué, c'est pas le truc le plus bloquant. Les éditeurs sont globalement pas si mauvais à mon gout, et je pense que le plus gros souci, c'est de trouver le fichier ( ie, utiliser un vcs ) et le workflow. Et surtout de l'utiliser sur le soft existant ( ie, compile depuis git, ou déploiement en cas d'application web ).
Ensuite, il faut pas "juste aller sur un site et voila", il y a aussi tout un travail de prise en compte du vocabulaire, suivre un glossaire pour la consistance ( proxy vs mandataire ), décider pour les raccourcis claviers, comprendre les soucis de pluriels et de substitutions de chaines. Et il faut quelqu'un pour relire ( an kas de fotes ), valider. IE, bien que ça soit ouvert à tous pour commencer, il faut des compétences pour faire une traduction de qualités. Deja, prendre conscience que la traduction, c'est pas simple permet de se rappeler que ç'est une compétence comme une autre qui s'acquiert, et dire "c'est simple sur transifex", c'est un peu nier l'existence des compétences et pas vraiment sympa pour les traducteurs.
Quand à écrire de la documentation, c'est pareil. C'est pas simple d'écrire de façon claire. Tu as des problématiques amusantes comme avoir un truc visible mais ou tu perds les informations sémantiques ( genre marqué un titre "titre" vs "mettre un titre en gras et en police X ) ou avoir un truc structuré qui permet pas de variation dans le style.
Je suis plus en accord avec la problématique des rapports de bugs, c'est un excellent exemple. Oui, bugzilla est pas idéal ( on va retirer les soucis sur le fait qu'un autre BTS serait mieux et se concentrer sur les cas ou un autre mode complet d'interaction est mieux ). Mais on l'utilise car on a une préférence pour les codeurs. Ce que les gens veulent, c'est pas rapporter des bugs, c'est communiquer avec le projet pour donner du feedback. Ensuite, que le feedback débouche sur des bugs, c'est autre chose. Et tout ça, c'est un domaine que les boites connaissent, le "service aux consommateurs". Sauf que c'est pas du tout comme ça qu'on le conçoit dans le libre. Tu mets des listes des discussions d'utilisateurs ( par oppositions aux devs, ce qui grave quand même bien la distinction dans l'esprit des gens ), des forums, etc. Mais y a pas de rôles désignés pour s'occuper de ça. Tu as tout au plus des modérateurs de forums, qui sont là pour bloquer les débordements, et qui ont le mauvais goût d'attirer les gens avides de pouvoir et parfois d'attiser les conflits ( cf la charte de freenode ).
En fait, ça me rappelle cet article ( http://www.laurenbacon.com/women-tech-empathy-work/ ), Les comportements de certains gens dans le libre et certaines startups ont parfois des points en communs, en partie parce que les premiers débouchent sur les seconds.
Mais oui, faudrait sans doute des nouveaux outils. mais pas que. Il faut aussi revoir l'approche et la perception de la contribution dans le libre en général.
Le souci, c'est que donner de l'argent entraine un petit paquet de complication. Faut faire les comptes, payer des impots, avoir une structure, des salariés pour gérer ça.
Donc faut avoir de l'argent pour gérer l'argent que tu reçois.
C'est pas impossible. C'est juste difficile à démarrer pour que ça dure dans le temps.
Et dans une communauté ou on chante les louanges des développeurs par rapport à tout le reste, forcement, les gens qui font le travail vu comme ennuyeux ( doc, QA, administratif ) sont pas attirés et mise en avant.
Je pense que la distinction technique ne fait sens que pour les personnes capables de la faire. Pour l'utilisateur moyen, la différence entre OS, hardware etc est perdu ou masqué, donc je serait pas étonné que la confusion des marques soit la même en matière de marque.
Le but, c'est pas d'avoir des cases toute fait pour satisfaire l'esprit compulsif du nerd moyen capable de classifier 4500 pokémons par couleur et par force avec une main parce qu'il est expert dans ce domaine et parce qu'il a passé du temps sur sa passion, mais bien de voir si quelqu'un rentrant un peu plus dans une norme vaguement défini comme etant un non expert risque de confondre et si la confusion risque de poser préjudice à un ou l'autre des groupes, et ce genre de considération.
[^] # Re: Les milieux culturels et techniques des zélateurs/détracteurs
Posté par Misc (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 2.
Ça me parait pas très concluant non plus comme division. Je pense qu'il y a une grande part des gens qui font de l'informatique pour leur métier, mais qui voient surtout que ça apporte des emmerdes, qu'on leur crie dessus quand ça ne marche pas, qu'on leur dit à longueur de temps qu'ils sont un cout financier, de façon direct ou indirect. La passion est peut être parti depuis longtemps, ou le temps. Et depuis quelques temps, j'ai le sentiment que l'informatique bouge de plus en plus vite, ne serais que parce qu'il y a un influx d'ingénieurs, une accélération de l'échange d'idée, et des moyens en plus.
Donc il y a peut être des gens qui ont peur de pas réussir à suivre, peur de ce que ça va apporter, et le changement par nature fait peur aux gens, c'est un mécanisme ancré dans notre subconscient. Il suffit de voir que beaucoup de choses ont commencé quand un journaliste a lancé l'idée d'une apocalypse qui vient, ce qui est quand même le summum du fear mongering. De voir que ça a provoqué des réactions disproportionnés pour un sujet technique comme celui la. Et que les gens relaient des informations sans vérifier si c'est vrai ou pas ( l'exemple de systemd et des logs binaires par exemple ). Les gens répètent ce qui confortent leurs peurs pour la propager, car c'est plus rassurant de pas être seul à paniquer.
Un autre exemple, le blog de iguru, totalement non fondé et basé sur des affirmations péremptoires non vérifiables, mais qui alimentent la paranoia.
Ensuite, encore une fois, tout le monde rentre pas dans ce cadre, et y a plein de gens avec un avis plus mesuré, mais masqué par les autres.
[^] # Re: Fonctionnalités clées.
Posté par Misc (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 8.
Ça dépend comment tu veux les utiliser. Pour limiter les processus en terme de ressources, non, tu as déjà des logiciels existants, tu peux le faire à la main. Systemd automatise cette partie et l'unifie au niveau de la configuration.
Pour ce qui est d'utiliser le tracking des processus, tu peux le faire à la main, mais c'est vite chiant. Donc openrc et systemd peuvent le faire pour toi.
Ensuite, dans le futur, le kernel s'oriente vers une architecture avec un seul processus autorisé à gerer les cgroups. Lennart parle sur la liste de systemd de l'impact qu'il y a eu ( http://lwn.net/Articles/555922/ ) et Linux.com explique pourquoi les devs kernels veulent changer ça :
http://www.linux.com/news/featured-blogs/200-libby-clark/733595-all-about-the-linux-kernel-cgroups-redesign
Il y a aussi pas mal d'info sur http://lwn.net/Articles/575672/
Et le fait que les devs de cgmanager et de systemd se sont réunis pour trouver une solution il y a 2 mois à Dusseldorf pour discutter interopérabilité ( une info qu'on ne relaye pas assez, bien sur, ç'est moins vendeur pour un journal )
[^] # Re: Ca ne règle pas la source du problème
Posté par Misc (site web personnel) . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 4.
Certes, mais on peut pas avoir le beurre et l'argent du beurre. La compatibilité a un cout humain, et le temps que tu passes à tester et à vérifier que rien ne casse, c'est du temps que tu passes pas à optimiser et à coder pour du nouveau hardware.
Un exemple stupide. Tu codes ton unix like avec l'infra video du moment, et en l'espace de 5 ans, tout change et il te faut de la 3d partout. Si tu t'occupes de la compatibilité, alors tu va maintenir 2 couches. Si tu t'en fout, alors tu va t'occuper que de la dernière. Et tu va passer plus de temps à rendre la dernière rapide/propre/etc que si tu avais que la moitié ou 75% du temps.
Bien sur, ça n'explique pas tout pour netbsd, mais ça explique une partie.
Et peut être qu'une innovation rapide mais chaotique et cahoteuse à la Linux marche mieux pour avoir le support du hardware et des perfs, ce qui ensuite attire plus de gens, dans un cercle vertueux.
Et en effet, des boites comme IBM, HP, RH font leur beurre sur les demandes de stabilité.
[^] # Re: Fonctionnalités clées.
Posté par Misc (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 6.
Alors je peux, avec une suffisance gonflant mon eog, me citer moi même, quand j'ai pourri Kadalka :
https://linuxfr.org/nodes/97210/comments/1426891
C'est un gros pâté, mais les exemples que je donnent sont vers 75% du texte. l'exemple de bind est facile à piger, mais il arrive sans doute peu en pratique sur une petite installation.
Tu as aussi mon exemple de apache et de sympa ( qui arrive plus souvent ). Ensuite, peut être que tu as accepté le fait que les bugs arrivent, ou que ça marche pas de temps en temps sans savoir pourquoi. D'autres non.
[^] # Re: Fonctionnalités clées.
Posté par Misc (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 5.
Non, sinon j'aurais dit "je trouve tel truc mieux que /etc/default".
Déjà, /etc/default est pourri car ça reste du shell. Ce qui veut dire que soit tu te limites à la syntaxe FOO="truc" et c'est plus du shell, soit tu mets du vrai shell (genre $() pour lire un truc dynamiquement) et la, ça devient difficile à parser par des outils automatisés (genre ansible/puppet, etc). Ensuite, la flexibilité d'un coté implique la lourdeur de l'autre, je peux comprendre que certains préfèrent la syntaxe de /etc/default pour divers raisons.
Ensuite, avec /etc/default, tu es quand même dépendant de ce que la personne qui a écrit le script a choisi d'utiliser. Par exemple, tu peux souvent pas surcharger proprement la ligne de commande complète du service que tu veux lancer, il te faut lire et trouver la version spécifique du paramètre que tu va utiliser. Paramètres non documentés upstream, bien sur, au contraire des options de démarrage. Parfois, c'est le contraire, tu as juste les options et tu peux faire presque ce que tu veux, sauf si ce que tu veux, c'est d'utiliser un programme avant (chroot foo, nsenter foo, runcon foo).
Donc non, je parle pas de /etc/default. C'est un mécanisme vite limité par rapport à ce que systemd propose et ce que j'utilise. Mais si tu as pas de souci avec et que tu penses que c'est suffisant, pas de souci pour moi.
[^] # Re: Hmm
Posté par Misc (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 10.
Alors si tu lances bash -x /etc/init.d/blabla start , c'est pas le daemon que tu examine, mais son script d'init. Le daemon va pas forcement t'afficher grand chose en plus par magie. Et faire ça va avoir des effets de bords comme importer l'environnement de root dans celui du daemon, en fonction du script, ce qui va perturber le debuggage.
Systemd a maintenant 4 ans. Y a une branche stable v208 qui est largement stabilisé depuis longtemps. Tu peux me dire quel soft n'est pas en dev dans le libre ?
Et c'est pas aussi à ça que sert le freeze de Debian, à trouver les bugs pour avoir un logiciel utilisable en prod ?
Il rajoute un message d'erreur dans les logs, comme à peut prêt tout les logiciels du monde. Et il y a assez de résultats sur "debug systemd" pour que la doc ne soit pas un souci. Est ce que tu peux détailler par exemple ce qui t'a manqué quand tu as eu un souci, à part le temps de lire avant ( chose que tu peux faire dès maintenant au lieu de poster sur linuxfr, par exemple )
[^] # Re: Les milieux culturels et techniques des zélateurs/détracteurs
Posté par Misc (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 6.
Non, j'ai trouvé ça aussi comme une grosse simplification, surtout parce que je me retrouve plus dans le barbu hacker avec du bagage technique, et pourtant, je rentre pas dans la case "defend sysvinit".
Ensuite, c'est un essai, le mec a quand même eu une réflexion avec laquelle je suis d'accord sur certains points, même si je pense qu'une autre approche est nécessaire pour comprendre le débat. ( genre, je penche de plus en plus à des problématiques d'ordre social et communautaires plus profondes vis à vis du web, d'educations des gens, et de mythologie du libre ).
[^] # Re: Fonctionnalités clées.
Posté par Misc (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 9.
Alors moi, j'apprécie déjà d'avoir des trucs plus facile à écrire que les scripts d'init. J'ai par exemple fait mon script pour lancer un serveur irc en perl en 5 minutes juste en le lancant en premier plan. J'ai pas mis très longtemps non plus pour lancer prosody dans docker, bien moins que de faire marcher docker en premier lieu.
J'aime aussi beaucoup journalctl -u, au point que je me perde un peu quand je me retrouve sur des Centos 6 ( on s'habitue vite à la completion et au rangement )
Et j'ai surtout bien aimé de pouvoir mettre un bout de config via /etc/systemd/monservice.d/foo.conf, ça me parait plus perenne pour contourner un bug que l'ancienne façon, ou je devait copier et refaire le script.
[^] # Re: Le choc ?
Posté par Misc (site web personnel) . En réponse au journal Devuan forks Debian: un choc ou c'était inévitable?. Évalué à 2.
Je suis en faveur du CCC
http://www.dailymotion.com/video/x1ivtx_les-nuls-comite-contre-les-chats_fun
[^] # Re: Le choc ?
Posté par Misc (site web personnel) . En réponse au journal Devuan forks Debian: un choc ou c'était inévitable?. Évalué à 5.
Red hat a aussi d'autres contraintes. La ou le fait de rajouter un paquet dans Debian implique pas grand chose sur le long terme, le fait de rajouter un paquet dans RHEL implique d'avoir une vérification des licenses ( et des brevets ), le fait de faire un audit sommaire et/ou poussé de sécurité ( en fonction du paquet, de la criticité, etc ), le fait de s'assurer que le support soit capable de répondre ( donc des formations, de la doc ), d'avoir de la doc, parfois traduite. Et le fait d'avoir des ressources internes pour tester et corriger les bugs. Et faire évoluer aussi le projet.
Et tout ces gens ( car oui, c'est des humains ) ont un cout. Donc les clients ont du poids, mais surtout parce qu'ils payent pour faire le boulot, et avoir des gens est le principal poids bloquant dans le libre, car des idées, on en a tous des tonnes :)
[^] # Re: Pourquoi un fork?
Posté par Misc (site web personnel) . En réponse au journal Devuan forks Debian: un choc ou c'était inévitable?. Évalué à 4.
C'est aussi l'occasion d'avoir les mains libres. Bien que je pense que les gens sous estiment les ressources pour faire un fork, je comprends aussi la position visant à avoir au moins un endroit pour rassembler les gens pas contents. Ensuite, je pense que malgré les efforts louables, et au vue de certaines personnalités qui viennent tourner autour du fork, j'ai peu d'espoir dans le dit fork.
Mais Debian va réussir à se débarrasser d'une partie de sa communauté ( genre tout les gens qui ont poussés les gens à partir du projet ces dernières semaines ), et ça ne peux pas être plus mal.
[^] # Re: Incompatible ?
Posté par Misc (site web personnel) . En réponse au journal Devuan forks Debian: un choc ou c'était inévitable?. Évalué à 7.
En pratique, upstart n'etait pas compatible inittab non plus et y a eu 0 personnes qui ont ralés pour ubuntu et rhel6.
En pratique aussi, rajouter un outil qui lit inittab et qui donne une unité systemd, ç'est assez trivial, je penche pour une après midi de boulot. Le fait que personne ne se charge de le faire depuis 4 ans laisse penser que ça intéresse pas grand monde en pratique.
[^] # Re: trop de bruit pour rien
Posté par Misc (site web personnel) . En réponse au journal Devuan forks Debian: un choc ou c'était inévitable?. Évalué à 3.
Ah Joerg Reisenweber , aka doc_scrutinizer. Un mec incapable de garder son calme bien longtemps et de ne pas se lancer au mieux dans des diatribes sur irc, au pire de commencer à insulter les gens.
Il est sans doute compétent d'un point de vue technique, mais du peu que j'ai vu sur le canal du projet openmoko au fil des ans, il m'a pas donné envie de contribuer, plutôt de fuir
Dans le même genre, j'ai vu un autre Joerg bien connu venir sur leur irc, le renommé développeur de cdrtools, visiblement encore vexé par cdrkit ( en 2006 ).
Je m'attends à tout moment de voir ESR débarquer avec un tshirt "Theo for président" pour conseiller le projet sur la manière de rassembler une communauté saine ou les insultes ne volent pas.
# Sur un autre sujet
Posté par Misc (site web personnel) . En réponse au journal Devuan forks Debian: un choc ou c'était inévitable?. Évalué à 8.
Je pense que j'ai déjà dit tout ce que j'avais à dire sur le sujet, mais la position de Roger Leigh me parait relativement déconnecté de la réalité.
Il y a un grand nombre de personnes de Debian qui viennent du monde universaitaire, et un grand nombre de papiers académiques qui utilisent Debian comme base. Il y a des expérimentations comme Debian Gnu/Hurd et Debian kfreebsd, des portages sur des architectures expérimentales et/ou inutilisés. J'ai même vu des gens tentaient de porter minix avec Debian comme base.
De part son cycle de release, Debian est en effet pas la plus adapté à une quelconque expérimentation, vu qu'il n'y a pas de possibilités rapides de mises à jour des paquets en dehors de la sécurité. mais ça ne change pas le fait que ça reste une distribution qui est utilisé pour ça.
Des projets comme netbsd et freebsd innovent bien plus ( il suffit de voir libxo, pf, capciscum et tout un tas de trucs du même genre ).
Donc sa position me parait juste démagogique, et cherche à faire peur sans donner de vrais problèmes qui pourrait être corriger à temps.
De plus, qualifier systemd d'expérimental alors que c'est poussé dans RHEL 7/Centos 7, que le projet existe depuis plus de 4 ans, qu'il est présent en option dans la dernière stable ( et qu'il marche sans souci, au contraire de selinux qui est la depuis des années dans Debian sans vrai support ), et tout ça sans donner le moindre argument, c'est assez dur de le prendre vraiment au sérieux, car soit il est vachement partial ( ce qui est pas étonnant venant d'un mainteneur de sysvinit ), soit il a l'air d'ignorer la réalité que je viens d'énoncer.
C'est un peu une constante dans certaines critiques, c'est de ressortir des choses que tout le monde sait quand on regarde un peu, mais d'appliquer ça à systemd pour faire peur aux masses ignorantes.
Je pense que le fork est légitime et je leur souhaite du courage car ils vont en avoir besoin, je suis déjà passé par la, donc je m'estime qualifier pour dire "la, ils vont dans le mur" et y a un certain nombre de points qui me disent que ça va être dur pour eux. Et ce genre d'attitude vis à vis de l'expérimentation est mauvaise, surtout vu que Devuan vise à moderniser l'infra de contributions ( en utilisant par exemple, github, en passant via jenkins, etc ). Autant dire que si des dissensions internes arrivent en semaine 1, je suis pas sur que la communauté grandisse de manière constructive ( encore une fois, je pourrais donner des exemples ).
[^] # Re: Ca ne règle pas la source du problème
Posté par Misc (site web personnel) . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 2.
je sais, même déjà à l'époque de UT99, c'était compliqué. Le faire tourner 3/4 ans après, il fallait ressortir les vielles libs dans un chroot.
Je suis d'accord pour dire que c'est un souci, je suis juste pas d'accord pour dire que systemd est le premier exemple, et donc ralé sur ça spécifiquement sur systemd, c'est faire preuve de mauvaise foi. Et accuser spécifiquement lennart alors qu'il ne fait que suivre la voie tracée par les codeurs noyaux et tout le reste de l'écosystème depuis des années, c'est simplement n'importe quoi. Des gens utilisent ça pour se donner un argument de respectabilité illusoire auprés des nouveaux venus. Et c'est un peu comme les gens du mouvement gamergate qui parle d'éthique dans le journalisme dans le jeu video d'un coup, alors que c'est un souci depuis des années ( exemple connu, Marc Lacombe aka Marcus ayant quitté Gameone à cause des pressions d'Infogramme sur la redaction ), et certains s'en servent pour se donner une image présentable pour juste se défouler et attaquer les gens. C'est moindre dans le libre, mais on retrouve quand même au moins un mec qui fait parti des 2 mouvements ( aka MikeeUSA, aka Gregory Smith, etc ).
mais si c'était tellement un souci pour le libre, les gens utiliseraient Netbsd, Centos ou ce genre d'OS qui promettent une compatibilité plus longue. Si c'était un souci suffisamment important, les gens ne rejetteraient pas la LSB comme contraignante mais l'adopteraient. Ou on aurais plus de tests automatisés d'ABI/API via http://ispras.linuxbase.org/index.php/ABI_compliance_checker . moins de gens à se jeter sur ruby/go/node etc et la catastrophe d’écosystème pas ultra mature et stabilisé.
Et ce qu'on voit plutôt, c'est que les devs veulent les nouvelles versions des libs ( Google Chrome et RHEL 6 pour ne citer que cet exemple, gcompris qui avait besoin d'un gtk récent et les discussions de son auteur ici il y a une paire d'année ).
C'est que ça fait chier de garder la compatibilité alors qu'on peut juste faire un code dump sur ruby.
[^] # Re: Ca ne règle pas la source du problème
Posté par Misc (site web personnel) . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 3.
Je confirme, mais visiblement, c'est un temps que Kaane a du soit oublier, soit ne pas connaitre, car ça remonte quand même à longtemps ( facile 7 à 10 ans ).
[^] # Re: Ca ne règle pas la source du problème
Posté par Misc (site web personnel) . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 5.
j'ai pas besoin de certaines fonctions de la glibc, je fait pas un foin car elles sont disponible, car je sais que trop de modularité a un cout. J'ai pas besoin de 90% des paquets dispo dans ma distributions, et ça prends du temps pour calculer les dépendances, et pareil, je demande pas à les virer spécialement pour moi.
C'est pareil ici. C'est bien joli de croire que le libre s'écrit tout seul, mais c'est pas le cas. A un moment, tu te dit que plutot que faire 2 fois le travail, tu va le faire qu'une fois, et tant pis si il y a des choses dont les gens ont "pas besoin", car ce qui est rare, c'est le temps de contribution, pas les besoins utilisateurs. Donc on optimise pour réduire les "couts" en terme de temps sur le contributeur, pas l'utilisateur de la contribution la plupart du temps ( j'écarte le cas plus complexe ou il y a plusieurs contributeurs chainés dans la chaine de de production vers l'utilisateur final ).
[^] # Re: Ca ne règle pas la source du problème
Posté par Misc (site web personnel) . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 0.
Nan mais c'est Kaane aussi. Il va te dire "tel truc trunk marche pas sans ça", et rien que le fait qu'il soit pas foutu d'utiliser le bon terme ( trunk, c'est pour svn, pas git ) montre qu'il maitrise pas vraiment le sujet.
Ensuite, tu va lire le code source, tu va voir que udevd utilise encore un socket netlink ( genre dans worker_new, http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udevd.c#n174 ), et la, tu as compris qu'il a du prendre sans doute du faire une faute dans un grep et qu'il conclue à la vavite.
Jamais il va pointer vers du code, ou ce genre de choses, faut toujours passé du temps à double vérifier ses affirmations, car ça a l'air sérieux, mais en pratique, non. Suffit de voir les dépêches sur systemd d'il y a 1 ou 2 ans, ou j'ai quand même passé un bon paquet de temps à expliquer les choses, car ce genre de comportement est à mon sens toxique pour la communauté, car ça masque les critiques légitimes en les recouvrant de bullshit.
[^] # Re: Ca ne règle pas la source du problème
Posté par Misc (site web personnel) . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 5.
Je ne sais pas si tu fudes, mais il est clair que soit tu selectionnes tes points, soit tu fait preuve d'ignorance.
Parce que avoir un kernel à jour en même temps que l'userspace, ça arrive relativement plus souvnet que tu veux faire croire.
Exemple, udev avant que ça devienne part au projet systemd :
http://lwn.net/Articles/193603/
( 2006, pour les gens qui veulent pas cliquer ). Et pour les gens qui veulent pas cliquer aussi, on voit GKH poser la question de "pourquoi on va supporter les trucs que les créateurs refusent de supporter plus longtemps".
Autre exemple ? Iptables, et notamment des projets approchants comme ipset, etc. Tu mets à jour ta distro, et il te faut une version plus à jour de tel ou tel truc interne.
Des APIs exposés sous la forme de chemin dans le système de fichier, y en a des tonnes. Le changement de pilote pour les disques IDE et le renommage des noms de disques qui a suivi ( hda/sda ) est un exemple de trucs qui a du casser des scripts. Les changements dans /sys aussi.
Le monde s'est pas arrêté de tourner pour autant. Découvrir juste aujourd'hui le problème des ABI/API c'est juste avoir été sous un igloo depuis longtemps.
Et le mail de Lennart prévient à l'avance qu'il va falloir s'adapter au changement. Je pense avoir lu sur lwn que l'idée est de déprécier l'interface au bout de ~2 ans, ce qui laisse largement le temps de pouvoir faire des mises à jours, donc on est loin des suppositions de "on va devoir mettre à jour le jour de la sortie".
[^] # Re: Ca ne règle pas la source du problème
Posté par Misc (site web personnel) . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 3.
Ceci dit, wheezy a forcé un support obligatoire des tags LSB dans les scripts d'init. C'est aussi une source d'erreur potentiel, et j'ai vu 0 personnes en parler et/ou raler et/ou demander un GR sur le sujet.
Bien sur qu'il y a des trucs qui ne vont pas marcher, comme par exemple, un script interactif au boot ( mais qui n'aurait pas marcher sans doute en wheezy non plus ). Maintenant, d'une part, y a encore quelques mois avant la release de jessie, et il y a encore quelques mois après la release. Et si le souci, c'est que Debian release trop vite, on peut difficilement dire que ç'est la fate à systemd.
Car des changements, y en a a toujours. L'exemple que je donne sans arrêt, c'est apache 2.4, mais je peux aussi donner les versions majeurs de php au moment de php4 et je peux te dire que du code php, c'est autrement plus long à fixer que 3/4 scripts d'inits.
Donc perso, je pige pas le fait de se focaliser sur systemd et d'idéaliser complétement le reste en occultant les pétages réguliers de la compatibilité par divers upstreams.
[^] # Re: Et systemd ?
Posté par Misc (site web personnel) . En réponse à la dépêche Exploiter inotify, c’est simple. Évalué à 3.
C'est amusant, car je voulais justement voir si le souci qu'on trouve sur upstart ( https://rachelbythebay.com/w/2014/11/24/touch/ ) serait géré par systemd. J'ai rien vu sur le fait d'avoir une gestion à ce niveau, mais si ça crashe pas, ça veut rien dire.
[^] # Re: Super mais seulement 1M ?
Posté par Misc (site web personnel) . En réponse au journal Freebsd reçoit une peu de thunes.. Évalué à 8. Dernière modification le 18 novembre 2014 à 23:30.
Les différentes fondations sont pas ouvertes à tous. Par exemple, apache a un processus spécifique avant d'être accepté, qui requiert d'avoir des commiteurs de sociétés différentes, qui impose de suivre une gouvernance et un processus à part, etc.
Ça impose aussi la license parfois, ou le sujet. Et je pense que la fondation décide ou va l'argent, pas toi.
Sur la traduction via des fichiers .po, tu oublies des points. D'une part, installer un éditeur n'est pas extrêmement compliqué, c'est pas le truc le plus bloquant. Les éditeurs sont globalement pas si mauvais à mon gout, et je pense que le plus gros souci, c'est de trouver le fichier ( ie, utiliser un vcs ) et le workflow. Et surtout de l'utiliser sur le soft existant ( ie, compile depuis git, ou déploiement en cas d'application web ).
Ensuite, il faut pas "juste aller sur un site et voila", il y a aussi tout un travail de prise en compte du vocabulaire, suivre un glossaire pour la consistance ( proxy vs mandataire ), décider pour les raccourcis claviers, comprendre les soucis de pluriels et de substitutions de chaines. Et il faut quelqu'un pour relire ( an kas de fotes ), valider. IE, bien que ça soit ouvert à tous pour commencer, il faut des compétences pour faire une traduction de qualités. Deja, prendre conscience que la traduction, c'est pas simple permet de se rappeler que ç'est une compétence comme une autre qui s'acquiert, et dire "c'est simple sur transifex", c'est un peu nier l'existence des compétences et pas vraiment sympa pour les traducteurs.
Quand à écrire de la documentation, c'est pareil. C'est pas simple d'écrire de façon claire. Tu as des problématiques amusantes comme avoir un truc visible mais ou tu perds les informations sémantiques ( genre marqué un titre "titre" vs "mettre un titre en gras et en police X ) ou avoir un truc structuré qui permet pas de variation dans le style.
Je suis plus en accord avec la problématique des rapports de bugs, c'est un excellent exemple. Oui, bugzilla est pas idéal ( on va retirer les soucis sur le fait qu'un autre BTS serait mieux et se concentrer sur les cas ou un autre mode complet d'interaction est mieux ). Mais on l'utilise car on a une préférence pour les codeurs. Ce que les gens veulent, c'est pas rapporter des bugs, c'est communiquer avec le projet pour donner du feedback. Ensuite, que le feedback débouche sur des bugs, c'est autre chose. Et tout ça, c'est un domaine que les boites connaissent, le "service aux consommateurs". Sauf que c'est pas du tout comme ça qu'on le conçoit dans le libre. Tu mets des listes des discussions d'utilisateurs ( par oppositions aux devs, ce qui grave quand même bien la distinction dans l'esprit des gens ), des forums, etc. Mais y a pas de rôles désignés pour s'occuper de ça. Tu as tout au plus des modérateurs de forums, qui sont là pour bloquer les débordements, et qui ont le mauvais goût d'attirer les gens avides de pouvoir et parfois d'attiser les conflits ( cf la charte de freenode ).
En fait, ça me rappelle cet article ( http://www.laurenbacon.com/women-tech-empathy-work/ ), Les comportements de certains gens dans le libre et certaines startups ont parfois des points en communs, en partie parce que les premiers débouchent sur les seconds.
Mais oui, faudrait sans doute des nouveaux outils. mais pas que. Il faut aussi revoir l'approche et la perception de la contribution dans le libre en général.
[^] # Re: Super mais seulement 1M ?
Posté par Misc (site web personnel) . En réponse au journal Freebsd reçoit une peu de thunes.. Évalué à 4.
Le souci, c'est que donner de l'argent entraine un petit paquet de complication. Faut faire les comptes, payer des impots, avoir une structure, des salariés pour gérer ça.
Donc faut avoir de l'argent pour gérer l'argent que tu reçois.
C'est pas impossible. C'est juste difficile à démarrer pour que ça dure dans le temps.
Et dans une communauté ou on chante les louanges des développeurs par rapport à tout le reste, forcement, les gens qui font le travail vu comme ennuyeux ( doc, QA, administratif ) sont pas attirés et mise en avant.
[^] # Re: Fonds
Posté par Misc (site web personnel) . En réponse au journal Gnome lance un financement et une action en Justice contre Groupon pour protéger sa marque !. Évalué à 3.
Il est aussi probable que les sponsors payent de façon annuelle.
[^] # Re: Deux critiques
Posté par Misc (site web personnel) . En réponse au journal Gnome lance un financement et une action en Justice contre Groupon pour protéger sa marque !. Évalué à 6.
Je pense que la distinction technique ne fait sens que pour les personnes capables de la faire. Pour l'utilisateur moyen, la différence entre OS, hardware etc est perdu ou masqué, donc je serait pas étonné que la confusion des marques soit la même en matière de marque.
Le but, c'est pas d'avoir des cases toute fait pour satisfaire l'esprit compulsif du nerd moyen capable de classifier 4500 pokémons par couleur et par force avec une main parce qu'il est expert dans ce domaine et parce qu'il a passé du temps sur sa passion, mais bien de voir si quelqu'un rentrant un peu plus dans une norme vaguement défini comme etant un non expert risque de confondre et si la confusion risque de poser préjudice à un ou l'autre des groupes, et ce genre de considération.