ce qui est pas si cher en fait pour le nieau de compétences. J'étais facturé par feu ma boite à 800€/j en début de carrière, en régie en Alsace pendant 3 ans. Et quand je vois le tarif des consultants de nos jours, je me dit que soit l'inflation est passé par la, soit j'étais pas si cher que ça.
Ensuite, il faut voir que ça ne vise pas que les travailleurs français, et je pense aussi qu'ils font ça par passion donc sont sans doute prêt à faire une réduction de principe, ce qui explique le prix pas si haut que ça (ça, ou une déformation du à Paris).
Y a un certain nombre de trucs qui me laisse songeur
un peu partout.
D'abord, faire une liste privé pour que les boites puissent se retrouver entre elles, ça me parait un peu aller contre la transparence qu'on attends de Debian. Je comprends bien le fait de devoir offrir quelque chose en plus, mais ça fait très "mandrake club", et historiquement, ça n'a super bien marché. À coté, toutes les sociétés commerciales font ça aussi. Je pense qu'une condition pour que ça apporte de la valeur est d'avoir une communauté suffisamment grande et ç'est pas encore le cas. Donc personnelement, je commencerais pas par proposer ça.
Ensuite, le fait d'avoir le droit de soumettre ses propres tests cases me parait aussi curieux. Si le test case est utile à plusieurs personnes, pourquoi ne pas le donner à tous, et le mettre upstream ? Je pense aussi que l'offre ne dit pas clairement quel genre de test case je peux donner (genre, si je dit "voila mon test case, il faut lancer ce benchmark sur 30 machines", ça va être refusé ). Ou ce qui se passe en cas de problème avec le test case, etc, etc. Et il se passe quoi si je paye pas et que je donne un test case, il est pas pris en compte ?
Pareil, direct contact to LTS staff, c'est tendu. Est ce que ça veut dire que les gens qui vont faire le travail ne vont pas avoir leur email publié, ou si c'est le cas, il y a quoi comme avantage par rapport à juste regarder dans l'annuaire ?
Les gens peuvent aussi s'attendre à avoir un SLA, à ce que ça servent de support, etc. Au début, avec des gens qui connaissent le libre, pas de souci, mais si tu veux trouver 50 boites, ça risque de coincer tot ou tard.
J'imagine que je suis pas le premier à poser les questions, mais je vois pas de FAQ dans le site.
Ouais, mais la, on sort des APIs openstack. Que je sache, la localité des données n'est pas exposé par openstack de manière standard. Ensuite, bien sur, tu peux faire tout ce que tu veux à coté, mais le point, c'est que ç'est à coté :)
Pour docker, tu as tout le projet atomic ( http://atomicproject.io/ ). Et par exemple, geard pour l'orchestration, cockpit pour le management, et Red hat a aussi contribué pas mal sur Docker.
Ensuite, le but d'openstack, c'est pas "pour le proprio", même si la virtu sert pas mal à ça. C'est aussi parce que ça offre plus de souplesse. Par exemple, tu peux faire du self service. Tes devs gérent leur bécane et les rendent sans te faire chier. Ou tes environnement de tests/qa/preprod.
Sinon, tu a aussi (tout chaud ce matin, avant c'était proprio) le projet manageiq (http://manageiq.org/).
la, on tape en effet dans le logiciel spécialisé de gestion complète de ton infrastructure cloud. Et je dit bien cloud, et pas IaaS, vu que l'outil fait aussi l'automatisation, la gestion des stats, le cycle de vie complet. l'outil va s'interfacer avec vmware, RHEV, openstack et sans doute à terme d'autres, pour que tu puisses déployer.
Et pour parler de RHEV, son pendant communautaire est ovirt (http://ovirt.org); La, on est dans le concurent à VCenter.
La ou Openstack file des machines jetables sans gestion fine du stockage, de l'endroit ou se trouve chaque machine ou la migration à cahdu, Ovirt gére des systèmes qui ont pas pour vocation d'être jetable. Donc tu peux faire de la migration automatique, tu as un concept de datacenter, etc, etc.
Y a largement de quoi gérer tout un tas de trucs cloud et virtu.
Ce n'est pas que je n'aime pas la nouvelle méthode - c'est que
je ne la connais pas. Et j'ai beau chercher et ouvrir des
tickets chez RH je n'ai pas encore eu de réponses
satisfaisantes.
En plus SELinux c'est quand même pas évident à gérer et très
facile à casser (ce qui en langage hypervisuer veut dire plus
personne ne peut rien faire tant qu'on a pas rebooter la
machine en single user et passé SELinux en audit only).
je sais pas exactement comment tu te débrouilles. Tu peux faire un setenforce 0 sur une machine de test, et tu charges ta policy, tu regardes si tu as des AVC avec auditd. Ou si tu tiens à faire ça en prod, tu peux faire des semanage permissive pour juste mettre ton domaine en permissif.
Les seuls fois ou tu va te bloquer avec selinux, c'est si tu bascules ton utilisateur dans un mode restreint sans prévoir un login root de secours et sans mettre selinux en permissive. Un peu comme basculer sur ldap sans te laisser un shell root ou ce genre de choses.
Enfin, les histoires de 7% à 15% , je pense que tu parles des audits, pas de selinux. Les 2 sont séparés ( ie, selinux peut tourner sans audit, auditd peut tourner sans selinux ), donc je suis pas sur du coup que tu testes vraiment ce que tu crois tester….
Je vois pas qui ferait ça ni dans quel intérêt. Des gens qui font des infras ultra complexes, ça existe à la pelle. On a tous croisé des usines à gaz et ce genre de choses, donc je vois pas pourquoi ça ne serait pas la vérité.
Les cgroups s'oriente vers une architecture avec un seul processus capable d'écrire dans la hierarchie. Donc c'est déjà mort, on le sait depuis quelques temps.
Ensuite, la façon de faire qui consiste à dire "nagios peut lancer et relancer tout", c'est aussi pas le but de nagios, qui fait du monitoring, pas du correctif en temps normal.
Le souci de Kaane, c'est qu'il monte ses propres architectures qui semble ultra complexes ( du moins, c'est l'impression que j'en retire des pavés et de ce que j'arrive à comprendre dans tout le mix qu'il fait ), qu'il fait des trucs relativement hors des clous ( la, nagios qui relance les services, avant, son histoire de réseau GRE à monter avant TCP/IP, etc ), et qu'ensuite, quand systemd fait la même chose (à savoir la gestion de processus) et que systemd est adopté, ça le bloque dans son architecture.
Mais systemd bloque pas quoi que ce soit, nagios peut parfaitement lancr tout ce qu'il veut soit via service ( et sudo ), soit via l'api DBUS de systemd qui est accessible à des non roots via une configuration standardisé ( vu que c'est le but de dbus ). Point bonus, tu peux contrôler ça via selinux ( ie, dire que nagios a les accès qui vont bien via dbus avec médiation par selinux https://fedoraproject.org/wiki/Features/SELinuxSystemdAccessControl ), ce qui renforce d'autant plus la sécurité et l'isolation qu'il semble vouloir.
Et en fait, l'API dbus est exactement fait pour ça, pour ne pas donner les droits roots mais pour avoir un accès fins aux données. Un project comme cockpit ( http://cockpit-project.org/ ) tire justement parti de ces APIs pour ne pas avoir besoin d'être root.
Je ne doute pas qu'il existe sans doute des vrais soucis, peut être que l'API ne donne pas les accès suffisamment finement pour ce qu'il veut, etc, mais la, les soucis semblent surtout être un mélange de dette technique et d'un manque de clarté dans l'explication du souci.
Je sais pas. Les cgroups sont orthogonaux à l'usage de ptrace. Ptrace sert juste à déterminer quel process doit être le process principal, du moins pour upstart. Mais tu peux t'en passer avec divers options, sauf erreur de ma part. Donc tu pourrais très bien imaginer que upstart se retrouve avec une option "kill cgroups", pour tuer tout les process, et avoir le support de "expect systemd", pour avoir la notification comme systemd, ou "expect pidfile", pour faire comme systemd également.
IE, la modularité est déjà la dans le code pour supporter divers choses à divers niveau, et sans remettre en cause le format.
Ensuite, le format est pourri ( difficilement parsable ), mais ça, c'est une autre histoire. Et je parle du code maintenant, pas de celui d'il y a 5 ans, et peut être que ça change tout aussi.
Les soucis de design n'étaient pas évident. Ni i impossible à corriger. Par exemple, le suivi de processus par cgroups auraient pu être mis dans upstart, le suivi avec ptrace aurait pu être refait ou abandonné. Mais Scott ne voulait pas.
Les parties manquantes dans le code (support ipv6, socket activation correct) aurait aussi pu se rajouter, avec un protocole d'activation mieux foutu.
Par contre, ce qui aurait été dur à corriger, c'est les soucis au niveau du design (genre le fait que les dépendances sont dans l'ordre inverse de ce que tu crois et que la logique interne avec les 'ou' a des résultats surprenants). Et ça, je pense qu'il fallait faire un gros usage avant de le voir.
Mir, je sais pas, mais upstart m'a intéressé. C'était une amélioration et un changement dans la gestion des processus, ça apportait des idées intéressantes ( le fait d'avoir une manière plus simple de lancer les services, le coté dynamique, le fait d'avoir une API haut niveau ).
Ensuite, l’exécution était défaillante, le CLA a bloqué des boites qui n'ont pas contribué, et Canonical n'a pas vraiment mis les moyens. Mais ça n'a pas empêché Fedora de le prendre en 2008, pour Fedora 9.
RHEL 6 aussi a adopté Upstart (bien qu'avec une intégration très light), mais je pense que c'est au cours des phases finales de RHEL 6 (cad en 2010, au vue du calendrier) que systemd a vu le jour. Le timing n'est à mon avis pas un hasard. Si je peux hasarder une rétrospective:
RHEL 6 sort en novembre 2010.
Systemd sort en avril 2010.
On peut donc supposer que l'idée de faire systemd est né fin 2009, le temps de faire un truc grosso modo potable pour la version 1, et de contacter des gens à gauche et à droite (Lennart a indiqué qu'il avait pris contact avec des mainteneurs d'autre distributions pour récolter les différentes pratiques et je pense que ça prends du temps).
On peut donc supposer que les équipes de RH ont regardé upstart plus en détail durant l'année 2009, et que ça a aboutit au fait que Lennart propose systemd. Il est aussi fort probable que ça soit la raison d'une intégration "light" au contraire d'Ubuntu.
Upstart est sorti en 2006, donc il a fallu 2/3 ans avant que des gens se penchent pour l'intégration ailleurs ( cad globalement après que la techno se soit montré assez viable pour la LTS en avril 2008, à vue de nez ).
Je sais qu'il y a eu des discussions pour prendre ça sur OpenSuse en voyant Fedora, et pareil pour Mandriva. Sauf que Mandriva a implosé en 2010, et que Suse n'a pas suivi, sans doute à cause de la sortie de systemd, et son intégration avec Fedora.
Mais voila, Upstart, sur son principe, a intéressé des gens. Le nokia n9, sorti en 2011, a upstart. On peut supposer que le choix d'upstart s'est fait 3 à 4 ans avant, ce qui montre bien le moment ou upstart a intéressé les gens. D'ailleurs, pareil pour Chromeos, toujours sur upstart, et qui a commencé en 2009 aussi.
Linus fait confiance aux divers lieutenants. Par exemple, pour le réseau, David Miller, qui est lui aussi membre de la conspiration au chapeau. J'ai pas réussi à trouver de listes des dit trusted lieutenants ( ce qui est ma foi un peu un manque de transparence ), mais je pense que Ingo Molnar est potentiellement dessus pour la partie RT , pareil, chapeau rouge ). Ou Al Viro.
Donc je pense que si ce qu'on dit est vrai ( à savoir que Linus ne regarde même pas les PR et merge direct ), Linus veille pas tant que ça. Mais bon, ça va, tant que la machine vger.kernel.org n'est pas sous la protection d'un firewall sous le controle de RH, on peut supposer que les gens sont libres.
déjà répondu:ils n'ont pas forcemment les moyens humains de le
faire
Alors, si Canonical a eu les moyens de faire son propre init ( et de continuer à faire son serveur d'affichage, son outil d'orchestration de serveur, son interface graphique et sa pile pour téléphone ), je pense qu'ils ont aussi les moyens de faire mieux, si ils le voulaient. Et Canonical est largement la plus petite des boites restantes à faire des distributions à destination du monde professionnel.
Donc, c'est quoi les moyens requis en terme d'ingénieur ?
2, 3 personnes à temps plein ? Plus, moins ?
C'est simplificateur. Tu as aussi l'équipe qui va sur Phoronix pour répandre la propagande dans les commentaires, l'équipe qui étudie comment casser la compatibilité sacré avec Unix et le passé, l'équipe qui prends en otage les gens des projets communautaires pour faire ce que RH veux.
Alors, j'ai demandé à un pote avec un compte chez FDO :
$ getent group systemd
systemd:x:882:david,walters,kay,harald,tfheen,lennart,mbiebl,holtmann,martin,colin,bor,michich,zbyszek,dreisner,straussd,tomegun,phomes,auke,dvdhrm,zonque,bphilips,msekleta,lnykryn,pflykt
Grosso modo, on a de chez RH:
- kay
- lennart
- msekleta
- lnykryn
- haralt
- tomegun
- walters
- michich
De chez intel, on a :
- pflykt
- auke
- holtmann
En indépendant, on a:
bphilips (brandon Philips) bosse chez CoreOS.
straussd (David Stauss), chez Pantheon system
dvdhrm (David Herman), est étudiant d'aprés sa page web
colin, (Colin Guthrie), chez une boite qu'il a fondé ( et pour le projet mageia )
dreisner (Dave Reisner), packager Arch, qui bosse chez Google d'aprés son compte github
tfheen (Tolef Fog Heen), Debian et qui bosse chez Fastly
mbiebl (Michael Biebl), Debian, étudiant
zbyszek, (Zbigniew Jędrzejewski-Szmek), bosse dans un labo de neuro science aux US
martin, (Martin Pitt), Canonical
Et ceux que je sais pas:
zonque ( Daniel Mack )
phomes ( Thomas Andersen )
bor ( Andrey Borzenkov ) ( potentiellement chez Suse, mais j'arrive pas à vérifier )
Et le reste, ou je suppose uniquement:
david, sans doute david stauss ( mais pourquoi 2 comptes )
On a donc 24 commiteurs, dont 8 gens chez Red Hat, 3 chez Intel.
Ça fait 33% de commiteurs chez RH, et donc 66% venant d'autres boites diverses et variées. On noteras qu'il y a des devs de divers distros (Arch, Debian, Ubuntu, Mageia, potentiellement Suse). Y a même des concurents (genre coreos, qui est relativement en concurence avec projectatomic de RH).
Et ça compte que les commiteurs, pas les gens qui filent des patchs sur la ml.
Trop de dev d'un endroit est un risque, si jamais RH va mal ou si il y a rachat. Maintenant, tu peux pas forcer non plus les gens à travailler sur les projets sauf si tu est leur employeur et les alternatives ont des effets de bord plus genant qu'un risque futur.
Exemple, ne pas bosser autant sur un projet, ça va ralentir le libre. Ne pas embaucher les codeurs principaux d'un projet, ç'est prendre le risque que le mec se barre dans un trou noir potentiel à la Google/Facebook/Apple et ne bosse plus sur le projet,ce qui implique de former quelqu'un ou d'attendre qu'un remplaçant émerge.
Des gens vont dire que l’émergence d'un concurrent est rendu difficile (exemple, Canonical) de part la position de la boite.
Mais ne pas chercher à augmenter son chiffre d'affaire, c'est prendre le risque qu'une boite moins orienté libre et plus grosse prenne le marché et qu'on revienne en arrière (exemple, une domination d'un secteur par vmware ou oracle). Et c'est pas en laissant une plus petite boite prendre la place d'une plus grosse que tu arrives à te battre contre une boite très grosse.
Il faut aussi voir que plus une technologie est générique (genre glibc, gcc), plus ça pourrait poser de souci. Mais plus elle est générique, plus on devrait avoir des contributions variés car la communauté est plus grande donc moins le risque est grand.
Ensuite, ça reste que du très théorique. Après le rachat de Sun par Oracle, les gens de ZFS et Solaris ont réussi à faire vivre le projet. Aprés Mandriva, Mageia est arrivé.
Oui. Je pense que j'ai la sale habitude de retailler les citations pour que ça rentre dans la boite de dialogue pour éviter de casser l'alignement, et en effet, ça doit donner une coupure à 80 caractères.
bon nombre de technologies flaguées "experimental" dans le noyau
comme ?
DBus utilise les sockets. Du moment que vous avez les droits
root, une version custom de DBus avec tracages des paquets
et la logique de désérialisation - ca n'est pas plus dur à
suivre qu'un socket non DBus.
tu bullshites un peu ( comme d'hab ). Y a dbus-monitor, fourni de base, pas besoin de version custom.
Mais sur systemd avoir un /usr séparé fonctionne très bien (sauf
en double montage - mais que personne n'arrive à faire marcher.
Je vous jure, si, si)
Oui, ça marche, si tu fait monter le /usr par l'initrd. D'ailleurs, c'est la raison de l'unification de /bin et /usr/bin, refaire un /usr commun pour plusieurs containeurs.
En ce qui concerne l'ajout d'un serveur DHCP dans l'init,
c'était obligatoires. Parceque des raisons
Visiblement, tu as oublié de te relire ici, tu as oublié un 's' en trop dans ta précipitation et tu as oublié le lien vers le post qui donnent une raison. Heureusement, il y a des gens qui suivent pour te corriger:
Encore faux, systemd peut parfaitement renvoyer le contenu de
journald sur syslog si vous tenez tant que ça à doubler les
I/Os.
Si je peux me permettre (c'est une formule de politesse), tu fait encore preuve d'imprécision (on t'en veux pas, on peut pas passer sa soirée sur un commentaire et savoir de quoi on parle), la page de man (c'est la documentation sous Unix, si tu connais pas) semble indiquer que si tu ne fait pas un repertoire /var:log/journal, alors rien n'est écrit sur le disque par journald. Donc je ne suis pas sur que les I/Os soient doublé, sauf si tu configures mal ton systéme aprés ne pas avoir lu la page de man.
Reference : http://www.freedesktop.org/software/systemd/man/systemd-journald.service.html
"By default, the journal stores log data in /run/log/journal/.". Comme /run est un tmpfs, ça fait pas d'I/O sur le disque (sauf si tu configures /run pour ne pas être un tmpfs, cad sauf si tu fait exprés de rendre les choses moins performantes).
Tu peux aussi filer à syslog et envoyer ça vers splunk/logstash ou autre. Enfin, ça, c'est pour les admins avec du pognon et ou des infras plus conséquentes.
Honnêtement on ne peut pas porter systemd ailleurs.
Visiblement, en 4 ans, personne n'a tenté, et encore moins réussi. Donc soit c'est pas faisable et Lennart a raison, soit ça intéresse personne, et Lennart a raison de pas perdre de temps dessus. Dans les 2 cas, il a raison.
Nous on a un système centralisé ou pour lancer une copie d'un
service qui tourne déjà avec d'autres paramètres il faut
copier un template
Non, tu fait le fichier et un include.
, le linker symboliquement, l'enregistrer, et finalement
l'initialiser (éventuellement avec des scripts pre et post
traitement) via des commandes DBus et/ou systemctl.
Faire un lien, comme sur gentoo et openrc ? C'est vrai, je me souviens des cris des gens quand on a dit "oui, faut faire un lien d'un script d'init pour en lancer plusieurs exemplaires, puis il faut connaitre le nom du nouveau script, puis taper 1 commande par script à lancer, comme c'était long. les gens ont râlés de partout à dire que Gentoo ne marcherais jamais avec un système si fastidieux. Je me souviens des gens envoyant des menaces à Daniel Robbins, etc.
Mais bon, je doit reconnaitre que ta mauvaise foi est distrayante, et ça change des fois ou tu as affirmé (je cite) que RHEL sortirais mi-2013 (supposition de ton chapeau), en envisageant sérieusement de ne pas mettre systemd. Comme tu as la mémoire courte (vu le nombre conséquent d'oubli à chaque fois), je te remets le lien:
Au final c'est pas bien connu, mais il me semble que les distributions serveurs (comme Suse Entreprise ou Red Hat) envisagent très sérieusement de ne PAS passer à systemd. En tout cas pas tout de suite.
En fait, ils envisagent tellement de revenir en arrière qu'il reste que 3 scripts d'init dans la version finale de RHEL 7.
La syntaxe des filtres BPF semble aussi ne pas être la même, donc il faut aussi faire des adaptations.
Les ioctl sont pas pareil ( je pense pas que BIOCVERSION existe sous Linux, aprés une rapide recherche ). Et je suis sur que l'ajout de route non plus. Et après lecture du code, je suis pas sur qu'il gére pas le dhcpv6 ( avec délégation de prefix, etc, etc ).
Et c'est pas une lib.
Donc si le but, c'est juste de forker le code pour faire chier Theo, je suis pas sur que ça vaille le coup, vraiment.
Et pour Freebsd, bah pareil, le client dhcp est dérivé de openbsd, et en plus, utilise capsicum (non dispo sur linux) :
Décider de ne pas suivre, ça a un coût que ne peuvent supporter
la majorité des distributions.
Tu veux dire "ne rien faire rends dépendant de ceux qui font les choses, car sinon, on arrive pas à suivre ?"
Les communautaires parce que créer et maintenir une solution
alternative, c'est hors de leurs moyens
khof BSDs khof
Avant que GNOME ne s'y mette, systemd vivait dans son coin et
personne ne songeait à switcher, ou en tout cas pas si vite
étant donné la quantité de problème qui restait à régler avec
systemd.
Fedora a switché. Suse, Mageia, Arch. Debian et Gentoo l'ont mis en option depuis longtemps. Je boote mon serveur Debian stable avec. Et il est dans Debian depuis 2010. Pour un truc ou personne ne songé à switcher, je trouve que les gens ont vite fait le travail.
Développer du logiciel libre, ce n'est pas comme développer du
logiciel tout court, il y a des règles tacites, des
communautés à prendre en compte.
Sinon quoi ?
Ah oui, sinon, les gens vont râler sur linuxfr et slashdot. En vérité, les règles, c'est pas "faut respecter les communautés". C'est plus "on propose, et si les gens sont content, ils suivent, sinon, ils se barrent". Et visiblement, la majorité se barre pas. Ou plutôt, la majorité qui compte, cad les contributeurs. L'équipe de systemd a consulté les gens des autres distributions dés le début, c'est pour ça que le système utilise /etc/hostname et d'autres debianismes.
Si tu ne respectes pas les règles de la communauté, tu as personne qui vient contribuer sur ton logiciel, et on se retrouve avec la même communauté qu'un logiciel proprio ( ie, personne ne t'aide ). Le fait que des externes au projet contribuent semble montrer que les règles sont respectés.
RedHat reste une entreprise avec ses intérêts particuliers et > il se peut qu'un jour les intérêts de RedHat soient en
contradiction avec les intérêts du monde libre.
En pratique, ça serait quoi ?
Le code est libre, si tu changes la licence, l'ancienne s'applique encore sur les anciens tarballs distribués. RH fait parti de l'OIN, donc je ne pense pas que les brevets soient un souci. Il reste divers trademarks, qui devraient bloquer qu'une paire de projets de la boite.
Le plus gros souci, ça serait d’arrêter de aire du libre. Mais pour ça, la solution, c'est que le reste du monde en fasse plus, et pour ça, faut arrêter de zoner sur linuxfr et commencer à contribuer.
Alors bien sur, ça reprends beaucoup de udev, preuve que c'est pas si simple. Et grosso modo, y a quelques distros qui doivent proposer ça, mais y a pas la vivacité de systemd.
[^] # Re: Tarif
Posté par Misc (site web personnel) . En réponse à la dépêche Support à long terme de Debian: une opportunité à ne pas manquer. Évalué à 4.
ce qui est pas si cher en fait pour le nieau de compétences. J'étais facturé par feu ma boite à 800€/j en début de carrière, en régie en Alsace pendant 3 ans. Et quand je vois le tarif des consultants de nos jours, je me dit que soit l'inflation est passé par la, soit j'étais pas si cher que ça.
Ensuite, il faut voir que ça ne vise pas que les travailleurs français, et je pense aussi qu'ils font ça par passion donc sont sans doute prêt à faire une réduction de principe, ce qui explique le prix pas si haut que ça (ça, ou une déformation du à Paris).
# Les chiffres me paraissent un chouia optimistes
Posté par Misc (site web personnel) . En réponse à la dépêche Support à long terme de Debian: une opportunité à ne pas manquer. Évalué à 10.
Y a un certain nombre de trucs qui me laisse songeur
un peu partout.
D'abord, faire une liste privé pour que les boites puissent se retrouver entre elles, ça me parait un peu aller contre la transparence qu'on attends de Debian. Je comprends bien le fait de devoir offrir quelque chose en plus, mais ça fait très "mandrake club", et historiquement, ça n'a super bien marché. À coté, toutes les sociétés commerciales font ça aussi. Je pense qu'une condition pour que ça apporte de la valeur est d'avoir une communauté suffisamment grande et ç'est pas encore le cas. Donc personnelement, je commencerais pas par proposer ça.
Ensuite, le fait d'avoir le droit de soumettre ses propres tests cases me parait aussi curieux. Si le test case est utile à plusieurs personnes, pourquoi ne pas le donner à tous, et le mettre upstream ? Je pense aussi que l'offre ne dit pas clairement quel genre de test case je peux donner (genre, si je dit "voila mon test case, il faut lancer ce benchmark sur 30 machines", ça va être refusé ). Ou ce qui se passe en cas de problème avec le test case, etc, etc. Et il se passe quoi si je paye pas et que je donne un test case, il est pas pris en compte ?
Pareil, direct contact to LTS staff, c'est tendu. Est ce que ça veut dire que les gens qui vont faire le travail ne vont pas avoir leur email publié, ou si c'est le cas, il y a quoi comme avantage par rapport à juste regarder dans l'annuaire ?
Les gens peuvent aussi s'attendre à avoir un SLA, à ce que ça servent de support, etc. Au début, avec des gens qui connaissent le libre, pas de souci, mais si tu veux trouver 50 boites, ça risque de coincer tot ou tard.
J'imagine que je suis pas le premier à poser les questions, mais je vois pas de FAQ dans le site.
[^] # Re: La vraie nouvelle du jour
Posté par Misc (site web personnel) . En réponse à la dépêche Red Hat Software Collections 1.1. Évalué à 2.
Ouais, mais la, on sort des APIs openstack. Que je sache, la localité des données n'est pas exposé par openstack de manière standard. Ensuite, bien sur, tu peux faire tout ce que tu veux à coté, mais le point, c'est que ç'est à coté :)
[^] # Re: Le vendredi c'est permis.
Posté par Misc (site web personnel) . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 7.
Genre ça:
http://www.freedesktop.org/software/systemd/man/systemd-run.html
[^] # Re: La vraie nouvelle du jour
Posté par Misc (site web personnel) . En réponse à la dépêche Red Hat Software Collections 1.1. Évalué à 5.
Pour docker, tu as tout le projet atomic ( http://atomicproject.io/ ). Et par exemple, geard pour l'orchestration, cockpit pour le management, et Red hat a aussi contribué pas mal sur Docker.
Ensuite, le but d'openstack, c'est pas "pour le proprio", même si la virtu sert pas mal à ça. C'est aussi parce que ça offre plus de souplesse. Par exemple, tu peux faire du self service. Tes devs gérent leur bécane et les rendent sans te faire chier. Ou tes environnement de tests/qa/preprod.
Sinon, tu a aussi (tout chaud ce matin, avant c'était proprio) le projet manageiq (http://manageiq.org/).
la, on tape en effet dans le logiciel spécialisé de gestion complète de ton infrastructure cloud. Et je dit bien cloud, et pas IaaS, vu que l'outil fait aussi l'automatisation, la gestion des stats, le cycle de vie complet. l'outil va s'interfacer avec vmware, RHEV, openstack et sans doute à terme d'autres, pour que tu puisses déployer.
Et pour parler de RHEV, son pendant communautaire est ovirt (http://ovirt.org); La, on est dans le concurent à VCenter.
La ou Openstack file des machines jetables sans gestion fine du stockage, de l'endroit ou se trouve chaque machine ou la migration à cahdu, Ovirt gére des systèmes qui ont pas pour vocation d'être jetable. Donc tu peux faire de la migration automatique, tu as un concept de datacenter, etc, etc.
Y a largement de quoi gérer tout un tas de trucs cloud et virtu.
[^] # Re: La vraie nouvelle du jour
Posté par Misc (site web personnel) . En réponse à la dépêche Red Hat Software Collections 1.1. Évalué à 2.
Tu sais, c'est pas grave, tu peux pas aller vérifier le code sur le ne…. oups, on me dit que si /o\
[^] # Re: Le vendredi c'est permis.
Posté par Misc (site web personnel) . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 1.
Que je récapitule. Tu as déjà migré tes services de prod en RHEL 7 sorti il y a une semaine, tu as déjà ouvert des tickets entre temps, mais par toi même, tu as pas trouvé les présentations comme
https://events.linuxfoundation.org/sites/events/files/slides/linuxcon.pdf
La doc officiel comme ça :
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Resource_Management_and_Linux_Containers_Guide/sec-Modifying_Control_Groups.html
Ou les blogs comme
http://schnouki.net/posts/2013/12/19/resource-control-with-systemd/
Ou la doc de systemd comme :
http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/
Ensuite, peut être que j'ai mal compris la question, mais globalement, tu peux faire l'ajustement avec un bon vieux sudo et voila.
Sinon, c'est du dbus. Cad que la doc que je trouve sur developpez.com avec google me semble suffisante :
http://yoannsculo.developpez.com/tutoriels/linux/introduction-dbus/#LIV
je sais pas exactement comment tu te débrouilles. Tu peux faire un setenforce 0 sur une machine de test, et tu charges ta policy, tu regardes si tu as des AVC avec auditd. Ou si tu tiens à faire ça en prod, tu peux faire des semanage permissive pour juste mettre ton domaine en permissif.
Les seuls fois ou tu va te bloquer avec selinux, c'est si tu bascules ton utilisateur dans un mode restreint sans prévoir un login root de secours et sans mettre selinux en permissive. Un peu comme basculer sur ldap sans te laisser un shell root ou ce genre de choses.
Enfin, les histoires de 7% à 15% , je pense que tu parles des audits, pas de selinux. Les 2 sont séparés ( ie, selinux peut tourner sans audit, auditd peut tourner sans selinux ), donc je suis pas sur du coup que tu testes vraiment ce que tu crois tester….
[^] # Re: Libre
Posté par Misc (site web personnel) . En réponse à la dépêche Red Hat Software Collections 1.1. Évalué à 3.
Sinon, y a softwarecollections.org pour les gens qui veulent du communautaire.
[^] # Re: Le vendredi c'est permis.
Posté par Misc (site web personnel) . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 4.
Je vois pas qui ferait ça ni dans quel intérêt. Des gens qui font des infras ultra complexes, ça existe à la pelle. On a tous croisé des usines à gaz et ce genre de choses, donc je vois pas pourquoi ça ne serait pas la vérité.
[^] # Re: Le vendredi c'est permis.
Posté par Misc (site web personnel) . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 10.
Les cgroups s'oriente vers une architecture avec un seul processus capable d'écrire dans la hierarchie. Donc c'est déjà mort, on le sait depuis quelques temps.
Ensuite, la façon de faire qui consiste à dire "nagios peut lancer et relancer tout", c'est aussi pas le but de nagios, qui fait du monitoring, pas du correctif en temps normal.
Le souci de Kaane, c'est qu'il monte ses propres architectures qui semble ultra complexes ( du moins, c'est l'impression que j'en retire des pavés et de ce que j'arrive à comprendre dans tout le mix qu'il fait ), qu'il fait des trucs relativement hors des clous ( la, nagios qui relance les services, avant, son histoire de réseau GRE à monter avant TCP/IP, etc ), et qu'ensuite, quand systemd fait la même chose (à savoir la gestion de processus) et que systemd est adopté, ça le bloque dans son architecture.
Mais systemd bloque pas quoi que ce soit, nagios peut parfaitement lancr tout ce qu'il veut soit via service ( et sudo ), soit via l'api DBUS de systemd qui est accessible à des non roots via une configuration standardisé ( vu que c'est le but de dbus ). Point bonus, tu peux contrôler ça via selinux ( ie, dire que nagios a les accès qui vont bien via dbus avec médiation par selinux https://fedoraproject.org/wiki/Features/SELinuxSystemdAccessControl ), ce qui renforce d'autant plus la sécurité et l'isolation qu'il semble vouloir.
Et en fait, l'API dbus est exactement fait pour ça, pour ne pas donner les droits roots mais pour avoir un accès fins aux données. Un project comme cockpit ( http://cockpit-project.org/ ) tire justement parti de ces APIs pour ne pas avoir besoin d'être root.
Je ne doute pas qu'il existe sans doute des vrais soucis, peut être que l'API ne donne pas les accès suffisamment finement pour ce qu'il veut, etc, mais la, les soucis semblent surtout être un mélange de dette technique et d'un manque de clarté dans l'explication du souci.
[^] # Re: Portabilité et forçage
Posté par Misc (site web personnel) . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 3.
Je sais pas. Les cgroups sont orthogonaux à l'usage de ptrace. Ptrace sert juste à déterminer quel process doit être le process principal, du moins pour upstart. Mais tu peux t'en passer avec divers options, sauf erreur de ma part. Donc tu pourrais très bien imaginer que upstart se retrouve avec une option "kill cgroups", pour tuer tout les process, et avoir le support de "expect systemd", pour avoir la notification comme systemd, ou "expect pidfile", pour faire comme systemd également.
IE, la modularité est déjà la dans le code pour supporter divers choses à divers niveau, et sans remettre en cause le format.
Ensuite, le format est pourri ( difficilement parsable ), mais ça, c'est une autre histoire. Et je parle du code maintenant, pas de celui d'il y a 5 ans, et peut être que ça change tout aussi.
[^] # Re: Portabilité et forçage
Posté par Misc (site web personnel) . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 3.
Les soucis de design n'étaient pas évident. Ni i impossible à corriger. Par exemple, le suivi de processus par cgroups auraient pu être mis dans upstart, le suivi avec ptrace aurait pu être refait ou abandonné. Mais Scott ne voulait pas.
Les parties manquantes dans le code (support ipv6, socket activation correct) aurait aussi pu se rajouter, avec un protocole d'activation mieux foutu.
Par contre, ce qui aurait été dur à corriger, c'est les soucis au niveau du design (genre le fait que les dépendances sont dans l'ordre inverse de ce que tu crois et que la logique interne avec les 'ou' a des résultats surprenants). Et ça, je pense qu'il fallait faire un gros usage avant de le voir.
[^] # Re: Portabilité et forçage
Posté par Misc (site web personnel) . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 8.
Mir, je sais pas, mais upstart m'a intéressé. C'était une amélioration et un changement dans la gestion des processus, ça apportait des idées intéressantes ( le fait d'avoir une manière plus simple de lancer les services, le coté dynamique, le fait d'avoir une API haut niveau ).
Ensuite, l’exécution était défaillante, le CLA a bloqué des boites qui n'ont pas contribué, et Canonical n'a pas vraiment mis les moyens. Mais ça n'a pas empêché Fedora de le prendre en 2008, pour Fedora 9.
RHEL 6 aussi a adopté Upstart (bien qu'avec une intégration très light), mais je pense que c'est au cours des phases finales de RHEL 6 (cad en 2010, au vue du calendrier) que systemd a vu le jour. Le timing n'est à mon avis pas un hasard. Si je peux hasarder une rétrospective:
RHEL 6 sort en novembre 2010.
Systemd sort en avril 2010.
On peut donc supposer que l'idée de faire systemd est né fin 2009, le temps de faire un truc grosso modo potable pour la version 1, et de contacter des gens à gauche et à droite (Lennart a indiqué qu'il avait pris contact avec des mainteneurs d'autre distributions pour récolter les différentes pratiques et je pense que ça prends du temps).
On peut donc supposer que les équipes de RH ont regardé upstart plus en détail durant l'année 2009, et que ça a aboutit au fait que Lennart propose systemd. Il est aussi fort probable que ça soit la raison d'une intégration "light" au contraire d'Ubuntu.
Upstart est sorti en 2006, donc il a fallu 2/3 ans avant que des gens se penchent pour l'intégration ailleurs ( cad globalement après que la techno se soit montré assez viable pour la LTS en avril 2008, à vue de nez ).
Je sais qu'il y a eu des discussions pour prendre ça sur OpenSuse en voyant Fedora, et pareil pour Mandriva. Sauf que Mandriva a implosé en 2010, et que Suse n'a pas suivi, sans doute à cause de la sortie de systemd, et son intégration avec Fedora.
Mais voila, Upstart, sur son principe, a intéressé des gens. Le nokia n9, sorti en 2011, a upstart. On peut supposer que le choix d'upstart s'est fait 3 à 4 ans avant, ce qui montre bien le moment ou upstart a intéressé les gens. D'ailleurs, pareil pour Chromeos, toujours sur upstart, et qui a commencé en 2009 aussi.
[^] # Re: Portabilité et forçage
Posté par Misc (site web personnel) . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 3.
Un simple truc comme ça:
Tu peux tenter aussi
Mais dans un cas plus proasaique, je suis pas sur que echo renvoie pas 1 si le tty disparait ( genre, tu tues sshd )
[^] # Re: Portabilité et forçage
Posté par Misc (site web personnel) . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 3.
Linus fait confiance aux divers lieutenants. Par exemple, pour le réseau, David Miller, qui est lui aussi membre de la conspiration au chapeau. J'ai pas réussi à trouver de listes des dit trusted lieutenants ( ce qui est ma foi un peu un manque de transparence ), mais je pense que Ingo Molnar est potentiellement dessus pour la partie RT , pareil, chapeau rouge ). Ou Al Viro.
Donc je pense que si ce qu'on dit est vrai ( à savoir que Linus ne regarde même pas les PR et merge direct ), Linus veille pas tant que ça. Mais bon, ça va, tant que la machine vger.kernel.org n'est pas sous la protection d'un firewall sous le controle de RH, on peut supposer que les gens sont libres.
[^] # Re: Portabilité et forçage
Posté par Misc (site web personnel) . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 7.
Alors, si Canonical a eu les moyens de faire son propre init ( et de continuer à faire son serveur d'affichage, son outil d'orchestration de serveur, son interface graphique et sa pile pour téléphone ), je pense qu'ils ont aussi les moyens de faire mieux, si ils le voulaient. Et Canonical est largement la plus petite des boites restantes à faire des distributions à destination du monde professionnel.
Donc, c'est quoi les moyens requis en terme d'ingénieur ?
2, 3 personnes à temps plein ? Plus, moins ?
[^] # Re: Calcul
Posté par Misc (site web personnel) . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 7.
C'est simplificateur. Tu as aussi l'équipe qui va sur Phoronix pour répandre la propagande dans les commentaires, l'équipe qui étudie comment casser la compatibilité sacré avec Unix et le passé, l'équipe qui prends en otage les gens des projets communautaires pour faire ce que RH veux.
Je te trouves pas super respectueux envers tout ces groupes qui travaillent à rendre le libre sur le point d'exploser, sans doute un vaste plan de l'armée américaine (
http://igurublog.wordpress.com/2014/04/03/tso-and-linus-and-the-impotent-rage-against-systemd/ & http://igurublog.wordpress.com/2014/04/08/julian-assange-debian-is-owned-by-the-nsa/ )
[^] # Re: Calcul
Posté par Misc (site web personnel) . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 10.
Alors, j'ai demandé à un pote avec un compte chez FDO :
$ getent group systemd
systemd:x:882:david,walters,kay,harald,tfheen,lennart,mbiebl,holtmann,martin,colin,bor,michich,zbyszek,dreisner,straussd,tomegun,phomes,auke,dvdhrm,zonque,bphilips,msekleta,lnykryn,pflykt
Grosso modo, on a de chez RH:
- kay
- lennart
- msekleta
- lnykryn
- haralt
- tomegun
- walters
- michich
De chez intel, on a :
- pflykt
- auke
- holtmann
En indépendant, on a:
bphilips (brandon Philips) bosse chez CoreOS.
straussd (David Stauss), chez Pantheon system
dvdhrm (David Herman), est étudiant d'aprés sa page web
colin, (Colin Guthrie), chez une boite qu'il a fondé ( et pour le projet mageia )
dreisner (Dave Reisner), packager Arch, qui bosse chez Google d'aprés son compte github
tfheen (Tolef Fog Heen), Debian et qui bosse chez Fastly
mbiebl (Michael Biebl), Debian, étudiant
zbyszek, (Zbigniew Jędrzejewski-Szmek), bosse dans un labo de neuro science aux US
martin, (Martin Pitt), Canonical
Et ceux que je sais pas:
zonque ( Daniel Mack )
phomes ( Thomas Andersen )
bor ( Andrey Borzenkov ) ( potentiellement chez Suse, mais j'arrive pas à vérifier )
Et le reste, ou je suppose uniquement:
david, sans doute david stauss ( mais pourquoi 2 comptes )
On a donc 24 commiteurs, dont 8 gens chez Red Hat, 3 chez Intel.
Ça fait 33% de commiteurs chez RH, et donc 66% venant d'autres boites diverses et variées. On noteras qu'il y a des devs de divers distros (Arch, Debian, Ubuntu, Mageia, potentiellement Suse). Y a même des concurents (genre coreos, qui est relativement en concurence avec projectatomic de RH).
Et ça compte que les commiteurs, pas les gens qui filent des patchs sur la ml.
[^] # Re: Portabilité et forçage
Posté par Misc (site web personnel) . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 2.
Tu veux dire "l'API" ?
http://www.freedesktop.org/software/systemd/libudev/
ça se trouve sur un moteur de recherche
[^] # Re: Calcul
Posté par Misc (site web personnel) . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 4.
Trop de dev d'un endroit est un risque, si jamais RH va mal ou si il y a rachat. Maintenant, tu peux pas forcer non plus les gens à travailler sur les projets sauf si tu est leur employeur et les alternatives ont des effets de bord plus genant qu'un risque futur.
Exemple, ne pas bosser autant sur un projet, ça va ralentir le libre. Ne pas embaucher les codeurs principaux d'un projet, ç'est prendre le risque que le mec se barre dans un trou noir potentiel à la Google/Facebook/Apple et ne bosse plus sur le projet,ce qui implique de former quelqu'un ou d'attendre qu'un remplaçant émerge.
Des gens vont dire que l’émergence d'un concurrent est rendu difficile (exemple, Canonical) de part la position de la boite.
Mais ne pas chercher à augmenter son chiffre d'affaire, c'est prendre le risque qu'une boite moins orienté libre et plus grosse prenne le marché et qu'on revienne en arrière (exemple, une domination d'un secteur par vmware ou oracle). Et c'est pas en laissant une plus petite boite prendre la place d'une plus grosse que tu arrives à te battre contre une boite très grosse.
Il faut aussi voir que plus une technologie est générique (genre glibc, gcc), plus ça pourrait poser de souci. Mais plus elle est générique, plus on devrait avoir des contributions variés car la communauté est plus grande donc moins le risque est grand.
Ensuite, ça reste que du très théorique. Après le rachat de Sun par Oracle, les gens de ZFS et Solaris ont réussi à faire vivre le projet. Aprés Mandriva, Mageia est arrivé.
[^] # Re: À mon tour
Posté par Misc (site web personnel) . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 2.
Oui. Je pense que j'ai la sale habitude de retailler les citations pour que ça rentre dans la boite de dialogue pour éviter de casser l'alignement, et en effet, ça doit donner une coupure à 80 caractères.
[^] # Re: Le vendredi c'est permis.
Posté par Misc (site web personnel) . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 10.
comme ?
tu bullshites un peu ( comme d'hab ). Y a dbus-monitor, fourni de base, pas besoin de version custom.
Oui, ça marche, si tu fait monter le /usr par l'initrd. D'ailleurs, c'est la raison de l'unification de /bin et /usr/bin, refaire un /usr commun pour plusieurs containeurs.
Visiblement, tu as oublié de te relire ici, tu as oublié un 's' en trop dans ta précipitation et tu as oublié le lien vers le post qui donnent une raison. Heureusement, il y a des gens qui suivent pour te corriger:
https://plus.google.com/+TomGundersen/posts/ht4nn9jHbAR
Si je peux me permettre (c'est une formule de politesse), tu fait encore preuve d'imprécision (on t'en veux pas, on peut pas passer sa soirée sur un commentaire et savoir de quoi on parle), la page de man (c'est la documentation sous Unix, si tu connais pas) semble indiquer que si tu ne fait pas un repertoire /var:log/journal, alors rien n'est écrit sur le disque par journald. Donc je ne suis pas sur que les I/Os soient doublé, sauf si tu configures mal ton systéme aprés ne pas avoir lu la page de man.
Reference :
http://www.freedesktop.org/software/systemd/man/systemd-journald.service.html
"By default, the journal stores log data in /run/log/journal/.". Comme /run est un tmpfs, ça fait pas d'I/O sur le disque (sauf si tu configures /run pour ne pas être un tmpfs, cad sauf si tu fait exprés de rendre les choses moins performantes).
Tu peux aussi filer à syslog et envoyer ça vers splunk/logstash ou autre. Enfin, ça, c'est pour les admins avec du pognon et ou des infras plus conséquentes.
Visiblement, en 4 ans, personne n'a tenté, et encore moins réussi. Donc soit c'est pas faisable et Lennart a raison, soit ça intéresse personne, et Lennart a raison de pas perdre de temps dessus. Dans les 2 cas, il a raison.
Non, tu fait le fichier et un include.
Faire un lien, comme sur gentoo et openrc ? C'est vrai, je me souviens des cris des gens quand on a dit "oui, faut faire un lien d'un script d'init pour en lancer plusieurs exemplaires, puis il faut connaitre le nom du nouveau script, puis taper 1 commande par script à lancer, comme c'était long. les gens ont râlés de partout à dire que Gentoo ne marcherais jamais avec un système si fastidieux. Je me souviens des gens envoyant des menaces à Daniel Robbins, etc.
Mais bon, je doit reconnaitre que ta mauvaise foi est distrayante, et ça change des fois ou tu as affirmé (je cite) que RHEL sortirais mi-2013 (supposition de ton chapeau), en envisageant sérieusement de ne pas mettre systemd. Comme tu as la mémoire courte (vu le nombre conséquent d'oubli à chaque fois), je te remets le lien:
https://linuxfr.org/nodes/96086/comments/1401229
En fait, ils envisagent tellement de revenir en arrière qu'il reste que 3 scripts d'init dans la version finale de RHEL 7.
[^] # Re: Quel joli troll !
Posté par Misc (site web personnel) . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 5.
Je pense que l'affaire du dernier bug d'openssl montre bien pourquoi les gens preferent manger du verre pilé que de traiter avec Theo.
Sinon, le client des BSD est dérivé de celui de l'ISC :
http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sbin/dhclient/dhclient.c?rev=1.311;content-type=text%2Fplain
Et il est pas portable tel quel sur Linux. Exemple, prenons le premier fichier, le code pour faire un socket bpf ( http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/dhclient/bpf.c?rev=1.32;content-type=text%2Fplain ). Openbsd demande à ouvrir un device dans /dev, Linux fait ça via une option sur le socket ( https://www.kernel.org/doc/Documentation/networking/filter.txt ).
La syntaxe des filtres BPF semble aussi ne pas être la même, donc il faut aussi faire des adaptations.
Les ioctl sont pas pareil ( je pense pas que BIOCVERSION existe sous Linux, aprés une rapide recherche ). Et je suis sur que l'ajout de route non plus. Et après lecture du code, je suis pas sur qu'il gére pas le dhcpv6 ( avec délégation de prefix, etc, etc ).
Et c'est pas une lib.
Donc si le but, c'est juste de forker le code pour faire chier Theo, je suis pas sur que ça vaille le coup, vraiment.
Et pour Freebsd, bah pareil, le client dhcp est dérivé de openbsd, et en plus, utilise capsicum (non dispo sur linux) :
http://svnweb.freebsd.org/base/head/sbin/dhclient/bpf.c?revision=263234&view=markup
[^] # Re: Portabilité et forçage
Posté par Misc (site web personnel) . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 5.
Tu veux dire "ne rien faire rends dépendant de ceux qui font les choses, car sinon, on arrive pas à suivre ?"
khof BSDs khof
Fedora a switché. Suse, Mageia, Arch. Debian et Gentoo l'ont mis en option depuis longtemps. Je boote mon serveur Debian stable avec. Et il est dans Debian depuis 2010. Pour un truc ou personne ne songé à switcher, je trouve que les gens ont vite fait le travail.
Sinon quoi ?
Ah oui, sinon, les gens vont râler sur linuxfr et slashdot. En vérité, les règles, c'est pas "faut respecter les communautés". C'est plus "on propose, et si les gens sont content, ils suivent, sinon, ils se barrent". Et visiblement, la majorité se barre pas. Ou plutôt, la majorité qui compte, cad les contributeurs. L'équipe de systemd a consulté les gens des autres distributions dés le début, c'est pour ça que le système utilise /etc/hostname et d'autres debianismes.
Si tu ne respectes pas les règles de la communauté, tu as personne qui vient contribuer sur ton logiciel, et on se retrouve avec la même communauté qu'un logiciel proprio ( ie, personne ne t'aide ). Le fait que des externes au projet contribuent semble montrer que les règles sont respectés.
En pratique, ça serait quoi ?
Le code est libre, si tu changes la licence, l'ancienne s'applique encore sur les anciens tarballs distribués. RH fait parti de l'OIN, donc je ne pense pas que les brevets soient un souci. Il reste divers trademarks, qui devraient bloquer qu'une paire de projets de la boite.
Le plus gros souci, ça serait d’arrêter de aire du libre. Mais pour ça, la solution, c'est que le reste du monde en fasse plus, et pour ça, faut arrêter de zoner sur linuxfr et commencer à contribuer.
[^] # Re: Portabilité et forçage
Posté par Misc (site web personnel) . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 5.
Y a eudev : https://github.com/gentoo/eudev/commits/master
Alors bien sur, ça reprends beaucoup de udev, preuve que c'est pas si simple. Et grosso modo, y a quelques distros qui doivent proposer ça, mais y a pas la vivacité de systemd.