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.
Je doit reconnaitre que je pige pas trop la méthode de comptage, mais je doute qu'on puisse contester que ça n'a pas bousculé vraiment le scrutin.
Mais comme c'est libre, on pardonne et on fait semblant de rien.
Oui. parce que c'est libre, c'est pas de l'enfermement. C'est juste des gens qui font pas ce que tu veux mais qui t’empêche pas de faire ce que tu veux. Que la majorité ne te suive pas est une autre paire de manche.
Je peux donner des contre exemples. Les nouveaux produits comme the foreman, openshift sont en ruby en rails, ou en go ( geard ), alors que RH promeut java via jboss ( et a du monde sur le jdk, etc ), du monde sur gcc, et fait son propre language par dessus la jvm.
De même, openshift utilise depuis quasiment le début ActiveMQ plutôt que Qpid, qui est pourtant "de la maison". Des esprits chagrins et observateurs vont dire qu'avec le rachat de fusesource, RH a mis le pied dans ActiveMQ, mais la chronologie ne colle pas, car Openshift est antérieur à ce rachat.
Ou le fait d'avoir choisi de mettre en avant docker plutôt que virt-sandbox ou une solution basé sur les lxc et libvirt, pour ne parler que des choses récentes.
Tu parles de Tom Gundersen, le développeur que Red hat a embauché pour bosser sur networkd, sans doute pour le récompenser d'avoir mis systemd au sein de Arch Linux. Il est fort probable que le but obscure de la manœuvre soit d'infecter la distro qui monte et qui menace la main mise de la société sur le marché des serveurs.
Moi je dit, il faut se méfier de tout le monde, je suis même sur qu'ils sont parmis nous ici à surveiller et à répandre la propagande pour cacher le plan de domination du libre !
(je précise que c'est du sarcasme, pour le cas ou des gens souffriraient du même travers que le docteur Sheldon Cooper.)
ie, "l'existant ne nous va pas, mais on a regardé et on va bosser sur une nouvelle lib proposé par quelqu'un d'autre". Donc reprendre le code de connman, c'est pas vraiment du NIH.
Qui ont leur propres standards d'options et ne réutilisent pas
l'existant
L'existant pour quoi ?
Les options de systemd-detect-virt réutilise pas l'existant de ou ?
Ou journalctl devrait reprendre quel options existantes ?
Pour les trucs ou ça a du sens, c'est exactement ce qui est fait. Exemple, /etc/fstab, /etc/hostname, /etc/cryptsetup. Quand il y a rien, ou quand il y a des implémentations divergentes, il faut faire un choix.
et ça sera forcément moins UNIX que l'était System V
(franchement, du XML c'est pas très UNIX…).
On parle de systemd, pas de SMF…
Après, c'est peut-être ça l'avenir du Libre : ça devient plus
professionnel, et les petits bénévoles ne pourront plus suivre
le développement des composants au cœur du système.
Tu sembles tout d'un coup te réveiller d'un sommeil de 10 à 15 ans. Tu connais beaucoup de gens qui bosse sur gcc sur leur temps libre ? Sur la glibc, le kernel ou Xorg ?
Tu t'es dit que des trucs comme xen ou kvm sont arrivés sans avoir des gens à temps plein dessus ?
C'est bien ce que j'avais compris. Mais, je ne sauterais pas
aussi vite que toi sur la conclusion. Les units sont distribués
par des logiciels tiers, que tu peux ne pas vouloir faire
tourner en root (souvent tu lances un daemon sous un autre
utilisateur par exemple)
Dans ce cas, systemd le permet, via User=. Encore mieux, via l'activation par socket, tu peux même espérer avoir les softs ne jamais voir l'uid root, dans certains cas spécifiques.
En fait, non seulement systemd permet ça, mais en plus, permet de rajouter facilement la configuration via les drop-in config ( ie, faire un fichier /etc/system/foo.service.d/foo.conf avec juste User=foo et paf, il va faire ce que tu veux, à savoir combiné ton service et celui du distributeur tierce en gérant l'upgrade proprement )
Tu peux toujours te NIH tout seul.
Le NIH, c'est "Not Invented Here". Quand tu refait ton propre code, c'est pas vraiment du NIH, par définition. Est ce que pour toi, NIH veut dire "refaire du code alors que du code existant rempli une partie des besoins", auquel cas, on peut qualifier tout un tas de trucs de NIH…
( ou du moins, je pense que systemd-consoled n'est pas un NIH de ksmcon pour ma définition de NIH, mais c'est juste mon point de vue ). J'imagine qu'on ne mets juste pas la même chose sous le terme NIH.
Quel est le soucis avec ISC ?
Personnellement, je leur reprocherais une certaine obscurité et/ou de l'amateurisme. Exemple, le bug tracker de bind qui est une liste de discussion, les VCS des projets sont parfois non publiques et/ou mal documentés ( celui de dhcp me semble assez récent par exemple, bind < 10 n'etait pas existant). L'abandon soudain de bind 10 est un exemple de process interne non discuté en publique, etc, etc.
Donc je pense que la collaboration peut être difficile avec l'ISC, d'ou sans doute le fait que personne ne tente de faire une lib pour le dhcp en partant de dhcpd (encore une fois, l'équipe de connman bosse sur ça)
C'est plus subtile. C'est dans le pid 1 pour les fichiers de root, et dans le pid du gestionnaire de session pour les fichiers accessibles par l'utilisateur ( ie, sous l'uid de l'utilisateur ). Donc je pense que si tu peux écrire le fichier, alors c'est déjà trop tard, pas besoin d'exploiter une erreur dans le parser. Non pas que ça veuille dire "on s'en fout de la sécurité", mais que le fait de faire l'analyse du fichier dans un process à part avec un canal de communication avec le pid 1 est une complication qui n'a pas jugé valoir la chandelle pour le moment. Une des choses que j'ai trouvé complexe dans le code d'upstart est justement ça, l'overhead lié à la communication interprocessus, avec les problématiques de synchronisation, etc, etc. Peut être que ça arriveras plus tard, mais je pense que c'est plus important pour un browser que systemd.
J'ai cherché justement après avoir posté ça, apparament ça n'a
pas été mergé, mais il y avait un début de code. J'espère
juste simplement qu'ils vont ajouter cette fonctionnalité
(parce que c'est une bonne idée) mais qu'ils vont se baser sur
l'existant, notament kmscon.
Visiblement, c'est le dev de ksmcon qui a proposé systemd-consoled, mais j'imagine qu'il fait du NIH sans le vouloir :)
Je pense que DHCP est un bon exemple, mais si ça te suffit
pas, il y aussi timesyncd
DHCP est pas le meilleur exemple de NIH. Timesyncd est déjà mieux. Ensuite, le client que tout le monde utilise ou presque, c'est celui de l'ISC. Pareil pour ntpd. Je dit pas qu'il y a un lien mais bon, peut être qu'il y a une piste.
Mais après avoir vu le code, il semble que timesync fasse juste du sntp client ( tu va pas loin avec 1200 lignes de code ), et pas la totale comme ntpd qui peut faire serveur, qui a un algo bien spécifique pour gérer les cas particuliers et le drift, etc.
( et tout comme dhcp, y a pas de lib existant qui vont permettre l'usage du code de ntpd, donc tu doit refaire tout ).
En fait, y a pas de lib dhcp. Je sais qu'il y a des discussions en cours entre les gens de connman chez intel et des gens qui bossent sur systemd pour justement avoir une lib.
Mais la, y a rien que je sache. Et c'est dommage, notamment pour dhcpv6 ou toute les options sont pas supportés aussi partout.
Les grosses icones, c'est aussi pour les souris (car les gens qui n'ont pas l'habitude d'une souris ont parfois du mal, et j'invite les gens à filer une souris à quelqu'un qui n'a jamais touché le mulot pour voir), et pour avoir des choses visuellement plus jolis.
Et il y a aussi le fait d'avoir une interface qui se rapproche des tablettes car c'est par la qu'on estime que les gens vont commencer leur apprentissage de l'informatique de nos jours. Donc en ayant un paradigme pas trop éloigné, on estime que la courbe d'apprentissage sera moins abrupte.
Pour faire vraiment du tactile, il faudrait plus de choses à tout les niveaux, comme un clavier tactile (notamment pour déverrouiller). Il faut des applications adaptées et les drivers d'écrans tactiles, sans doute une applet de calibration.
Et bon, on peut dire ce qu'on veut, je doute qu'un mode de recherche au clavier (comme l'overview de gnome shell) soit très tablette friendly, donc je pense qu'il faudrait changer ça aussi. Et sans doute agrandir le menu et la barre du haut, à vue de nez. j'imagine qu'un vrai test sur une tablette donnerais plein de trucs à corriger.
Il se retire aussi avec esc ou quand tu commence à taper le mot de passe. Et le fait de ne pas se retirer quand tu touches la souris, c'est pour pouvoir mettre un widget (genre dans mon souvenir, tu peux couper la musique directement sur le screensaver).
Je pense qu'il y a aussi des idées pour un déverrouillage par pin code (https://wiki.gnome.org/Design/OS/ScreenLock/PinAuthentication) mais pour le moment, personne ne bosse dessus (ou il y a des soucis compliqués à résoudre). L'idée serait je pense un jour d'avoir un truc pour tablette ou écran tactile. Mais c'est pas encore ça.
Même si je suis utilisateur de DWM, je trouve dommage que ça
bash autant pour rien sur KDE/GNOME, pour ne citer qu'eux. Je ne
comprends pas pourquoi autant de gens sont contre le moindre
changement.
Je ne pense pas que ces gens soient contre le changement d'une manière absolu. Mais j'imagine que ces gens se disent "c'est du libre donc je fait ce que je veux" et retombe de haut quand ils découvrent que leur liberté dépend surtout de tout les autres gens qui font le travail.
C'est l'exemple de KDE4, de Gnome3, de systemd. Tout des choix qui ont apportés des changements visibles, sur des sujets familiers, à un rythme décidé par quelqu'un d'autre.
Et c'est la réalisation que l'indépendance qu'on leur a donné comme allant de paire avec le libre a un prix parfois exorbitant qu'ils n'avaient pas vu qui fait un choc. Que le libre n'est pas une démocratie, que les dirigeants sont totalement sourds à leur demande, et qu'au final, ils ne sont rien dans une hiérarchie qui soudain se dessine. Et donc, que râler et partir sont les seuls choses qu'ils peuvent faire dans leur majorité.
Partir, ça arrive toujours. Râler de façon récurrente et longue, par contre, je trouve que ça fascinant. Par exemple, sur slashdot, y a un mec qui poste dans toute les dépêches en lien avec RHEL pour dire qu'il a déployé pacemaker en 6.3 et qu'il a été retiré ensuite, donc que RH l'a trahi. Et y a toujours 3 personnes qui vont lui dire "c'était marqué comme technology preview, c’était donc possible et non couvert par un support longue durée". Malgré ça, le mec reste sur sa position, car il n'arrive pas à se remettre en cause.
Je pense que tu n'as pas saisis mon point de vue qui est :
en effet. En parti parce qu'il se base sur pas grand chose, et en partie parce que même si j'avais pu lire dans tes pensées, ça ne reste qu'un point de vue.
l'expérience utilisateur gnome 3 est un échec total.
Je connais des gens satisfait, et en proportion, pas mal de gens parmi les utilisateurs de gnome 2 autour de moi. Les KDEistes sont restés sous KDE, etc. Ensuite, je vais pas dire que je connais que des gens satisfaits, mais la présence d'alternative à Gnome 2, à KDE et à d'autres depuis longtemps montrent bien qu'il y a des gens qui veulent autre chose, même avec ce gnome 2 si génial qu'on nous en parle à chaque fois.
Passer de ça à "un echec total", j'ai des doutes (je ne dirait pas "mauvaise foi", car j'ai le sentiment que ça te vexerais comme un pou ). Je m'en sert tout les jours et j'ai pas eu envie de m'arracher les yeux, on me force pas à l'utiliser ni rien.
Livrer gnome 3 avec l'extension classique activée c'est un
rétro pédalage dans les règles de l'art.
Livrer mate serait un rétro pédalage. Ou ne pas supporter le mode non classique serait un rétro pédalage. La, c'est une transition en douceur pour les utilisateurs du desktop RHEL, qui ne sont pas les mêmes utilisateurs que Fedora. Fedora vise les gens qui veulent expérimenter et découvrir les derniers trucs du libres. RHEL vise les gens qui veulent la continuité, et tout comme l'intégration de docker et des scl, tout comme le support des scripts d'init, RHEL vise la migration au rythme des gens.
Mais je suis pas la pour faire la pub de la distro. Je constate juste que dans la mesure ou l'extension classique ne modifie pas les applications, alors on peut aussi dire que pour un truc que tu qualifie de retro pédalage dans les règles de l'art, ça manque de profondeur. L'expérience utilisateur reste quand même profondément changé par les applications. Donc si ton propos est que les changements entre Fedora et RHEL sont un retro pédalage, alors il est simple de déduire que tout ce qui n'a pas changé est une validation pur et simple de tout le travail des designers gnomes, donc de la grande partie de l'expérience utilsiateur, qui va au dela du bureau.
Mais je pense que tu es juste allergique aux changements de gnome-shell pour divers raisons, et que tu cherches à te rassurer sur ton opinion en ralant ici ou sur irc à longueur de temps.
Ce qui est amusant avec les gens qui rale sur un réglage par défaut, c'est que quand RHEL et Fedora font la même chose, c'est la main mise de RH sur Fedora qui est en cause.
Quand c'est le contraire, c'est la main mise de RH qui fait en sorte que les gens qui payent se retrouve avec un réglage par défaut différent.
Si la mauvaise foi était un carburant, on serait déjà sur alpha du centaure depuis 20 ans…
[^] # 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.
[^] # Re: Portabilité et forçage
Posté par Misc (site web personnel) . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 1.
Sauf erreur de ma part, c'est visiblement pas un problème pour la communauté gnome, vu qu'Emily Gonyer n'a pas été élu:
https://vote.gnome.org/results.php?election_id=22
Je doit reconnaitre que je pige pas trop la méthode de comptage, mais je doute qu'on puisse contester que ça n'a pas bousculé vraiment le scrutin.
Oui. parce que c'est libre, c'est pas de l'enfermement. C'est juste des gens qui font pas ce que tu veux mais qui t’empêche pas de faire ce que tu veux. Que la majorité ne te suive pas est une autre paire de manche.
[^] # 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.
Je peux donner des contre exemples. Les nouveaux produits comme the foreman, openshift sont en ruby en rails, ou en go ( geard ), alors que RH promeut java via jboss ( et a du monde sur le jdk, etc ), du monde sur gcc, et fait son propre language par dessus la jvm.
De même, openshift utilise depuis quasiment le début ActiveMQ plutôt que Qpid, qui est pourtant "de la maison". Des esprits chagrins et observateurs vont dire qu'avec le rachat de fusesource, RH a mis le pied dans ActiveMQ, mais la chronologie ne colle pas, car Openshift est antérieur à ce rachat.
Ou le fait d'avoir choisi de mettre en avant docker plutôt que virt-sandbox ou une solution basé sur les lxc et libvirt, pour ne parler que des choses récentes.
[^] # Re: Portabilité et forçage
Posté par Misc (site web personnel) . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 10.
Tu parles de Tom Gundersen, le développeur que Red hat a embauché pour bosser sur networkd, sans doute pour le récompenser d'avoir mis systemd au sein de Arch Linux. Il est fort probable que le but obscure de la manœuvre soit d'infecter la distro qui monte et qui menace la main mise de la société sur le marché des serveurs.
Moi je dit, il faut se méfier de tout le monde, je suis même sur qu'ils sont parmis nous ici à surveiller et à répandre la propagande pour cacher le plan de domination du libre !
(je précise que c'est du sarcasme, pour le cas ou des gens souffriraient du même travers que le docteur Sheldon Cooper.)
[^] # 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.
La version anglaise dit 32, la version française ( qui doit avoir du retard sur ma machine ) dit 16.
Et en fait, c'est dépendant de l'os :
http://community.aegirproject.org/developing/architecture/unix-group-limitations
Donc si on veut faire vraiment portable sur les anciens OS, c'est 8.
Et en effet, si on veut être compatible avec les systèmes à 16:
[^] # Re: Quel joli troll !
Posté par Misc (site web personnel) . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 8.
La réponse est sur le g+ du dev:
https://plus.google.com/+TomGundersen/posts/U6Es8bpmMbP
ie, "l'existant ne nous va pas, mais on a regardé et on va bosser sur une nouvelle lib proposé par quelqu'un d'autre". Donc reprendre le code de connman, c'est pas vraiment du NIH.
Voir aussi https://plus.google.com/+TomGundersen/posts/eztZWbwmxM8
Et les commentaires, surtout la fin, ou il dit avoir regardé les 3 libs et en avoir repris une.
Il explique aussi pourquoi systemd a sa propre lib pour la communication avec le kernel :
https://plus.google.com/+TomGundersen/posts/JhaBNn8Ytwu
( TLPL: les libs sont synchrones et bloquantes, le dev veut de l'asynchrone non bloquant, ça implique de tout refaire dans tout les cas )
[^] # Re: À mon tour
Posté par Misc (site web personnel) . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 6.
L'existant pour quoi ?
Les options de systemd-detect-virt réutilise pas l'existant de ou ?
Ou journalctl devrait reprendre quel options existantes ?
Pour les trucs ou ça a du sens, c'est exactement ce qui est fait. Exemple, /etc/fstab, /etc/hostname, /etc/cryptsetup. Quand il y a rien, ou quand il y a des implémentations divergentes, il faut faire un choix.
On parle de systemd, pas de SMF…
Tu sembles tout d'un coup te réveiller d'un sommeil de 10 à 15 ans. Tu connais beaucoup de gens qui bosse sur gcc sur leur temps libre ? Sur la glibc, le kernel ou Xorg ?
Tu t'es dit que des trucs comme xen ou kvm sont arrivés sans avoir des gens à temps plein dessus ?
[^] # Re: Calcul
Posté par Misc (site web personnel) . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 2.
Pour la liste des gens qui peuvent commiter, suffit de trouver une personne avec un accès à fdo et de dire "qui est dans le groupe qui peux commiter".
Pour savoir qui bosse chez RH, suffit de trouver un mec qui bosse chez RH et de demander.
En effet, demander à Lennart remplit les 2 conditions.
[^] # Re: Quel joli troll !
Posté par Misc (site web personnel) . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 3.
Dans ce cas, systemd le permet, via User=. Encore mieux, via l'activation par socket, tu peux même espérer avoir les softs ne jamais voir l'uid root, dans certains cas spécifiques.
En fait, non seulement systemd permet ça, mais en plus, permet de rajouter facilement la configuration via les drop-in config ( ie, faire un fichier /etc/system/foo.service.d/foo.conf avec juste User=foo et paf, il va faire ce que tu veux, à savoir combiné ton service et celui du distributeur tierce en gérant l'upgrade proprement )
Le NIH, c'est "Not Invented Here". Quand tu refait ton propre code, c'est pas vraiment du NIH, par définition. Est ce que pour toi, NIH veut dire "refaire du code alors que du code existant rempli une partie des besoins", auquel cas, on peut qualifier tout un tas de trucs de NIH…
( ou du moins, je pense que systemd-consoled n'est pas un NIH de ksmcon pour ma définition de NIH, mais c'est juste mon point de vue ). J'imagine qu'on ne mets juste pas la même chose sous le terme NIH.
Personnellement, je leur reprocherais une certaine obscurité et/ou de l'amateurisme. Exemple, le bug tracker de bind qui est une liste de discussion, les VCS des projets sont parfois non publiques et/ou mal documentés ( celui de dhcp me semble assez récent par exemple, bind < 10 n'etait pas existant). L'abandon soudain de bind 10 est un exemple de process interne non discuté en publique, etc, etc.
Donc je pense que la collaboration peut être difficile avec l'ISC, d'ou sans doute le fait que personne ne tente de faire une lib pour le dhcp en partant de dhcpd (encore une fois, l'équipe de connman bosse sur ça)
[^] # Re: Quel joli troll !
Posté par Misc (site web personnel) . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 5.
C'est plus subtile. C'est dans le pid 1 pour les fichiers de root, et dans le pid du gestionnaire de session pour les fichiers accessibles par l'utilisateur ( ie, sous l'uid de l'utilisateur ). Donc je pense que si tu peux écrire le fichier, alors c'est déjà trop tard, pas besoin d'exploiter une erreur dans le parser. Non pas que ça veuille dire "on s'en fout de la sécurité", mais que le fait de faire l'analyse du fichier dans un process à part avec un canal de communication avec le pid 1 est une complication qui n'a pas jugé valoir la chandelle pour le moment. Une des choses que j'ai trouvé complexe dans le code d'upstart est justement ça, l'overhead lié à la communication interprocessus, avec les problématiques de synchronisation, etc, etc. Peut être que ça arriveras plus tard, mais je pense que c'est plus important pour un browser que systemd.
C'est le lien que tu cherches, je pense :
http://lists.freedesktop.org/archives/systemd-devel/2013-November/014808.html
Visiblement, c'est le dev de ksmcon qui a proposé systemd-consoled, mais j'imagine qu'il fait du NIH sans le vouloir :)
DHCP est pas le meilleur exemple de NIH. Timesyncd est déjà mieux. Ensuite, le client que tout le monde utilise ou presque, c'est celui de l'ISC. Pareil pour ntpd. Je dit pas qu'il y a un lien mais bon, peut être qu'il y a une piste.
Mais après avoir vu le code, il semble que timesync fasse juste du sntp client ( tu va pas loin avec 1200 lignes de code ), et pas la totale comme ntpd qui peut faire serveur, qui a un algo bien spécifique pour gérer les cas particuliers et le drift, etc.
( et tout comme dhcp, y a pas de lib existant qui vont permettre l'usage du code de ntpd, donc tu doit refaire tout ).
[^] # Re: Gnome 3
Posté par Misc (site web personnel) . En réponse à la dépêche Red Hat Enterprise Linux 7. Évalué à 3.
Certes, pour les contacts ( je pense que tu parles de ça ), mais ça ne parait pas être le paradigme premier d'usage.
En tout cas, pas sur mon vieux android ou mon nokia.
[^] # Re: Quel joli troll !
Posté par Misc (site web personnel) . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 6.
En fait, y a pas de lib dhcp. Je sais qu'il y a des discussions en cours entre les gens de connman chez intel et des gens qui bossent sur systemd pour justement avoir une lib.
Mais la, y a rien que je sache. Et c'est dommage, notamment pour dhcpv6 ou toute les options sont pas supportés aussi partout.
[^] # Re: xfs ?
Posté par Misc (site web personnel) . En réponse à la dépêche Red Hat Enterprise Linux 7. Évalué à 2.
J'aurais pensé que l'usage du cloud ( enfin tu veux dire IaaS ), c'est de crasher ta VM car elle est éphémère ?
[^] # Re: Gnome 3
Posté par Misc (site web personnel) . En réponse à la dépêche Red Hat Enterprise Linux 7. Évalué à 3.
Les grosses icones, c'est aussi pour les souris (car les gens qui n'ont pas l'habitude d'une souris ont parfois du mal, et j'invite les gens à filer une souris à quelqu'un qui n'a jamais touché le mulot pour voir), et pour avoir des choses visuellement plus jolis.
Et il y a aussi le fait d'avoir une interface qui se rapproche des tablettes car c'est par la qu'on estime que les gens vont commencer leur apprentissage de l'informatique de nos jours. Donc en ayant un paradigme pas trop éloigné, on estime que la courbe d'apprentissage sera moins abrupte.
Pour faire vraiment du tactile, il faudrait plus de choses à tout les niveaux, comme un clavier tactile (notamment pour déverrouiller). Il faut des applications adaptées et les drivers d'écrans tactiles, sans doute une applet de calibration.
Et bon, on peut dire ce qu'on veut, je doute qu'un mode de recherche au clavier (comme l'overview de gnome shell) soit très tablette friendly, donc je pense qu'il faudrait changer ça aussi. Et sans doute agrandir le menu et la barre du haut, à vue de nez. j'imagine qu'un vrai test sur une tablette donnerais plein de trucs à corriger.
[^] # Re: Gnome 3
Posté par Misc (site web personnel) . En réponse à la dépêche Red Hat Enterprise Linux 7. Évalué à 2.
Il se retire aussi avec esc ou quand tu commence à taper le mot de passe. Et le fait de ne pas se retirer quand tu touches la souris, c'est pour pouvoir mettre un widget (genre dans mon souvenir, tu peux couper la musique directement sur le screensaver).
Je pense qu'il y a aussi des idées pour un déverrouillage par pin code (https://wiki.gnome.org/Design/OS/ScreenLock/PinAuthentication) mais pour le moment, personne ne bosse dessus (ou il y a des soucis compliqués à résoudre). L'idée serait je pense un jour d'avoir un truc pour tablette ou écran tactile. Mais c'est pas encore ça.
[^] # Re: xfs ?
Posté par Misc (site web personnel) . En réponse à la dépêche Red Hat Enterprise Linux 7. Évalué à 3.
Surtout si tu vises les volumes de données que tu va avoir dans 10 ans avec le code d'aujourd'hui, au vue de la durée de vie de la distribution.
[^] # Re: Gnome 3
Posté par Misc (site web personnel) . En réponse à la dépêche Red Hat Enterprise Linux 7. Évalué à 10.
Je ne pense pas que ces gens soient contre le changement d'une manière absolu. Mais j'imagine que ces gens se disent "c'est du libre donc je fait ce que je veux" et retombe de haut quand ils découvrent que leur liberté dépend surtout de tout les autres gens qui font le travail.
C'est l'exemple de KDE4, de Gnome3, de systemd. Tout des choix qui ont apportés des changements visibles, sur des sujets familiers, à un rythme décidé par quelqu'un d'autre.
Et c'est la réalisation que l'indépendance qu'on leur a donné comme allant de paire avec le libre a un prix parfois exorbitant qu'ils n'avaient pas vu qui fait un choc. Que le libre n'est pas une démocratie, que les dirigeants sont totalement sourds à leur demande, et qu'au final, ils ne sont rien dans une hiérarchie qui soudain se dessine. Et donc, que râler et partir sont les seuls choses qu'ils peuvent faire dans leur majorité.
Partir, ça arrive toujours. Râler de façon récurrente et longue, par contre, je trouve que ça fascinant. Par exemple, sur slashdot, y a un mec qui poste dans toute les dépêches en lien avec RHEL pour dire qu'il a déployé pacemaker en 6.3 et qu'il a été retiré ensuite, donc que RH l'a trahi. Et y a toujours 3 personnes qui vont lui dire "c'était marqué comme technology preview, c’était donc possible et non couvert par un support longue durée". Malgré ça, le mec reste sur sa position, car il n'arrive pas à se remettre en cause.
[^] # Re: Xen
Posté par Misc (site web personnel) . En réponse à la dépêche Red Hat Enterprise Linux 7. Évalué à 2.
Non supporté, sauf erreur de ma part.
Mais le projet Centos a un sous groupe visant à intégrer xen dans Centos, donc à terme, ça serait une solution.
[^] # Re: Gnome 3
Posté par Misc (site web personnel) . En réponse à la dépêche Red Hat Enterprise Linux 7. Évalué à 5.
en effet. En parti parce qu'il se base sur pas grand chose, et en partie parce que même si j'avais pu lire dans tes pensées, ça ne reste qu'un point de vue.
Je connais des gens satisfait, et en proportion, pas mal de gens parmi les utilisateurs de gnome 2 autour de moi. Les KDEistes sont restés sous KDE, etc. Ensuite, je vais pas dire que je connais que des gens satisfaits, mais la présence d'alternative à Gnome 2, à KDE et à d'autres depuis longtemps montrent bien qu'il y a des gens qui veulent autre chose, même avec ce gnome 2 si génial qu'on nous en parle à chaque fois.
Passer de ça à "un echec total", j'ai des doutes (je ne dirait pas "mauvaise foi", car j'ai le sentiment que ça te vexerais comme un pou ). Je m'en sert tout les jours et j'ai pas eu envie de m'arracher les yeux, on me force pas à l'utiliser ni rien.
Livrer mate serait un rétro pédalage. Ou ne pas supporter le mode non classique serait un rétro pédalage. La, c'est une transition en douceur pour les utilisateurs du desktop RHEL, qui ne sont pas les mêmes utilisateurs que Fedora. Fedora vise les gens qui veulent expérimenter et découvrir les derniers trucs du libres. RHEL vise les gens qui veulent la continuité, et tout comme l'intégration de docker et des scl, tout comme le support des scripts d'init, RHEL vise la migration au rythme des gens.
Mais je suis pas la pour faire la pub de la distro. Je constate juste que dans la mesure ou l'extension classique ne modifie pas les applications, alors on peut aussi dire que pour un truc que tu qualifie de retro pédalage dans les règles de l'art, ça manque de profondeur. L'expérience utilisateur reste quand même profondément changé par les applications. Donc si ton propos est que les changements entre Fedora et RHEL sont un retro pédalage, alors il est simple de déduire que tout ce qui n'a pas changé est une validation pur et simple de tout le travail des designers gnomes, donc de la grande partie de l'expérience utilsiateur, qui va au dela du bureau.
Mais je pense que tu es juste allergique aux changements de gnome-shell pour divers raisons, et que tu cherches à te rassurer sur ton opinion en ralant ici ou sur irc à longueur de temps.
[^] # Re: Gnome 3
Posté par Misc (site web personnel) . En réponse à la dépêche Red Hat Enterprise Linux 7. Évalué à 10.
Ce qui est amusant avec les gens qui rale sur un réglage par défaut, c'est que quand RHEL et Fedora font la même chose, c'est la main mise de RH sur Fedora qui est en cause.
Quand c'est le contraire, c'est la main mise de RH qui fait en sorte que les gens qui payent se retrouve avec un réglage par défaut différent.
Si la mauvaise foi était un carburant, on serait déjà sur alpha du centaure depuis 20 ans…