udev, le gestionnaire de périphériques dans /dev vient d’être forké. C’est grâce à cet outil que l’on peut, par exemple, monter automatiquement des disques externes ou des clés USB, et les afficher dans un explorateur. En effet, udev reçoit des messages de la part du noyau et les traite en fonction d’un ensemble de règles définies dans les répertoires rules.d. Ainsi, il est possible de lancer des sauvegardes dès que le disque dur correspondant est branché sur la machine.
Au mois d’avril, les sources de udev ont été déplacé dans l’arborescence de systemd. Le but est de forcer l’utilisation de systemd pour pouvoir utiliser udev, illustré par la célèbre citation de Lennart :
Yes, udev on non-systemd systems is in our eyes a dead end, in case you
haven't noticed it yet. I am looking forward to the day when we can drop
that support entirely.
Que l’on peut approximativement traduire par : « Oui, udev sur les systèmes non-systemd est à nos yeux un cul de sac, au cas ou vous n’auriez pas encore remarqué. J’attends avec impatience le jour où nous pourrons entièrement laisser tomber ce support. » Cette phrase a lancé tout un tas de commentaires, par exemple sur reddit. Lennart, son caractère, et son rêve, GNU/Lennax, étant probablement encore moins appréciés qu’Ulrich Drepper (tous passés par Red Hat).
L’incorporation d’udev dans systemd est assez contraignante puisqu’il faut non seulement télécharger tout le paquet systemd, mais aussi appliquer des patchs, par exemple ceux de Linux From Scratch, pour avoir un système cohérent. Le nouveau fork permet de résoudre ces problèmes, par exemple sous Gentoo.
Le plus gros problème, d’un point de vue idéologique, étant systemd. En effet il s’agit d’un gros logiciel (plusieurs dizaines de milliers de lignes de code) incorporant tout un tas de fonctionnalités, avec des dépendances largement discutables pour un système d’initialisation (notamment D-BUS), tout en étant entièrement spécifique à Linux. Si vous avez perdu votre temps à apprendre les scripts shells, vous pouvez tout remballer pour apprendre la nouvelle syntaxe pour systemd. Là aussi, devant le passage en force que font certains développeur pour passer à systemd, notamment sous ArchLinux (un comble étant donné que rc.conf était l’une de ses grandes forces), différents forks sont à attendre.
# la guerre de s unices
Posté par coïn . Évalué à 10.
apres la guerre des unices qui a tuer les unix proprio (et a laissé l opportunité d`expansion à Linux) voici la guerre fratricide des linux
hallucinant
[^] # Re: la guerre de s unices
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Bof. Ça va vite tourner à la guerre de Lennart contre le reste du monde. Il l'a un peu cherché en même temps.
[^] # Re: la guerre de s unices
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 6.
Pas sûr. Pour ma part, je trouve son travail plutôt pas mal. L'init sysV actuel est quand même bien pourri.
Et si le script shell finit par mourir, c'est pas moi qui me plaindrais :) On a fait largement mieux depuis comme langage.
[^] # Re: la guerre de s unices
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Moi aussi je trouve ça pas mal dans l'idée, mais ce mec est un troll-né… Coder volontairement pour Linux seulement, et envoyer chier les autres comme des malpropres…
[^] # Re: la guerre de s unices
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 5.
Est-ce qu'il a déjà refusé des patchs qui apportaient la portabilité vers d'autres noyaux ? (c'est une vraie question)
[^] # Re: la guerre de s unices
Posté par neil . Évalué à 10. Dernière modification le 04 septembre 2012 à 20:30.
Lennart a annoncé qu’il refuserait les patchs pour d’autres systèmes (il n’aime pas les
#ifdef), et que c’est aux autres systèmes à proposer une émulation de Linux pour que systemd tourne dessus.[^] # Re: la guerre de s unices
Posté par Didier (site web personnel) . Évalué à 4.
.. ou de maintenir un fork avec lesdits patches. C'est exactement ce qui est fait pour OpenSSH. La version pour Linux est annotée "p" (pour portable), ce n'est pas directement celle de OpenBSD.
[^] # Re: la guerre de s unices
Posté par Mr Kapouik (site web personnel) . Évalué à 10.
Pour rappel la version portable de OpenSSH est maintenu par l'équipe de OpenSSH. C'est une volonté de leur part de faire un logiciel pour OpenBSD puis de le rendre portable partout ce qui fait que les sources sont légèrement différente.
Lennart ne maintient pas deux branches à ce que je sache ?
[^] # Re: la guerre de s unices
Posté par Sufflope (site web personnel) . Évalué à -9.
Et ? C'est libre, crée systemdp.
[^] # Re: la guerre de s unices
Posté par rakoo (site web personnel) . Évalué à 10.
Sa position, si je la résume, m'a l'air de tout à fait tenir :
"Si vous voulez rendre systemd compatible avec d'autres noyaux, ça va créer un machin horrible à maintenir, je ne veux pas le faire. Mais quiconque veut le faire peut"
Autrement dit : le systemd de Lennart ne sera pas compatible avec autre chose que Linux, mais rien n'empêche JohnDoe de créer JDsystemd qui sera compatible avec tous les noyaux, et qui peut même être accepté partout.
C'est incroyable ça. Le type fait le logiciel comme il l'entend, il le rend dispo à tout le monde, mais on trouve le moyen de se plaindre de lui parce qu'il ne veut pas bosser à l'oeil pour son propre noyau.
Bon sang, systemd est même sous LGPL, qui contient quand même ce bout en ALL CAPS :
Si ça ne fait pas ce que tu veux, dommage pour toi, Lennart et les contributeurs ne te doivent rien. Forke donc !
[^] # Le thread dont vous éte le Mollah
Posté par Tonton Benoit . Évalué à 10. Dernière modification le 04 septembre 2012 à 23:29.
C'est exactement ça, quand le créateur de GCompris a exposé les différentes demandes plus ou moins folles de communautés tout le monde a dit qu'il doit faire ce qu'il veut, que c'est son travail et que c'est déjà gentil de le mettre à la disposition de tous, ce qui ne sont pas contents n'ont qu'a forker…
Et là on retrouve les mêmes, sauf que cette fois ça c'est eux la communauté chiante, le libre c'est leur science et il savent mieux que Lennard ce qu'il doit développer.
[^] # Re: Le thread dont vous éte le Mollah
Posté par etenil . Évalué à 10.
Si c'était Lennart le problème, tout le monde s'en cognerait.
Le problème avant tout c'est la volonté de l'imposer partout via des astuces comme l'intégration d'udev citée dans ce journal, et que les distributions commencent à suivre le mouvement.
Systemd n'a pas vraiment fait ses preuves et a des avantages pratiques peu tangibles par rapports aux autres systèmes d'init. Par contre il permet d'isoler complètement une partie de l'userland GNU/Linux et aliéner le reste des systèmes d'exploitations libres, et ça s'est dangereux.
[^] # Re: Le thread dont vous éte le Mollah
Posté par Adrien . Évalué à 10.
Plusieurs trucs me pose problème dans ta phrase :
– la volonté de l'imposer : à mon avis, si les distributions commence à fournir systemd, c'est qu'il y a des raisons techniques. Il me semble plutôt « choisit » que « imposer ».
– astuces comme l'intégration d'udev : encore une fois, il me semble que les développeurs d'udev ne sont pas contre cette inclusion… ce n'est donc peut⁻être pas une astuce pour l'imposer, mais une astuce pour facilité la maintenance…
Plutôt que de troller sans fin, il nous faudrait donc des preuves fortes comme quoi ces choix ne sont pas fait sur des critères techniques, mais grâce à des stratagèmes indignes de Lennart (payer des putes aux dev, menacer leurs familles de représailles, etc.).
Quand à l'argument inverse, je me base sur ceux qui font – les développeurs, mainteneurs de distributions – et qui font confiance à systemd, pour me dire que le choix a été fait suivant des contraintes techniques et non suivant des contraintes politiques.
[^] # Re: Le thread dont vous éte le Mollah
Posté par liberforce (site web personnel) . Évalué à 10.
Il n'essaie pas d'imposer Linux. Ce qu'il veut, c'est pouvoir tirer parti de fonctionnalités performantes, qui sont parfois spécifiques à Linux. Or, si tu dois faire un système qui est compatible avec tout le monde, tu dois te limiter au plus petit dénominateur commun. Tu perds donc soit en fonctionnalité, soit en vitesse. Mais le but même du bazar c'est d'être le plus rapide possible ! Pour faire un boulot efficace, il faut donc une version spécifique à chaque OS, et il ne veut pas s'amuser à les développer et les maintenir lui même, ce qui peut se comprendre.
[^] # Re: Le thread dont vous éte le Mollah
Posté par Jux (site web personnel) . Évalué à 10.
Bon ok stop. Je te laisse lire un des post de base de Lennart :
http://0pointer.de/blog/projects/systemd.html
Ainsi que (cité dans un commentaire plus bas), celui d'un dev ArchLinux (qu'on peut pas vraiment accuser d'être à la solde de RedHat):
https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530
Les gros avantages tournent autour du fait que le design est plus adapté au monde moderne : Contrairement à init standard, systemd considère que tout peut être hotpluggé (pas besoin d'attendre que tout soit monté avant de fsck). Il permet de starter les services en parallèle sans utiliser de hacks comme c'est le cas actuellement. Il permet d'avoir un journal centralisé du stdout/stderr de tous les processus et de facilement trouver ce qu'un processus a loggé (via des metadata). J'en passe et des meilleurs.
Donc maintenant, si quelqu'un d'autre que Lennart propose des réponses (avec du code qui marche, pas au café du commerce) à ces problèmes, y'a probablement plein de distribs qui seront content de proposer l'alternative. Mais voilà, y'a personne qui ne le fait.
[^] # Re: Le thread dont vous éte le Mollah
Posté par gnumdk (site web personnel) . Évalué à 1.
J'aime bien cette partie qui fout à la poubelle les arguments de anti systemd qui pense qu'ils pourront plus contrôler leur système après alors que c'est tout l'inverse…
[^] # Re: Le thread dont vous éte le Mollah
Posté par Batchyx . Évalué à 6.
Ah c'est modulaire ? Comment on enlève D-Bus de ce machin ? Et comment on enlève sa gestion des cgroups si j'ai pas envie d'activer cette option dans mon noyau ?
Quand on compare ça à un inittab ou on peut remplacer /etc/init.d/rc par ce que je veux, y compris par un machin utilisé par trois pélerin, ou un machin custom qui utilise des cgroups, c'est plutôt systemd le binaire monolithique.
Ah, on peut ne pas utiliser le machin systemd qui monte les partoches ? Ah on pouvait pas le faire avant avec sysvinit ? C'est bizarre ça, je me souviens l'avoir fait pourtant…
Pareil sur l'argument sur les dépendances: d'une part il y a les entêtes LSB (et insserv, qui est tout sauf un hack), et l'argument sur les changements à maintenir est aussi valable pour un systemd custom.
[^] # Re: Le thread dont vous éte le Mollah
Posté par gnumdk (site web personnel) . Évalué à 3. Dernière modification le 05 septembre 2012 à 14:12.
Tu rajoutes init=/bin/ton_init.sh dans les paramètres de ton noyau et cela fera ce que tu veux… Si t'as pas envie de dbus, je vois pas pourquoi t'aurais envie de udev donc y'a pas de problème… Ton Linux fonctionnera comme tu le veux.
[^] # Re: Le thread dont vous éte le Mollah
Posté par Joris Dedieu (site web personnel) . Évalué à 6.
Tu peux détailler s'il te plais ? A ce que je sache udev sert à créer les devices ce qui ne nécessite aucunement dbus.
[^] # Re: Le thread dont vous éte le Mollah
Posté par gnumdk (site web personnel) . Évalué à 3.
Je précise que c'est une techno linux only qui n'est pas obligatoire pour démarrer comme dbus… Pourtant systemd dépend aussi de udev et cela n'a pas l'air de gener ;)
[^] # Re: Le thread dont vous éte le Mollah
Posté par Etienne Bagnoud (site web personnel) . Évalué à 10.
Et s'il n'y avait pas de questions ? Et si la raison d'être opposé à systemd est que le init traditionnel est la meilleure réponse à la problématique du démarrage ?
L'init sys V apporte toutes les réponses nécessaire à la majorité des cas, systemd est une optimisation pour un nombre de cas restraints : les serveurs n'ont pas besoin de systemd (les quelques secondes de gagnées ne valent pas la simplicité de corriger le démarrage s'il y a un problème), les portables et les ordinateurs de bureaux entrent et sortent de veille (ils démarrent une fois chaque mois), donc pas besoin de systemd.
Demander des changements aussi profonds aux systèmes pour un concept presque révolu, le démarrage, c'est la mauvaise réponse aux questions : comment améliorer la veille prolongée et comment faire que l'ordinateur passe par la séquence de démarrage que lors de la première utilisation ?
On ne doit pas améliorer le démarrage, on doit fournir :
Si on arrive à ça, l'informatique aura avancé de manière très significative. Et on s'y approche, mon ordinateur de tous les jours démarrent une fois chaque deux mois mais c'est pas encore parfait.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Le thread dont vous éte le Mollah
Posté par barmic . Évalué à 5.
Tu pars très mal avec ça. Dire qu'initsysv est une bonne solution, je comprends la meilleure ça me semble présomptueux. Il y a toujours possibilité d'améliorer un logiciel, ce serait bien triste sinon. Note que je ne dis pas que systemd est meilleur (j'en sais rien) juste qu'en informatique je n'ai pas encore trouvé de logiciel qui implémente « la meilleure solution » à un problème quelque soit ce problème.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Le thread dont vous éte le Mollah
Posté par Etienne Bagnoud (site web personnel) . Évalué à 8.
Je ne dis pas que c'est la meilleure ou la moins bonne, je dis que ça pourrait être la meilleure solution. Qui sait, dans une infinité d'années, l'humanité, après avoir expérimenté, testé, mesuré une infinité de solutions pour le démarrage pourrait juger que l'init sys v, dans l'absolu, est la meilleure solution.
Là seule chose que je sais, c'est que systemd est un code n'ayant que deux ans et quand je vois, dans le code, autant de
goto, de dizaine dereturnpar fonction et de pointeurs non-initialisés à NULL, je me dis que systemd n'est pas prêt pour être en production."It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Le thread dont vous éte le Mollah
Posté par Batchyx . Évalué à 5.
Ça ne veut pas dire grand chose sur la qualité du code. Il faudrai plutôt mesurer le bloat, la factorisation, la gestion des erreurs et le nombre d'erreurs que sort un analyseur de code statique ou dynamique.
[^] # Re: Le thread dont vous éte le Mollah
Posté par gnumdk (site web personnel) . Évalué à 5.
Comme dans le noyau Linux
Comme dans le noyau Linux
Mwai, ca ce discute, mais bon, quand tu fais:
Ca n'a absolument aucun intérêt de l'initialisé à 0 quand tu fais l'init 3 lignes plus bas…
Mais bon, après, tout ce que tu dis, c'est ce qu'on m'a appris à l'école mais c'est un peu la guerre de clocher entre les devs system et les devs objets.
[^] # Re: Le thread dont vous éte le Mollah
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Surtout que linux fait la guerre aux initialisations à zéro qui prennent au final une place dingue dans le binaire finale.
"La première sécurité est la liberté"
[^] # Re: Le thread dont vous éte le Mollah
Posté par claudex . Évalué à 4.
Ça ne peut pas être optmisé par le compilateur ce genre de truc ? Genre si une assignation n'est lue dans aucun chemin d'exécution, on la vire.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Le thread dont vous éte le Mollah
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Le compilo ne peut pas forcément le voir à tout les coups.
"La première sécurité est la liberté"
[^] # Re: Le thread dont vous éte le Mollah
Posté par claudex . Évalué à 4.
Qu'il y ait quelques cas, je veux bien croire mais que ça « prennent au final une place dingue dans le binaire finale » même avec des optimisations d'un compilateur, j'aimerais comprendre.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Le thread dont vous éte le Mollah
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
J'avais lu un article sur le sujet il y a bien longtemps sur kernelnewbies ou lwn, mais impossible de remettre la main dessus.
J'imagine qu'ils incluent aussi les mise à zéro des structures allouées sur le tas, donc à travers de pointeur et donc les compilos ne font rien.
"La première sécurité est la liberté"
[^] # Re: Le thread dont vous éte le Mollah
Posté par Batchyx . Évalué à 2.
Est ce que c'est vraiment une histoire de place dans le binaire ou le fait que ça soit plus facile pour un analyseur statique de détecter des mauvais chemins ou on utilise une variable sans qu'elle soit initialisée à une valeur qui à du sens ?
[^] # Re: Le thread dont vous éte le Mollah
Posté par Misc (site web personnel) . Évalué à 6.
Soit on fait les init à zero et ça rale "le binaire est trop gros et bloated".
Soit on le fait pas, et on rale "le binaire est mal écrit".
Du coup, y a vraiment l'impression qu'écrire en C, c'est jamais possible de faire du code qui soit vu comme beau par les codeurs C.
[^] # Re: Le thread dont vous éte le Mollah
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Disons qu'il y a beaucoup de règles "à la con". L'initialisation à zéro permet de masquer des erreurs en injectant une valeur qui peut être bonne (à la limite je préfère 0xFFFFFFFF pour un entier). Je pense que l'on voulait parler de l'initialisation à null des pointeurs pour qu'un déférencement introduise directement une erreur de protection mémoire.
J'imagine aussi que ce genre de règle devienne obsolète avec le temps, quand les compilateurs sont capables de détecter l'usage de variable non initialisé.
"La première sécurité est la liberté"
[^] # Re: Le thread dont vous éte le Mollah
Posté par gnumdk (site web personnel) . Évalué à 4.
C'est vrai que le reprise d'un service sans coupure en cas de segfault d'un service, c'est pas du tout intéressant…
T'en connais beaucoup des gens toi qui n'éteignent pas leur pc et même leur portable ?
[^] # Re: Le thread dont vous éte le Mollah
Posté par Etienne Bagnoud (site web personnel) . Évalué à 9.
Non, pas sans savoir pourquoi et comme le service est redondant, il n'y a pas de problèmes pour les utilisateurs.
Quand un truc s'arrête brutalement, je veux savoir pourquoi avant de le redémarrer (ne serait-ce que pour m'assurer qu'il ne va pas se comporter sauvagement quand il est redémarré).
Les utilisateurs Apple parce que la veille disque et RAM fonctionne à merveille. Moi parce que j'ai passé deux heures à bidouiller mon système pour que ça fonctionne presque à merveille.
Et pour les utilisateurs Windows, de plus en plus.
Par contre, les utilisateurs Linux sont toujours à éteindre/allumer leur machine parce que s'ils mettent en veille, et bien c'est plus long : le réveil met du temps avant de planter et devoir, finalement, redémarrer brutalement la machine.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Le thread dont vous éte le Mollah
Posté par gnumdk (site web personnel) . Évalué à -4.
Tu travailles dans une MJC, c'est ça ?
De plus, si vraiment t'as un service non critique, ben tu dis à systemd de pas le redémarrer automatiquement.
[^] # Re: Le thread dont vous éte le Mollah
Posté par Etienne Bagnoud (site web personnel) . Évalué à 7.
C'est quoi ça ?
Ou plutôt je surveille que les services critiques nécessitant un redémarrage immédiat avec un outil qui ne fait que ça et qui le fait bien.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Le thread dont vous éte le Mollah
Posté par nud . Évalué à 7.
Sauf que systemd est idéalement placé pour se rendre compte que le service disparaît au moment où il disparaît. Idem s'il bloque. Il reçoit le sigchld, il contrôle le socket, bref, il est où il faut pour ça.
Les services externes de monitoring (mon, monit, god et consorts) ne font que du polling, donc si tu vérifies tes services une fois toutes les 5 minutes tu cours le risque de rester avec un service down pendant 4:59 au pire des cas. Systemd peut réagir immédiatement.
J'attends la sortie de wheezy justement pour pouvoir utiliser systemd sur des serveurs, justement pour avoir cette surveillance qui fonctionne bien mieux avec systemd qu'avec mon.
[^] # Re: Le thread dont vous éte le Mollah
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 7.
Un service qui ne répond plus, ou trop lentement, ça ne veut pas forcément dire que le démon associé est mort. systemd ne dispensera pas de la surveillance.
[^] # Re: Le thread dont vous éte le Mollah
Posté par ashgan . Évalué à 2.
le problème du temps de démarrage reste quand même présent, et c'est sympa de voir des gens qui s'en préoccupent au moins un minimum.
je sais pas vous, mais je suis en dualboot sur mon laptop essentiellement à cause de matériel non supporté sous linux et qui me sont nécessaire au boulot.
mettre en veille le pc (unix ou windows, hein) c'est pas top: faudrait déjà que ça marche avec unix. sous windows, c'est pas mal supporté.
ceci dit, mon portable mets presque le même temps pour démarrer à froid que pour revenir dans un état fonctionnel depuis une veille sur disque.
ensuite, quand tu veux monter tes partitions sur l'autre système histoire de passer des fichiers d'un système à l'autre: oups: filesystem non libéré, tu ne peux pas. obligé de passer par un reboot pur et simple.
et NON, la clé USB ou le disque externe n'est pas la pour palier à ce défaut.
enfin, je ne parles pas des mises a jour qui vont de facto te demander un reboot.
je vais pas rentrer dans le débat pour savoir si telle ou telle vision est la meilleure, mais en caricaturant exprès: pitié, c'est pas parce que vous êtes 4 avec des macbooks uniquement en veille prolongée que personne ne démarre jamais son ordi.
[^] # Re: Le thread dont vous éte le Mollah
Posté par Misc (site web personnel) . Évalué à 2.
Je sais pas pour toi, mais moi, sur mes serveurs, pouvoir avoir un /tmp séparé par service ( directive privateTmp de systemd ), pouvoir retirer le réseau d'un daemon ( PrivateNetwork ), mettre une partie du FS en readonly voir le faire disparaitre , bref tout ce qui est mis ici : http://0pointer.de/blog/projects/security.html et le faire facilement avec 1 ligne, ça me parait pas mal. Libre à toi de croire ensuite que ton serveur ne va pas en tirer un bénéfice. résumer systemd a "ça boute plus vite", c'est faire preuve d'un sacré manque de curiosité.
Sinon :
Y a ksplice. Grande nouvelle, c'est le merdier car tu dois connaitre la version exacte du noyau que tu as pour faire un patch qui va modifier les structures à la volée. Sinon, tu as le hurd qui propose ça via son architecture de micronoyau.
La veille en ram marche parfaitement sur mon portable lenovo, donc le souci est du coté du hardware,
pas du software.
Le suspend hybride existe aussi : http://daniel.hahler.de/use-hybrid-suspend-method-by-default
Ma suggestion est donc de mieux choisir ton matos.
Resize2fs le fait depuis le kernel 2.6.14, sauf erreur de ma part.XFS le fait aussi depuis longtemps. Et lvm permet de retailler les partitions depuis toujours. Grub 2 propose le but sur une machine en lvm pur ( avec raid et chiffrement, etc ). Toutes les distros supportent lvm et ext2 ou plus. Donc faut juste que tu fasses l'installation comme il faut.
Premier lien sur google pour le cpu hotplug :
http://www.cyberciti.biz/faq/debian-rhel-centos-redhat-suse-hotplug-cpu/
Si tu veux tester, il faut par contre du hardware qui le supporte, genre sans doute du hardware virtuel.
Pareil, memory hotplug, supporté par linux depuis des années :
http://www.kernel.org/doc/Documentation/memory-hotplug.txt
Je vais pas énumérer les composants, mais je sais que alsa supporte l'ajour de carte son ( et pulseaudio gére ça aussi dynamiquement, que ça soit un appareil genre apple airport, un écouteur bluetooth ou de l'usb ), qu'on peut rajouter des cartes réseaux de tout type, des periphs d'entrées de tout types, et qu'au final, c'est rarement coté soft que le souci se pose.
Donc si tu as besoin de rajouter des cpus à chaud, je te propose en effet de virtualiser plus. Ou d'acheter du matos qui supporte ( genre les serveurs haut de gammes IBMs s/390 etc )
Process par process, tu as des trucs genre cryopid
Pour l’intégration au kernel, il y a des efforts depuis des années :
http://lwn.net/Articles/478111/
http://lwn.net/Articles/375855/
Dragonfly bsd le propose aussi, d'ailleurs :
http://leaf.dragonflybsd.org/cgi/web-man?command=checkpoint§ion=ANY
Et pour tout un systéme, tu as la migration de vm de qemu/kvm
http://www.linux-kvm.org/page/Migration
Donc installe juste tes machines comme noeud d'un cluster ovirt, archipel ou autre, et tu pourras migrer tes systémes. ( alors oui, y a un overhead mais on peut pas tout avoir )
Globalement, sur toutes les améliorations que tu demandes, toute sauf une sont déjà la. Certaines sont bloqués par d'autres choses genre le matériel ( non existant autre que dans une vm ou sans doute plus cher ) genre l'archi du truc ( le hurd étant pas réputé terrible niveau perf, ksplice étant ultra spécifique à chaque update ).
[^] # Re: Le thread dont vous éte le Mollah
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 7.
Le système d'initialisation utilisé par NetBSD et FreeBSD permet tout ça, simplement, et à base de shell scripts.
[^] # Re: Le thread dont vous éte le Mollah
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 5.
Là, tu prends des risques en tant que BSDiste à venir t'immiscer dans un fil de discussion sur une fonctionnalité typiquement linuxienne !!
Ceci dit, je suis bien d'accord. De plus, les scripts shell qui sont dans /usr/local/etc/rc.d sont finalement assez simple.
Mais le problème n'est pas là !
<ironique>Le boot d'un FreeBSD reste très long et c'est d'ailleurs la raison pour laquelle il n'est pas prêt pour le Desktop</ironique>.
[^] # Re: Le thread dont vous éte le Mollah
Posté par 2PetitsVerres . Évalué à 1.
Je n'ai pas posé la question dans le journal sur GCompris, mais si rien n'a changé, le créateur de GCompris vend une version non libre compilée pour windows de GCompris. Je suppose que c'est une telle version que les différentes communautés voulaient. Donc ils payent probablement pour.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: la guerre de s unices
Posté par Guillaume Knispel . Évalué à 7.
Oui enfin bon, il bosse pour RH.
[^] # Re: la guerre de s unices
Posté par rakoo (site web personnel) . Évalué à 1.
Tiens, j'aimerais savoir: il m'a l'air d'avoir un sacré caractère ce monsieur, donc est-ce que RH lui dit ce qu'il doit coder, ou est-ce qu'il fait plutôt ce qu'il veut (et pense être bon) et est force de proposition chez RH ?
Par exemple, Linus a un contrat avec la Linux Foundation qui dit qu'il a le droit de faire ce qu'il veut. Donc il "bosse" pour eux, mais fait ce qu'il veut.
[^] # Re: la guerre de s unices
Posté par Misc (site web personnel) . Évalué à 3.
Suffit de lui demander, il traine sur irc ( genre, freenode, nick mezcalero ), il a un compte google plus, un email ( voir plusieurs ). tu peux aussi le trouver à des confs IRL genre le FOSDEM.
Ceci dit, aussi loin que je me souvienne, il avait déjà le même caractère quand il était étudiant ( au vue de la page http://0pointer.de/lennart/projects/atitvout/ vu que j'avais ça sur mon portable de l'époque )
[^] # Re: la guerre de s unices
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Est-ce que cela n'aurait pas été plus simple de faire un yanobash (yet an other bash) qui serait simplement plus rapide à l'exécution ?
"La première sécurité est la liberté"
[^] # Re: la guerre de s unices
Posté par Didier (site web personnel) . Évalué à 10.
Déjà fait avec dash. Ça ne résout pas le problème des scripts shell plus ou moins bordéliques et surtout différents sur chaque distribution Linux !
[^] # Re: la guerre de s unices
Posté par Misc (site web personnel) . Évalué à 10.
En même temps, c'est un problème que des gens ne veulent pas voir résolu, car ça impliquerais de collaborer au lieu de bosser dans son coin. Voir même, de renoncer à des trucs.
[^] # Re: la guerre de s unices
Posté par cedric . Évalué à 7.
Non, car le nombre de fork + exec ne diminuerait pas, le nombre de fichiers a acceder sur le systeme reste eleve, chaque unite de demarrage resterait complexe et dependante de la distribution. Au final, le shell restera toujours inefficace face a un programme qui fait toute l'init.
Sans compter que, avec systemd, il est possible d'optimiser beaucoup de chose. On peut, par exemple, arriver a generer un cache compose d'un unique fichier decrivant tout le boot. En terme de performance et d'efficacite, par design, un programme comme systemd a un avantage impossible pour un script shell a atteindre.
[^] # Re: la guerre de s unices
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
D'ailleurs est-ce que les fork/exec ne pourrait pas être plus rapide ?
De plus, l'interpréteur connait une partie des programmes utilisé par le shell et pourrait les "précharger".
"La première sécurité est la liberté"
[^] # Re: la guerre de s unices
Posté par cedric . Évalué à 2.
Difficilement et compare a la vitesse de l'equivalent windows, Linux est deja tres optimise. Le probleme principal, c'est que tu dois faire :
- destruction des anciennes pages
- chargement du nouveau programme
- chargement des dependences
- linkage
- initialisation du programme et des dependences
- execution
- retour du resultat
- nettoyage de la memoire
Forcement, face a juste execution + retour du resultat, tu as zero chance d'y arriver meme avec la meilleur volonte du monde :-) Ensuite systemd amene aussi d'autres amelioration, comme des optimisations entre les differentes taches que tu ne peux pas faire en shell vu que chaque process est isole. Et ainsi de suite.
[^] # Re: la guerre de s unices
Posté par Nicolas Boulay (site web personnel) . Évalué à -3.
Mais la lenteur est effroyable :
La mise en place de wc pourrait être rapide. Le binaire des librairy est partagé en mémoire, pourquoi ne pas faire pareil pour le code des binaires ? On peut imaginer un préchargement dés le lancement de interpréteur de "echo" et "wc", comme le script est linéaire, les mêmes instances pourrait rester en mémoire, seul les données devraient être mises à zéro.
Ou alors, que l’interpréteur intègre un loadeur et utilise les binaires comme des plug-in, pour économiser les fork. Dans un script purement linéaire, cela devrait être la solution la plus rapide.
"La première sécurité est la liberté"
[^] # Re: la guerre de s unices
Posté par Moonz . Évalué à 4.
Tu tournes sur un 286 DX ? Chez moi c’est 10 fois plus rapide que ça, et à la base l’idée que lancer 200 processus aussi simples que wc (echo est un built-in normalement) prenne plus d’une seconde est absolument délirant.
[^] # Re: la guerre de s unices
Posté par Alex . Évalué à 3.
Son but étant de montrer le cout d'un fork
tu peux faire le test avec de 1 à 50 wc
ce qui est plus intéressant, c'est que chez moi ce n'est pas tant le temps passé dans le noyau qui coute, mais bien le temps en userland
[^] # Re: la guerre de s unices
Posté par Nicolas Boulay (site web personnel) . Évalué à -4.
sur un cygwin en fait sur un core i5.
"La première sécurité est la liberté"
[^] # Re: la guerre de s unices
Posté par Buf (Mastodon) . Évalué à 9.
Donc pas comparable avec ce que l'on peut obtenir sous Linux.
Avec Cygwin, le fork() est particulièrement lent, parce qu'il faut émuler la sémantique d'un appel Posix qui n'a pas d'équivalent direct en Win32.
[^] # Re: la guerre de s unices
Posté par Michaël (site web personnel) . Évalué à 3.
C'est déjà le cas sur tout OS digne de ce nom, sauf s'il autorise la modification du segment .text de tes programmes, évidemment!
[^] # Re: la guerre de s unices
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Pourquoi je suis en négatif ? Il est interdit de publier un bench pour montrer que le shell est lent ?
"La première sécurité est la liberté"
[^] # Re: la guerre de s unices
Posté par Alex . Évalué à 3.
tu as juste montré que cygwin est lent
[^] # Re: la guerre de s unices
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
C'est pas parce que le test sous linux est plus rapide que cela ne reste pas lent.
Au moment d'écrire le test, je n'avais qu'un cygwin sous la main, mais la lenteur reste pour linux aussi.
"La première sécurité est la liberté"
[^] # Re: la guerre de s unices
Posté par Alex . Évalué à 2.
Personne ne nie que le shell est lent,
mais même mon rectificatif n'a aucun intérêt
il faudrait un point de référence, et voir si la partie shell en elle même engendre une surcharge importante et préjudiciable par rapport à une solution sans shell
[^] # Re: la guerre de s unices
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
A quoi cela servirait ? Mon but est juste de montrer que les shells sont lent. C'est tout. Ensuite, il y a un paquet de solution envisageable. Je ne cherchais pas de coupable.
"La première sécurité est la liberté"
[^] # Re: la guerre de s unices
Posté par Alex . Évalué à 2.
Ok
je pense tout de même que ce bench n'est pas probant
on constate juste qu'avec un process qui ne fait pratiquement rien (wc), 1/3 du temps est passé dans le noyau
A prioris on aurait le même problème si tu faisais la même chose en C
[^] # Re: la guerre de s unices
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Tu enfonces une porte ouverte là.
Mais j'inclue la gestion du fork() dans la vitesse du shell.
"La première sécurité est la liberté"
[^] # Re: la guerre de s unices
Posté par etenil . Évalué à -7.
Marrant, tu parle d'efficacité mais sur tous les ordinateurs où j'ai pu tester systemd (opensuse ou fedora), j'ai eu le sentiment que le temps de boot avait augmenté. Pas terrible quand même pour un truc qu'on nous annonçait comme le messie des systèmes d'init.
[^] # Re: la guerre de s unices
Posté par groumly . Évalué à 10.
C'est la classe de faire des mesures de perfs sur des sentiments…
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: la guerre de s unices
Posté par gnumdk (site web personnel) . Évalué à 2. Dernière modification le 05 septembre 2012 à 12:06.
2 secondes sur mon laptop entre syslinux et kdm avec systemd, voilà mon sentiment…
Après, il faut savoir ce que l'on test, en gros, si on installe systemd en mode compatibilité sysvinit, y'a peux de chance que ça aille plus vite… Mais c'est surement trop dur de lire une doc…
[^] # Re: la guerre de s unices
Posté par eastwind☯ . Évalué à 0.
Quel remplaçant proposes tu ?
(j'inclus dans les scripts shell les langages de script comme le python etc … )
[^] # Re: la guerre de s unices
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 9.
Pas moi. Python et Ruby ne peuvent plus vraiment être qualifiés de langages de script… Et quand bien même, dire que tous les langages de script sont équivalent au langage POSIX shell, c'est osé…
[^] # Re: la guerre de s unices
Posté par Anonyme . Évalué à 6.
Perso moi il m'arrive de faire des scripts système en php.
(oui vous pouvez moinser).
[^] # Re: la guerre de s unices
Posté par Christophe B. (site web personnel) . Évalué à 5.
Beurk !
Bien qu'étant pour la liberté de choix des langages et des méthodes en générales, beurk quand même.
Mais bon si c'est toi qui maintiens …
Qu'apporte systemd par rapport à l'ancienne méthode (rc.* /etc/init.d inittab et autres), quelqu'un peut me résumer les grandes lignes s'il vous plait, j'ai bien lu la première page et la page wikipedia mais comme l'arrêt et le reboot d'une machine sont des situations exceptionnelles ET que le systeme "classique" est facile a suivre et a peu près logique.
Dans certain cas il vrai qu'optimiser le boot et le reboot est important :) (non je ne citerais pas de nom) mais dans d'autres il s'agit de script lancé qu'une ou 2 fois tout les 2 ou 3 ans alors même si c'est pas tip top au poil l'essentiel c'est que ca marche non ?
Donc si quelqu'un pouvait me dire ce qu'apporte systemd, cela serait sympa
Merci d'avance
[^] # Re: la guerre de s unices
Posté par Zenitram (site web personnel) . Évalué à 1.
Sympa ta machine trouée…
Tu peux lire la page wikipedia avec comme condition de ne pas avoir de préjugés, et tu auras la réponse.
Question inverse : pourquoi vouloir l'ancienne méthode que les mainteneurs de distro ne veulent plus si on l’utilise que 2 ou 3 fois par an? Ca fait beaucoup de réaction pour un truc peu utilisé…
[^] # Re: la guerre de s unices
Posté par Kaane . Évalué à 6.
Question inverse : pourquoi vouloir l'ancienne méthode que les mainteneurs de distro ne veulent plus si on l’utilise que 2 ou 3 fois par an?
Tu veux dire : "Pourquoi ne pas rajouter à un OS tout un tas de fonctionnalité dont tu n'as pas besoin et dont tu ne te servirais que très rarement si tu les avais à disposition ?"
Ben écoute chacun fait comme il veut bien sur, mais personnellement les trucs dont je ne me sers pas je ne les installe pas. Il y a près de 15000 packages dans ma distrib, j'évite de les installer tous.
[^] # Re: la guerre de s unices
Posté par Zenitram (site web personnel) . Évalué à 0.
La réponse est pourtant simple : parce que plus personne n'est intéressé à maintenir ta chose (je parie que le fork va être abandonné bientôt, car quasi tout le monde sera tourné vers systemd) car il y a mieux et plus maintenable (à commencer par du monde intéressé).
Encore une fois, si ça intéresse réellement des gens de passer son temps à maintenir la chose, vous pourrez encore utiliser la chose. Si. Super l'argument : bon les gars, il y a des gens qui veulent leur ancien truc juste parce qu'ils ont du mal à suivre le changement, mais attention, aucun n'est prêt à payer, on fait ce qu'ils ont envie ou on les laisse se faire plaisir dans la complainte des vieux n'aimant pas le changement? Ca a un nom : résistance au changement.
Quel est le rapport? Ici, tu remplaces un package par un autre, pas un de plus.
[^] # Re: la guerre de s unices
Posté par Kaane . Évalué à 10.
La réponse est pourtant simple : parce que plus personne n'est intéressé à maintenir ta chose
Dans le cadre d'un système d'init la question ne se pose pas. SystemV en lui même est très simple à maintenir, ce qui coute cher ce sont les scripts d'init. Mais à moins que Linux/systemd n'envoient tous les autres systèmes à la casse on aura toujours des scripts raisonnablement simple à adapter chez les *BSD pour toutes les applications phares.
C'est la puissance de SystemV : en quelques minutes je peux écrire un script de démarrage qui correspond exactement à mes besoins. Le seul problème qui va se poser c'est au niveau du démarrage des couches réseaux (ip, gre, pptp etc.) mais bon les scripts n'ont pas été réécrits pour le passage ifconfig -> iptables (il y a 16 ans, presque 14 ans qu'ifconfig est en deprecated) donc on peut légitimement se demander si ils vont l'être pour systemd.
bon les gars, il y a des gens qui veulent leur ancien truc juste parce qu'ils ont du mal à suivre le changement
Non, c'est juste que systemd est une mauvaise idée. Il s'agit ni plus ni moins que de la nième tentative pour normaliser Linux, on sait ce qui est arrivé aux précédentes et on a pas envie d'investir dans un truc qui va forcément se péter la gueule. (comprenons nous bien, par péter la gueule je veux aussi bien dire disparaitre que d'être obligé d'évoluer dans de telles proportion que d'ici trois ans les scripts systemd auront autant de ifdef et d’exceptions que les inits actuels).
[^] # Re: la guerre de s unices
Posté par Prosper . Évalué à 0.
C'est pas iptables mais iproute
D'autre part au moins Redhat utilise iproute dans ces scripts network et probablement network-manager
[^] # Re: la guerre de s unices
Posté par Chris K. . Évalué à -1. Dernière modification le 05 septembre 2012 à 15:02.
J'ai cru qu'il parlait d'ipchains au départ quand j'ai lu le post ^^
Par contre iproute j'ai pas sur ma debian… ip route ou ip addr par contre oui ;) ip addr est quand même plus proche de la sortie de ifconfig.
[^] # Re: la guerre de s unices
Posté par Anonyme . Évalué à 0.
ipest issue deiproute2[^] # Re: la guerre de s unices
Posté par Misc (site web personnel) . Évalué à 2.
En fait, c'est toujours pareil, tu dit "tel truc est déprécié", la plupart des gens font rien. Tu retires, ça crie de partout.
les scripts réseau de rh sont aussi ceux qui sont utilisés par les autres distros rpm-based, donc ça a migré également.
Les debians utilisent ifup, un executable, donc je suppose qu'il fait direct les appels aux ioctls ( comme NetworkManager, au passage ). j'ai trouvé encore des appels à la commande "route" ceci dit dans un script.
J'ai rien pigé au script de gentoo, donc je peux pas dire, mais je pense que ça a du être migré.
Au final, les distributions ont fait leur taf. Ce qui coince, c'est toujours pareil, c'est le reste du monde. Et qui doit faire le travail pour que d'autres puissent ne rien faire ? Les distributions… ( et souvent gratuitement, avec le sourire )
[^] # Re: la guerre de s unices
Posté par cedric . Évalué à 8.
La difference majeur, c'est qu'une unite systemd peut etre fourni par le projet upstream et fonctionnera sur toutes les distribs. Ca veut dire moins de boulot dans la distrib, integration a terme plus rapide des nouveautes et teste plus large. Pour les mainteneurs, c'est un gain, pour les developpeurs, c'est un gain.
Si c'etait une si mauvaise idee, pourquoi la majorite des gens qui font des distribs, developpe des plateformes ou developpe du soft sur Linux suivent le mouvement ? Ni upstart ni openrc n'ont reussi a gagner une tel attraction. Et ni Lennart ni Red Hat ne paye ces gens pour adopter systemd, ils le font parce que techniquement, c'est une meilleur solution que l'existent. Cela leur facilite la vie, leur permet d'avoir un systeme plus dynamique, plus maintenable et plus efficace…
Ensuite il y a un truc que tu n'as pas compris, Linux est base sur l'evolution. Tous les logiciels, les bibliotheques vivent et meurent au gres de l'apparition d'une concurrence plus efficace, d'une mainteneur plus motive and so on. Linux est un eco systeme ou les theorie Darwinnienne s'applique. Il n'y a rien de stable ad vitam eternam. Si la communaute dans sa majorite pense que d'aller dans une direction est mieux, c'est ce qui se passera.
Tu peux de maniere individuelle choisir de ne pas la suivre. C'est ton droit. Et tu peux le faire, tu as les sources. Mais il y a un prix a payer, le faire soi meme. A toi de choisir.
[^] # Re: la guerre de s unices
Posté par Alex . Évalué à 2.
Parce que ça leur offre plein d'avantage, il manque c'est l'avis de l'utilisateur, ou surtout de l'admin
ce que je dis est un troll gratuit, je ne suis pas admin (ou que de mes serveurs perso), et je connais peu/pas systemd, et je dirai même qu'à titre perso j'y vois certains avantage
Mais j'imagine assez facilement les craintes d'un admin: un composant critique et bas niveau éffectuant énormément de taches et interagissant avec des composants haut niveau, à la place d'un ensemble de composant n'effectuant chacun qu'une seule tache.
[^] # Re: la guerre de s unices
Posté par Zenitram (site web personnel) . Évalué à 4.
L'utilisateur ne voit absolument pas systemd (ou alors, on n'a pas la même notion d'utilisateurs…)
L'admin, qu'est-ce qui te fait dire que ce n'est pas mieux pour lui aussi? Et si "c'était mieux avant", ils ne verront aucun inconvénient à faire le boulot de maintenance ou à payer les mainteneurs pour faire le boulot pourri de maintenance de ces vieux trucs.
C'est fou comme on peut vouloir demander tout aux autres…
[^] # Re: la guerre de s unices
Posté par Alex . Évalué à 1.
tu as raison, je pense même que ça apportera des plus à l'utilisateur lambda, ne serait ce que pour les futurs ihm qui controleront l'outil via dbus
peut être, néanmoins je vois souvent les admins pestés contre les bloatware surtout pour tout ce qui est critique (et j'ai la prétention de croire que c'est le cas du système d'init, ainsi que de pas mal de features que systemd reprend a son compte)
on trouve dans systemd n'est plus qu'un système d'init, il prend en charge inetd, reprend a son compte une partie de ce que fait cron, fait du monitoring de process, etc… mais fait (actuellement) doublons avec d'autres process courrament utilisés
Pas plus que ce qu'on lui demande à lui même.
Faut arrêter ce genre de logique, le dev fait un taf, le mainteneur fait un taf, l'admin fait un taf, les 2 premiers sont sensé travaillés pour que le 3ème puisse faire son travail correctement (oui je sais, moi aussi j'ai fait des patchs qui ne servaient qu'à moi même)
l'admin on lui demande suffisament de choses pour qu'il ne se fasse pas chier à maintenir lui même des système que d'autres considèrent comme deprecated.
Mais en effet, si la solution ne lui convient pas, il passera sur autre chose
[^] # Re: la guerre de s unices
Posté par Zenitram (site web personnel) . Évalué à 3.
Tu n'as pas répondu à la principale question : L'admin, qu'est-ce qui te fait dire que ce n'est pas mieux pour lui aussi?
PArce que la, ce que je vois, c'est que l'admin n'a plus à ce taper du script bash à la con (bash, c'est quand même dans les trucs les plus merdiques à débuguer) et qu'en plus, ses fichiers de config seront les mêmes sur toutes les distros qu'il a à gérer. Et ça, ça a une valeur… systemd est peut-être la pour répondre au problèmes de l'admin?
Rappel : systemd est sponsorisé par RedHat, dont le but est de vendre. Et il n'y a pas mieux pour vendre du Linux que de se mettre l'admin dans la poche, qui argumentera sur le gain de temps de la distro.
J'ai plutôt l'impression que les gens qui refusent le changement se braquent, mais que sinon systemd répond à un réel besoin de la part de tous les gens impliqués.
[^] # Re: la guerre de s unices
Posté par Alex . Évalué à 4.
Si c'était la seconde partie:
risque pour la stabilité, moins de souplesse dans les déploiement
Bien sur, ça ne veut pas dire que cela y réponde
mais ça y répond peut être très bien, je rebondissais juste qu'on n'ait pas placé l'admin dans la liste des gens ayant de bonne raison d'adopter systemd
perso je ne suis pas admin, ceux que je connais ne sont pas fan, surtout pour le coté bloat et le risque pour la stabilité de leur système.
Mouais, ou la minorité d'admin qui n'ont que linux en unix
Mouais, et c'est grâce à l'admin que linux c'est développé.
Néanmoins vendre et répondre au besoin ne vont pas nécessairement de paire, même si redhat est la mieu vendue je n'ai pas l'impression qu'elle fasse l’unanimité chez les admins (changement brutal de techno, support couteux, etc…)
Si il y a une constante, c'est bien ça: beaucoup d'early adopters qui veulent tout changer tout de suite, et beaucoup de gens craintifs au changement.
Néanmoins ici je vois des arguments intéressants , philosophiques (bloat, adoption trop rapide par les distros) et techniques (problème avec l'utilisation de partition chiffrés, vpn, dépendances, linux only, services en doublon )
[^] # Re: la guerre de s unices
Posté par Zenitram (site web personnel) . Évalué à 2.
Ces problèmes ne sont-ils pas simplement un manque de fonctionnalités dû à la jeunesse de la chose? Ca peut évoluer, comme tout nouveau logiciel qui fait bouger les choses. Si ont attend de répondre à tous les besoins avant de commencer à déployer, on ne déploie plus jamais rien et on meurt face à la compétition.
Pour le "linux only", udev est linux only et ne pose pas de problème philosophique aux critiqueurs, donc ce n'est pas un argument.
[^] # Re: la guerre de s unices
Posté par Alex . Évalué à 5.
Certainement, mais actuellement c'est vu comme des régressions, d'où la critique sur l'adoption trop rapide par les distros
Mouais, j'ai entendu pas mal de critique sur udev aussi (mais bon on sortait de devfs, de hotplug et de je ne sais plus quoi d'autre, donc les critiques devaient être émoussées)
de plus il est plus facile de se passé de udev que du système d'init.
Mais bon je trolle je trolle, le peu que je connais de systemd me plait bien (ptet que je suis devenu un trolleur de haut niveau finalement), même si je lui reproche certaines choses (la non portabilité, le coté bloat, j'ai même lu qu'à terme ça voulait remplacer cron ! ). De toute façon quoique quelqu'un fasse (y compris ne rien faire) il y aura toujours des mécontents
[^] # Re: la guerre de s unices
Posté par B16F4RV4RD1N . Évalué à 7.
les conseilleurs ne sont pas les payeurs. Tu n'utilises pas Linux, ça te sert à quoi de promouvoir systemd ?
si si, beaucoup de gens sont contre systemd, le risque que tout bloque en cas de problème de démarrage n'est pas négligeable. La conception est bizarre aussi (dépendance à Linux etc)
Déjà Debian ne va pas l'utiliser par défaut donc va sans doute continuer à maintenir "la chose". http://www.h-online.com/open/news/item/Debian-testing-a-systemd-to-sysvinit-converter-1670713.html
Gentoo ne va pas l'utiliser par défaut non plus : https://wiki.gentoo.org/wiki/Systemd
D'autres sont prêts à travailler sur divers fork si nécessaires :
http://bbs.archbang.org/viewtopic.php?pid=17877#p17877
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: la guerre de s unices
Posté par Marotte ⛧ . Évalué à 3.
Il a déjà expliqué qu'il utilisait Linux. Pas sur son poste de travail mais ailleurs. Je suppose sur des serveurs/routeurs ?
[^] # Re: la guerre de s unices
Posté par liberforce (site web personnel) . Évalué à 4. Dernière modification le 05 septembre 2012 à 12:30.
C'est sûr, c'est super étonnant qu'un système d'init cherche à tirer parti de toutes les fonctionnalités de l'OS plutôt que d'un sous-ensemble… =)
[^] # Re: la guerre de s unices
Posté par Moonz . Évalué à 10.
C’est quoi les fonctionnalités de Linux ? Celles activées dans le
.configde Fedora ? de Debian ? dans un noyau compilé avecyes | make config? Et quelle version de Linux ?Parce qu’on a beau parler des BSD, faut pas oublier que le noyau lui-même peut ne pas avoir les cgroups d’activés par exemple. Et qu’on peut tout à fait utiliser un userland récent sur un noyau beaucoup moins récent. Ce genre de problématique, d’expérience, est assez courant sur les VPS, ce n’est pas juste du « et si » dans le vent. Dans ce cas, qu’est-ce qu’il va faire, systemd-je-veux-absolument-utiliser-toutes-les-dernières-fonctionnalités-de-linux ? Se vautrer lamentablement ?
[^] # Re: la guerre de s unices
Posté par Misc (site web personnel) . Évalué à 1.
Il va pas démarrer, en effet. D'ailleurs, il y a eu des soucis avec lxc au début, car lxc utilise aussi les cgroups, et il y a eu clash sur l'usage en simultané des 2 ( souci corrigé depuis ).
Ceci dit, j'ai pour le moment vu personne se plaindre de ça à part toi, et bien que la remarque soit valable et génante pour ton usage, je pense qu'il y a donc un choix à faire sur ce que tu supportes en tant que distribution, et pour la plupart, l'usage en VPS est minoritaire AMHA.
[^] # Re: la guerre de s unices
Posté par zebra3 . Évalué à 4.
Donc tout va bien. S'il y a tant de gens que ça, il y a en bien quelques-uns qui vont maintenir les autres solutions (dont le fork de udev).
Du coup, tu es parfaitement libre d'utiliser leur solution plutôt que systemd et autres, et tu peux laisser tranquilles ceux qui préfèrent systemd au lieu de tenter de les convaincre que ce qu'ils utilisent, c'est de la merde.
Je ne vois pas pourquoi on se prend la tête à ce point.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: la guerre de s unices
Posté par lasher . Évalué à 3.
Voilà, exactement. D'un côté on a Red Hat qui paie des gens (a priori pas mauvais techniquement) pour developper systemd, de l'autre on a un nombre indéterminé de gens (sans doute en majorité des admins plutôt que des devs), et c'est évident que maintenir l'init façon SysV ou BSD va se faire naturellement, en dehors de leurs heures de travail…
[^] # Re: la guerre de s unices
Posté par Christophe B. (site web personnel) . Évalué à 0.
+1
c'est pour cette raison que je demande si VRAIMENT cela vaut le coup systemd si cela apporte
le truc_de_la_mort_ki_tue sinon pourquoi changer une équipe qui gagne ?
bien souvent en informatique la DERNIERE version n'est qu'un truc marketting pour se faire remarquer ou pour faire du chiffre d'affaire donc sans interet.
Si ya une raison technique, du mieux du plus simple alors je ca m'interresse
A+
[^] # Re: la guerre de s unices
Posté par zebra3 . Évalué à 0.
Va demander aux mainteneurs des plus grosses distributions. Si elles y passent toutes progressivement, c'est qu'elles y trouvent un intérêt, même si nous utilisateurs ne voyons pas lequel.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: la guerre de s unices
Posté par gaaaaaAab . Évalué à 10.
raisonnement dangereux.
Nos responsables politiques ont surement raison de privatiser les services publiques même si nous, utilisateurs, ne voyons pas lequel.
Le monde de la finance a surement raison de spéculer sur les matières premières même si nous, utilisateurs, …
[^] # Re: la guerre de s unices
Posté par tiot (site web personnel) . Évalué à 3.
Tout est une question de confiance. Manifestement tu n'as pas confiance en nos responsables politiques ni au monde de la finance.
En étant utilisateur d'archlinux j'ai confiance en ces développeurs qui m'ont toujours amené une entière satisfaction, lorsque systemd sera mis par défaut j'y passerai comme tout le monde.
Si pour une raison ou une autre je ne suis pas satisfait les développeurs perdront ma confiance et j'irai voir ailleurs.
[^] # Re: la guerre de s unices
Posté par cedric . Évalué à 4.
Il y a une difference. Tu peux le faire toi meme. Il y a une doc, tu peux lire, apprendre, comprendre, verifier et agir.
La politique, c'est une autre histoire. Faut raconter aux gens ceux qu'ils veulent bien entendre sur le moment. Apres la realiter et les consequences ont peu d'importance.
Pour la finance, il y a clairement un manque d'information, de culture economique, scientifique et geostrategique importante qui fait que bon nombre de personne ne sont pas capable de comprendre ceux qu'on raconte. Entre autre chose, la speculation sur les matieres premieres a une influence minimal sur leur prix. A leur actuel, la principale raison de la monte du prix, c'est la rarefaction du petrole a bas cout…
[^] # Re: la guerre de s unices
Posté par lasher . Évalué à 3.
Tu rigoles j'espère ? La politique, ça commence au niveau zéro, celui de l'engagement militant. Si un truc ne te plaît pas, et que tu ne participes pas d'une manière ou d'une autre pour contribuer à ce qu'elle change, tu es aussi coupable qu'un admin qui (au hasard) ne saurait pas faire plus que scripter (parce que bon, le dév système et la prog en C, ça fait 10-20 ans qu'il en fait plus…).
[^] # Re: la guerre de s unices
Posté par cedric . Évalué à 4.
Non, je ne rigole pas. Les gens ne veulent pas entendre la realite. Ils ne veulent pas qu'on leur parle des contraintes du monde reel. Il faut leur vendre du reve et celui qui leur raconte les bobards les plus proches de leurs aspirations se fait elire. Le principe est de bien connaitre son electorat, savoir qu'elle partie de la population choyer pour maximiser ses votes et se faire elire. J'ai arrete de croire aux bisounours, il y a quelques annees deja !
Il n'y a rien a attendre de la politique, ni du gouvernement.
[^] # Re: la guerre de s unices
Posté par B16F4RV4RD1N . Évalué à 3.
ouais, comme de juste, à part Mageia et Frugalware, les autres sont des distributions commerciales (ou des sous-marins de ces distributions, comme Fedora ou OpenSuse). Et vu que c'est red hat qui pousse la techno, c'est qu'elle doit y trouver un intérêt commercial, par exemple pour encourager à faire des logiciels qui ne tournent que sous Linux, dans un contexte précis, et pousser de plus en plus vers leurs services. À mon avis c'est guère plus compliqué que ça et tout le monde s'engouffre connement là dedans.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: la guerre de s unices
Posté par gnumdk (site web personnel) . Évalué à 2.
Ou alors systemd répond à un besoin que sysvinit n'est pas capable de comblé…
Parce que bon, tu oublies quand même ArchLinux dans l'histoire, et tu le fais exprès en plus pour appuyer ton propos.
[^] # Re: la guerre de s unices
Posté par cedric . Évalué à 5.
Wouah ! Une theorie du complot des distributions Linux commerciales ! Joli, j'avais pas encore rencontre une telle idee… Lennart, il aurait pas tue JFK ? Et ca serait pas ca soucoupe volante qui s'est crashe a Roswell ?
[^] # Re: la guerre de s unices
Posté par Anthony Jaguenaud . Évalué à 3.
Pourquoi ? Le crash était dû à une faille logiciel ?
[^] # Re: la guerre de s unices
Posté par Misc (site web personnel) . Évalué à 3.
Et arch aussi. Et tu noteras qu'il y a des distros commerciales comme Ubuntu qui n'ont pas suivi.
Donc on trouve grosso modo dans ceux qui proposent pas :
- Debian qui ne bascule pas car ils ont des raisons techniques ( kfreebsd, hurd )
- slackware et autres pour des questions de minimalisme
- gentoo qui le propose en option ( à la méthode gentoo )
- mint, parce que mint fait 0 devs sur la plateforme et fait juste de la repompe de ubuntu
- openembedded, pas de probléme avec hurd/kfreebsd, pas de souci de minimalisme => proposé en option comme gentoo
Du coté des autres distros à but commerciales, tu as :
- Ubuntu, qui le propose pas car ils ont leurs propres trucs, à savoir upstart ( upstart qui a été intégré dans RHEL et Fedora, mais personne ne va crier au complot dans ce cas la, car c'est juste quand un truc a du succès qu'il y a complot )
En gros, pour chaque distro qui propose pas, on trouve une raison de pas le faire.
Regardons maintenant les distros qui proposent :
- opensuse, mageia, fedora, mandriva, rosa => pas de souci techniques comme Debian ( ie linux only ), pas de souci de minimalisme comme lfs ( ie, udev, dbus sont déja la ), pas de système de boot maison aussi avancé comme Ubuntu
curieusement, aucune des raisons des autres ne s'appliquent. Donc la question est de savoir pourquoi est ce que :
- les distros n'ont pas décidé de faire leur truc
- les distros n'ont pas décidé de garder les anciens initscripts
Alors le 1, c'est simple, parce que ça coute des ressources. Et le 2, c'est simple, parce que personne n'a vraiment envie de s'occuper d'une grosse pile de trucs bash pour avoir en plus moins de fonctionnalités. Pour le moment, ça va, mais si dans 1 ou 2 ans, faut intégrer des nouveautés, ça devient vite galère.
Et peut être que l’intérêt est juste la, c'est de proposer un système qui correspond plus au besoin des mainteneurs ( genre, tu sais, les gens qui te file gratuitement leur boulot sous la forme d'une distribution ) et que c'est pour ça que les distros y passent ? Et parce que du coup, ça laisse du temps pour faire autre chose.
conclusion, on a une paire de distros qui n'ont pas de raisons de refuser un truc, pas envie de se taper le cout de maintenance du à une divergence, trouve des avantages à basculer et qui, du coup, bascule dessus.
C'est vraiment bien foutu ce complot
[^] # Re: la guerre de s unices
Posté par zebra3 . Évalué à 3.
Debian ne bascule pas, mais elle fournit tout de même systemd pour ceux qui veulent.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: la guerre de s unices
Posté par Christophe Turbout . Évalué à -1.
c'est quand même un poil abusé leur truc !!! Il n'y a pas tous les 3 jours un bug de sécurité impliquant un reboot du noyau !
[^] # Re: la guerre de s unices
Posté par Zenitram (site web personnel) . Évalué à 1.
Il a parlé d'années, et si, c'est troué dans ce cas, que ça te plaise ou pas. Je n'ai jamais parlé de jours.
D'ailleurs, il y a une infographie sur le lien que j'ai mis, clique dessus…
[^] # Re: la guerre de s unices
Posté par Prosper . Évalué à 3.
J'adore les affirmations autoritaires de ce genre… nan mais sans blague, personne n'utilise linux en dualboot peut-être ? personne n'eteint son Pc sans utiliser la veille ? sans compter que très souvent le boot par SSD est plus rapide que la sortie de veille sur disque. On est loin de situations exceptionnelles, bien au contraire.
[^] # Re: la guerre de s unices
Posté par Christophe B. (site web personnel) . Évalué à -1.
Pardon, je précise dans le cas ou Unix et Linux sont utilisés comme serveur, ce pour quoi il est fait à l'origine, et d'ailleurs c'est pour les autres cas dual boot, portable etc … que je recherche des infos sur systemd.
[^] # Re: la guerre de s unices
Posté par Buf (Mastodon) . Évalué à 4.
php, c'est déjà moisi dans le domaine pour lequel il a été conçu (le web), alors l'utiliser pour autre chose… Ça ne donne vraiment pas envie…
[^] # Re: la guerre de s unices
Posté par Christophe B. (site web personnel) . Évalué à 0.
+1
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: la guerre de s unices
Posté par Christophe B. (site web personnel) . Évalué à -2.
plus 2
mais comme je le disais plus haut, le shell (ksh bash meme le bourne shell) ont encore de longues années d'avenir. car comme le papier et le crayon ils sont proche de la perfection dans leur usage courant.
[^] # Re: la guerre de s unices
Posté par lasher . Évalué à 4.
Laisse Perl tranquille ! Il t'a rien fait ! :-(
[^] # Re: la guerre de s unices
Posté par ze_lionix (site web personnel) . Évalué à 1.
Et tu n'as pas constaté que quand ton "script système php" se lance la CPU commence à fumer comme pas possible ?
C'est ce qui m'a fait me tourner vers perl et dash…
Fuse : j'en Use et Abuse !
[^] # Re: la guerre de s unices
Posté par Anonyme . Évalué à 5.
Non.
D'une façon assez générale, je sais objectivement la raison pour laquelle php est un mauvais langage (voir là par exemple http://sametmax.com/deterer-le-cadavre-dun-troll-non-php-nest-pas-simple/ ), contrairement à beaucoup de gens agissant de façon mimétiques en disant php c'est de la merde sans en avoir la moindre idée de pourquoi mais ayant l'impression d'être aussi, voir plus, intelligent que les autres.
Php me permet d'avoir une syntaxe simple, lisible, et une rapidité de déploiement non négligeable, je suis pas un développeur pro et la documentation très accessible du langage me permet de faire les choses proprement sans y passer des heures.
Alors, objectivement, oui php est pas le meilleur langage du monde, sauf qu'en réalité, il est tout à fait fonctionnel tant qu'il ne s'agit pas d'écrire des applications extrêmement complexes et tout à fait maintenable car c'est un langage à la syntaxe simple et lisible.
(et je terminerais avec encore un peu de psychologie inverse en disant une fois encore que vous pouvez moinser ce commentaire dans le but que vous fassiez exactement le contraire, bien évidement)
[^] # Re: la guerre de s unices
Posté par ze_lionix (site web personnel) . Évalué à 1.
Hello,
On est un peu en dehors du débat, mais je tenais juste à te dire que je ne dénigre pas le php, j'ai fais mes premières armes dessus et continue de l'utiliser à outrance depuis plus de 12 ans pour tout ce qui est www !
J'ai pris sa défense il y a pas longtemps et j'ai appris, contrairement à ce que tu penses, que le php est en ascension pour tout ce qui est application lourde ! Pour diverses raisons : performance, rapidité d’apprentissage…etc..
Tes arguments _ que je rejoins _ sont pourtant à côté de la plaque par rapport à mon commentaire… J'utilise le langage de Rasmus, mais plus pour la partie administration système car #!/usr/bin/php est un shebang qui pèse sur la CPU !
NON => Si si ! Fait un traitement de plus d'une minutes en shell php, lance un top et constate…
Ce langage est fait pour le web, plus de 75% des serveurs web l'utilisent !
Mais faire avec son pear des scripts systèmes est un détournement qui n'est pas approprié.
Fuse : j'en Use et Abuse !
[^] # Re: la guerre de s unices
Posté par Anonyme . Évalué à 1.
Désolé, mon commentaire regroupaient aussi des réponses aux autres commentaires de la même teneur qui étaient au dessus du tiens. Mon propos était un peu plus global.
Sinon, en ce qui concerne mon usage, ce n'est pas quelque chose que j'ai constaté. J'utilise le shebang /usr/bin/php aussi et ça n'a jamais posé problème en ce qui me concerne. Après les scripts que j'écrie en php sont rarement des daemons, donc ils ne s'exécutent jamais très longtemps.
[^] # Re: la guerre de s unices
Posté par Christophe B. (site web personnel) . Évalué à 10.
mmmm je ne crois pas au langage unique qui pourrait tout faire et surtout plaire a tout le monde, le scripts shell va mourir, comme le papier et le crayon … c'est annoncé depuis longtemps longtemps … mais c'est pas pour tout de suite :)
[^] # Re: la guerre de s unices
Posté par gaaaaaAab . Évalué à 7.
une phrase qui ne veut pas dire grand chose. "mieux" selon quels critères ?
C'est sûr qu'il y a pleins de langages plus adaptés que le shell pour écrire des applications complexes, mais il y a aussi des cas d'usage pour lesquels je n'ai pour l'instant rien trouvé de "mieux" que le shell.
L'analogie pourrie du jour: une perceuse est "mieux" qu'une chignole si on veut percer 10000 trous, mais uand on veut percer un pauvre trou dans une planchette, une chignole, c'est "mieux" qu'une perceuse.
[^] # Re: la guerre de s unices
Posté par Zenitram (site web personnel) . Évalué à 3.
Lennart contre le reste du monde??? Son travail a l'air bien apprécié, ça semble partie pour toutes les distros majeures contre les petites… Pas sûr que Lennart ne gagne pas.
[^] # Re: la guerre de s unices
Posté par Guillaumito (site web personnel) . Évalué à 8.
Pas toutes les distros majeures, pas Debian en tous cas.
[^] # Re: la guerre de s unices
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 1.
Source ? Parce que systemd marche quand même plutôt pas mal sous Debian… Tu as une position officielle indiquant que ça ne passera jamais par défaut ?
[^] # Re: la guerre de s unices
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 8.
Déjà entendu parler de Debian GNU/kFreeBSD ?
[^] # Re: la guerre de s unices
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 2.
Ah oui tiens, j'avais pas pensé à ça… Mais ça veut forcément dire que le système d'init par défaut sur Debian GNU/kfreebsd et sur Debian GNU/Linux seront les mêmes ?
Josselin Mouette disait justement que tous les paquets de Debian GNU/Linux ne marchaient pas sur Debian GNU/kfreebsd.
[^] # Re: la guerre de s unices
Posté par Misc (site web personnel) . Évalué à 6.
Il y a eu un summer of code pour résoudre le souci ( de la même façon que debian avait résolu le souci des menus avant la norme freedesktop ).
En gros, tu as un format de base ( genre le format .ini de systemd ), et tu peux générer un script d'init pour debian kfreebsd, pour le hurd, etc.
Ensuite, comme systemd utilise quand même des fonctionnalités difficiles à émuler partout ( genre les cgroups, l'intégration de selinux, le filtrage des appels systèmes des programmes lancés, le fait de lancer les applis dans un chroot avec montage particulier de certains répertoire ), je suis pas sur que ça puisse vraiment transposer tout dans un script shell, sauf à se retrouver avec un truc comme autoconf.
[^] # Re: la guerre de s unices
Posté par Maclag . Évalué à 2.
Certes, ça pourrait vite devenir très compliqué. D'un autre côté, le problème principal, ce serait un mainteneur Debian qui écrit la config pour systemd et ne fournit plus de script shell.
Combien de paquets ont des besoins particuliers (au-delà de start/stop/etc. classiques), et quelle charge de travail supplémentaire pour maintenir les script pour les deux systèmes d'init sur ces paquets?
(En fait, si j'ai bien compris, même sous systemd, quand on a des besoins spécifiques, l'idée est de retomber sur un script shell au lieu du fichier de config systemd, j'ai bon?)
Dans le pire des cas, la solution "générique" simple couvrirait déjà la plupart des besoins.
[^] # Re: la guerre de s unices
Posté par Misc (site web personnel) . Évalué à 1.
Tu appelles quoi "besoin particulier" ?
À vue de nez je pense que tu veux dire 2 trucs :
1) les services avec des actions en plus ( genre, postgresql, dump de la db via le script d'init ).
C'est une chose qui fait pas stricto sensu parti du script d'init. En général, ça a été mis dedans parce le script d'init a besoin de la config du daemon, et sans doute pour des questions d'ergonomie et d'affordance ( ie, pour le modèle mentale de l'utilisateur, le script est la porte d'entrée sur la manipulation du daemon, un dump de la db est une manip de ce genre donc on rajoute la fonction )
Avec systemd, tu doit faire un script à part ( vu que tu peux pu intégrer ça dans le script principal ). Il y a un emplacement spécifique quand tu utilise ça avec service pour garder l'intégration ( genre service pgsql dump va appeler /XXX/pgsql/dump ). La différence entre "j'écris du code que je mets avec un case en plus dans un script" et "j'écris du code que je mets dans un fichier à un endroit spécifique" est pas flagrante. En fait, tu peux juste garder ton script d'init qui fait appel à ton 2eme script.
2) les services qui ne sont pas des daemons classiques. Exemple, tu as un truc à lancer au démarrage, mais c'est pas vraiment un daemon, c'est juste la configuration de l'affichage sur un ecran lcd 4" du nom de la machine ( le seul exemple que j'ai trouvé qui ne soit pas géré autrement ). En gros, tu doit lancer une paire de commande pour charger le matos, et lancer ce que tu veux écrire. Ben ça, oui, tu peux lancer un script shell, ou un programme en C. Ou tu peux lancer les commandes à la suite dans le fichier systemd, avec plusieurs lignes Execstart, en précisant "c'est normal si il reste aucun process à la fin" et "ne fait pas de tracking de PID". IE pour les actions spécifiques, rien n'empeche de faire encore du shell. Après tout, si le but est de lancer des softs, personne ne va vérifier si le soft est en C, en python, en perl, en bash ou autre. Donc pareil, si tu codes bien, tu as fichier que tu appelles depuis un script classiques ou systemd.
Maintenant, en pratique, j'ai du mal à voir ce qui requiert des dizaines de commandes spécifiques au boot, à part le réseau et perso, je pense que ça peut sans doute être mieux intégré et de plus haut niveau que sous la forme d'un script shell.
Mais du coup, est ce que tu penses à autre choses pour "besoins non spécifiques" ?
[^] # Re: la guerre de s unices
Posté par Maclag . Évalué à 3.
C'est le genre de trucs qui vient en tête. Après, je ne prétends pas connaître tous les cas de figure et tous les scripts de tous les paquets qui ont un script init. C'est pour ça que je demande: dans le pire des cas, combien de scripts à "porter" de l'un à l'autre.
Comme tu dis, en plus d'une quantité limitée de scripts, le gros du boulot resterait commun.
[^] # Re: la guerre de s unices
Posté par Olivier (site web personnel) . Évalué à 1. Dernière modification le 05 septembre 2012 à 10:55.
Pourtant, systemd est bien dans Debian (Testing et +) : http://packages.debian.org/search?keywords=systemd&searchon=names&suite=all§ion=all&sourceid=mozilla-search
Il n'est pas présent par défaut, mais est instable :
Je ne suis cependant pas assez joueur pour avoir testé sur ma machine principale… :)
[^] # Re: la guerre de s unices
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 3.
Il faut installer systemd-sysv aussi je crois, sinon c'est toujours sysvinit qui fonctionne. Pour ma part je suis joueur :)
[^] # Re: la guerre de s unices
Posté par Maclag . Évalué à 3.
En fait non, c'est pas indispensable, tu peux activer systemd sans systemd-sysv avec une option à passer dans grub.
Installer systemd-sysv, c'est pour ceux qui ne veulent pas revenir en arrière.
Pour ma part, je suis juste assez joueur pour avoir l'option dans grub et bien tester avant de sauter le pas définitivement.
[^] # Re: la guerre de s unices
Posté par Batchyx . Évalué à 10.
Systemd est dans Debian, et alors ?
Upstart aussi l'est, tout comme file-rc (encore un truc zarbe utilisé par trois pélerins…)
Tu viens juste de prouver que Debian est une distribution qui laisse le choix du système d'init à utiliser. Ça tombe bien, c'est pour ça que je l'aime.
[^] # Re: la guerre de s unices
Posté par Psychofox (Mastodon) . Évalué à 4.
Le problème n'est pas tant dans son travail que dans la méthode et la communication.
[^] # Re: la guerre de s unices
Posté par Zenitram (site web personnel) . Évalué à 6.
Personnellement, je préfère une forte gueule qui se bouge le cul et qui fait évoluer l'éco-système Linux (et virer ces script d'init, c'est une belle évolution) que des gens "gentils" qui laissent la situation pourrir au point de ne plus être compétitif. Bon, après, il y a pire : les forte gueules qui râlent sur les évolutions sans se bouger le cul :-D.
[^] # Re: la guerre de s unices
Posté par CHP . Évalué à 4.
C'est une évolution. Belle, pas sur, dans le bon sens, non plus. Perso je prefere un systeme peu performant (au sens vitesse d'execution) mais facile à comprendre et maintenir qu'un truc plus performant auquel je ne comprend rien. Et je n'ai pas envie de passer 10 heures à apprendre un nouveau systeme qui me ferait gagner 30 secondes à chaque reboot, si je ne reboot mon serveur que quelques fois par an… C'est pas rentable.
Prouve le. En quoi la situation était en train de pourrir ? J'ai pas remarqué ce pourissement, perso. Pareil, le coup de plus être compétitif : par rapport à quoi ? Tu crois vraiment que sur un serveur, le temps de boot est un critère de compétitivité pour un OS ?
Il y a ENCORE pire : les fortes gueules qui gueulent sur les fortes gueules qui ralent sur les evolutions qui les emmerdent.
[^] # Re: la guerre de s unices
Posté par gnumdk (site web personnel) . Évalué à 7.
Si tu pouvais passer 10 minutes à comprendre ce que fait systemd plutot que de montrer que tu n'en sais rien… Si systemd avait été créer pour gagné 30 seconde au boot, alors upstart suffisait…
[^] # Re: la guerre de s unices
Posté par barmic . Évalué à 7.
Moi ce que j'aime c'est les « gentils » qui préfèrent bosser et communiquer de manière posée plutôt que de lancer un flameware à chaque fois qu'ils ouvrent leur MUA. Si si il y en a pleins. Même Shuttleworth s'est calmé et a arrêté d'être aussi gamin. Les grands noms (Torvalds, RMS, De Raadt, etc) le font rarement. Il n'y a guère que chez RedHat et gnome qu'ils n'ont pas compris que la communication peut se faire autrement.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: la guerre de s unices
Posté par neil . Évalué à 10.
Il y a aussi eu la guerre des navigateurs, sans laquelle on utiliserait tous IE, la guerre des BSD, qui a donné naissance à OpenBSD ou DragonFly, la guerre des compilateurs qui a donné naissance à EGCS puis GCC 3, la guerre des FAI, la guerre des forfaits de téléphone portable, etc. Que du mal ;-)
[^] # Re: la guerre de s unices
Posté par Kekun (site web personnel, Mastodon) . Évalué à 8.
Bah c'est ce qu'il dit: les Unix proprio ont été détruits, c'est une bonne chose non ?
Comment ça j'ai mal compris ?
[^] # Re: la guerre de s unices
Posté par Misc (site web personnel) . Évalué à 8.
Avant, rien n'était compatible, chaque distro avait son système d'init, son système de paquet, sa version de chaque composant, donc son abi.
maintenant c'est pareil.
C'est moi ou d'une part, les gens cherchent du sang et du drame la ou il y en a pas, et les gens ont la mémoire aussi courte que le slip d'un stripteaser dans un casino de las vegas ?
[^] # Re: la guerre de s unices
Posté par Laurent A. . Évalué à 5.
Justement, Systemd cherche à unifier le système de démarrage en supprimant notamment les scripts de lancement qui sont toujours propres à chaque distribution… donc on va plutôt dans la bonne direction.
[^] # Re: la guerre de s unices
Posté par Batchyx . Évalué à 6.
Ou plutôt dans la mauvaise. Si ces scripts étaient spécifiques, c'est qu'il y avait peut-être une raison. Raison qui n'est peut-être valable que dans certains cas, mais c'est largement suffisent.
Moi je n'ai pas envie d'installer D-Bus sur un serveur à moitié embarqué juste pour pouvoir admirer la rapidité du boot.
[^] # Re: la guerre de s unices
Posté par Zenitram (site web personnel) . Évalué à -2.
Et pourquoi pas? C'est si horrible que ça?
Pourquoi ce principe sur D-Bus et pas sur tous les autres composants qui seraient tout autant "inutiles" sur ta machine? Ca bouffe 1 Go de RAM?
C'est juste un dogme sur lequel s'arc-bouter…
[^] # Re: la guerre de s unices
Posté par Kaane . Évalué à 10.
Et pourquoi pas? C'est si horrible que ça?
Oui.
Déjà il y a des dépendances dans tous les sens, ça ne peut être piloté correctement que via DBus (donc pour le debug il va falloir créer un client DBus avec des droits démentiels et des cgroups transversaux), c'est fortement incompatible avec pas mal de méthodes de chiffrement de la partition de boot (grosso-modo tous sauf luks), ca monopolise des ressources mémoires (les cgroups c'est loin d'être gratuit, surtout en embarqué) etc.
Mais surtout :
- C'est fait par Red Hat, les experts en "on laisse tomber la fonctionnalité phare de la version précédente". Si vous avez investi dans les technos de virtualisation à la sauce Red Hat, vous savez de quoi je parle.
Il faut réécrire profondément les scripts d'init pour en tirer partie. Certes on peut créer assez rapidement des scripts qui fonctionnent du moment que l'on force une exécution séquentielle (c'est d'ailleurs ce que font pas mal de distribs en ce moment) mais pour que systemd apporte quelque chose il faut repenser l'init. Quand on voit qu'en près de 14 ans de déprécation les scripts utilisant ifconfig n'ont pas tous été réécrit et que iwconfig n'est toujours pas complètement intégré à au set d'outils iproute2 …
Vu la gueule de la stabilité API des linuxeries du passé (HAL, DBus, SELinux etc.) je n'investirais pas de temps à apprendre systemd. Et quand je n'aurais pas le choix (tous les linux avec systemd) je créerai un script bien gruik dans un cgroup absolu (tous les pouvoirs) qui lancera un bon vieux script shell en mode séquentiel. Bref il y aura un script init2 sur ma machine sur lequel je pourrais intervenir en mode texte avec pour toute arme une console et un vi.
Mais bon le truc c'est que ce qu'il y a de plus chiant dans Linux (bien plus que de gérer les dépendances et de faire un système de packages cohérent) c'est de faire des scripts d'init. C'est probablement la seule raison pour laquelle j'utilise une distrib toute faite et pas un LFS ultra customisé. Donc la perspective de devoir tous les réécrire et les maintenir pendant les deux ou trois ans que va mettre systemd à crever ne m'enchante pas.
[^] # Re: la guerre de s unices
Posté par gnumdk (site web personnel) . Évalué à 0.
L'espoir fait vivre hein, bon courage :p
[^] # Re: la guerre de s unices
Posté par Kaane . Évalué à 4.
L'espoir fait vivre hein, bon courage :p
Si encore c'était un espoir. Mais je connais déjà un gros client RH qui utilise massivement oracle avec des scripts d'init custom pas piqué des hannetons. Et là ils sont en train de bomberder le support RH de questions pour être iso fonctionnel en systemd.
Je ne pense pas un seul instant que RH va accepter de perdre ce client (même si 5 ans de support c'est long, tu peux être sur qu'à la première version d'Oracle qui n'est plus certifié sur le RH qu'ils utilisent ils changent de crêmerie).
Donc comme RH veut garder ce client (et rpobablement d'autres avec des problematiques similaires) je suis prêt à parier qu'ils vont mettre des gruikeries dans leur systemd… Et de là c'est juste une question de patience.
[^] # Re: la guerre de s unices
Posté par gnumdk (site web personnel) . Évalué à 5.
Pfff, ca devient insupportable les mecs qui parlent de systemd sans savoir de quoi ils parlent…
Ca doit prendre 2 minutes de faire une "unit" systemd qui lance des scripts shell comme le faisait sysvinit…
Mais bon, c'est tellement plus simple d'utiliser la bonne vielle technique du Fear, uncertainty and doubt.
[^] # Re: la guerre de s unices
Posté par Kaane . Évalué à 1.
Ca doit prendre 2 minutes de faire une "unit" systemd qui lance des scripts shell comme le faisait sysvinit
Et qui va créer 32 watcher si tu utilise apache en mode démon+fast cgi avec 32 spawn, et comme mentionné dans un autre post on va être gentil et pas parler d'Erlang ou des programmes qui utilisent du GPGCU.
La seule bonne façon d'utiliser systemd c'est d'avoir des démons et des outils de controle (type apachectl) qui parlent courament le DBus.
Et je veux pas de DBus dans mon apache, je ne veux pas de watcher, je veux des perfs maximale parceque j'ai des centaines de milliers de connexion par minute et que le roundtrip DBus est loin d'être gratuit.
Donc non, pour des programmes aussi marginaux que apache, mysql, postfix, JBoss, Oracle etc. il va falloir rajouter des trucs dedans pour que ca marche intelligemment avec systemd, des trucs qui vont géner les perfs et dont moi, personellement, je n'ai rien à foutre.
[^] # Re: la guerre de s unices
Posté par gnumdk (site web personnel) . Évalué à 3. Dernière modification le 06 septembre 2012 à 00:46.
Faux, surtout que apachectl, c'est l'exemple type de l'outils codé parce que sysvinit ne répondait pas aux besoins… T'inquiètes, si systemd devient vraiment le standard, ton apachectl, il va partir dans /dev/null
Et je le redis: systemd n'a pas besoin de dbus pour fonctionner et pour controller les services
[^] # Re: la guerre de s unices
Posté par Kaane . Évalué à 2.
Faux, surtout que apachectl, c'est l'exemple type de l'outils codé parce que sysvinit ne répondait pas aux besoins…
On passe sur la logique tarabiscotté (il est faux de dire que A a besoin de B pour fonctionner avec C vu que A a été créé à cause de D)
Ensuite tu penses sincèrement que toutes les options de apachectl seront codées dans un init un jour, notamment les options des modules compilés statiquement dans apache ? Parce que apachectl fait ça aussi.
T'inquiètes, si systemd devient vraiment le standard, ton apachectl, il va partir dans /dev/null
Clairement, si systemd devient le standard, apache laisse tomber windows, Mac et *BSD.
Et je le redis: systemd n'a pas besoin de dbus pour fonctionner et pour controller les services
CF mon autre post dans l'autre thread pour cette question, systemd est aveugle et sourd sans DBus. (ce qui ne l'empêche pas de lancer des services d'accord, mais pour le contrôle on repassera)
[^] # Re: la guerre de s unices
Posté par gnumdk (site web personnel) . Évalué à 1.
Ce qui est faux, comme je te le démontre dans l'autre journal, il fonctionne très bien sans dbus.
[^] # Re: la guerre de s unices
Posté par Misc (site web personnel) . Évalué à 4.
En fait, le support est passé à 10 ans, comme indiqué sur Linuxfr :
https://linuxfr.org/news/le-support-de-redhat-enterprise-linux-passe-a-10-ans
D'autre part, RHEL 6 tourne avec upstart, et visiblement, ça n'a pas l'air de déranger grand monde ( vu que personne n'en parle et j'ai pas entendu de grand cri ), et le support de sysV par systemd est au même niveau que celui d'upstart ( ie, ça se lance directement les scripts de /etc/init.d )
Enfin, sachant que oracle avait déjà décidé de prendre son temps pour la certif de RHEL 6 ( http://blog.vishalgupta.com/2011/09/19/oracle-11gr2-on-rhel6/ ), donc j'ai l'impression qu'une version d'oracle non supporté sur RHEL est un événement déjà arrivé.
Moi, quand je relit ton histoire, je vois juste un client qui collabore avec son fournisseur sur un produit pas encore sorti, et ça me semble relativement positif comme façon de faire. Et à te lire, tu en reviendrais presque à le regretter, voir à imaginer des luttes de pouvoir qui n'existent pas. On pourrais même croire que tu sous entends que RH ne va pas pousser les bugfixes upstream, ou qu'il y a pas moyen de supporter proprement les scripts shell avec autre chose que sysV ( voir même que tes scripts magiques feraient des trucs si magiques que ça marcherais pas )
Tu serais pas un peu aigri et totalement subjectif ?
[^] # Re: la guerre de s unices
Posté par Kaane . Évalué à 6.
donc j'ai l'impression qu'une version d'oracle non supporté sur RHEL est un événement déjà arrivé.
Ne pas confondre pas encore supporté et non supporté. Je reviens dessus dans un instant.
Moi, quand je relit ton histoire, je vois juste un client qui collabore avec son fournisseur sur un produit pas encore sorti, et ça me semble relativement positif comme façon de faire.
C'est très positif comme façon de faire. Il faut bien voir que les scripts d'init custom sont une plaie à maintenir, et que c'est la partie sur laquelle il est le plus complexe d'obtenir du support. Donc forcément il vaut mieux s'y prendre à l'avance. Le truc est que l'on peut lancer des scripts shells standard avec systemd mais que ça coince quand même à pas mal de niveaux.
Par exemple systemd essaye de suivre le double fork de la daemonisation comme il peut, parceque le plus souvent le processus qui est lancé immédiatement n'est pas le processus définitif. Au bout d'un temps X (qui dépend de tout un tas de paramètres y compris l'age du capitaine et les exceptions codées en dur) il va choisir un ou plusieurs processus à surveiller comme étant "le(s) bon(s)" processus.
Dans le cas d'un cluster qui peut mettre un certain temps à se synchroniser avant de démarrer (des fois plusieurs minutes, rarement quelques heures) le bon processus est lancé très tard et le processus daemonisé en premier qui ne fait que la synchro s'arrête. systemd n'aime pas du tout ce comportement, et on a pas de moyen simple de lui envoyer un message pour dire "tout va bien c'est XXXX le vrai processus".
Il existe des méthodes de contournement (on peut passer certaines infos d'un processus à un autre en systemd) mais ca fait des scripts complexes avec des exceptions, des tests et des cas aux limites un peu douteux.
Tu serais pas un peu aigri et totalement subjectif ?
Si bien sur pourquoi ? Mais pour autant la question à se poser est de savoir si j'ai tort ou pas…
[^] # Re: la guerre de s unices
Posté par Kaane . Évalué à 2.
Ne pas confondre pas encore supporté et non supporté. Je reviens dessus dans un instant.
Je suis pas revenu dessus.
Une des conditions pour la certif Oracle est de pouvoir faire monter les disque dur en raw directement par l'appli Oracle. Apparament (je ne suis pas complètement dans le secret des dieux) ca peut poser des problèmes avec systemd.
Le problème sera très certainement résolu bientôt, mais la question est de savoir comment.
Mon pari (et la c'est personnel et je l'admet un peu trollesque) est que pour faire face à tout un tas de situation (dont celle mentionnée plus haut) systemd va devoir se rapprocher progressivement d'un shell complet (voire d'un mini OS vu le nombre d'outils qui lui sont rajoutés chaque mois).
Red Hat ne peut pas se permettre d'essuyer un refus de certification de la part d'Oracle, donc si systemd bloque systemd sera poussé à évoluer, et ca le met dans une situation désagréable (un système d'init qui s'adapte à un programme userland c'est pas forcément glop).
[^] # Re: la guerre de s unices
Posté par Misc (site web personnel) . Évalué à 5.
Sincèrement, j'apprécierais d'avoir une discussion ou je suis pas obligé de sans arrêt sortir la documentation pour dire "voila comment faire tel chose" pour dire que la personne avec qui je discute qu'elle semble être dans le faux.
En l’occurrence, dans le cas que tu donnes, c'est prévu, tu peux désactiver le fait de trouver le pid via GuessMainPid=no, et juste utiliser un fichier de pid comme avant. Nombre de modif de systemd : 0, tout le taf est poussé sur le mec qui fait l'unit, en l’occurrence pour un soft proprio ou l'upstream ( ou le packageur ).
C'est dans les premières lignes de la page de man, avec les options "forking", "oneshot", ou "remainAfterExit".
http://0pointer.de/public/systemd-man/systemd.service.html
Donc si, on peut lui dire de faire ça, car ça reste assez flexible.
Ensuite, si le souci, c'est l'orchestration de services sur le réseau ( ie, ce que tu parles quand tu dis "cluster", c'est pas le but de systemd ou de sysv init, plus le but d'outils comme juju, mcollective, noah, et des dizaines d'autres qui fleurissent depuis l’avènement du cloud.
Enfin, tu parles de certif Oracle, mais sachant que OEL est juste une bête recompilation de RHEL avec une paire de patches et de modifs ( genre, btrfs par défaut ), tu penses vraiment que Oracle va dire "on certifie pas notre db sur notre distro" si jamais sa distro d'origine passe à systemd par défaut ?
( et visiblement, c'est fort probable au vue de patch comme https://www.redhat.com/archives/libvir-list/2012-June/msg00374.html ).
Ou tu penses que Oracle va juste décider de maintenir un system de boot différent à base d'initscripts pur, quitte à proposer moins de fonctionnalités que ses concurrents ( car comme la dépêche sur opensuse le laisse supposer, suse semble aussi bien parti pour basculer ), une doc et des outils d'admins différents etc.
[^] # Re: la guerre de s unices
Posté par Kaane . Évalué à 1.
Sincèrement, j'apprécierais d'avoir une discussion ou je suis pas obligé de sans arrêt sortir la documentation pour dire "voila comment faire tel chose" pour dire que la personne avec qui je discute qu'elle semble être dans le faux.
Et moi donc j'apprécierai que tu lises la doc que tu me balances avant de me dire que je suis dans le faux.
Je récapitule pour ce qui ne suivent pas : on a un process qui éventuellement fork et repasse la main à l'init avant de commencer une synchronisation et finalement de lancer le vrai processus.
On va partir du principe que le process ne fork pas pour simplifier le boulot, mais c'est encore pire si il fork
Les options intéressantes :
RemainAfterExit=
PIDFile=
ExecStart=
ExecStartPre=, ExecStartPost=
Dès le départ je suis obligé d'aller remplir le PIDFile avec le PID de mon premier élément sinon ca s'arrête et systemd concluera à un echec de lancement.
Ensuite je poursuis ma synchro. Quand ma synchro est finie problème :
Soit j'avais mis RemainAfterExit à TRUE et là je peux fermer mon process de synchro l'esprit tranquille, mais si mon process principal ne se lance pas, ben systemd ne sera jamais mis au courant du fait que ca ne marche pas. Pareil si le process se lance mais meurt par la suite.
Soit j'avais mis RemainAfterExit à FALSE et là c'est le drame parceque je ne peux pas fermer mon processus de synchro avant d'être sur que la mise a jour des PID a bien eu lieu dans systemd. Sauf que je sais pas quand elle a lieu la mise à jour. Donc je boucle en mode texte du systemctl jusqu'à ce que le PID modifié soit pris en compte. (Je ne sais pas si ca a changé, mais en vrai le nouveau PID dans le fichier ne sera jamais pris en compte)
On triche avec ExecStartPre, je lance la moitié de mon script d'init en pre pour la synchro et l'autre moitié en normal.
Problème : si la synchro se foire, l'autre commande n'est jamais executée. Sauf si je mets un - devant ma commande, auquel cas l'autre commande est toujours executée. Sauf que je veux du "des fois oui, des fois non". Donc il faut que j'étoffe mes deux scripts pour que le second script puisse récupérer et analyser les résultats du premier script (BEURK). Donc non seulement j'ai deux scripts à maintenir au lieu d'un, mais en plus j'ai du boilerplate qui vient se rajouter en plus sur l'existant.
Sauf que si le second script plante pendant le démarrage, il n'est pas dit qu'il aura fait le ménage avant que le plantage. Donc un petit troisième script en ExecStartPost pour passer le balais….(que tant qu'à faire je met aussi en ExecStartPre des fois que).
YOUPI trois scripts pour le prix d'un avec du boilerplate en plus…
Ensuite, si le souci, c'est l'orchestration de services sur le réseau
Non le soucis c'est de passer le service dans un état dans lequel il pourra être orchestré par la suite. C'est dire cohérent, synchronisé, stable et avec les bon paramètres de connexion connus.
_Ou tu penses que Oracle va juste décider de maintenir un system de boot différent à base d'initscripts pur, quitte à proposer moins de fonctionnalités que ses concurrents _
Non c'est quasiment certain que systemd évoluera pour s'adapter au besoin. Je doute sincèrement que RH aille au bras de fer (c'est à dire dise à Oracle : soit c'est comme on veut, soit il va vous falloir trouver une nouvelle distrib de référence). Aucun interet pour eux. Si ils le font - c'est à dire si ils refusent de rajouter des gruikeries dans systemd malgré un besoin Oracle je leur tire mon chapeau, et j'applaudirai des deux mains. Mais très honnêtement (et il s'agit de mon opinion personnelle là) je n'y crois pas.
[^] # Re: la guerre de s unices
Posté par gnumdk (site web personnel) . Évalué à 0.
Et sinon, c'est quoi le logiciel de merde en question ? Oracle DB?
Parce que moi, j'aurai tendance à dire que l'éditeur, si systemd devient le défaut, il va corriger son soft en faisant deux units:
- Une qui lance la synchro sans forker
- Une seconde qui lance le programme définitif quand l'unit précédente est terminée.
[^] # Re: la guerre de s unices
Posté par Misc (site web personnel) . Évalué à 5.
J'aime assez le coté péremptoire de ton commentaire qui fait croire que tu t'y connais sur systemd, suivi par "je n'investirais pas de temps à apprendre systemd". Faut savoir, tu connais systemd sur le bout des doigts pour expliquer comment dbus est obligatoire pour le debug ( ie, tu as eu à débugguer ? ), ou tu n'y connais rien et tu es juste un raleur aigri ?
Je penche pour le second, personnellement, mais je te laisse le bénéfice du doute.
En fait, je penche pour le second parce que tu sembles tourner les choses pour un bon FUD.
"pour avoir les fonctions qu'on a pas pour le moment, faut faire du boulot". En effet c'est logique, si tu veux des trucs qu'un script shell fournit pas, faut le refaire autrement. Mais sinon, les scripts marchent encore. Service marche encore.
Et contrairement à ce que tu crois, y a pas mal de distro qui font plus d’exécution séquentielle. RHEL, ubuntu ont upstart. Mandriva/Mageia a un système qui lance tout en même temps depuis 2006 ( pinit ). Et la plupart font de la gestion automatique de l'ordre via un système de tags LSB.
En fait, tu oublie aussi que les paquets des distros sont migrés, donc le travail de refonte est déjà fait ( comme les migrations à python 3 ou gcc 4, en fait ).
Pour la pérennité, prends au moins des trucs qui ont disparus ( genre oss, genre ipchains ), car selinux est la depuis facile 10 ans, et il n'a pas changé des masses, il a surtout eu des features en plus. Dbus existe depuis au moins 5 ans, et pareil, les changements sont pas révolutionnaires. Certes, hal a disparu.
Et sinon, comme tu avoues bien que faire des scripts d'init, c'est chiant, tu te rends bien compte que tu valides le point de vue des packageurs qui pousse à migrer à systemd ?
[^] # Re: la guerre de s unices
Posté par Kaane . Évalué à 2.
_Faut savoir, tu connais systemd sur le bout des doigts pour expliquer comment dbus est obligatoire pour le debug _
A l'heure actuelle il y a une personne qui connait systemd sur le bout des doigts et peut-être 150 qui le connaissent vraiment très bien. Je ne fais pas partie de ces élus, et j'éviterai aussi longtemps que possible d'en faire partie.
En ce qui concerne DBus, à l'heure actuelle (sauf erreur de ma part) on ne dispose que de deux façon de dialoguer avec systemd : systemctl et DBus.
Si on utilise systemctl on a un nombre (pour l'instant) limité de fonctions. Un autre utilitaire systemadm est en cours de création, mais il ne fonctionne qu'en mode graphique.
Et systemctl est assez pourri. (Ce n'est pas un troll, tout le monde est d'accord là dessus même chez RH/Fedora). Pourri pourquoi ? Parcequ'il est très incomplet et pas forcément cohérent avec lui même. Sur les commandes un peu complexe on se retrouve à faire du ;echo $ $ $ pour pouvoir lire le résultat, pour certaines opérations il faut aller shooter des symlinks à la main etc.
Systemctl permet de faire très simplement toutes les opérations de base (restart, reload, reboot, status, changement d'init etc.) par contre pour les opérations un peu plus complexe il faut soit passer par des variables d'environnement, ce qui nécessite un peu de jonglerie. Par exemple que veut dire :
On top of that basic environment variable substitution is supported. Use ${FOO} as part of a word, or as word of its own on the command line, in which case it will be replaced by the value of the environment variable including all whitespace it contains, resulting in a single argument. Use $FOO as a separate word on the command line, in which case it will be replaced by the value of the environment variable split up at whitespace, resulting in no or more arguments. Note that the first argument (i.e. the program to execute) may not be a variable, and must be a literal and absolute path name.
Et l'air de rien ça complique pas mal la mise en mode maintenance…
[^] # Re: la guerre de s unices
Posté par gnumdk (site web personnel) . Évalué à 1.
C'est vrai qu'avant, a part pouvoir faire start/stop/status/reload, on avait vachement plus de possibilités…
[^] # Re: la guerre de s unices
Posté par Kaane . Évalué à 1.
C'est vrai qu'avant, a part pouvoir faire start/stop/status/reload, on avait vachement plus de possibilités…
Ben avant le systeme d'init se prenait pas pour un système de controle. Donc un bête script rc de type
marchait plutôt pas mal. Même si en vrai on était obligé de rajouter des tests pour tout un tas de cas à la con.
[^] # Re: la guerre de s unices
Posté par claudex . Évalué à 3.
Et c'est toujours possible avec systemd, je ne vois pas le problème.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: la guerre de s unices
Posté par Kaane . Évalué à 2.
Et c'est toujours possible avec systemd, je ne vois pas le problème.
Si je fais systemsctl reload "monfichier de conf" ca va executer tructl reload "monfichierdeconf" ou ça va me mettre un message d'erreur ?
Parce que la dernière fois que j'ai testé ca me mettait un message d'erreur.
[^] # Re: la guerre de s unices
Posté par zebra3 . Évalué à 3.
Ben tu lances « tructl reload "monfichierdeconf" », au moins tu es sûr de ce que ça fait.
Ce que tu ne veux pas admettre, c'est que tu ne perds strictement rien.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: la guerre de s unices
Posté par Kaane . Évalué à 2.
Ben tu lances « tructl reload "monfichierdeconf" », au moins tu es sûr de ce que ça fait.
Même pas. Parce que tructl reload peut relancer le processus principal (qui s'occupe juste de créer des sous process qui font le boulot eux-même) et dans ce cas là je ne sais pas comment systemd va réagir. Une fosi de plus je peux changer le comportement de systemd pour lui dire d ene pas surveiller les PID ou de ne pas accorder d'importance au contenu des cgroup, mais dans ce cas là systemctl status renverra des infos erronées.
De la même façon si tructl reload lance de nouveaux processus, je ne vais pas savoir facilement les intégrer dans le bon cgroup, donc systemctl restart risque là aussi de faire n'importe quoi.
Au final si je veux pouvoir utiliser tructl, il faut que je n'utilise QUE tructl. Mais là si j'ai des dépendances dans un sens ou dans l'autre il faut aussi que je les gère à la main. Bref je refais un système d'init parallèle.
[^] # Re: la guerre de s unices
Posté par Damien Thébault . Évalué à 1.
À vrai dire, sur un serveur à moitié embarqué j'aurais tendance à utiliser un système largement utilisé afin d'éviter au maximum des problèmes.
Si je résume, systemd c'est au final plus de fonctionnalités, moins de bugs, plus rapide. C'est quoi l'intérêt de garder un sysv à l'ancienne qui est lent et moins testé?
Personnellement je ne l'utilise pas encore parce que je ne veux pas casser mes systèmes, mais je l'activerais sûrement lors d'une nouvelle installation sur une distribution qui le supporte.
[^] # Re: la guerre de s unices
Posté par Batchyx . Évalué à 7.
Ça tombe bien, j'utilise Debian.
Plus sérieusement, ça dépend de ce qu'on appelle "à moitié embarqué". Mais bien souvent, il y a au moins une des contraintes de l'embarqué à tenir compte. Moi dans mon cas, c'est un manque de RAM, mais j'ai quand même un disque dur pour swapper. Donc je vire tout ce qui prend de la RAM et qui ne swappe pas bien, du genre ifplugd qui passe son temps à poller alors qu'on peut faire sans si on daigne utiliser netlink, ou… D-Bus.
[Référence nécessaire]. Sérieux, d'ou tu sort que systemd est plus tésté que sysv ? Et je veux bien des tests sur la rapidité de systemd sur des petites machines. Quand aux nouvelles fonctionnalités, c'est bien pour celui qui les attend, mais c'est pas mon cas.
[^] # Re: la guerre de s unices
Posté par Damien Thébault . Évalué à 1.
Je me base sur le fait que :
J'avais installé un init systemd minimal sur un système ARM et ça démarrait rapidement mais vu le peu de services lancés c'est un peu normal et j'ai pas vraiment regardé plus loin sur la consommation mémoire ou quoi (en même temps faut voir ce qu'on appelle "petite machine", c'était quand même un CortexA9 1GHz dual core avec 1Go de RAM).
Sinon il me semble que dbus est une dépendance de systemd parce que Lennart propose un set de fonctionnalité fixé, mais rien ne semble vraiment en dépendre (pas systemctl par exemple), donc à mon avis un petit patch devrait permettre de désactiver facilement dbus.
[^] # Re: la guerre de s unices
Posté par nud . Évalué à 3.
systemd dépend de la libdbus car il propose une "activation dbus" similaire à l'activation par socket, mais utilisant un nom dbus. Si on avait un autre mode d'IPC de type bus répandu il dépendrait probablement de la lib idoine pour fournir également une activation paresseuse pour ce protocole d'IPC.
[^] # Re: la guerre de s unices
Posté par gouttegd . Évalué à 10.
C’est vrai que l’init System V est un truc trop récent et trop peu utilisé en production pour avoir été longuement testé.
(Et que dire de l’init BSD, c’est carrément expérimental ça, faut aimer jouer avec le feu pour utiliser un truc aussi peu rôdé.)
[^] # Re: la guerre de s unices
Posté par zebra3 . Évalué à 6.
Par curiosité, laquelle ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
# Pas compris
Posté par lathan . Évalué à 5.
Quel intérêt de lier systemd et udev ? Des performances, des fonctionnalités, une meilleur architecture ?
Un fork est-il nécessaire ? Serait-il impossible de proposer un patch pour udev, avec les même avantages, mais sans dépendance dure entre systemd et udev ?
Sans connaître les motivations qui poussent à ce fork, difficile de se faire une opinion, et de savoir si c'est une question de facilité pour les développeurs de systemd, ou un fork réellement justifié.
[^] # Re: Pas compris
Posté par Misc (site web personnel) . Évalué à 4.
Au yeux de celui qui forke, c'est toujours justifié, la question est plus "est ce que le fork va tenir la route" ( perso, j'aurais tendance à dire "non" ). Car c'est bien joli de forker, mais faut le maintenir. C'est pas faire le git clone le souci, c'est les 500 git commit et push par la suite.
# « On ne vous met pas le couteau sous la gorge »
Posté par Tsomi . Évalué à 10.
Il y a quelques temps on disait que Lennart n'imposait pas ses créations aux autres… eh bien LOL.
C'est vraiment fatigant toutes ces distribs qui imposent leurs « technologies ». Qu'ils cherchent à mettre au point de nouveaux trucs, OK, que certains les aiment et en veulent sur leurs machines, OK. En revanche, y aller à coup de « c'est moi qui développe tel outil standard » et « c'est moi qui développe tel nouveau joujou, donc autant lier les deux pour que tout le monde utilise aussi mon joujou parce que ça me fait du bien à l'égo », ça saoule. Red Hat a trouvé sa petite variante du embrace, extend and extinguish, il semblerait.
On a affaire à une sorte de mondialisation des distributions, tout se ressemble et tout devient fade. Et cela est vaguement soutenu par quelques kékés qui pensent que c'est un bien pour que Linux soit « prêt pour le desktop » (re-LOL).
Bientôt quoi ? Xorg ne voudra plus rien lancer d'autre que Gnome 3 ? Personnellement, je suis venu sur Linux pour la liberté de choisir, enfin bon…
a systems programmer has seen the terrors of the world and understood the intrinsic horror of existence
[^] # Re: « On ne vous met pas le couteau sous la gorge »
Posté par Sufflope (site web personnel) . Évalué à 7.
T'aimes pas, bah tu utilises une autre distrib que celles que tu décris. OK.
Bah c'est-à-dire que si ça déplaît à toute la planète… allez-y les mecs ! Faites un truc qui plait à tout le monde ! Du coup tout le monde délaissera le boulot de Redhat !
Les quelques kékés qui financent tous les développements. Mais, vas-y, ton garage attend tes 4 potes.
[^] # Re: « On ne vous met pas le couteau sous la gorge »
Posté par Tsomi . Évalué à 10.
J'utilise Slackware depuis fin 2005, si tu veux savoir.
Et son mainteneur, Patrick Volkerding, commence à avoir du mal à résister à certains changements. Il ne veut pas de PAM, mais va finir par l'ajouter parce que tous les gros composants ne laissent plus la possibilité de s'en passer à moins de patcher. Et à mon avis, il va finir par devoir faire pareil pour PulseAudio et systemd, alors que ces composants ne correspondent pas à sa vision des choses. C'est lui qui le dit.
Finalement, je suis passé à OpenBSD parce qu'ils m'ont l'air de mieux tenir le coup, mais ça n'a pas l'air tellement facile pour eux non plus…
Je pense que c'est vain et dangereux de vouloir faire un truc qui plait à tout le monde. Par contre, laisser la possibilité à chacun de choisir ce qu'il préfère, c'est toujours une bonne chose, selon moi.
J'aimerais juste avoir la possibilité de garder mon init BSD quelques années, entre autres. Mais ça sent le sapin.
Tu peux garder ce ton de merdeux condescendant pour tes amis parisiens. Patrick Volkerding, dont je parlais plus haut, développe sa distrib Linux depuis 20 ans avec quelques potes, je pense que son point de vue sur l'écosystème Linux est quand même plutôt pertinent. Il n'a pas le portefeuille de Red Hat, mais j'aimerais qu'il puisse défendre sa vision des choses encore un moment.
Systemd est pertinent pour pas mal de distribs et d'utilisateurs, mais, dans tous les cas, le fait que udev soit absorbé par systemd est une aberration. Surtout quand, quelques mois plus tard, les gros composants (développés par ceux qui ont le portefeuille) casseront la compatibilité avec l'ancienne version d'udev.
Les « kékés » dont je parlais, c'était une référence à quelques blogueurs qui pensent qu'il ne devrait exister qu'une seule distrib Linux et que nous devrions tous y contribuer pour aller combattre le méchant Windoze. Et accessoirement, Lennart serait notre messie. Ils traînent parfois ici et me font à la fois peur et rire.
a systems programmer has seen the terrors of the world and understood the intrinsic horror of existence
[^] # Re: « On ne vous met pas le couteau sous la gorge »
Posté par Zenitram (site web personnel) . Évalué à -1.
Gni??? Pas facile? C'est pas bientôt fini? "imposer", "pas facile", mais… Fait le boulot, point. Ils offrent, ils n'obligent pas. Par contre ils sont libres de ne pas faire ce que tu voudrais, tant que tu n'es pas leur employeur.
Eh oh, c'est qui qui balance des "imposer" n'importe comment? Bordel, c'est libre! Bordel, on est libre de ne pas prendre! Le reste existe toujours, et tu peux forker si plus personne ne s’intéresse à ta vision. Ah oui, il faudra bosser, mais il est hors de question d'être ton esclave aussi. Ils sont libres, comme toi.
C'est sûr, à continuer comme ça depuis 10 ans, ta vision est… Clairvoyante.
[^] # Re: « On ne vous met pas le couteau sous la gorge »
Posté par Tsomi . Évalué à 10.
Ah, ça a mordu.
L'argument bien facile du « fais le boulot » et « t'es libre de forker ».
Il y a une différence de ressources entre la boîte qui finance les développeurs et de simples utilisateurs qui n'en seraient pas satisfaits.
Surtout quand la boîte s'en fout des autres points de vue. Voir les citations de Lennart plus haut, ou les listes de diffusion d'OpenBSD où tu liras des choses marrantes sur les développeurs de GCC ou Mozilla, par exemple.
Parfois, ça peut tout à fait se comprendre, techniquement. D'autres fois, c'est tout à fait intentionnel et ça pourrait facilement être évité. Le code a beau être libre, il n'est pas forcément maintenable par d'autres personnes que leurs vrais développeurs.
Tu vas vraiment aller dire aux BSD d'aller forker systemd ? Ils n'en veulent pas et le code est énorme et il a été développé en partant du principe qu'il ne fonctionnerait que sur Linux. Puis Gnome ne voudra plus fonctionner sans systemd, et donc plus de Gnome sur les BSD.
Connais-tu seulement des forks qui aient coexisté sur le long terme ? Y en a toujours un qui étouffe l'autre. Et à mon avis, ça sera celui de Red Hat, parce qu'il sera utilisé par une majorité de distribs. Et une bonne partie de celles-ci se mettront à l'utiliser parce que d'autres composants casseront, à leur tour, la compatibilité pour tout ce qui est différent de systemd.
a systems programmer has seen the terrors of the world and understood the intrinsic horror of existence
[^] # Re: « On ne vous met pas le couteau sous la gorge »
Posté par Zenitram (site web personnel) . Évalué à 8. Dernière modification le 04 septembre 2012 à 23:11.
Tu as dû louper la partie : on n'est pas ton esclave. La liberté, c'est aussi la liberté de faire ce qu'on a envie (et ce qu'on croit meilleur)
C'est ton problème. A toi de trouver le financement pour ce qui te plait, ce que tu crois meilleur, à mettre les gens d'accord. Le libre n'est pas faire ce qu'il te plait gratos. Et Lennart n'est pas ton employé. La, il semble que le monsieur, avec ses priorités, arrive à attirer suffisamment de monde pour que ça marche. Lui. A toi de démontrer que ta solution est meilleure.
C'est ça la beauté du libre aussi. Etre libre.
[^] # Re: « On ne vous met pas le couteau sous la gorge »
Posté par Tsomi . Évalué à 10.
La liberté n'existe vraiment que quand elle ne restreint pas sciemment celle des autres.
systemd ressemble de plus en plus à un cheval de Troie. Il touche aux scripts de démarrage, il touche à Gnome, il touche à udev. Je te parie que d'ici 2 ans, vouloir se passer de systemd sera quasiment impossible.
J'ai l'impression d'avoir un ultra-libéral devant moi. Quelqu'un abuse de sa situation, mais heureusement je suis libre de faire pareil si je ne suis pas content, quel argument et quelle idée de la liberté (t'as qu'à avoir un bon portefeuille si tu veux défendre ta vision des choses !).
Je ne demande pas à démontrer que ma solution est meilleure. J'aimerais juste que ma vision des choses puisse continuer de cohabiter avec la sienne. Actuellement, je peux encore me passer de systemd, techniquement, mais ça ne va pas durer. Que Fedora ait besoin, développe et utilise systemd, c'est normal. Qu'elle empêche les autres distributions de s'en passer (indirectement mais tout à fait intentionnellement), c'est anormal. Ils empêchent volontairement la compatibilité avec tout ce qui ne les intéresse pas (et c'est pas un patch qu'il faudrait, mais une totale réécriture) et ensuite ils rendent un composant majeur dépendant de ce nouveau composant.
Je dois te dire que dans ma tête, quand j'évalue un logiciel, j'ai une cinquième liberté fondamentale en tête. Celle de se dire « est-ce que ce logiciel n'empêchera pas le développement d'alternatives ? ». Dans ce sens-là, des composants tels que xf86-video-nv ou systemd n'ont pas l'éthique libre, pour moi. Car ils m'enlèvent une liberté de façon tout à fait intentionnelle.
a systems programmer has seen the terrors of the world and understood the intrinsic horror of existence
[^] # Re: « On ne vous met pas le couteau sous la gorge »
Posté par pasBill pasGates . Évalué à 3.
systemd ressemble de plus en plus à un cheval de Troie. Il touche aux scripts de démarrage, il touche à Gnome, il touche à udev. Je te parie que d'ici 2 ans, vouloir se passer de systemd sera quasiment impossible.
Ben si ce sera possible, il te suffira de creer quelque chose de meilleur et les gens l'adopteront. Il n'y a rien qui empeche les gens de modifier le code ou bien ?
Je ne demande pas à démontrer que ma solution est meilleure. J'aimerais juste que ma vision des choses puisse continuer de cohabiter avec la sienne. Actuellement, je peux encore me passer de systemd, techniquement, mais ça ne va pas durer.
Fais un fork, ou convainc les gens que ta solution vaut la peine d'etre supportee. Simplement dire "je veux pas changer" n'est pas une raison suffisante pour se taper la maintenance de ton truc, sinon fais le toi-meme.
Je dois te dire que dans ma tête, quand j'évalue un logiciel, j'ai une cinquième liberté fondamentale en tête. Celle de se dire « est-ce que ce logiciel n'empêchera pas le développement d'alternatives ? ». Dans ce sens-là, des composants tels que xf86-video-nv ou systemd n'ont pas l'éthique libre, pour moi. Car ils m'enlèvent une liberté de façon tout à fait intentionnelle.
Tu peux toujours forker et avoir ton propre truc, rien ne l'empeche. Et au final si ta solution est meilleure, alors les gens l'adopteront, si non, ben c'est probablement une bonne chose qu'ils ne se tapent pas le support de ton truc.
[^] # Re: « On ne vous met pas le couteau sous la gorge »
Posté par Zenitram (site web personnel) . Évalué à 4.
Elle peut : tu peux prendre l'ancien udev, et travailler dessus. D'ailleurs, c'est le cas ici. Tu n'as toujours pas dit pourquoi des mecs que tu ne payes pas devraient bosser gratos pour toi et faire un truc qu'ils trouvent inutiles.
Plutôt à un mec qui se tape aussi des gens qui pensent savoir ce qui est mieux pour le monde, qui se tape d'autres personnes qui voudraient que que ce mec devrait faire des choses gratos pour eux parce que "tu comprend, il faudrait que je puisse continuer avec l'ancien système qui ne te sert plus", bref qui se tape des sangsues qui veulent le beurre, l'argent du beurre et le cul de la crémière.
Les autres, ceux qui ne développent pas, savent tout mieux que le développeur de ce qu'il y a de mieux et d'important à faire. Ou pas.
Ici, systemd n'enlève aucune liberté, tu es tout à fait libre de ne pas l'adopter. D'ailleurs, il y a un fork. On va voir si il y a assez de gens intéressés par ce fork… Tu aurais aussi pu avoir tout le loisir d'embaucher Lennart ou sponsoriser financièrement la perte de temps à faire ces maintenances inutiles pour lui (ça serait utile pour lui du coup), mais non, ici, on râle sur un forum, c'est gratuit c'est plus facile.
Lennart fait ce pour quoi il est payé, que ça vous plaise ou non c'est la vie. Ca ne vous plait pas, libre à vous de proposer mieux (par exemple un système qui permet de "cohabiter" avec les autres). On va voir juste si vous arrivez à être aussi bon et rapide ("time to market") que lui.
Le problème que je vois est surtout que quand un produit marche, il faut surtout le casser au maximum, s'en plaindre, dire que "c'et pas dans l'esprit du libre" qui n'existe pas (hop, on invente une cinquième liberté perso). Avant c'était Ubuntu le grand méchant, c'est un peu passé, hop le suivant est systemd. Jaloux? Le point commun? Ca répond au besoin des gens, qui l'adoptent.
[^] # Re: « On ne vous met pas le couteau sous la gorge »
Posté par gnumdk (site web personnel) . Évalué à 9.
Dans ce sens-là, tu dois penser la même chose de udev avant systemd non? Ce truc codé pour Linux et qui bloque la liberté des BSDistes…
[^] # Re: « On ne vous met pas le couteau sous la gorge »
Posté par Sufflope (site web personnel) . Évalué à -7.
Bah… ouais.
Salut, dinosaure.
[^] # Re: « On ne vous met pas le couteau sous la gorge »
Posté par Tsomi . Évalué à 10.
"Those who don't understand Unix are condemned to reinvent it, poorly." – Henry Spencer
Salut, petit système d'exploitation qui me plaisait bien. Tu vas devenir un Windows gratuit très mauvais.
a systems programmer has seen the terrors of the world and understood the intrinsic horror of existence
[^] # Re: « On ne vous met pas le couteau sous la gorge »
Posté par groumly . Évalué à -9.
Oh mon dieu!!!!
LA FIN DU MONDE!!!!
AAAAAAAAH!!!!
ON VA TOUS MOURIR!!!!
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
# La lutte contre Lennart m'énerve un peu
Posté par Renault (site web personnel) . Évalué à 10.
Je trouve, particulièrement agaçant d'attaquer Lennart en lui mettant sur son dos des maux dont il n'a aucune responsabilité.
Ce type est un trolleur hors catégorie, comme Miguel de Icaza, Linus Torvals, RMS, Eric Raymond, et la liste est probablement bien plus longue. Je suis d'accord dessus, mais troller n'a aucun rapport avec le travail effectué. On peut critiquer les personnes précédentes, dont Lennart, pour leur trolls et réactions parfois très sévères mais techniquement pour la plupart d'entre eux, le travail reste d'une grande qualité.
Lennart est donc critiquable pour ses prises de positions, soit. Cependant, je trouve étonnant qu'on reproche toujours à Lennart ses logiciels alors que la plupart des distributions ont adopté son travail et dont il n'a aucun pouvoir de décision dans ces équipes si différentes. Oui Lennart travaille pour Red-Hat ce qui lui a ouvert les voies de Red-Hat et Fedora. Je veux bien croire que Red-Hat a une influence décisionnel dans l'écosystème GNU/Linux. Mais si c'était de la merde en boîte, j'ai de gros doutes que Debian, Ubuntu, Mandriva/Mageia, Suse, ArchLinux et autres acceptent ces logiciels en standard ou options. D'autant plus que certaines équipes de dévs n'hésitent pas à aller en contre-sens vis à vis de Red-Hat s'ils jugent nécessaires.
Donc Lennart n'a rien imposé du tout à qui que ce soit, à aucun projet que ce soit. Donc j'ai du mal à voir le désastre ou le problème. Si les distributions suivent, avec leurs développeurs expérimentés, je pense qu'il y a de bonnes arisons sans subir de menaces de la part de Lennart (qui n'a de toute façon aucun moyen de pression).
Et je peux également ressortir la problématique de la compatibilité UNIX. Oui UNIX c'est un système robuste et large avec un ensemble d'API commun pour facilité les portages et l'administration système de manière général. Le problème est que trop de compatibilité tue la compatibilité. *BSD ne doit pas être un Linux sous une autre licence, si c'était le seul intérêt de *BSD ça n'intéresserait pas grand monde. Il faut des différences entre les systèmes, c'est bien pour l'innovation, les performances et les possibilités. J'ai du mal à saisir l'intérêt d'avoir un gestionnaire de boot comme init commun à tous, d'autant que *BSD a suivi une voie différente que Linux sur ce point et que init montrait des signes de faiblesses. N'est-il pas mieux d'avoir des différences entre les systèmes ? Pas trop mais un minimum quand même ?
Enfin si ça vous plait d'avoir des OS qui se ressemblent tellement que la seule différence est la version de Firefox employée ou la mascotte disponible, ça vous regarde mais ça ne m'intéresse personnellement pas. Du temps que la compatibilité reste globalement bonne pour porter facilement les applications et dialogues entre système, ça me va et systemd n'est pas un frein particulier à cela.
[^] # Re: La lutte contre Lennart m'énerve un peu
Posté par Renault (site web personnel) . Évalué à 9.
J'ajoute volontiers qu'on a de la chance d'avoir des systèmes sous licence libre ce qui permet à chacun d'apporter ce qu'on veut.
Si vous souhaitez ne pas dépendre de systemd pour une raison ou une autre, vous pouvez participer à un projet pour ça. Vous pouvez porter systemd pour avoir ce système disponible pour *BSD, Hurd, Plan 9 et autres ce qui permettrait de garder une compatibilité entre « UNIX ».
En tout cas, vous ne pouvez forer personne de faire quelque chose qu'il ne veut pas pour vous faire plaisir. Les développeurs cherchent souvent à se faire plaisir à eux d'abord. Donc à moins de payer des gens pour ça, vous pouvez donner votre touche personnelle aux projets. ;)
[^] # Re: La lutte contre Lennart m'énerve un peu
Posté par neil . Évalué à 10.
C’est le sujet de ce journal. L’incorporation d’udev à systemd est une forme de chantage, que le fork tente de corriger. Il y a aussi eu la tentative de dépendance obligatoire dans GNOME.
Au contraire, les Linux actuels utilisent de systèmes d’initialisation différents (par exemple : SystemVinit, OpenRC, upstart, systemd). Le problème de systemd est justement qu’il tente de se rendre obligatoire (par udev ou par GNOME). Si systemd fournissait une alternative non obligatoire au système d’initialisation, on pourrait se contenter de l’ignorer si ça ne nous plaisait pas.
Les logiciels libres ce n’est plus seulement les libertés fondamentales d’accès aux sources et de modification. C’est aussi de pouvoir choisir ce que l’on veut dans l’écosystème, c’est à dire l’interopérabilité.
[^] # Re: La lutte contre Lennart m'énerve un peu
Posté par Renault (site web personnel) . Évalué à 5.
Bof non, ce n'est pas du chantage. Les gens peuvent abandonner systemd si ça ne leur va pas, ou de garder udev également d'autre part si besoin.
Gnome n'a pas accepté le fait de dépendre de systemd, même s'il a proposé il ne pouvait pas l'imposer à Gnome s'ils ne le voulaient pas (et si Gnome avait accepté, ils en ont le droit).
Les projets udev et Gnome n'ont pas et ne sont pas obligés de dépendre de systemd s'ils ne le veulent pas. S'ils acceptent ce n'est pas la faute à Lennart ou systemd en soit.
Je ne vois aucune des 4 libertés qui rendent cette disposition obligatoire… Au contraire, un logiciel libre est libre de se foutre des autres projets s'il le souhaite… Et chacun est libre de modifier ce logiciel pour l'adapter aux autres.
[^] # Re: La lutte contre Lennart m'énerve un peu
Posté par Olivier Serve (site web personnel) . Évalué à 10.
udev est devenu un incontournable. Les alternatives comme mdev ne sont pas assez complètes (pas de support lvm/raid…). Or il est clairement annoncé que l'utilisation sans systemd risque de ne plus être supportée. En gros dès que les dévs de udev vont en avoir marre, ça va gicler. Et on peut leur faire confiance, c'est déjà arrivé avec la fin du support des /var et /usr séparés depuis udev-181.
C'est bien du chantage. Et c'est le droit des développeurs de udev, je suis bien d'accord. Mais du coup il ne faut pas trop s'étonner du fork.
[^] # Re: La lutte contre Lennart m'énerve un peu
Posté par zebra3 . Évalué à -3.
Hé bien, si tout ceux qui se plaignent se retroussent les manches, ça ne sera plus un problème, non ?
Juste se plaindre sans essayer d'améliorer la situation, ça ne sert à rien.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: La lutte contre Lennart m'énerve un peu
Posté par Psychofox (Mastodon) . Évalué à 5.
Tout dépend du niveau de contributions des uns et des autres. D'autre part tout le monde n'a pas le même temps à disposition.
Enfin bref, y'a rien dans la loi qui interdit de se plaindre, au contraire c'est assez sain et vouloir nier ça est une abération.
[^] # Re: La lutte contre Lennart m'énerve un peu
Posté par zebra3 . Évalué à 1.
C'est sûr, rien n'interdit de se plaindre. Tout comme rien n'oblige non plus de prendre en compte ces plaintes.
Mais si c'est constructif et ça tente d'apporter quelque chose, il y a déjà plus de chances que ça soit écouté.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: La lutte contre Lennart m'énerve un peu
Posté par eastwind☯ . Évalué à 3. Dernière modification le 04 septembre 2012 à 21:32.
Si les informations de ce journal sont exactes, je pense pour ma part, que si un système est techniquement supérieur à un autre, il peut le prouver point par point face à ses concurrent de manière rationnelle tout en sachant que ceux ci bénéficie eux du fait qu'ils ont dans un certains nombre de domaine fait leur preuve.
Il n'est pas nécessaire d'utiliser le système de dépendance de manière détourner pour qu'il soit utilisé.
Cette technique ressemble effectivement au embrace et extend… (c'est comme le fait de rester sous Word car il est le seul à pouvoir lire les documents DOC sans aucune perte de formatage ….)
Actuellement je n'ai pas encore vue d'étude quantifée entre systemＤ et le script shell. Je ne vois pas pourquoi je devrais accordé ma confiance dans l'utilisation de ce nouveau système à moins de me le prouver par A + B.
Le fait de faire les choses de manière fallacieuse n'est pas un gage de confiance …
Un système techniquement supérieur n'a pas besoin qu'on le soutienne par des techniques détournées, il suffit à lui meme pour convaincre.
Ajouté quelque chose à la vérité c'est le transformer en mensonge…
[^] # Re: La lutte contre Lennart m'énerve un peu
Posté par HSimpson . Évalué à -4.
Euh… je suis pas sur que tu serve vraiment ton propos là:
(Le gras est de moi.)
PS: merde moi aussi j'ai rajouté du gras sur ta vérité
[^] # Re: La lutte contre Lennart m'énerve un peu
Posté par cedric . Évalué à 10.
Vous croyez que le merge de systemd et udev, c'est fait comment ? Lennart a debarque sur la ML de udev en prenant en otage les familles des developpeurs de ce projet ?!
Si udev a finit dans systemd, c'est que les mainteneurs de udev ont trouve que c'etait une bonne idee. Ils l'ont accepte et meme voulu, on merge pas du code par magie ! C'est un choix qui doit aider ces deux projets et les faire avancer plus efficacement.
Alors faut arreter avec vos theories du complot et vos histoires de restriction de liberte. Les developpeurs font les choix techniques qui leur semblent les meilleurs, si jamais ca vous convient pas faite un fork et prouve que vous avez raison en le faisant depasser l'original (C'est clairement l'objectif du fork de udev). Ce sera une competition technique et pas des idiotes theories complotistes qui veulent des rapports d'evaluation geostrategiques…
[^] # Re: La lutte contre Lennart m'énerve un peu
Posté par Olivier Serve (site web personnel) . Évalué à 7.
Forker un composant système comme udev, c'est autre chose qu'un explorateur de fichier ou un navigateur web. Le problème de la compatibilité des API risque de se poser.
Malheureusement, être le meilleur techniquement n'est ni une assurance de réussite ni même un pré-requis.
[^] # Re: La lutte contre Lennart m'énerve un peu
Posté par tiot (site web personnel) . Évalué à 8.
moi je n'ai pas le temps de lire des études comparés de tous les logiciels que j'utilise alors je fais confiance aux développeurs de ma distribution…
[^] # Re: La lutte contre Lennart m'énerve un peu
Posté par nud . Évalué à 10.
Ce point a déjà été discuté précédemment. Gnome ne dépend pas de systemd, mais il dépend d'interfaces D-Bus diverses (genre org.freedesktop.hostname1) spécifiées au sein de freedesktop.org, et qui sont pour l'instant uniquement implémentées par des petits utilitaires fournis par systemd. Ces interfaces sont triviales (vraiment) et peuvent être implémentées facilement par un autre outil.
Il s'agit juste de déplacer la maintenance des outils spécifiques aux distros au sein des distros au lieu de les garder au niveau de l'upstream, car de toute façon les outils upstream (system-tools-backend) ne supportaient que redhat, debian et opensuse.
[^] # Re: La lutte contre Lennart m'énerve un peu
Posté par oao . Évalué à 7.
Pourquoi ces interfaces sont-elles fournies par systemD, et non par un programme autonome ? Elles interagissent en profondeur avec SystemD, ou est-ce juste car c'est le même auteur ?
[^] # Re: La lutte contre Lennart m'énerve un peu
Posté par nud . Évalué à 3.
Juste car c'est le même auteur, tu peux tout à fait faire tourner ces petits programmes triviaux sans systemd, certaines distro le font. Ça utilise probablement un .so commun mais ça marche aussi avec sysvinit.
[^] # Re: La lutte contre Lennart m'énerve un peu
Posté par claudex . Évalué à 6.
comme exemple il y a Ubuntu des fournis sans utiliser systemd.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: La lutte contre Lennart m'énerve un peu
Posté par cedric . Évalué à 4.
Elles interragissent reellement en profondeur avec systemd declenchant des evenements auquel des units peuvent reagir entre autre chose. Mais rien n'empeche une distrib de recoder un daemon qui a la meme API DBus. En fait techniquement, c'est la meilleur solution. Systemd fournit une infra qui permet au projet upstream de propager plus facilement leurs ameliorations dans les distribs en diminuant les acces a des fichiers ou des scripts custom.
Pour un projet upstream, c'est juste ideal. Je me plug sur l'API DBus, et je n'ai plus a avoir un truc custom par distrib. Forcement, ca facilite la vie de tout le monde, sauf ceux qui veulent etre different… A eux de developper leur demon de remplacement, c'est pas tres difficile en meme temps. Mais ca deplace clairement les problemes sur ceux qui les creent ce qui est une bonne chose.
[^] # Re: La lutte contre Lennart m'énerve un peu
Posté par Batchyx . Évalué à -2.
Si tu veux remplacer systemd par un autre démon qui à la même API D-Bus, et bien désolé, mais tu dépendra toujours de D-Bus, et ça sera toujours une putain de mauvaise idée. Alors oui, tu peut te recoder la libdbus (comme ça tu pourra là faire un peu moins viellotte tant qu'à faire), mais bon, systemd est bloat de base, on pourra pas faire moins pire en étant compatible.
(Hé! j'ai cru comprendre que tu voulais une alternative à systemd, alors je t'ai recodé son interface D-Bus dans un recodage de l'interface libdbus pour que tu puisse t'interfacer avec libdbus pendant que tu t'interface avec D-Bus!)
Enfin bref, question remplacabilité et modularité on à fait mieux.
[^] # Re: La lutte contre Lennart m'énerve un peu
Posté par gnumdk (site web personnel) . Évalué à -2.
Et sinon, toi tu codes quoi de beau qu'on puisse admirer la qualité et le non bloat de ton travail, si il y'en a ce dont je me permet de douter…
[^] # Re: La lutte contre Lennart m'énerve un peu
Posté par cedric . Évalué à 2.
Wouhou, ca se transforme en troll sur DBus ! Bon, tu proposes quoi comme alternative a DBus ? Un truc libre, standard avec des outils et facilement integrable par tout le monde ?
A ma connaissance, il n'y a rien. Et non, faire des IPC direct a la mano avec les daemons, n'est pas une bonne reponse. Car cela duplique du code, rend difficile l'interoperabilite et l'ecriture de frontend alternatif.
Certe techniquement dbus, ca pourait etre plus lege, plus rapide, plus efficace, mais tu peux proposer des patchs pour ca. Je rappel, le code est libre et tous les utilisateurs de libdbus en profiteraient… Avantage d'avoir une brique comune !
[^] # Re: La lutte contre Lennart m'énerve un peu
Posté par Misc (site web personnel) . Évalué à 1.
Y a binder \o/
http://developer.android.com/reference/android/os/Binder.html
sinon, y a aussi les bons vieux RPC de Sun, pour nfs. Il y a eu corba ( bonobo ).
mais la vraie solution, c'est de mettre directement le passage de message dans le kernel, et de ressortir un micro noyau, soit à la qnx, soit le hurd.
Et je pige pas, si tout le monde veut un truc modulaire et KISS, y a le hurd. L'archi est propre, il y a du taf pour tous :
- portage de logiciel sur le hurd ( genre, ne pas utiliser MAX_PATH )
- écriture de documentation ( genre, un guide pour linuxien, comment afficher son ip, etc )
- des tests, des présentations, etc
ou du plus complexes, genre écriture de pilote, etc.
[^] # Re: La lutte contre Lennart m'énerve un peu
Posté par neil . Évalué à 2.
Oui enfin si on parle d’IPC, 9p peut faire tout ce que fait DBus de façon nettement plus propre (dans Plan9 tout est fichier, contrairement à Unix), avec une implémentation beaucoup plus légère.
[^] # Re: La lutte contre Lennart m'énerve un peu
Posté par Batchyx . Évalué à 3.
Une alternative à D-Bus ? Pourquoi pas … aucune ?
Ça ne me gène pas que D-Bus soit utilisé sur la session de madame michu. Un processus qui plante tout le bureau quand il merde, il y en a suffisamment, alors un de plus ou un de moins …
Mais sur un système de boot, non, quoi. Déjà la libdbus est extrêmement chiante à intégrer dans un programme, surtout si tu n'a pas une mainloop des années 90. Et encore faut t'il en avoir un, de programme qui tourne.
Ensuite, ne faire qu'une API qui parle à travers des sockets, c'est franchement lourdingue. Une socket, ça à plein de cas d'erreurs différents qui sont chiants à gérer pour faire des choses simples : une socket peut se fermer en plein millieu à n'importe quel moment, peut rester sans réponse indéfiniment, ou peut recevoir de la merde.
À coté, quand je fait un
service monservice reload, Je demande rien à personne. Le fork peut merder, l'exec aussi et j'ai peut-être un sigchld à ignorer, et hop c'est fini. Un système de boot pourra choisir de lancer le service directement à partir de /sbin/service ou alors pourra charger son D-Bus lourdingue et planter lamentablement avec fallback sur la première solution en cas de problème). Si j'ai envie d'une information supplémentaire sur l'opération, je peux regarder le code de retour. C'est vrai que c'est très limité, et c'est sans doute la première chose que je changerai si on me demandait de faire une API systemd-like.Et voilà comment une API qui existe presque déjà est plus simple, plus fiable, plus portable et plus facilement implémentable (et donc remplaçable) que n'importe quel machin avec du D-Bus dedans: Si tu veux causer au système de boot, tu lance un programme avec des arguments spécifiés. Va trouver un système de boot qui ne puisse pas implémenter ça !
[^] # Re: La lutte contre Lennart m'énerve un peu
Posté par flan (site web personnel) . Évalué à 5.
Pour moi, le chantage, c'est quand tu forces quelqu'un à faire quelque chose, en le menaçant de lui faire autre chose s'il n'obéit pas.
Là, je ne vois pas trop quelle est la menace brandie en cas de désobéissance, alors que c'est tout de même l'élément le plus important du chantage.
# systemd et arch
Posté par saimn . Évalué à 6.
quelques liens sur le (futur) passage d'archlinux à systemd :
http://allanmcrae.com/2012/08/switching-my-laptop-to-systemd/
http://jasonwryan.com/blog/2012/08/04/systemd/
de ce que j'ai pu lire rapidement sur les ml, ce choix a l'air approuvé par tous les dev, et j'ai tendance à faire confiance à ces gens là pour faire les bons choix. Du coup je suis passé à systemd et ca ne me marche pas plus mal qu'avant, donc d'un point de vue utilisateur ca me va :-)
Un autre lien avec un post du dev qui s'occupe de cette migration, sur les raisons techniques notamment: https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530
[^] # Re: systemd et arch
Posté par Arthur Accroc . Évalué à 10.
Ça fait plus d’un an que je suis passé à systemd sous Arch, en mode natif (à l’époque, la Fedora 15 ne l’utilisait qu’en mode compatible).
Ma conclusion principale est que systemd n’est pas stable, au sens Debian du terme, c’est-à-dire que les bugs changent régulièrement.
Étonnament (systemd n’était à l’époque qu’un paquet du dépôt community), il y a un an, tout fonctionnait nickel.
Actuellement, j’ai ce bug, qui n’existait pas à l’époque, et entre les deux, c’était NetworkManager qui partait systématiquement en sucette à l’arrêt du système et systemd qui attendait de très longues minutes après.
Et déboguer l’arrêt du système, ce n’est pas trop pratique… j’étais bien content de m’être gardé la possibilité de démarrer avec rc.sysinit.
À part ça, la prise en compte de la ligne DAEMONS de rc.conf, que j’avais désactivée (l’idée était d’être en mode natif mais en gardant la possibilité de démarrer avec rc.sysinit), a aussi été réactivée (ce n’est plus la même procédure pour la désactiver) et journald est arrivé sans que je l’aie demandé. Je me demande si je pourrai échapper à Pulseaudio, Avahi et aux prochains projets de Lennart, bons ou mauvais…
Bref, à mon avis, systemd n’est pas encore mûr et si l’on veut un truc simple et fiable, mieux vaut en rester au vieux système d’init. Pour ma part, je l’ai remis par défaut.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: systemd et arch
Posté par gnumdk (site web personnel) . Évalué à 3.
C'est un peu facile de cracher sur systemd quand on utilise ArchLinux…
Ca fait des mois que l'init standard Archlinux me fait des FAILS sur toutes mes machines aléatoirement (un shutdown sur trois) donc dois je en déduire que l'init Archlinux n'est pas stable ?
Par contre, sur mon laptop sous ArchLinux avec systemd, je n'ai aucun problème…
[^] # Re: systemd et arch
Posté par Arthur Accroc . Évalué à 2.
Avec systemd, les dépendances entre services sont renseignées d’origine, probablement presque toujours correctement (après, si on a par exemple mis les paramètres pour autofs dans l’annuaire LDAP, il faut peut-être ajuster soi-même).
Par contre, l’init standard démarre les services dans l’ordre où tu les as indiqués et les arrête dans l’ordre inverse. C’est à toi de mettre le bon. As-tu essayé de le changer ?
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: systemd et arch
Posté par Ambroise . Évalué à 2.
Pour Avahi, il est devenu une dépendance pour Cups sous Archlinux donc ça a déjà commencé…
Par contre, pas de dépendance à Pulseaudio à ma connaissance.
[^] # Re: systemd et arch
Posté par stopspam . Évalué à 3.
Déjà qu'il faut maintenir ces propres PKGBUILD pour samba et kvm :
Bluetooth et Avahi, ça a de la gueule sur un serveur en prod !
[^] # Re: systemd et arch
Posté par gnumdk (site web personnel) . Évalué à 2.
Mon dieu!!! Y'a deux dépendances vers une pauvre librairie, c'est la fin du monde, t'as raison, recompile tout! A ta place, je passerai sous Gentoo histoire d'optimiser un peu tout cela, ca se trouve, tu pourrais virer directement le support cups de samba, puis virer le support usb de cups, …
Et en plus, dans le cas de Arch, les paquets étant peu découpé, le service est installé mais je ne pense pas qu'il se lance tout seul.
[^] # Re: systemd et arch
Posté par Anonyme . Évalué à 4.
C'est d'ailleurs assez marrant de constater que c'est approuvé par les dev mais désapprouver par une relativement grosse partie de la communauté.
C'est exactement le même problème que lors du passage à GRUB2, de la suppression de AIF, etc.
[^] # Re: systemd et arch
Posté par zebra3 . Évalué à 3.
C'est toujours pareil : on voit que ceux qui ne sont pas d'accord sont ceux qui n'auront pas à se taper le boulot de développement et de maintenance.
Et tout ça gratuitement, bien entendu.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
# Loin de la foule
Posté par eqfm (site web personnel) . Évalué à 10.
Le truc qui me frappe avec systemd, et c’était déjà vrai avec Pulseaudio, c’est que je suis complètement largué. Largué par Linux, on pourrait me conseiller de passer à Windows. Sauf que pour comprendre le fonctionnement de Windows, il a fallu que je passe par Linux. Et du coup j’y suis resté.
La liberté de vérifier ou de retoucher le code source : pas les compétences pour ça. En revanche, la liberté de complicité avec le système, et d’en tirer le meilleur parti, Linux OK pour moi. La simplicité d’init de Slack ou d’Arch m’allaient très bien.
Linux a la réputation de ne pas être immédiatement abordable. Je le traduis autrement : il est formateur. Ou du moins il l’était. Beaucoup de windowsiens autour de moi n’arrivent pas à différencier le programme de son icône sur le bureau. Avec Linux, c’est impossible, et impossible de ne pas comprendre ce que sont un répertoire ou un fichier invisible.
Cette pédagogie ambulante était à mon avis le meilleur argument en faveur de Linux sur le bureau. Il est vrai que les facilitateurs comme Ubuntu conserveront une bonne valeur ajoutée par rapport à Windows. Il est vrai aussi que les arcanes n’ont jamais cessé d’être abscons.
Mais les profanes — entendre : tous ceux qui n’achètent pas un ordi pour devenir informaticiens — pouvaient apprendre avec Linux tout ce qu’ils ont besoin de savoir, tout ce qui permet de ne pas être largué devant sa bécane.
Or, voici qu’au bout de 15 ans d’utilisation, grâce à systemd d’abord, et surtout à la logique de débats d’initiés dont il procède si elle était amenée à s’étendre, je suis bouté hors du système. Un peu comme les bricoleurs sont dépassés par l’électronique des voitures.
Pas dramatique pour moi, si Arch casse je continuerai avec ma partition Xubuntu et le /home partagé. Mais j’entrevois disparaître le Linux que j’ai connu pédagogique, à forte valeur ajoutée pour l’utilisation familiale. Le Linux passerelle entre les pros et les quidams.
Linuxien risque de devenir être hacker ou ne pas être.
La curiosité de ne plus être un droit d’entrée suffisant.
Le créneau minoritaire de plutôt se réduire que s’agrandir.
Est-ce un bien, est-ce un mal, je ne trancherai pas.
[^] # Re: Loin de la foule
Posté par gnumdk (site web personnel) . Évalué à 1.
Euh, comprendre le fonctionnement de systemd, c'est à la porté de toute le monde, t'inquiètes que les prochains Linuxiens qui n'ont connu que cela le comprendront, après si tu ne veux pas faire d'effort…
Bref, c'est plus abordable de comprendre la conf de systemd que de comprendre la syntaxe de bash pour un profane…
[^] # Re: Loin de la foule
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 05 septembre 2012 à 14:58.
La syntaxe de bash est-elle même compréhensible.
Ca me fait rire de lire que le système actuel à coup de bash est compréhensible. Ca l'est que pour les esprits qui se sont fait tordre poru arriver à lire du bash. Pour les autres, systemd a l'air bien plus lisible. Ah la résistance au changement…
[^] # Re: Loin de la foule
Posté par jbbourgoin (site web personnel) . Évalué à 10.
Je suis assez d'accord.
Craindre l'arrivée de systemd parce que cela fait 10 ans (ou plus) que l'on utilise et maîtrise sysV, que l'on ne veut pas tout réapprendre et surtout risquer bugs et plantages pour cause de méconnaissance d'une techno neuve, je le comprends tout à fait.
Après tout, quand ça fonctionne comme on veut, on veut pas que ça change, et je le comprends.
Mais reporter la faute sur systemd alors que l'on ne connait pas l'outil, est injuste.
Quel est le problème ? Systemd s'impose ? Et alors ? Lennart a menacé de mort tous les mainteneurs de distros du monde pour passer à son truc ?
La réalité c'est que les besoins en informatique changent, et que le but d'une distro et de répondre à des besoins plus ou moins divers en fonction de l'orientation du projet. Mais jamais une distro n'a pour objectif de répondre à mon besoin à moi et uniquement le mien.
Si systemd s'impose c'est peut-être simplement que mes besoins ne sont pas ceux de la plupart des utilisateurs des distros concernées (ou de leurs mainteneurs).
De plus la situation est loin d'être catastrophique :
Amoureux des scripts bash ? Systemd est compatible avec les scripts sysV.
Unixiens pur et dur ? Ça fait longtemps qu'il fallait passer à BSD, et c'est là peut-être l'occasion de s'y mettre.
Ça me fait penser au fork de Gnome 2 ça. Pourquoi forker Gnome 2 quand XFCE existe ? Pour contrer le sort ? Parce qu'on ne veut pas penser un monde dans lequel Gnome 3 existe ?
Franchement XFCE et Gnome 2 c'est kif-kif-bourricot. À ceci près que le premier est plus léger et plus freedesktop-compliant (ce qui devrait plaire au unixiens-anti-lennart…).
Pour le reste Linux et son écosystème n'a jamais été un Unix pur et dur.
C'est pour ça que je l'aime, son côté "laboratoire" d'idée.
Alors oui, moi, les systemd, les upstart, les pulseaudio et les Gnome 3, ça me plaît. Les FreeBSD et les jails aussi.
Y a suffisamment de choix pour que tout le monde soit content non ?
[^] # Re: Loin de la foule
Posté par eqfm (site web personnel) . Évalué à 6.
Je me suis intéressé à Systemd. Je n’ai pas trouvé de documentation qui me soit accessible.
Il est possible que la question se réglera pour mon cas personnel.
Ce n’est pas cela qui m’inquiète. Je me suis formé à Linux quand il démarrait par étapes visibles et bien documentées.
La meilleure façon de marcher, c’est de mettre un pied devant l’autre. Ça n’a l’air de rien, mais cette progression par étapes de Lilo au choix d’un window manager en passant par le prompt, quand on découvre l’ordinateur, aide énormément pour la suite à situer les éléments les uns par rapport aux autres.
À l’inverse, je vois beaucoup de profanes totalement perdus quand ils se retrouvent immédiatement devant l’interface de Windows. Ils ne savent pas par quoi commencer devant cette profusion, et ils ne savent pas non plus par quel bout prendre la documentation, quand documentation il y a.
Quelques années plus tard, ils ont encore besoin d’aide pour retrouver leurs fichiers, dans les cas extrêmes. Tous les cas ne sont pas extrêmes, heureusement. Et certains s’en sortent très bien. Mais que de temps gagné avec Linux !
Systemd et Pulseaudio m’inquiètent parce qu’ils semblent avant-coureurs d'un fonctionnement sur mode circulaire, comme l’interface de Windows, et je crains qu’à terme Linux devienne inabordable pour le commun des mortels.
Je ne critique pas cette évolution. Je défendrai bec et ongles qu’il a représenté une formidable opportunité pour le grand public. Mais qui en aura profité ? Il y faut de la curiosité et un concours de circonstances. Ou du marketing.
Je vous parle d’un temps que les programmeurs ne peuvent pas connaître : l’ordinateur tout nouveau dans le paysage, et qu’il va falloir dompter. Ça vous paraît simple. Pour d’autres c’est plus compliqué.
Et Linux pouvait leur simplifier la tâche. Hors mézigue, je ne suis pas sûr qu’il ait jamais tenu ce rôle, qui lui allait comme un gant. Alors, peu importe peut-être la disparition de ce potentiel.
[^] # Re: Loin de la foule
Posté par gnumdk (site web personnel) . Évalué à 2.
https://wiki.archlinux.org/index.php/Systemd#Writing_custom_.service_files
[^] # Re: Loin de la foule
Posté par eqfm (site web personnel) . Évalué à 0.
Sorry, I don't speak English.
Je connaissais déjà cette page. Et j’en avais trouvé une ou deux autres en Français, pas sur le site d’Arch.
Il m’est arrivé de déchiffrer d’autres pages in English, pas celle-là.
Et celles en Français non plus.
Ça viendra peut-être un jour mais merci quand même.
[^] # Re: Loin de la foule
Posté par zebra3 . Évalué à 4.
Oui enfin, pour travailler dans l'informatique, savoir lire l'anglais technique est un peu la base.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Loin de la foule
Posté par Blackknight (site web personnel, Mastodon) . Évalué à -1.
C'est sûr qu'avec une réflexion comme ça, Linux va toucher de plus en plus de monde…
Donc si tu cherches un peu, tu verras qu'eqfm ne bosse pas forcément dans l'informatique et que je pense qu'il n'est pas le seul à utiliser Linux et à ne être pas être "informaticien".
[^] # Re: Loin de la foule
Posté par zebra3 . Évalué à 9.
OK, raccourci trop rapide.
Je vais préciser ma pensée :
« pour administrer un ordinateur, savoir lire l'anglais technique est un peu la base. »
Parce que j'ai un peu de mal à voir qui d'autre qu'un admin peut avoir à chercher la doc de Systemd.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Loin de la foule
Posté par Zenitram (site web personnel) . Évalué à 4.
Attend, j'ai l'impression dans dans une faille spatio-temporelle? La on parle bien de systemd, ou d'un utilisateur normal d'ordinateur?
Une personne qui utilise Linux n'a pas besoin de bidouiller systemd, et son interface est en français (ou autre, il y a plein de traductions)
Une personne qui bidouille Linux en touchant à systemd, ce n'est plus un simple utilisateur de Linux et alors désolé mais ne pas comprendre l’anglais technique ça craint un max quand même. Et dire qu'on se pose encore cette question en 2012, et ben…
Bientôt, on demandera à mettre les commentaires pour chaque ligne de code on de conf dans 100 langues plutôt que l'anglais avant que le code soit accepté, comme si on a que ça à foutre…
Alors un conseil : avant de s’intéresser à systemd, il vaut mieux apprendre l’anglais de base, c'est autrement plus utile, bien plus important, ne serait-ce que pour voyager un peu en dehors de la France. Drôles de priorités.
[^] # Re: Loin de la foule
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 06 septembre 2012 à 10:55.
Ben ouais, je suis un vieux con et un vieux con qui a eu des non-anglophones en formation de programmation. D'ailleurs, c'était à l'époque où Microsoft, comme toi, s'est rendu compte que fournir des supports en français pour les dites-formations est totalement inutile car le programmeur doit connaître l'anglais technique. Enfin, il faut peut-être plus y voir un intérêt économique qu'autre chose.
Mais sinon quand toutes les notices d'utilisation seront en chinois, tu diras quoi ? Qu'il est absurde de pas parler le chinois ?
Pour info, en dehors de la France, y a encore plein de pays où on ne parle pas forcément l'anglais et encore moins l'anglais technique.
C'est ton avis mais dis-toi que pour d'autres, tu fais de l'informatique plutôt que du VTT alors que le VTT c'est bon pour la santé… Drôle de priorités
[^] # Re: Loin de la foule
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 06 septembre 2012 à 11:09.
Voila, tu n'as pas d'argument pour ce dont on parle (un élément très technique), tu noies le poisson avec un truc qui n'a rien à voir (des manuel d'utilisation de l'outil).
Sinon, si le chinois devient la langue de référence pour la communication internationale, oui il sera absurde de ne pas parler chinois. On n'en est pas la. C'est triste de voir qu'en 2012 on reste encore sur cette idée de ne savoir lire qu'une seule langue est acceptable. Tu m'étonnes que la France perd de sa stature (c'est con, car le français perd même son statut de langue diplomatique).
Il n'est pas non plus important de savoir nager. Ni conduire. Mais on peut aussi parler de savoir compter. ça peut être utile aussi, bien plus que systemd traduit pour quelques personnes ne comprenant pas l'anglais. Il y a des domaines primordiaux quand même, nager, conduire, l'anglais de base lu en font partie!
[^] # Re: Loin de la foule
Posté par eqfm (site web personnel) . Évalué à 0.
J’en connais beaucoup dont la scolarité a été perturbée par des raisons x ou y et parfois dès la naissance. Laissons une chance à ceux qui ne sont pas nés avec une cuillère dans la bouche, et n’ont pu acquérir la maîtrise de l’anglais qui en découle. Laissons une chance à ceux qui ont préféré apprendre d’autres langues, en admettant même que le choix leur ait appartenu.
[^] # Re: Loin de la foule
Posté par Zenitram (site web personnel) . Évalué à 2.
Ca empêche d’apprendre plus tard? Ca n'a pourtant pas l'air d’empêcher l'apprentissage de systemd après la scolarités…
On ne parle pas de maîtrise, mais de base.
J'en connais un paquet qui ont préféré d'autres langues. Mais ces personnes ont aussi des bases d’anglais.
Va falloir trouver d'autres excuses pour convaincre.
[^] # Re: Loin de la foule
Posté par eqfm (site web personnel) . Évalué à -1.
L’anglais c’est une chose, systemd c’en est une autre, l’écosystème systemd-udev c’en est encore une autre.
Oui, des difficultés initiales ou tout simplement des urgences bouffeuses de temps peuvent rendre impossible l’apprentissage tardif de l’anglais. Ne cherche pas à comprendre, ce n’est pas une équation.
Et je ne parle pas de mon cas personnel sur ce coup-là.
Un anglais de base pour lire de la documentation technique : tu parles sérieusement ?
J’en resterai là parce que le journal est axé sur les conséquences de l’interdépendance entre udev et systemd. Faut-il ou non devenir des Zenitram clonés, le sujet m’intéresse déjà moins.
[^] # Re: Loin de la foule
Posté par zebra3 . Évalué à 4.
Je ne savais pas qu'en loupant sa scolarité, on perdait toute chance de s'éduquer par la suite.
Grande nouvelle : à l'école, tu n'apprends quasiment rien. Tout ce que je fais aujourd'hui, je l'ai appris sur le tas. Les études ne m'ont servi qu'à apprendre une méthodologie et une façon de travailler.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Loin de la foule
Posté par Alex . Évalué à 3.
C'est vrai à partir du lycée, mais il me semble que ce que tu apprends bettement avant sert de socle, socle particulièrement difficile à rattraper par la suite (il suffit de voir les galères de ceux qui tentent d'apprendre à lire à 30 ans)
[^] # Re: Loin de la foule
Posté par Zenitram (site web personnel) . Évalué à 2.
C'est clairement dur de rattraper la scolarité, oui.
Mais à partir du moment où tu t’intéresse à systemd, on peut considérer que tu as le niveau pour apprendre l'anglais, on est loin de l'apprentissage de la lecture.
Tout est question de priorités…
[^] # Re: Loin de la foule
Posté par eqfm (site web personnel) . Évalué à 1.
La question au départ n’était pas l’apprentissage de systemd ou de la lecture, mais celui de l’ordinateur.
Et des répercussions de l’interdépendance entre systemd et udev sur les vertus pédagogiques de Linux. Mais je reconnais que ça peut être un faux problème, vu que dans ma zone je n’ai jamais vu de non-informaticiens, à part moi quand je croise une glace, intéressés par Linux.
[^] # Re: Loin de la foule
Posté par oao . Évalué à 1.
Tu as pensé à traduire le manuel en BD pour ceux qui ne savent pas lire ? C'est horripilant ce centrisme sur les élites qui savent lire ! Tu ferras quoi quand la configuration de Systemd se fera en brainfuck ?
[^] # Re: Loin de la foule
Posté par eqfm (site web personnel) . Évalué à 1.
Entièrement d’accord avec des nuances.
Question difficultés sociales, la pente peut être très longue à remonter. Je ne parle pas de moi, mais j’ai eu à côtoyer, voire à m’impliquer. Et dans ces cas-là, ce n’est pas l’anglais qu’il urge d’apprendre, c’est l’écriture du français.
À l’école, ce que tu apprends, ce n’est pas seulement ce qu’on t’enseigne. Tu y apprends aussi à te sentir plus ou moins en phase avec la société. Et quand tu es en phase avec ta classe, ta scolarité même si tu es un cancre, avec la société, ça te paraît tellement naturel que tu auras par la suite du mal à mesurer les difficultés de ceux qui n’ont pas eu cette chance.
L’essentiel de ce qui t’est utile, tu l’apprends effectivement hors de l’école. Mais le passage plus ou moins réussi à l’école n’est pas sans incidences sur cet apprentissage encore.
[^] # Re: Loin de la foule
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 1.
Nous n'étions pas en train de parler de la qualité technique de systemd ou de sa configuration, on est en train de parler de la disponibilité d'une documentation de l'outil donc je n'ai pas d'argument à donner sur l'élément technique.
Maintenant crois-tu que parce que quelqu'un ne parle pas anglais, il n'a pas envie de comprendre un peu plus comment son système fonctionne, comme le permet Linux ? Et donc, tu préfères largement dire à cette personne :
C'est assez gonflé.
Effectivement, d'un point de vue technique, d'après ce que j'ai pu voir, systemd n'est pas horrible à configurer. Cela ne demande pas forcément un grand niveau d'anglais pour comprendre approximativement mais ne pas traduire, c'est fermer la porte à des gens que ça intéresse et qui n'ont pas forcément ton niveau en anglais.
Là, c'est toi qui rajoute n'importe quoi. Mais si tu veux parler de ça, pas de problème. Combien d'Anglais et d'Américains continuent à étudier le français ? Eux pensent qu'une seule langue est acceptable, tant que c'est la leur. Alors oui, je suis d'accord qu'il faut apprendre l'anglais mais ce n'est pas une obligation.
Tant que des gens auront ton discours, y a pas de raison que ça s'inverse et que la langue française survive puisqu'elle va devenir inutile.
[^] # Re: Loin de la foule
Posté par eqfm (site web personnel) . Évalué à 2.
L’intérêt, pour un non-informaticien, n’est pas de pouvoir bidouiller son système, mais d’en comprendre le fonctionnement pour en tirer le meilleur parti. Pulseaudio, le mariage de raison d’udev et systemd, ça tourne à l’écosystème spaghetti, comme l’interface de Windows. Ça ne facilite pas la compréhension, et partant la prise en main par les non-informaticiens. Je bidouille très peu, uniquement par nécessité et en suivant le guide. Mais tout ce que j’ai appris de Linux m’aide énormément pour utiliser ne serait-ce que LibreOffice.
[^] # Re: Loin de la foule
Posté par eqfm (site web personnel) . Évalué à 1.
Sauf que là il est question de Linux pour les non-informaticiens.
[^] # Re: Loin de la foule
Posté par gnumdk (site web personnel) . Évalué à 1.
Les non informaticiens qui vont être perdu sous Linux parce qu'ils ne peuvent plus comprendre le fonctionnement de l'init de leur OS (ce qui de plus est faut)… AH AH AH!
[^] # Re: Loin de la foule
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 2.
Ahahahah !! T'as raison, bosses ton anglais parce que là, t'es dans le faux :D
En tout cas, j'aime bien ton élitisme qui interdit aux non-informaticiens de s'intéresser au fonctionnement de leur OS.
[^] # Re: Loin de la foule
Posté par eqfm (site web personnel) . Évalué à 2.
Non. Un système d'init qui devient trop complexe pour devenir une porte d’entrée.
Moi je m’en fous, j’ai déjà suffisamment de pieds dans le système pour m’en tirer toujours.
Mais quand j’y suis entré, c’était quand même bien pratique de savoir par quel bout commencer.
Le système d’init, par exemple et pas que lui, était comme un alphabet.
Comparativement à Windows où manquait la pierre de Rosette.
Systemd + udev n’y enlèvera pas grand-chose immédiatement.
Mais à terme…
[^] # Re: Loin de la foule
Posté par Maclag . Évalué à 3.
J'avoue que je rejoins les autres sur le sujet: en quoi est-ce que la config de systemd te parait plus compliquée que init?
Dis-moi si je me trompe: avec sysvinit, on peut aller lire des scripts bash pour savoir ce qu'ils font. Et c'est pareil avec plein d'autres trucs sous Linux: des scripts bash, des commandes shell, on voit tout de suite ce que ça fait.
systemd est codé en C. Du coup, on ne "voit pas" ce que ça fait en se baladant dans l'arborescence. On sait que ça utilise les fichiers de config, mais pour en faire quoi? Il faut aller lire le code source…
La barrière technique pour lire un source C et le comprendre est plus élevée que pour lire un "bête" script shell.
Maintenant, si tu veux retomber en territoire que tu peux appréhender, il va effectivement te falloir lire de la doc. Ça tombe bien, entre tous les journaux et dépêches sur le sujet ici, on peut trouver ce qu'il fait et comment il marche, et tout est expliqué en Français.
Enfin, se contenter des scripts init pour comprendre l'init, c'est très réducteur, et finalement, cette facilité cache d'autres éléments importants du processus. Donc grâce à systemd, tu vas pouvoir trouver plus d'infos sur la problématique du lancement des services (démonisation, récupération du PID, tout ça: on peut lire voire écrire des scripts init sans comprendre le problème).
# Merci Lennart
Posté par wolowizard . Évalué à 10.
Merci Lennart, merci udev.
Merci car j'apprends dorénavant (bon, ça fait un an quand même) à faire la connaissance d'une petite communauté que je trouve géniale : NetBSD.
Mon opinion ne vaut sûrement rien, mais j'ai une petite envie de m'exprimer (puis pour une fois écrire sur linuxfr)
Ca fait une bonne dizaine d'années que je touche à du linux, au moins 5 ans à gentoo, système linux que j'aime bien (pour le moment).
Je ne suis pas admin. pro ( mais dépanne les windows, les linux des autres et administre mes quinzaine de bécanes chez moi) ;
je ne suis pas développeur pro. (bien que j'automatise mes tâches et que je code pour mon job. pour acquérir des données);
je suis ce qu'on pourrait appelé un simple petit utilisateur avancé.
Dans ce contexte je ne peux pas critiquer le job de Lennart bien que j'arrive à comprendre (à peu près) le système d'init. .
J'ai vecu les périodes chez gentoo avec le passage du Xorg.conf à du xml hal fdi. pour au final revenir à un Xorg.conf.
J'ai connu ( et je connais ) les systèmes en *kit (avec le mélange polkit/policykit), pour me rendre compte qu'au final ConsoleKit est deprecated.
Je connais dernièrement, l'arrivée dans l'arbre instable de gentoo une version udev où le support /usr sur une partoche autre que la racine n'est plus supporté… alors que la plupart de la doc. conseille celà. , que mes systèmes sont tous montés de cette manière depuis x années, que je n'utilise pas de initram sur gentoo depuis x années…
Comme je ne peux pas me plaindre ( je n'ai de toute façon pas droit au chapitre), j'ai fait ce que conseillent les "extrêmistes" boutonneux linuxiens (j'en étais un dans ma prime jeunesse mais c'est fini), je migre pour plus de liberté. Ca me prend du temps, mais j'en suis content.
Ma seule tentative avec systemd, c'était avec une opensuse au boulot, c'était en gros il y a un ans (oui j'avais voulu laissé la chance à opensuse). Le changement de version 11.4 vers 12.0 c'est mal passé puisque j'ai basculé sous gentoo. Systemd ne lançait pas le système, avec des messages que je ne maitrisais pas; heureusement il y avait encore une possibilité de boot avec l'init sys V. Tout ça pour dire que probablement, c'est un manque d'intégration ( un problème venant de moi-même vous pouvez me dire, mais bon je n'en étais pas à ma première expérience).
L'histoire de /usr et udev, c'est je crois la chose de trop en tout cas pour moi et pour pas mal d'utilisateurs ( cf. mailing list gentoo et forums).
Ainsi, mon seul message à propos de systemd/udev, c'est:
Testez les *BSD.
Une communauté vraiment sympa. (merci miod, gaston, bapt, imil,…)
Des systèmes KISS et stables.
Il y a bien entendu quelques problèmes, mais bon qui n'en a pas ;) ?
En tout cas merci Lennart, et bon troll!
[^] # Re: Merci Lennart
Posté par barmic . Évalué à 4.
Je suis d'accord avec toi. Je trouve cool cette remise en cause. Ça donne l'occasion de se poser des questions (la distribution que j'utilise est-elle vraiment celle qu'il me faut ? devrais-je m'impliquer plus dans ma distribution pour peser sur ses choix ? le système d'exploitation que j'utilise est-il celui qui me convient ?). C'est jamais négatif de se poser ces questions, soit ça permet de trouver mieux soit de réaffirmer les raisons de nos choix.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Merci Lennart
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 3.
Je trouve aussi que c'est effectivement une grande occasion pour tester d'autres choses.
Perso, en 2001, c'est la multitude de variantes d'emplacements de fichiers de configuration sous les différents Linux qui m'a fait passer à FreeBSD 4.2.
Après, pour ce qui est de systemd, j'ai pas trop d'avis mais effectivement, on est toujours plus à l'aise avec ce que l'on connaît et ça prend un peu la tête de ré-apprendre un énième truc.
Enfin bon, le jour où j'y serai obligé, je ferai comme les copains parce que, même si j'ai peut-être les connaissances, je n'ai ni l'envie ni le temps de m'amuser à faire et maintenir un fork de quoique ce soit.
[^] # Re: Merci Lennart
Posté par B16F4RV4RD1N . Évalué à 5.
je me retrouve dans ton commentaire.
Je n'ai pas spécialement envie de me prendre la tête avec la découverte un nouvel OS (et notamment recréer des paquets dont j'ai besoin), mais je crois que j'en ai ma claque de ces fameuses "nouveautés" ou "évolutions" (grub2, *kit, pulseaudio qui n'a jamais marché, et maintenant systemd) qu'il n'est pas possible de refuser sans faire aveux de non-remise en cause de ses habitudes de vieux.
Aussi quitte à prouver qu'il est toujours possible de changer, je préfère quand même passer à un OS qui me semble plus sain, par exemple FreeBSD via PCBSD, à moins que j'essaye Slackware. À voir. J'avais testé PCBSD il y a quelques temps, ça me paraissait très bien.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Merci Lennart
Posté par YBoy360 (site web personnel) . Évalué à -2.
C'est propre à Gentoo ce problème d'udev et de usr qui peut pas être sur une autre partition?
Je suis globalement d'accord pour dire que certaines nouvelles techno ont mis plus de temps à mûrir qu'elles n'auraient dû, et que d'autres font carrément du tord à l'utilisateur fidèle/final (je pense à Gnome 2.0, je ne connais pas Gnome 3.0). Cependant, j'apprécie énormément SystemD, que j'ai trouvé très simple à prendre en main, et que je trouve très prometteur.
Certes, ça va faire du boulot pour les admin, ça obligera peut-être certains de créer leur propre init (pour l'embarqué je croyais que c'était la règle), mais j'ai du mal à voir en quoi il ne réponds pas aux besoins du plus grand nombre, simplement de manière compréhensible.
Je pense que le mécontentement viens plus de l'admin, qui monitor des applications et surveille le système, qui ne veut surtout pas être emmerder par un truc qui en fait trop, que du développeur qui déteste les forks, les scripts et le code non optimisé.
[^] # Re: Merci Lennart
Posté par Anthony Jaguenaud . Évalué à 2.
Non, ça semble propre à systemd…
Pourquoi tout les fans de systemd crachent-ils sur gentoo ?
[^] # Re: Merci Lennart
Posté par claudex . Évalué à 2.
Systemd l'oblige maintenant mais la justification était, lors de la mise en place de cette obligation, que de toute façon ça ne marchait déjà pas (à cause d'udev je crois).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Merci Lennart
Posté par Anthony Jaguenaud . Évalué à 2.
Je réagissais car sur ma gentoo, j’ai un contre exemple. udev marche et j’ai un /usr séparé. Je dois être une exception…
[^] # Re: Merci Lennart
Posté par wolowizard . Évalué à 1.
Quelle version de udev as-tu?
Es-tu en stable ou instable?
Si tu es en stable, tu es sur une vieille version de udev et tu peux avoir une partition contenant /usr séparée de celle contenant la racine.
Si tu utilises l'arbre instable ce n'est plus le cas… et tu auras besoin d'un initramfs.
D'ailleurs tu as du recevoir la news à propos de udev:
eselect read listnews : 2012-03-16-udev-181-unmasking
[^] # Re: Merci Lennart
Posté par Anthony Jaguenaud . Évalué à 2.
Oui, je suis en stable pour udev. Le message que tu pointes, j’ai dû le lire en mars, mais depuis j’avais oublié.
De quel programme à t’il besoin qui soit dans /usr et qui ne l’était avant ? ou plutôt qu’il n’avait pas besoin avant ?
[^] # Re: Merci Lennart
Posté par Olivier Serve (site web personnel) . Évalué à 3.
Les besoins n'ont pas changé. Simplement quand un programme n'était pas encore disponible, udev mettait l'action en attente et la rejouait quand /usr et /var étaient montés. Et ça marchait très bien.
Seulement un matin les dévs en ont eu marre et on décidé que c'était "broken" plutôt que se demander si c'était pas leur architecture qui l'était.
[^] # Re: Merci Lennart
Posté par SamG . Évalué à 1.
Pourquoi tout les fans de gentoo crachent-ils sur systemd ?
Avant de propager des
idiotiesFUD, essayes un peu de te renseigner par toi-même : separate usr is broken[^] # Re: Merci Lennart
Posté par Anthony Jaguenaud . Évalué à 3.
En fait, j’ai réagi tard sur le sujet. Mais au bout d’un moment, j’en ai eu marre de lire des remarques sur gentoo. Et de lire des gens qui sont passé à GNU/Linux récemment encenser ce genre de chose parce que c’est trop bien, ça ressemble à leur ancien OS.
Je me sens vieux. Les répertoires /bin et /sbin sont là pour avoir les softs nécessaire au démarrage et /usr (note: ressemble à user), pour tout ce qui n’est utile que lors d’une session utilisateur. Pourquoi casser ça ?
Les gens quittent Windows parce que pas interropérable… puis, une fois sous GNU/Linux, on fait du Linux, parce que programmer de manière portable demande de la rigueur. Si je n’aime pas systemD, ce n’est pas pour le but (atteint partiellement par l’init gentoo), mais bien la manière de faire. Le libre ne passera jamais plus loin tant que les gens ne feront pas des applis portables.
Si j’ai été désobligeant avec quelqu’un, je le prie de m’en excuser. Mais je continue à ne pas comprendre l’intérêt.
[^] # Re: Merci Lennart
Posté par gnumdk (site web personnel) . Évalué à 4.
Ca fait 13 ans que j'utilise GNU/Linux et c'est pour ça que je fait mon vieux…
Parce que bon, j'espère que tu charges encore tes clés usb à la main parce que sinon, ca craint, ca ressemble trop à ton ancien OS (si tu l'as utilisé un jour).
Parce que ca sert plus à rien? On est plus dans les années 70, si c'était fait comme cela, c’était par contrainte, pas parce que c'est plus cool.
Ben va demander à Linus de ne plus rajouter de fonctionnalité dans son OS tant que les BSDs n'ont pas la même fonctionnalité et va demander à la même chose aux BSDistes vis à vis de Linux, tu vas te faire recevoir…
Systemd n'est pas portable, pas parce que Lennart ne sait pas coder, mais parce que Linux propose des fonctionnalités non POSIX qui sont utilisés par ce dernier.
[^] # Re: Merci Lennart
Posté par Anthony Jaguenaud . Évalué à 2.
Félicitation, nous avons autant de « bouteille » sous GNU/Linux. Tu peux me rajouter du NextStep, HP-UX à partir de 93.
Je l’ai très longtemps fait à la main. Parce que je trouvais ça plus simple que le nommage immonde de hotplug. Je ne vois rien de compliqué dans un mount.
Je suis pas SI vieux ! :'(
Je me souviens de l’époque ou le noyaux 2.2 était stable. On y mettait que des corrections. Le 2.3 (deuxième chiffre impair) était la branche instable, dans laquelle on ajoutait les nouvelles fonctionnalités, les changements d’interfaces du noyau… une fois stabilisé, ça devenait la 2.4.
Puis un jour en 2.6, je ne sais pas pourquoi, la main branche du kernel à commencer à avoir des interfaces mouvantes, parce que le nouveau scheduler est chouette… ça a apporté beaucoup de dynamique à Linux. Les distributions et les lib bas niveau ont suivies. Aujourd’hui, je me demande si ça ne va pas porter préjudice à Linux et GNU/Linux sur le long terme.
Après, une aproche de type system D est très bien pour des tablettes. Moins bien pour un desktop (c’est mon avis) et pas terrible pour un serveur. Notamment, à cause de cette nouvelle politique de fuite en avant sur les projets. Une faille sur la version n, c’est pas grave, on la corrige sur la n + 3, et on continue. Sauf que pour des grosses boites, il faut être sûr que le changement de version n’induira pas d’effet de bord.
Faire des drivers, du développement sur des systèmes critiques avec un maximum de briques réutilisables, c’est mon métier. Le soir je ne développe pas pour des projets libres. Aux yeux de certains ici, cette expérience ne vaut rien. Je ne m’étendrai pas plus sur ce sujet. Maintenant, si quelqu’un est prêt à m’offrir un boulot pour faire des drivers libres, des softs sans pertes de salaire, je veux bien. Mais pour ça, il faudrait que je prenne le temps pour le faire et passer moins de temps avec ma famille. Alors, oui, je critique. En ai-je le droit ?
[^] # Re: Merci Lennart
Posté par gnumdk (site web personnel) . Évalué à 1.
Euh, dans quel monde ?
Canonical: 5 ans de support gratuit sur les mises à jour de sécurité
Redhat et Suse: J'en sais rien mais plus j'imagine vu que c'est payant
[^] # Re: Merci Lennart
Posté par Anthony Jaguenaud . Évalué à 3.
Je parle de logiciel. Ex: firefox. La fondation à même décidé d’en faire une version de temps en temps un peu plus suivie. C’est aux distribs genre debian de corriger les trous.
Owncloud, si je veux garder la version 2 sur mon serveur et qu’il y a une faille, alors on répond : la 4 n’a pas ce bug
Quand à Canonical, ils arrivent quand même à intégrer la version 3 de openoffice.org dans leur version d’octobre, alors que la version 3 était prévu pour novembre. Du coup, il y a pas mal d’utilisateur qui ont eu une béta sans même le savoir. À part word c’est mieux… il n’y a pas eu beaucoup de commentaires. (Ça date un peu, mais c’est l’esprit qui me gène)
[^] # Re: Merci Lennart
Posté par Misc (site web personnel) . Évalué à 2.
10 + 3 ans sur RHEL, 8+2 ans sur SLES
Détails de ce qui est couvert sur les urls suivantes :
https://access.redhat.com/support/policy/updates/errata/
http://support.novell.com/lifecycle/#policy
Et pour être complet, la policy Canonical :
http://www.canonical.com/enterprise-services/support/server/support-life-cycles
3 ans sur le desktop, 5 sur les serveurs.
[^] # Re: Merci Lennart
Posté par claudex . Évalué à 3.
Ils sont passés à 5 ans pour tout depuis la 12.04.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Merci Lennart
Posté par Misc (site web personnel) . Évalué à 2.
Bah, faut leur dire de mettre à jour leur site web :
"Ubuntu Server LTS is maintained with security updates and bug fixes for up to 60 months (five years) and Ubuntu Desktop LTS for up to 36 months (three years). However, stability doesn't need to mean stagnant systems."
C'est aussi ce que je trouve ailleurs :
http://vlinux-freak.blogspot.fr/2011/10/ubuntu-support-life-cycle.html
Ceci dit, tu as raison dans le sens ou c'est contraire à ce que dit la press release
http://www.canonical.com/content/ubuntu-1204-feature-extended-support-period-desktop-users
ou sur :
http://www.ubuntu.com/business/desktop
Du coup, est ce qu'il y a une version spécifiquement supporté plus longtemps ou c'est juste le site web qui est pas du tout à jour ?
[^] # Re: Merci Lennart
Posté par claudex . Évalué à 3.
C'est passé à 5 ans partout à partir de la 12.04, je ne crois pas que ce soit rétroactif et donc c'est logique que ce soit toujours annoncé comme tel pour les version pre 12.04.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Merci Lennart
Posté par Zenitram (site web personnel) . Évalué à 0.
Si une grosse boite a besoin de la version n, elle n'aura aucun problème à payer pour le patch. Ceux qui ne corrigent pas sont les mainteneurs principaux, mais la beauté du libre est qu'une grosse boite peut patcher aussi, ou un autre prestataire. Tu es libre.
PS : je trouve certes que Mozilla joue un jeu dangereux avec ce non support de vieilles version car il y a plein d'admins prosélytistes qui se retrouvent dans la merde (et eux ne peuvent pas décider de lacher le fric pour payer le patch), mais c'est un choix de la part de Mozilla. Les "grosses boites" comme tu dis ont vachement de mal à sortir leur portefeuille, c'est aussi leur choix, je comprend que Mozilla laisse tomber. Surtout que le monde évolue, et comprend plein de boites qui ont compris qu'il vaut mieux coder des sites standards et faire des projet en "release often" et du coup ça passe vachement mieux maintenant.
[^] # Re: Merci Lennart
Posté par Olivier Serve (site web personnel) . Évalué à 1.
La séparation bin/sbin était une contrainte de l'époque en effet qui n'a plus vraiment de raison d'être. Par contre séparer le système des applications me semble toujours aussi pertinent.
[^] # Re: Merci Lennart
Posté par gnumdk (site web personnel) . Évalué à 3.
Sur un Unix qui n'a pas de gestionnaire de paquet, ca peut être logique, mais sous GNU/Linux, faut m'expliquer…
[^] # Re: Merci Lennart
Posté par wolowizard . Évalué à 3. Dernière modification le 07 septembre 2012 à 12:09.
Ca veut dire la racine au final, vraiment? C'est le premier système de fichier à être monté, non?
Pourquoi ne devrait-on pas mettre l'init /etc, /bin, /sbin la-dedans et dire au noyau de monter /usr comme racine? Au final qu'est-ce cela va changer?
Au final, pourquoi garder /usr? Ca sert à rien. Puis pour garder un semblant de bout de compatibilité, faisons un lien symbolique /usr.
/usr a perdu son intérêt puisqu'il possédait les données utilisateurs avec les /home…
Si je n'ai pas peur de vraiment casser avec l'histoire ( à près tout au diable les vieux râleurs, c'est pas eux qui codent), et que je voudrais rendre linux bien plus agréable, je changerais complètement l'arborescence et les noms! C'est vrai à quoi sert FSH, vraiment?
voyons:
/boot pour tout ce qui est boot
/apps pour toutes les applis
/sys pour tout ce qu'a besoin le système pour démarrer (montage, hotplug, etc…)
/conf pour tout ce qui est conf
/users pour les données utilisateurs
/data pour les données du système
/dev pour les devices
/virt pour tous les systèmes de fichiers noyau…
Poussons l'arborescence:
/apps/lib
/apps/bin
et
/sys/lib
/sys/bin
Plus simple, plus comprehensible, ne trouvez-vous pas?
… puis si on regarde un peu, ça me rappelle quelquechose…
[^] # Re: Merci Lennart
Posté par wolowizard . Évalué à 2.
Veuillez m'excuser avec le post précédent, les premières phrases ne sont plas claires:
Je voulais dire mettre tous l'init, /etc, /sbin, /bin tout dans /usr.
Désolé
[^] # Re: Merci Lennart
Posté par Misc (site web personnel) . Évalué à 2.
Tu veux dire ça :
http://wiki.gobolinux.org/index.php?title=The_GoboLinux_Filesystem_Hierarchy
Ou ça :
http://osxdaily.com/2007/03/30/mac-os-x-directory-structure-explained/
[^] # Re: Merci Lennart
Posté par wolowizard . Évalué à 2. Dernière modification le 07 septembre 2012 à 15:29.
Oui!
on peut prendre ces alternatives aussi…
Maintenant si on regarde bien, et qu'on change un peu les noms, bah on en revient pratiquement au même point:
/boot
/bin
/etc
/home
/var
/usr
/mnt
…
On réinvente la roue au final… un /usr.
Ce n'est pas /usr et son histoire qui est problématique, …
[^] # Re: Merci Lennart
Posté par Moonz . Évalué à 5.
Étant donné que les mêmes qui poussent systemd aujourd’hui ont joué avec « alors on peut monter les disques amovibles avec HAL, finalement non, finalement si, finalement HAL disparait, mais vous pouvez monter vos clés avec udisk (qui a changé de nom d’exécutable une ou deux fois), finalement non, finalement si » pendant des années, oui, j’ai fini par me décider à monter mes clés usb à la main (ou plutôt me faire un petit script en suid qui faisait ça).
[^] # Re: Merci Lennart
Posté par Anonyme . Évalué à 2.
pacman -S pmount:)[^] # Re: Merci Lennart
Posté par Olivier Serve (site web personnel) . Évalué à 2.
Mais CE N'EST PAS CASSÉ !
Le /usr (et /var est aussi concerné) séparé fonctionne en ce moment même sur mes machines, avec udev, et sans initrd. Depuis 2006 au moins. Ce qui est mentionné dans ton lien montre effectivement un problème. Mais ça montre un problème dans l'architecture de udev, pas dans le /usr (et /var) séparé.
Et ça rale beaucoup chez Gentoo avant tout parce que c'était le partitionnement recommandé dans les guides d'installation, donc la plupart des utilisateurs sont dans ce cas.
[^] # Re: Merci Lennart
Posté par SamG . Évalué à 0.
Petit extrait du lien :
Effectivement, c'est de la faute d'udev si un device déclenche une règle et que le binaire correspondant ne peut-être lancé car il se trouve dans /usr qui n'est pas encore monté.
Ce n'est pas parce que quelque chose tombe en marche 99.9% des cas, qu'il faut en déduire que ça marche tout le temps.
[^] # Re: Merci Lennart
Posté par Misc (site web personnel) . Évalué à 3.
Et c'est pas parce que ça marche que c'est pas chiant. Vérifier de manière non automatisable la chose, ça coute du temps. Tu peux voir "mon binaire a besoin de /usr/lib/libtoto.so.3" facilement. Tu peux pas voir "mon binaire lance tel logiciel depuis son code source, ou depuis les régles udevs ou depuis un script bash un soft dans /usr".
Debian a toujours fait en sorte que ça soit possible, mais ça reste un travail manuel, avec tout les risques que ça comporte ( genre loupé un cas obscur ). Au final, conceptuellement, au lieu d'avoir les choses faites dans l'initrd et dans le système, c'est fait juste à un endroit, ça me parait plus sain.
[^] # Re: Merci Lennart
Posté par wolowizard . Évalué à 3.
/usr is broken par udev dans la version 181.
Pourquoi?
C'est voulu car "c'est vieux", "pas d'intérêt", "unmaintainable":
les arguments sont ici,
avec une discussion sur la mailing-list de Fedora,
un point de vue du côté de FreeBSD,
puis les discussions sans fin sur la mailing-list gentoo,
avec des remarques intéressantes ici,
là, par là… enfin bref partout!
Par contre, je suis désolé pour les non anglicistes, je n'ai plus la patience de traduire…
[^] # Re: Merci Lennart
Posté par Yth (Mastodon) . Évalué à 3.
Je ne crois pas que ça soit un problème de gentoo, mais bien une volonté de faire disparaître /bin et /sbin pour les mettre dans /usr/bin et /usr/sbin.
De là, mount n'est plus accessible que depuis /usr/bin, et donc tu ne peux pas monter /usr s'il n'est pas déjà monté au préalable.
Il te reste comme choix de faire une bidouille tordue dans ton initrd (ya déjà une bascule de / puisque tu démarres avec le / de ton initrd, et qu'à un moment du boot tu passes à celui de ton système, mais là il faudra prévoir de déjà avoir monté /usr, et de lui faire suivre la bascule de / !), ou alors d'avoir /usr dans ta partition root.
Un truc que j'avais fait il y a pas mal d'années, quand je m'amusais avec mes trois machines persos, c'était justement d'avoir le /usr sur le réseau et partagé en NFS, la maintenance du système devient de fait triviale, tu n'as pas à prendre en compte l'espace pris par le système sur une petite machine type serveur qui aurait peu d'espace disque, et ça peut être monté en lecture seule pour apporter plus de sécurité à un firewall ou un serveur par exemple.
J'ai arrêté de le faire parce que j'ai arrêté d'avoir trois machines utiles allumées en permanence, et que mon serveur est sur une mini machine ARM à consommation réduite, mais donc sans compatibilité binaire avec ma machine perso en x86. Et que ça marche moins bien pour un portable aussi, ça lui enlève sa capacité à être utilisé en déplacement, tout de suite c'est moins utile ^
Yth.
[^] # Re: Merci Lennart
Posté par Yth (Mastodon) . Évalué à 2.
Apparemment, en lisant les liens fournis par wolowizard juste au dessus, la bidouille de l'initrd est assez simple à faire, et pourrait largement être automatisée dans les distribs.
En conclusion on peut utiliser /usr sur une partition différente de /, et avec systemd, mais en utilisant un initrd prévu pour.
Yth.
[^] # Re: Merci Lennart
Posté par Olivier Serve (site web personnel) . Évalué à 3.
Euh non, faire un vrai initrd avec des contrôles histoire de pas faire n'importe quoi, c'est pas aussi simple qu'un exemple.
De plus, dès qu'on a du LVM, du Raid ou du NFS, ça complexifie encore la chose.
Enfin, il faut refaire l'initrd quand un binaire inclus dedans est mis à jour (utilitaires lvm/raid/nfs par exemple). Sachant que les binaires sont des versions statiques et pas celles qu'on trouve dans /usr.
Donc oui c'est faisable, mais non ce n'est pas trivial.
[^] # Re: Merci Lennart
Posté par Misc (site web personnel) . Évalué à 2.
Ce que dracut peut faire. C'est expliqué ici :
http://unix.stackexchange.com/questions/18057/dracut-and-separate-usr
[^] # Re: Merci Lennart
Posté par wolowizard . Évalué à 0.
Oui.
"mode ironique"
On devrait mettre dracut comme dependance de fonctionnalité à systemd/udev…
A quand le merge de dracut dans systemd/udev?
"end mode ironique"
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.