Je pense que pour rhel6, l'idée était d'intégrer upstart parce que Fedora a pris upstart, et si l'intégration avait été poussé plus loin, ça aurait été bien mieux.
Mais même Canonical n'avait pas vraiment poussé upstart et apparmor à l'époque ( vers la 10.04 ), ce qui m'a un peu déçu. Je comprends qu'ils ont pas le staff requis pour ça, mais ça a rajouté une raison de plus pour moi de prendre ce qu'ils disent avec des pincettes. Dieu merci, maintenant, ça semble se faire, même si il reste encore pas mal de boulot.
Non mais tu as raison sur le fait que les gens sortent l'argument de la méritocratie bien souvent pour dire que tout est parfait alors que non. De la même façon que la démocratie n'est pas sans faille ( vu que ça dépend grandement de qui vote, de la façon dont les arguments sont présentés, etc ), mais en effet, la méritocratie est souvent idéalisé alors que c'est pas le cas, y a plein de souci malgré le fait qu'on croit que tout le monde est égal devant la contribution, alors que la seule égalité qu'on a, c'est celle des contraintes du code ( ie, tout le monde ou presque a les mêmes opportunités donnés par une license libre, sauf cas spéciaux ).
Il reste à coté les contraintes de temps, de compétences, de trouver des gens proches de chez toi, proche d'un point de vue temporel, proche pour t'aider, etc, etc. Contraintes qu'on peut pas nier, mais contraintes qu'on peut pas résoudre facilement et complétement juste par la volonté et 3/4 lignes en anglais.
D'une part, c'est considérer que dans les distribs, il y a
toujours unanimité des choix, ce qui est faux
Tu veux dire quoi par "unanimité dans les distros". Unanimité, ça implique d'avoir un ensemble fini de gens avec des critères, et la, je pense que "une distro", c'est flou. Est ce que la distribution, c'est "tout les gens qui ont le droit de commit", tout les gens qui sont sur une ml, dans un ldap, qui utilisent à un moment T, etc. En général, le but n'est pas d'avoir l'unanimité, c'est bien plus pragmatique que ça, le but est de réduire la maintenance du projet tout en permettant de faire un certains nombres de choses avec le produit.
Et bien que ça reste subjectif comme définition, il faut pas oublier que c'est ça. Les gens peuvent rajouter tout ce qu'ils veulent par dessus, à la fin, faut produire un truc. Si ton but n'est pas de sortir un produit, alors c'est pas une distribution que tu fait. Y a rien de mal à ça, c'est juste pas la même chose.
D'autre part, cette histoire permanente de contribution ne
devient rien d'autre qu'un prétexte pour envoyer les gens se
faire foutre.
J'aurais tendance à dire que ça peut être pris comme ça, mais en pratique, tu verra que même sans parler de contribution, si quelqu'un dit "faut faire ça" et personne ne le fait, le travail ne se fait pas tout seul et la personne est frustré. D'un point de vue de la dynamique de groupe qui en résulte, vu qu'on veut que le travail se fasse, on récompense ceux qui font le travail par rapport à ceux qui font pas.
Que ça soit aliénant pour les gens qui veulent/peuvent pas faire le travail est hélas secondaire, car vu qu'il n'y aucun impact sur la sortie ou non du produit alors il y a aucune boucle de feedback qui fait que dire merde a un effet suffisamment négatif. On pourrait trés bien en effet avoir des gens qui sont la uniquement pour faire le taf de ceux qui peuvent/veulent pas le faire, mais ça ne tient pas la charge. Pour une personne qui va être dans ce groupe, tu va avoir 10, 20 voir plus dans le groupe des gens qui peuvent/veulent pas. Donc à un moment, faut voir les ressources que tu as, et dire non. ( et être gentil en disant 'non' est juste un palliatif pour réduire la frustration mais ça fait pas disparaitre la cause de la frustration, à savoir le fait de pas le faire )
Et pour finir la méritocratie est un mythe qui a fait long
feu, on sait que ce sont des fadaises pour enfumer les gens en
bas de l'échelle
C'est bien joli, mais on parle pas d'un vaste système politique qui décide de ta vie de tout les jours, mais de gens qui collabore pour faire un produit, soit sur leur temps libre, soit sur leur temps de travail.
Donc même si la méritocratie dans le milieu en général est une fumisterie et ne devrait pas être employé, ça change rien au principe de base que soit les gens bossent, soit les gens bossent pas, et ceux qui bossent pas n'ont pas d'influence parce que ne rien faire ne produit rien.
C'est pas parce qu'on dit que c'est une méritocratie qu'il y a une hiérarchie supposé, c'est parce qu'il y a collaboration et dépendance entre les membres du groupe ( ie, les contributeurs du projet comme les non contributeurs, avec toutes les nuances possibles ). C'est parce que l'utilisateur dépend de quelqu'un d'autre ( et dépend de par son propre choix dans pas mal de cas ) qu'il y a une relation de pouvoir de l'un vers l'autre.
Dans un échange marchand, je pense que l'équilibre est plus facile à atteindre. IE le vendeur et l'acheteur font un échange. Dans le libre, en renonçant à avoir un truc en retour via un don ( car bosser et filer son code sans que ça coute à la personne qui recoit, c'est ça ), la personne qui fait le don gagne en échange la liberté de pas écouter la personne qui reçoit le dit don ( autrement dit "le droit de dire merde" ).
Donc oui, si tu veux avoir plus de pouvoir, il faut contribuer. Sinon quoi que tu fasses, ça sera inégal sauf coercition externe tel qu'on retrouve dans un groupe humain par le biais de la police, de l'ancien du village, de la loi, du shérif, etc. Et à ce moment la, tu as juste passé le pouvoir ailleurs donc tu n'as rien réglé au problème d'égalité de base.
En conclusion, ouais, les gens qui font rien par choix ou par contrainte l'auront dans l'os, surtout parce que je pense personne ne doit rien à personne. Personne ne va dire qu'il y a pas de droit inhérent à avoir ses bugs lus et corrigés pour le moment, contrairement au fait d'avoir un toit, etc, et tant de choses dans les droits de l'homme ( et pourtant pas mis en pratique partout ).
En même temps, si ceux qui ont l'usage sont pas ceux qui contribuent, tant pis pour eux. On se gargarise de méritocratie de partout ( bien que ça ne soit pas le cas ), mais dans ce cas précis, c'est les gens qui font qui décident.
L'intérêt du shell, à mon avis, c'est que c'est le langage par
défaut d'administration de la machine, et celui qu'on trouve par
défaut en console. On y est confronté à un moment ou un autre,
et normalement, on apprend à le connaître et à le maîtriser.
Permet moi de douter la capacité des gens à maitriser le shell.
Il suffit de voir le simple fait que les gens confondent shell et bash, il suffit de voir le nombre de gens qui utilisent pas trap dans leur code, le nombre de gens pour qui la syntaxe ${i#plop#coin} va être trop ésotérique, le nombre de gens qui savent pas qu'il faut éviter d'utiliser /tmp et que le shell est le seul language ou tu peux pas garantir de faire ça de façon parfaitement propre sans race condition.
Dire que le shell, c'est bien parce que tout le monde comprends, c'est comme dire que php est bien car tout le monde sait en faire.
Ceci dit, j'ai regardé un peu le code de upstart en vue de voir si il serait dur de faire une couche de compatibilité pour l'activation des sockets ( entre systemd et upstart vu que ça semble presque compatible, ça passe un FD via une variable d'env ), et j'ai un peu sourcillé de voir la macro NIH_MUST, une macro qui tente une fonction jusqu'à ce que ça réussisse ( cf http://ifdeflinux.blogspot.fr/2012/05/quick-libnih-tutorial.html ).
Je sais pas si c'est vachement bien foutu, ou juste vachement bourrin (ou les deux).
Mais pourquoi utiliser une variable d'environnement et pas autre chose comme maniére de transmettre l'information, et entre quoi et quoi. Pourquoi au boot et pas à chaque fois, pour détecter quoi, etc, etc.
Donc récapitulons, l'incompatibilité entre haproxy et systemd, c'est le fait de devoir rajouter 1 ligne de bash dans l'unité systemd, chose qui a bien du prendre 5 minutes, vu que la ligne vient du script d'init haproxy avec une rapide adaptation pour l'accès à $MAINPID. Si une ligne de bash est un souci, j'ose me demander ce que les 108 autres lignes du script d'init sont…
J'imagine dire que "attention, des logiciels comme haproxy et plein d'autres que je ne cite pas peuvent requérir un oneliner bash pour fonctionner", ça casse vachement moins la baraque.
Je pense qu'il serait plus efficace de dire ce que tu veux obtenir comme résultat plutôt que comment tu veux implémenter ce que tu penses être une solution.
Les variables d'environnement sont hérités par les processus fils, pas par les processus parents. Tout au plus, tu peux bidouillé en écrivant /etc/profile ou en faisant des trucs avec pam.
(ou tu peux faire un module moche dans le kernel pour écraser l'env des softs existants)
Non, la tu parles de cgroups tout court, à aucun moment tu ne parles de selinux dans ta réponse. Quand aux histoires de hiérarchies des cgroups, c'est une chose que le dev des cgroups veut revoir pour justement éviter l'explosion de complexité, cf par exemple le dernier linuxmag ou il est interviewé. Systemd utilise le concept de slices pour faire une abstraction sur tout ça.
Fedora a écrit un wrapper qui a son tour lance HAProxy - sinon
c'est la guerre au moment des reloads.
Je vais coller le fichier unit qu'on voit le fameux wrapper :
Je ne sais pas quel distribution tu utilises pour faire du systemd avec un wrapper haproxy, mais ça doit pas être Fedora à vue de nez. Y a pas de mention du wrapper dans le changelog du paquet, pas de patch.
Si vous avez déjà vos politiques cgroups et selinux, vous
pouvez prier qu'elles soient compatibles avec systemd,
parce que l'alternative est probablement de redéfinir des
politiques à partir de 0…
Tu bullshites ( comme d'hab sur certains sujets, donc je vais pas passer du temps à te répondre ). Sur une distro RHEL 6, pour avoir un programme lancé par init, tu va utiliser ça par exemple:
init_daemon_domain(ahcpd_t, ahcpd_exec_t)
Sur une fedora 20, avec systemd, tu va utiliser:
init_daemon_domain(ahcpd_t, ahcpd_exec_t)
La réécriture est en effet si douloureuse qu'on pourrais croire qu'il y a rien à faire à part recompiler la policy. Mais peut être que tu veux dire qu'il faut rajouter des autorisations quand on rajoute des fonctions ( car peut être que "compatible avec systemd", tu veux dire "compatible avec l'activation par socket" ce qui est totalement différent, et qui reviens à dire "selinux requiert de tout refaire de 0 si jamais on rajoute une feature sur un soft", ce qui est n'importe quoi ).
Certains logiciels (dont l'excellent HAProxy) ne peuvent tout
simplement être lancés par systemd
[root@liliana misc]# systemctl status haproxy
haproxy.service - HAProxy For TCP And HTTP Based Applications
Loaded: loaded (/usr/lib/systemd/system/haproxy.service; disabled)
Active: active (running) since dim. 2013-12-01 23:10:03 CET; 988ms ago
Process: 9018 ExecStart=/usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid (code=exited, status=0/SUCCESS)
Process: 9015 ExecStartPre=/usr/sbin/haproxy -c -q -f /etc/haproxy/haproxy.cfg (code=exited, status=0/SUCCESS)
Main PID: 9019 (haproxy)
CGroup: /system.slice/haproxy.service
└─9019 /usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid
déc. 01 23:10:03 liliana.example.com systemd[1]: Started HAProxy For TCP And HTTP Based Applications.
Oups, tu peut remplir un bug pour Fedora, car visiblement, la fedora 20 que j'ai a l'air de réussir à le lancer, et visiblement, ç'est un bug que ça marche.
Ensuite peut être que tu veux dire "haproxy n'utilise pas le démarrage par socket ou à la demande", ce qui est différent de "ne marche pas avec systemd". Mais bon, comme tout le reste de ta prose est assez souvent de la même acabit, je vais laisser quelqu'un d'autre te répondre ( ou ne pas passer de temps dessus, car ça ne vaut pas le temps passé à l'exercice ).
Tu aurais aussi pu cliquer sur le premier, qui pointe sur le 3eme. ( et vers d'autres articles de qualités comme "apt vs yum, what is the best one", et sans doute d'autres )
Le 3eme date de 2011, donc ça reste un document qui parle des premières versions de systemd, et qui n'abordent pas les features rajoutés par la suite ( genre les fonctions de sécurités de coupure du réseau, systemd-nspawn, etc).
Donc les arguments techniques ( car on va éviter ceux sur "propagande de RH avec tout son argent" en pointant la doc de systemd sur freedesktop , ç'est assez peu convaincant ) sont les suivants suivi de mon rebuttal :
L'argument est assez mal construit. Soit il veut dire qu'il y a déjà des outils come monit/runit, et auquel cas, je dirais que /bin/init le fait aussi, soit il veut dire que la feature est déjà utilisé avant, et auquel cas je dirait qu'il s'agit juste de coder ce qui est utilisé.
"collecting information on daemon crashes". C'est vrai, init ne le fait pas, et dans la philosophie d'avant, c'est fait par le kernel sous la forme de la création d'un coredump quelque part sur le FS. Ce que systemd fait, c'est d'enregistrer le coredump dans journald, et de sauver divers infos. Et ça n'implique pas de ne pas faire les choses à coté si quelqu'un le veux aussi, tout comme systemd n'implique pas de retirer les appels à chroot et/ou setuid bien que le faisant également ( appels parfois mal fait par les daemons, quand le logiciel ne fait pas de chdir avant ou d'initgroups, mais bon, on le saurait si la réécriture du code sans arrêt implique de faire des erreurs de temps en temps )
keeping control with cgroups. L'argument est faible, car pour lui, on a pas besoin d'utiliser les cgroups car on peut juste utiliser les cgroups. Je suppose qu'il veut dire "y a pas besoin d'utiliser les cgroups dans le binaire d'init car on peut juste demander à tout les scripts de le faire directement". Mais la, curieusement, il ne dit pas "good luck making the author conform to a single standard", alors que visiblement, c'est ce qui arriverais.
delayed on demand. La, l'auteur dit que ça sert à rien ( car la ram sur sa workstation est suffisante et/ou la swap sert à ça ), et si jamais ça venait à servir, on peut déjà le faire via xinetd ( car soyons sérieux, inetd est un peu merdique à utiliser, et je mentirais si je faisait la comparaison en le prenant comme base ). Le fait que par exemple xinetd ne supporte pas les sockets unix, le fait que ça supporte pas les scripts d'init classiques, c'est des détails d'implémentation. Détail que personne n'a codé depuis que xinetd existe mais sans doute parce que ça sert à rien ( le fait que cups s'en serve, que X11 sur mac s'en serve et que j'ai une dizaine d'autres trucs sur mon laptop montre peut être que ça sert pas à rien ). L'auteur loupe aussi que ç'est pas juste "économiser de la ram", mais surtout assurer la parallélisation par design.
"dependency based service management". La, le mec semble vivre dans un monde à part, car "on range les choses dans un ordre arbitraire", ça n'a rien à voir avec la gestion de dépendance. Par exemple, la gestion de dépendance, ça implique que la transaction échoue si une dep échoue. Chose que sysvinit ne fait pas. Mais je peux reconnaitre que je voit fort peu d'usage en local ( à part "postfix a besoin que ldap soit up sinon il rejette les mails" et ce genre de choses ). Et bien sur, le mec n'a pas lu la doc de systemd, car l'option --ignore-dependencies existe. Donc la partie sur "l'admin doit pouvoir faire ce qu'il veut" est factuellement incorrect.
la partie sur autofs est light sur les détails. Je ne pige pas exactement ce qu'il veut dire, car je voit moi que les unités sont pour la plupart lancé après local-fs.target, donc le souci ne semble pas vraiment se poser dans mon cas d'usage. Mais bon, je ne m'y connais pas en autofs, à part que autofs sur linux fait jurer mon coloc à intervalles régulier. Je vais donc laisser le bénéfice du doute.
listening on hardware change. Que je sache, ç'est fait via udev. Et donc ça rentre dans "c'est déjà fait ailleurs". Donc c'est un peu creux comme argument, surtout parce qu'il est pas détaillé des masses. Au passage, upstart va bien plus loin que systemd et gère les choses de façons bien plus poussé, comme le montre un des développeurs : http://ifdeflinux.blogspot.fr/2013/04/upstart-user-sessions-in-ubuntu-raring.html ( c'est vers la fin ).
enfin, l'argument qui tue : "dbus, c'est orienté desktop, car c'est dans le nom". Il y a aucun example de ce qu'il propose de mieux comme les sunrpc de nfs, java rmi, ou faire ça en xml-rpc par dessus le réseau, en soap ? Je suis pas sur que ça soit mieux, tout le monde rale sur soap, sunrpc est inutilisé ( et semble un peu compliqué à utiliser ). Mais encore une fois, sans argument, j'aurais tendance à dire que c'est un détail. Après tout, d'autres composants ( nm, upstart, bluez, wpa_supplicant pour ne citer qu'eux) passent aussi par dbus donc ça a une certaine logique de se baser sur ce que les autres font.
Donc au final, les arguments sont très discutables. Certains sont incorrects ( le 5 ), d'autres sont assez peu explicites ( le 6, le 8, le 1 ), d'autres sont pas très clairs car ça demande à réutiliser des choses existantes ce qui est le cas ( le 3, le 7 ). Il reste donc le 2 et le 4, à savoir la gestion des crashs, qui n'obligent à rien ( et qui reste une feature pour journald, donc hors du pid 1 ) et la partie sur le démarrage à la demande.
Grosso modo, je pense que la discussion et les arguments ont été exposés en détails et les gens considèrent la position comme étant final ( ie, les pages sont complètes ).
Celle de systemd est déclaré final : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#538
et celle de openrc :
bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#558
Donc depuis fin novembre, je pense que c'est bon, et la phase suivante peut commencer ( malgré la tentative de Ian jackson de relancer le débat en parlant de sécurité ).
Le caractère essential du package sysvinit me semble raisonnable
Pour les gens qui n'ont pas lu le lien, je le colle :
"Essential is defined as the minimal set of functionality that must be available and usable on the system at all times, even when packages are in the "Unpacked" state. "
IE, essential est utilisé pour les trucs qu'on ne peut pas retirer, et qu'on estime donc faire parti de la base sur laquelle on peut s'appuyer. Donc ça impose le support des scripts d'init aux DDs. Le choix oui, mais pas pour les DDs, sauf si par choix on veut dire "faire tout ce que les utilisateurs veulent".
Faudrait avoir plus qu'un rêve, genre avoir la possibiltié de faire la chose, si seulement les sources des distributions étaient disponibles, et si seulement le code pouvait donner le droit de faire ce qu'on veut (ou presque) avec ..
Si il y a autant de gens qui cherchent à remplacer
NetworkManager, systemd, udev ou dbus, il faudrai peut-être
regarder pourquoi.
bah, systemd est lui même censé remplacé sysvinit, et contrairement à systemd, sysvinit a été remplacé par : openrc, upstart, launchd, smf, parmi tant d'autres.
Au contraire, j'attends de voir qui remplace udev ou dbus.
Par exemple, qui utilise eudev, en dehors de gentoo ?
Et en fait, au vue de l'activité des derniers mois, ou on voitsoit des commits qui sont globalement une synchro du travail de l'original, ou rien à part de la doc, ou sont tout les gens qui veulent remplacer udev ?
Ou sont tout les gens qui poussent à faire des distros basé sur mdev ? Ou sont les gens qui ont cherché à garder devfsd en vie ? Tout ces howtos pour avoir une distro avec un /dev statique et tout les avantages si innombrale qu'on comprends pas comment on peut s'en passer ?
Il me semble que IBM édite aussi une version de Linux mais
pousse plus son AIX sur les grosses machines.
IB n'édite pas de version de Linux, ils proposent du RHEL, voir du SLES, en fonction de ce que les clients demandent. Si jamais les clients venaient à demander en masse autre chose, je suis sur qu'IBM le ferait sans souci.
D'une part, du fait d'avoir des développeurs en grand nombre. Je peux citer par exemple les contributeurs à gcc, à Linux, à gnome, etc, etc. Des logiciels que tout le monde utilise sans le savoir sont des contributions directs de salariés de la boite, comme par exemple kvm. Tu retrouves les gens dans les projets comme coreutils ( http://git.savannah.gnu.org/cgit/coreutils.git ). Tu peux avoir plus de détails sur http://community.redhat.com/software/
Ensuite, le fait d'avoir pris le magma primal qu'est le corpus de logiciels libres disponibles et d'en avoir fait un produit fini. Plein de boite le font, je ne dit pas le contraire, mais RH a réussi à s'en tirer de façon des plus honorables. La documentation traduite, écrit par des personnes à temps plein, a beaucoup aidé pour la perception du logiciel libre. De même, le fait de faire de la QA un peu plus formel que "si personne ne signale de bug alors c'est bon", de faire des revues de sécurités sur le code, de faire certifier les OS pour divers gouvernements, etc. Ou simplement de proposer du support, des roadmaps sur leurs produits.
Et troisièmement, le fait de ne pas s'opposer à la communauté, mais d'en faire parti. Par exemple, avoir monté des choses comme l'OIN pour tous et pas juste pour leur propre pomme, d'envoyer des avis légaux sur les procés sur les brevets logiciels afin d'aider à établir une jurisprudence en faveur du libre, d'être sponsor pour la Linux Fondation, pour pycon et d'autres, d'avoir aidé à monter la fondation Openstack, d'avoir proposé des briques comme libvirt ( sur lequel repose quand même pas mal de projet d'IaaS du moment ).
Pour quiconque l'ayant utilisé en server, c'est une plaie!
C'est une affirmation qui manque fortement de substance, et je suis sur que ton propos gagnerais en solidité si il était moins lapidaire. Mais sinon, il semble qu'il y a plein de gens satisfait de RHEL sur les serveurs, en partie de part la stabilité de la chose.
Sinon, moi, j'ai une Fedora sur un serveur, et je suis content d'avoir des choses comme selinux, comme systemd, comme des versions récentes de divers composants. Peut être qu'il y a des gens qui sont content d'avoir hadoop sans installer à la main ( cf https://fedoraproject.org/wiki/Releases/20/ChangeSet ) ou sans avoir à prendre des dépôts non officiels.
Je ne compare pas le développeur propriétaire à un esclavagiste, je donne un contre exemple au fait que l'argument de la diversité est valable.
Soit je donne un exemple ou une majorité de gens estime que la diversité passe en arrière plan, soit j'en trouve un ou tout le monde estime que la diversité passe en arrière plan. Si j'avais choisi le premier cas, je pense que la discussion virer sur le fait que ça soit discutable. Donc du coup, il a fallu prendre le 2eme, avec effectivement le risque que quelqu'un comprenne de travers et voit une comparaison direct alors que ce n'est pas le cas. On noteras que j'ai fait l'effort de pas donner le nazisme.
Je répète, l'argument "il faut garder la diversité des licences" est vide et creux de sens. Celui "les développeurs doivent pouvoir faire ce qu'ils veulent dans la limite de la loi" est déjà plus défendable.
le tout ensuite est de savoir ce qu'on estime juste et équitable, et savoir si on veut autoriser les choses en dehors de ce qu'on estime juste et équitable.
Mais dans ce cas, c'est le droit du développeur à choisir que tu veux défendre, pas le fait de garder la diversité parce que la diversité est vu comme bien.
La biodiversité à tout prix en gardant les licences propriétaires, c'est un peu de la connerie. C'est comme dire qu'il faut garder une diversité en se disant qu'il y a de la place pour les esclavagistes au nom de la diversité des approches en matière de travail.
Mais tu peux défendre la liberté des gens à avoir un rapport de force en leur faveur ( ie, je garde le code pour tel ou tel raison ), parce que tu estimes que c'est légitime, que le créateur a des droits, etc.
C'est pas trés dur à voir. Si jamais les plateformes libres ( ce qui dans le cas présent représente une distro, on va dire Debian pour la peine ) prends l'ascendance sur les plateformes proprios ( on va dire OS X ), alors le modèle consistant à vendre la version OS X va s'écrouler. Tout comme les gens finançant une version Windows gratuite avec l'argent que tu te fait sur la version OS/2 ( exemple hypothétique pour bien dédramatiser ).
Tu peux vouloir te dire "il faut pas que le libre prenne le pas sur le propriétaire", mais dans ce cas, faut le dire clairement "je ne veux pas que le logiciel libre soit majoritaire, car je pense que le logiciel propriétaire… "suivi de tout les arguments que tu veux en faveur du propriétaire et pourquoi c'est meilleur pour tous ( et pas juste toi, car bien sur, avoir plus de pouvoir en ta faveur est bien mieux pour toi, comme dans tout rapport de force, mais comme dans tout rapport de force, c'est dur d'argument pour dire qu'il est mieux que ça soit inégal en sa faveur ).
[^] # Re: Upstart
Posté par Misc (site web personnel) . En réponse à la dépêche Petit état de l'art des systèmes d'initialisation (1). Évalué à 3.
Je pense que pour rhel6, l'idée était d'intégrer upstart parce que Fedora a pris upstart, et si l'intégration avait été poussé plus loin, ça aurait été bien mieux.
Mais même Canonical n'avait pas vraiment poussé upstart et apparmor à l'époque ( vers la 10.04 ), ce qui m'a un peu déçu. Je comprends qu'ils ont pas le staff requis pour ça, mais ça a rajouté une raison de plus pour moi de prendre ce qu'ils disent avec des pincettes. Dieu merci, maintenant, ça semble se faire, même si il reste encore pas mal de boulot.
[^] # Re: systemd
Posté par Misc (site web personnel) . En réponse à la dépêche Petit état de l'art des systèmes d'initialisation (1). Évalué à 6.
Non mais tu as raison sur le fait que les gens sortent l'argument de la méritocratie bien souvent pour dire que tout est parfait alors que non. De la même façon que la démocratie n'est pas sans faille ( vu que ça dépend grandement de qui vote, de la façon dont les arguments sont présentés, etc ), mais en effet, la méritocratie est souvent idéalisé alors que c'est pas le cas, y a plein de souci malgré le fait qu'on croit que tout le monde est égal devant la contribution, alors que la seule égalité qu'on a, c'est celle des contraintes du code ( ie, tout le monde ou presque a les mêmes opportunités donnés par une license libre, sauf cas spéciaux ).
Il reste à coté les contraintes de temps, de compétences, de trouver des gens proches de chez toi, proche d'un point de vue temporel, proche pour t'aider, etc, etc. Contraintes qu'on peut pas nier, mais contraintes qu'on peut pas résoudre facilement et complétement juste par la volonté et 3/4 lignes en anglais.
[^] # Re: systemd
Posté par Misc (site web personnel) . En réponse à la dépêche Petit état de l'art des systèmes d'initialisation (1). Évalué à 10.
Tu veux dire quoi par "unanimité dans les distros". Unanimité, ça implique d'avoir un ensemble fini de gens avec des critères, et la, je pense que "une distro", c'est flou. Est ce que la distribution, c'est "tout les gens qui ont le droit de commit", tout les gens qui sont sur une ml, dans un ldap, qui utilisent à un moment T, etc. En général, le but n'est pas d'avoir l'unanimité, c'est bien plus pragmatique que ça, le but est de réduire la maintenance du projet tout en permettant de faire un certains nombres de choses avec le produit.
Et bien que ça reste subjectif comme définition, il faut pas oublier que c'est ça. Les gens peuvent rajouter tout ce qu'ils veulent par dessus, à la fin, faut produire un truc. Si ton but n'est pas de sortir un produit, alors c'est pas une distribution que tu fait. Y a rien de mal à ça, c'est juste pas la même chose.
J'aurais tendance à dire que ça peut être pris comme ça, mais en pratique, tu verra que même sans parler de contribution, si quelqu'un dit "faut faire ça" et personne ne le fait, le travail ne se fait pas tout seul et la personne est frustré. D'un point de vue de la dynamique de groupe qui en résulte, vu qu'on veut que le travail se fasse, on récompense ceux qui font le travail par rapport à ceux qui font pas.
Que ça soit aliénant pour les gens qui veulent/peuvent pas faire le travail est hélas secondaire, car vu qu'il n'y aucun impact sur la sortie ou non du produit alors il y a aucune boucle de feedback qui fait que dire merde a un effet suffisamment négatif. On pourrait trés bien en effet avoir des gens qui sont la uniquement pour faire le taf de ceux qui peuvent/veulent pas le faire, mais ça ne tient pas la charge. Pour une personne qui va être dans ce groupe, tu va avoir 10, 20 voir plus dans le groupe des gens qui peuvent/veulent pas. Donc à un moment, faut voir les ressources que tu as, et dire non. ( et être gentil en disant 'non' est juste un palliatif pour réduire la frustration mais ça fait pas disparaitre la cause de la frustration, à savoir le fait de pas le faire )
C'est bien joli, mais on parle pas d'un vaste système politique qui décide de ta vie de tout les jours, mais de gens qui collabore pour faire un produit, soit sur leur temps libre, soit sur leur temps de travail.
Donc même si la méritocratie dans le milieu en général est une fumisterie et ne devrait pas être employé, ça change rien au principe de base que soit les gens bossent, soit les gens bossent pas, et ceux qui bossent pas n'ont pas d'influence parce que ne rien faire ne produit rien.
C'est pas parce qu'on dit que c'est une méritocratie qu'il y a une hiérarchie supposé, c'est parce qu'il y a collaboration et dépendance entre les membres du groupe ( ie, les contributeurs du projet comme les non contributeurs, avec toutes les nuances possibles ). C'est parce que l'utilisateur dépend de quelqu'un d'autre ( et dépend de par son propre choix dans pas mal de cas ) qu'il y a une relation de pouvoir de l'un vers l'autre.
Dans un échange marchand, je pense que l'équilibre est plus facile à atteindre. IE le vendeur et l'acheteur font un échange. Dans le libre, en renonçant à avoir un truc en retour via un don ( car bosser et filer son code sans que ça coute à la personne qui recoit, c'est ça ), la personne qui fait le don gagne en échange la liberté de pas écouter la personne qui reçoit le dit don ( autrement dit "le droit de dire merde" ).
Donc oui, si tu veux avoir plus de pouvoir, il faut contribuer. Sinon quoi que tu fasses, ça sera inégal sauf coercition externe tel qu'on retrouve dans un groupe humain par le biais de la police, de l'ancien du village, de la loi, du shérif, etc. Et à ce moment la, tu as juste passé le pouvoir ailleurs donc tu n'as rien réglé au problème d'égalité de base.
En conclusion, ouais, les gens qui font rien par choix ou par contrainte l'auront dans l'os, surtout parce que je pense personne ne doit rien à personne. Personne ne va dire qu'il y a pas de droit inhérent à avoir ses bugs lus et corrigés pour le moment, contrairement au fait d'avoir un toit, etc, et tant de choses dans les droits de l'homme ( et pourtant pas mis en pratique partout ).
[^] # Re: systemd
Posté par Misc (site web personnel) . En réponse à la dépêche Petit état de l'art des systèmes d'initialisation (1). Évalué à 10.
En même temps, si ceux qui ont l'usage sont pas ceux qui contribuent, tant pis pour eux. On se gargarise de méritocratie de partout ( bien que ça ne soit pas le cas ), mais dans ce cas précis, c'est les gens qui font qui décident.
[^] # Re: systemd
Posté par Misc (site web personnel) . En réponse à la dépêche Petit état de l'art des systèmes d'initialisation (1). Évalué à 8.
Permet moi de douter la capacité des gens à maitriser le shell.
Il suffit de voir le simple fait que les gens confondent shell et bash, il suffit de voir le nombre de gens qui utilisent pas trap dans leur code, le nombre de gens pour qui la syntaxe ${i#plop#coin} va être trop ésotérique, le nombre de gens qui savent pas qu'il faut éviter d'utiliser /tmp et que le shell est le seul language ou tu peux pas garantir de faire ça de façon parfaitement propre sans race condition.
Dire que le shell, c'est bien parce que tout le monde comprends, c'est comme dire que php est bien car tout le monde sait en faire.
[^] # Re: Upstart et portages
Posté par Misc (site web personnel) . En réponse à la dépêche Petit état de l'art des systèmes d'initialisation (1). Évalué à 2.
Il reste plus qu'à porter sur le hurd et minix :)
Ceci dit, j'ai regardé un peu le code de upstart en vue de voir si il serait dur de faire une couche de compatibilité pour l'activation des sockets ( entre systemd et upstart vu que ça semble presque compatible, ça passe un FD via une variable d'env ), et j'ai un peu sourcillé de voir la macro NIH_MUST, une macro qui tente une fonction jusqu'à ce que ça réussisse ( cf http://ifdeflinux.blogspot.fr/2012/05/quick-libnih-tutorial.html ).
Je sais pas si c'est vachement bien foutu, ou juste vachement bourrin (ou les deux).
[^] # Re: Quelques alternatives
Posté par Misc (site web personnel) . En réponse à la dépêche Petit état de l'art des systèmes d'initialisation (1). Évalué à 3.
helas, les budgets pour pardus ont disparus, si je me souviens bien après avoir discuté sur irc avec un professeur d'istanbul, membre du projet.
[^] # Re: Juste une question
Posté par Misc (site web personnel) . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 1.
j'ai lu le truc vu que j'ai répondu.
Mais pourquoi utiliser une variable d'environnement et pas autre chose comme maniére de transmettre l'information, et entre quoi et quoi. Pourquoi au boot et pas à chaque fois, pour détecter quoi, etc, etc.
[^] # Re: GNU/SystemD/Linux
Posté par Misc (site web personnel) . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 10.
Donc récapitulons, l'incompatibilité entre haproxy et systemd, c'est le fait de devoir rajouter 1 ligne de bash dans l'unité systemd, chose qui a bien du prendre 5 minutes, vu que la ligne vient du script d'init haproxy avec une rapide adaptation pour l'accès à $MAINPID. Si une ligne de bash est un souci, j'ose me demander ce que les 108 autres lignes du script d'init sont…
J'imagine dire que "attention, des logiciels comme haproxy et plein d'autres que je ne cite pas peuvent requérir un oneliner bash pour fonctionner", ça casse vachement moins la baraque.
[^] # Re: Juste une question
Posté par Misc (site web personnel) . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 3.
Je pense qu'il serait plus efficace de dire ce que tu veux obtenir comme résultat plutôt que comment tu veux implémenter ce que tu penses être une solution.
[^] # Re: Juste une question
Posté par Misc (site web personnel) . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 2.
Non.
Les variables d'environnement sont hérités par les processus fils, pas par les processus parents. Tout au plus, tu peux bidouillé en écrivant /etc/profile ou en faisant des trucs avec pam.
(ou tu peux faire un module moche dans le kernel pour écraser l'env des softs existants)
[^] # Re: GNU/SystemD/Linux
Posté par Misc (site web personnel) . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 6.
Non, la tu parles de cgroups tout court, à aucun moment tu ne parles de selinux dans ta réponse. Quand aux histoires de hiérarchies des cgroups, c'est une chose que le dev des cgroups veut revoir pour justement éviter l'explosion de complexité, cf par exemple le dernier linuxmag ou il est interviewé. Systemd utilise le concept de slices pour faire une abstraction sur tout ça.
Je vais coller le fichier unit qu'on voit le fameux wrapper :
Il n'y a pas de wrapper pour lancer haproxy, ça lance direct le binaire :
Je ne sais pas quel distribution tu utilises pour faire du systemd avec un wrapper haproxy, mais ça doit pas être Fedora à vue de nez. Y a pas de mention du wrapper dans le changelog du paquet, pas de patch.
[^] # Re: GNU/SystemD/Linux
Posté par Misc (site web personnel) . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 8.
Tu bullshites ( comme d'hab sur certains sujets, donc je vais pas passer du temps à te répondre ). Sur une distro RHEL 6, pour avoir un programme lancé par init, tu va utiliser ça par exemple:
Sur une fedora 20, avec systemd, tu va utiliser:
La réécriture est en effet si douloureuse qu'on pourrais croire qu'il y a rien à faire à part recompiler la policy. Mais peut être que tu veux dire qu'il faut rajouter des autorisations quand on rajoute des fonctions ( car peut être que "compatible avec systemd", tu veux dire "compatible avec l'activation par socket" ce qui est totalement différent, et qui reviens à dire "selinux requiert de tout refaire de 0 si jamais on rajoute une feature sur un soft", ce qui est n'importe quoi ).
Oups, tu peut remplir un bug pour Fedora, car visiblement, la fedora 20 que j'ai a l'air de réussir à le lancer, et visiblement, ç'est un bug que ça marche.
Ensuite peut être que tu veux dire "haproxy n'utilise pas le démarrage par socket ou à la demande", ce qui est différent de "ne marche pas avec systemd". Mais bon, comme tout le reste de ta prose est assez souvent de la même acabit, je vais laisser quelqu'un d'autre te répondre ( ou ne pas passer de temps dessus, car ça ne vaut pas le temps passé à l'exercice ).
[^] # Re: GNU/SystemD/Linux
Posté par Misc (site web personnel) . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 8.
Tu aurais aussi pu cliquer sur le premier, qui pointe sur le 3eme. ( et vers d'autres articles de qualités comme "apt vs yum, what is the best one", et sans doute d'autres )
Le 3eme date de 2011, donc ça reste un document qui parle des premières versions de systemd, et qui n'abordent pas les features rajoutés par la suite ( genre les fonctions de sécurités de coupure du réseau, systemd-nspawn, etc).
Donc les arguments techniques ( car on va éviter ceux sur "propagande de RH avec tout son argent" en pointant la doc de systemd sur freedesktop , ç'est assez peu convaincant ) sont les suivants suivi de mon rebuttal :
L'argument est assez mal construit. Soit il veut dire qu'il y a déjà des outils come monit/runit, et auquel cas, je dirais que /bin/init le fait aussi, soit il veut dire que la feature est déjà utilisé avant, et auquel cas je dirait qu'il s'agit juste de coder ce qui est utilisé.
"collecting information on daemon crashes". C'est vrai, init ne le fait pas, et dans la philosophie d'avant, c'est fait par le kernel sous la forme de la création d'un coredump quelque part sur le FS. Ce que systemd fait, c'est d'enregistrer le coredump dans journald, et de sauver divers infos. Et ça n'implique pas de ne pas faire les choses à coté si quelqu'un le veux aussi, tout comme systemd n'implique pas de retirer les appels à chroot et/ou setuid bien que le faisant également ( appels parfois mal fait par les daemons, quand le logiciel ne fait pas de chdir avant ou d'initgroups, mais bon, on le saurait si la réécriture du code sans arrêt implique de faire des erreurs de temps en temps )
keeping control with cgroups. L'argument est faible, car pour lui, on a pas besoin d'utiliser les cgroups car on peut juste utiliser les cgroups. Je suppose qu'il veut dire "y a pas besoin d'utiliser les cgroups dans le binaire d'init car on peut juste demander à tout les scripts de le faire directement". Mais la, curieusement, il ne dit pas "good luck making the author conform to a single standard", alors que visiblement, c'est ce qui arriverais.
delayed on demand. La, l'auteur dit que ça sert à rien ( car la ram sur sa workstation est suffisante et/ou la swap sert à ça ), et si jamais ça venait à servir, on peut déjà le faire via xinetd ( car soyons sérieux, inetd est un peu merdique à utiliser, et je mentirais si je faisait la comparaison en le prenant comme base ). Le fait que par exemple xinetd ne supporte pas les sockets unix, le fait que ça supporte pas les scripts d'init classiques, c'est des détails d'implémentation. Détail que personne n'a codé depuis que xinetd existe mais sans doute parce que ça sert à rien ( le fait que cups s'en serve, que X11 sur mac s'en serve et que j'ai une dizaine d'autres trucs sur mon laptop montre peut être que ça sert pas à rien ). L'auteur loupe aussi que ç'est pas juste "économiser de la ram", mais surtout assurer la parallélisation par design.
"dependency based service management". La, le mec semble vivre dans un monde à part, car "on range les choses dans un ordre arbitraire", ça n'a rien à voir avec la gestion de dépendance. Par exemple, la gestion de dépendance, ça implique que la transaction échoue si une dep échoue. Chose que sysvinit ne fait pas. Mais je peux reconnaitre que je voit fort peu d'usage en local ( à part "postfix a besoin que ldap soit up sinon il rejette les mails" et ce genre de choses ). Et bien sur, le mec n'a pas lu la doc de systemd, car l'option --ignore-dependencies existe. Donc la partie sur "l'admin doit pouvoir faire ce qu'il veut" est factuellement incorrect.
la partie sur autofs est light sur les détails. Je ne pige pas exactement ce qu'il veut dire, car je voit moi que les unités sont pour la plupart lancé après local-fs.target, donc le souci ne semble pas vraiment se poser dans mon cas d'usage. Mais bon, je ne m'y connais pas en autofs, à part que autofs sur linux fait jurer mon coloc à intervalles régulier. Je vais donc laisser le bénéfice du doute.
listening on hardware change. Que je sache, ç'est fait via udev. Et donc ça rentre dans "c'est déjà fait ailleurs". Donc c'est un peu creux comme argument, surtout parce qu'il est pas détaillé des masses. Au passage, upstart va bien plus loin que systemd et gère les choses de façons bien plus poussé, comme le montre un des développeurs :
http://ifdeflinux.blogspot.fr/2013/04/upstart-user-sessions-in-ubuntu-raring.html ( c'est vers la fin ).
enfin, l'argument qui tue : "dbus, c'est orienté desktop, car c'est dans le nom". Il y a aucun example de ce qu'il propose de mieux comme les sunrpc de nfs, java rmi, ou faire ça en xml-rpc par dessus le réseau, en soap ? Je suis pas sur que ça soit mieux, tout le monde rale sur soap, sunrpc est inutilisé ( et semble un peu compliqué à utiliser ). Mais encore une fois, sans argument, j'aurais tendance à dire que c'est un détail. Après tout, d'autres composants ( nm, upstart, bluez, wpa_supplicant pour ne citer qu'eux) passent aussi par dbus donc ça a une certaine logique de se baser sur ce que les autres font.
Donc au final, les arguments sont très discutables. Certains sont incorrects ( le 5 ), d'autres sont assez peu explicites ( le 6, le 8, le 1 ), d'autres sont pas très clairs car ça demande à réutiliser des choses existantes ce qui est le cas ( le 3, le 7 ). Il reste donc le 2 et le 4, à savoir la gestion des crashs, qui n'obligent à rien ( et qui reste une feature pour journald, donc hors du pid 1 ) et la partie sur le démarrage à la demande.
[^] # Re: GNU/SystemD/Linux
Posté par Misc (site web personnel) . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 6.
C'est une bonne question, du coup, j'ai relu :
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708
Grosso modo, je pense que la discussion et les arguments ont été exposés en détails et les gens considèrent la position comme étant final ( ie, les pages sont complètes ).
Celle de systemd est déclaré final :
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#538
Celle de upstart :
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#548
Celle du support multiple :
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#553
et celle de openrc :
bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#558
Donc depuis fin novembre, je pense que c'est bon, et la phase suivante peut commencer ( malgré la tentative de Ian jackson de relancer le débat en parlant de sécurité ).
[^] # Re: GNU/SystemD/Linux
Posté par Misc (site web personnel) . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 1.
Mhhh intéressant :
suivi de
Pour les gens qui n'ont pas lu le lien, je le colle :
"Essential is defined as the minimal set of functionality that must be available and usable on the system at all times, even when packages are in the "Unpacked" state. "
IE, essential est utilisé pour les trucs qu'on ne peut pas retirer, et qu'on estime donc faire parti de la base sur laquelle on peut s'appuyer. Donc ça impose le support des scripts d'init aux DDs. Le choix oui, mais pas pour les DDs, sauf si par choix on veut dire "faire tout ce que les utilisateurs veulent".
[^] # Re: Busybox
Posté par Misc (site web personnel) . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 7.
Faudrait avoir plus qu'un rêve, genre avoir la possibiltié de faire la chose, si seulement les sources des distributions étaient disponibles, et si seulement le code pouvait donner le droit de faire ce qu'on veut (ou presque) avec ..
[^] # Re: GNU/SystemD/Linux
Posté par Misc (site web personnel) . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 10.
bah, systemd est lui même censé remplacé sysvinit, et contrairement à systemd, sysvinit a été remplacé par : openrc, upstart, launchd, smf, parmi tant d'autres.
Au contraire, j'attends de voir qui remplace udev ou dbus.
Par exemple, qui utilise eudev, en dehors de gentoo ?
Et en fait, au vue de l'activité des derniers mois, ou on voitsoit des commits qui sont globalement une synchro du travail de l'original, ou rien à part de la doc, ou sont tout les gens qui veulent remplacer udev ?
Ou sont tout les gens qui poussent à faire des distros basé sur mdev ? Ou sont les gens qui ont cherché à garder devfsd en vie ? Tout ces howtos pour avoir une distro avec un /dev statique et tout les avantages si innombrale qu'on comprends pas comment on peut s'en passer ?
[^] # Re: La touche finale
Posté par Misc (site web personnel) . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 3.
Tu peux aussi parler de Greg KH qui encourage le dit David dans son entreprise :
http://lists.freedesktop.org/archives/systemd-devel/2013-November/014836.html
[^] # Re: suprématie de RedHat?
Posté par Misc (site web personnel) . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 8.
IB n'édite pas de version de Linux, ils proposent du RHEL, voir du SLES, en fonction de ce que les clients demandent. Si jamais les clients venaient à demander en masse autre chose, je suis sur qu'IBM le ferait sans souci.
[^] # Re: La touche finale
Posté par Misc (site web personnel) . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 10.
Je pense que ça vient de plusieurs choses.
D'une part, du fait d'avoir des développeurs en grand nombre. Je peux citer par exemple les contributeurs à gcc, à Linux, à gnome, etc, etc. Des logiciels que tout le monde utilise sans le savoir sont des contributions directs de salariés de la boite, comme par exemple kvm. Tu retrouves les gens dans les projets comme coreutils ( http://git.savannah.gnu.org/cgit/coreutils.git ). Tu peux avoir plus de détails sur http://community.redhat.com/software/
Ensuite, le fait d'avoir pris le magma primal qu'est le corpus de logiciels libres disponibles et d'en avoir fait un produit fini. Plein de boite le font, je ne dit pas le contraire, mais RH a réussi à s'en tirer de façon des plus honorables. La documentation traduite, écrit par des personnes à temps plein, a beaucoup aidé pour la perception du logiciel libre. De même, le fait de faire de la QA un peu plus formel que "si personne ne signale de bug alors c'est bon", de faire des revues de sécurités sur le code, de faire certifier les OS pour divers gouvernements, etc. Ou simplement de proposer du support, des roadmaps sur leurs produits.
Et troisièmement, le fait de ne pas s'opposer à la communauté, mais d'en faire parti. Par exemple, avoir monté des choses comme l'OIN pour tous et pas juste pour leur propre pomme, d'envoyer des avis légaux sur les procés sur les brevets logiciels afin d'aider à établir une jurisprudence en faveur du libre, d'être sponsor pour la Linux Fondation, pour pycon et d'autres, d'avoir aidé à monter la fondation Openstack, d'avoir proposé des briques comme libvirt ( sur lequel repose quand même pas mal de projet d'IaaS du moment ).
C'est une affirmation qui manque fortement de substance, et je suis sur que ton propos gagnerais en solidité si il était moins lapidaire. Mais sinon, il semble qu'il y a plein de gens satisfait de RHEL sur les serveurs, en partie de part la stabilité de la chose.
Sinon, moi, j'ai une Fedora sur un serveur, et je suis content d'avoir des choses comme selinux, comme systemd, comme des versions récentes de divers composants. Peut être qu'il y a des gens qui sont content d'avoir hadoop sans installer à la main ( cf https://fedoraproject.org/wiki/Releases/20/ChangeSet ) ou sans avoir à prendre des dépôts non officiels.
[^] # Re: shareware ou logiciel libre payant ?
Posté par Misc (site web personnel) . En réponse au journal Financement des applications sur le 'bureau'. Évalué à 4.
Je ne compare pas le développeur propriétaire à un esclavagiste, je donne un contre exemple au fait que l'argument de la diversité est valable.
Soit je donne un exemple ou une majorité de gens estime que la diversité passe en arrière plan, soit j'en trouve un ou tout le monde estime que la diversité passe en arrière plan. Si j'avais choisi le premier cas, je pense que la discussion virer sur le fait que ça soit discutable. Donc du coup, il a fallu prendre le 2eme, avec effectivement le risque que quelqu'un comprenne de travers et voit une comparaison direct alors que ce n'est pas le cas. On noteras que j'ai fait l'effort de pas donner le nazisme.
Je répète, l'argument "il faut garder la diversité des licences" est vide et creux de sens. Celui "les développeurs doivent pouvoir faire ce qu'ils veulent dans la limite de la loi" est déjà plus défendable.
le tout ensuite est de savoir ce qu'on estime juste et équitable, et savoir si on veut autoriser les choses en dehors de ce qu'on estime juste et équitable.
[^] # Re: shareware ou logiciel libre payant ?
Posté par Misc (site web personnel) . En réponse au journal Financement des applications sur le 'bureau'. Évalué à 3.
Mais dans ce cas, c'est le droit du développeur à choisir que tu veux défendre, pas le fait de garder la diversité parce que la diversité est vu comme bien.
[^] # Re: shareware ou logiciel libre payant ?
Posté par Misc (site web personnel) . En réponse au journal Financement des applications sur le 'bureau'. Évalué à 6.
La biodiversité à tout prix en gardant les licences propriétaires, c'est un peu de la connerie. C'est comme dire qu'il faut garder une diversité en se disant qu'il y a de la place pour les esclavagistes au nom de la diversité des approches en matière de travail.
Mais tu peux défendre la liberté des gens à avoir un rapport de force en leur faveur ( ie, je garde le code pour tel ou tel raison ), parce que tu estimes que c'est légitime, que le créateur a des droits, etc.
[^] # Re: shareware ou logiciel libre payant ?
Posté par Misc (site web personnel) . En réponse au journal Financement des applications sur le 'bureau'. Évalué à 5.
C'est pas trés dur à voir. Si jamais les plateformes libres ( ce qui dans le cas présent représente une distro, on va dire Debian pour la peine ) prends l'ascendance sur les plateformes proprios ( on va dire OS X ), alors le modèle consistant à vendre la version OS X va s'écrouler. Tout comme les gens finançant une version Windows gratuite avec l'argent que tu te fait sur la version OS/2 ( exemple hypothétique pour bien dédramatiser ).
Tu peux vouloir te dire "il faut pas que le libre prenne le pas sur le propriétaire", mais dans ce cas, faut le dire clairement "je ne veux pas que le logiciel libre soit majoritaire, car je pense que le logiciel propriétaire… "suivi de tout les arguments que tu veux en faveur du propriétaire et pourquoi c'est meilleur pour tous ( et pas juste toi, car bien sur, avoir plus de pouvoir en ta faveur est bien mieux pour toi, comme dans tout rapport de force, mais comme dans tout rapport de force, c'est dur d'argument pour dire qu'il est mieux que ça soit inégal en sa faveur ).