Bonsoir, amis amateurs de systemd. Nous ne sommes plus Vendredi, mais j'ai pensé que ceci méritait d'être souligné :
http://lists.freedesktop.org/archives/systemd-devel/2013-November/014808.html
Pour les anglophobes, cela dit en gros que 4 nouveaux modules vont être ajoutés à Systemd :
systemd-consoled: Une console systemd (émulateur basique de terminal)utilisé comme session/console de "fallback" (secours ?).
systemd-splashd: Un boot-splash pour les initrds. Il n’inclura pas d'"eye-candy" (beaux graphismes?) mais sera seulement requis pour accepter les champs de mot de passe pour les partitions root encryptées. Il faudra utiliser Plymouth pour avoir des graphismes sexy.
systemd-welcomed: Un login-screen pour lancer des sessions. Cela remplace /sbin/agetty et /bin/login dans un VT. Après le login, il lance systemd-consoled.
systemd-er: L’assistant de la salle d'urgence.
En résumé, une systemd-console en plus dépouillé conçu pour les développeurs. Ce n'est pas activé par défaut. Pensez-y comme une variante de "magic sysrq" en espace utilisateur.
Si vous n'aimez pas ces changements, vous n'aurez qu'à mettre CONFIG_VT=y au lieu de CONFIG_VT=n .
Des avis sur ces changements, pour ceux connaissant mieux ces parties du système ?
# La touche finale
Posté par lolcat . Évalué à 1.
Merci
Je pense que c'est bien que systemd apporte sa touche finale avec un bootsplash graphique. Jusque là, en mode console, on avait seulement le manchot repu, ce qui est un peu limité.
[^] # Re: La touche finale
Posté par anaseto . Évalué à 10.
À quand une alliance entre les devs de Systemd et Emacs pour nous faire enfin un vrai système d'exploitation ?
[^] # Re: La touche finale
Posté par aurel (site web personnel, Mastodon) . Évalué à 9.
Ils savent sans doute qu'une telle alliance serait vouée à l'échec car elle ne serait pas en mesure de prendre l'ascendant sur MultideskOS.
Sinon, moi j'utilise vim (on est samedi).
[^] # Re: La touche finale
Posté par anaseto . Évalué à 10.
Pas de soucis, Systemd a besoin d'Emacs parce qu'il ne propose pas encore de navigateur web, et Emacs n'a pas encore à ma connaissance de login-screen avec bootsplash, mais aucun des deux ne propose un éditeur de texte, donc on est peut-être encore à temps pour nécogier cette partie là, faudra faire une feature-request dans leur bugtracker.
[^] # Re: La touche finale
Posté par Le Gab . Évalué à 1. Dernière modification le 30 novembre 2013 à 12:31.
Dans sa dernière diatribe sur son compte +Lennart, Lennart bien conscient que systemd est "validé" fini par expliquer réellement l'impact de ce dernier et qu'il va être très difficile de faire sans ce composant, chose qu'il niait au départ.
Pareil pour logind etc…
Je ne sais pas vous mais on n'est pas très loin de la rangaine GWBush: "Vous avec nous ou contre nous".
D'où vient la suprématie de RedHat? Pour quiconque l'ayant utilisé en server, c'est une plaie! Fedora est horrible et je ne comprends pas que ça puisse "faciliter" la vie à un développeur.
Sont-ce là les distributions qui vont définir le GNU/Linux de demain?
[^] # Re: La touche finale
Posté par saltimbanque (site web personnel) . Évalué à 10.
Dire que systemd devient nécessaire alors que ce n'était pas annoncé, ça se tient. Dans ce cas prends en toi à toutes les distro qui adoptent systemd, puis prends en toi à Greg Kroah-Hartman.
[^] # Re: La touche finale
Posté par Joris Dedieu (site web personnel) . Évalué à 10.
Non. La plaie vient du fait qu'on cherche à utiliser RHEL comme Debian. La plaie vient aussi du fait qu'on démarre de projets en entreprise sur des versions antédiluviennes au lieu de prendre la version actuelle.
Pour la maintenance à long terme d'un projet, RHEL c'est juste parfait :
RedHat te permet d'avoir une version de PHP maintenue durant plus de dix ans. Si cela ne t'intéresses pas alors tu t'es simplement trompé de distribution.
[^] # Re: La touche finale
Posté par Rémi Duraffort (site web personnel) . Évalué à 1.
Cela dépends de ce que tu souhaite faire avec ta Red Hat. Si tu as besoin de logiciel non complètement obsolète, c'est juste impossible.
Voir ce commentaire sur reddit :
http://www.reddit.com/r/linux/comments/1r5q79/red_hat_enterprise_linux_65_released_brings_new/cdkfqwa
[^] # Re: La touche finale
Posté par paulez (site web personnel) . Évalué à 3.
Pas mal le commentaire reddit où le mec se plaint d'avoir un système avec des vieilles versions alors qu'il utilise RHEL5. RHEL6 est quand même sortie il y a un trois ans hein.
[^] # suprématie de RedHat?
Posté par Mimoza . Évalué à 4.
Parce que des entreprises qui édite une distribution Linux avec un vrai support pouvant donner confiance aux entreprises se compte sur les doigts de la main.
Mandriva = Très peu connu dans le monde de l'entreprise et plus pour sa version "grand public" que ses serveurs.
Ubuntu = De base grand public et commence a percer sur les serveurs car de nombreux admin son séduit par la version bureau, je sais c'est pas logique mais c'est les retours que j'ai. Surtout d'admin Windows qui sont "obligés" d'avoir un serveur Linux.
Suse = Trop peu connu malgré ses qualités, ils ont eux aussi adopté systemd
Il me semble que IBM édite aussi une version de Linux mais pousse plus son AIX sur les grose machines.
RedHat a toujours fait dans l'entreprise et les gros systèmes et ils ont acquis une belle notoriété dans ce domaine. Enfin et surtout RedHat est une boite Américain, donc tout le reste importe peu aux décideur pressé qui considère que le choix américain est toujours le meilleur :-/
[^] # Re: suprématie de RedHat?
Posté par Misc (site web personnel) . Évalué à 8.
IB n'édite pas de version de Linux, ils proposent du RHEL, voir du SLES, en fonction de ce que les clients demandent. Si jamais les clients venaient à demander en masse autre chose, je suis sur qu'IBM le ferait sans souci.
[^] # Re: La touche finale
Posté par cedric . Évalué à 10.
Peut etre parce qu'ils ont un developpeur qui est un bon leader de developpeurs. Redhat n'est pas seul a developper systemd. Ce n'est d'ailleur pas une contribution de redhat, mais de David Herrmann qui est encore etudiant en Allemagne. Demande toi plutot comment avahi, pulseaudio, systemd ont pu reussir en etant si mauvais et nuisible a tes yeux a etre choisi par tout un tas de developpeurs et de distributions sur lequel RedHat n'a pas de controle. Et si tu as encore des doutes, commence donc a coder des alternatives et devient le leader de la resistance ! :-D
[^] # Re: La touche finale
Posté par Misc (site web personnel) . Évalué à 3.
Tu peux aussi parler de Greg KH qui encourage le dit David dans son entreprise :
http://lists.freedesktop.org/archives/systemd-devel/2013-November/014836.html
[^] # Re: La touche finale
Posté par Misc (site web personnel) . Évalué à 10.
Je pense que ça vient de plusieurs choses.
D'une part, du fait d'avoir des développeurs en grand nombre. Je peux citer par exemple les contributeurs à gcc, à Linux, à gnome, etc, etc. Des logiciels que tout le monde utilise sans le savoir sont des contributions directs de salariés de la boite, comme par exemple kvm. Tu retrouves les gens dans les projets comme coreutils ( http://git.savannah.gnu.org/cgit/coreutils.git ). Tu peux avoir plus de détails sur http://community.redhat.com/software/
Ensuite, le fait d'avoir pris le magma primal qu'est le corpus de logiciels libres disponibles et d'en avoir fait un produit fini. Plein de boite le font, je ne dit pas le contraire, mais RH a réussi à s'en tirer de façon des plus honorables. La documentation traduite, écrit par des personnes à temps plein, a beaucoup aidé pour la perception du logiciel libre. De même, le fait de faire de la QA un peu plus formel que "si personne ne signale de bug alors c'est bon", de faire des revues de sécurités sur le code, de faire certifier les OS pour divers gouvernements, etc. Ou simplement de proposer du support, des roadmaps sur leurs produits.
Et troisièmement, le fait de ne pas s'opposer à la communauté, mais d'en faire parti. Par exemple, avoir monté des choses comme l'OIN pour tous et pas juste pour leur propre pomme, d'envoyer des avis légaux sur les procés sur les brevets logiciels afin d'aider à établir une jurisprudence en faveur du libre, d'être sponsor pour la Linux Fondation, pour pycon et d'autres, d'avoir aidé à monter la fondation Openstack, d'avoir proposé des briques comme libvirt ( sur lequel repose quand même pas mal de projet d'IaaS du moment ).
C'est une affirmation qui manque fortement de substance, et je suis sur que ton propos gagnerais en solidité si il était moins lapidaire. Mais sinon, il semble qu'il y a plein de gens satisfait de RHEL sur les serveurs, en partie de part la stabilité de la chose.
Sinon, moi, j'ai une Fedora sur un serveur, et je suis content d'avoir des choses comme selinux, comme systemd, comme des versions récentes de divers composants. Peut être qu'il y a des gens qui sont content d'avoir hadoop sans installer à la main ( cf https://fedoraproject.org/wiki/Releases/20/ChangeSet ) ou sans avoir à prendre des dépôts non officiels.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
# Busybox
Posté par superna (site web personnel) . Évalué à 2.
Ce sera en somme un super busybox ?
[^] # Re: Busybox
Posté par fravashyo . Évalué à 5.
bientôt, systemd-os, avec un serveur graphique qui va remplacer
X11wayland« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: Busybox
Posté par anaseto . Évalué à 10.
Il va falloir t'y faire, tu devras démarrer le serveur D avec
startdet le.dinitrc, puis configurer tondtermà l'aide du.Dressources. Pour le gestionnaire de fenêtres tu auras le choix entredwmetxmonaD;dmenupour lancer les applications etdzenpour afficher des infos sur la barre. Il paraît qu'on pourra désactiver certains trucs sur un fichier de conf, mais c'est sans doute juste un piège. Et d'ailleurs, ne faisons pas trop comme si on était surpris, alors qu'on pouvait s'en douter il y a longtemps que le mal s'était déjà glissé parmi nous :cd,dd,du,dmesg,ed,…[^] # Re: Busybox
Posté par Elfir3 . Évalué à 9.
Au moins on aura droit à jackd par défaut, ce sera mieux que… mince, nous sommes foutus !
[^] # Re: Busybox
Posté par Tonton Th (Mastodon) . Évalué à 2.
I have a dream…
[^] # Re: Busybox
Posté par Misc (site web personnel) . Évalué à 7.
Faudrait avoir plus qu'un rêve, genre avoir la possibiltié de faire la chose, si seulement les sources des distributions étaient disponibles, et si seulement le code pouvait donner le droit de faire ce qu'on veut (ou presque) avec ..
[^] # Re: Busybox
Posté par Tonton Th (Mastodon) . Évalué à 5.
Figure-toi que j'ai quelques vieilles bricoles sonores qui trainent depuis des années, et dont je voudrais bien reprendre le développement. À l'époque (2007 en gros) j'en avait pas mal chié pour comprendre les subtilités de l'api d'ALSA. Et maintenant, je souhaite interfacer ces bricoles avec Jack, parce que bon, si tu veux faire du son sérieusement sous Linux, Jack me semble bien la voie à suivre.
Et tout ça va se finir probablement par une Slack presque fabriquée à la main, pour ne pas avoir ce fscking pulseaudio en travers de mon chemin.
Ça tombe bien, les sources sont disponibles :)
[^] # Re: Busybox
Posté par Obsidian . Évalué à 3.
Entre Chrome, Android, Firefox OS, System D et même « FreeboxOS » qui a remplacé la chouette interface précédente de ma Freebox V6, les années 2010 seront celles de la guerre des aspirants OS. :-)
J'ai bien peur qu'ils ne fassent tous qu'essayer de s'entretuer et qu'il ne se dégage rien de positif à l'issue de tout cela. Juste des centaines de miettes à gérer pour les gens qui travaillent dans le secteur…
[^] # Re: Busybox
Posté par dave_null (site web personnel) . Évalué à 3.
Non
[^] # Re: Busybox
Posté par fravashyo . Évalué à 5.
non parce que busybox a l'avantage d'être optionnel…
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
# .
Posté par Astaoth . Évalué à 7.
Sinon les FreeBSD c'est pas si mal maintenant qu'il y a pkg2ng.
Emacs le fait depuis 30 ans.
[^] # Re: .
Posté par Atem18 (site web personnel) . Évalué à 8.
Oui mais non, il manque Systemd-pkg2ng.
# GNU/SystemD/Linux
Posté par Mimoza . Évalué à -9.
J'espère franchement que Debian ne va pas adopté systemd, sinon il n'y aura plus de grande distribution de qualité qui ne sera pas sous le joug de cette brique obscure. L'avantage des Linux était de pouvoir remplacer une brique par une autre sans "trop" d'impact. Là il ne seras plus possible de se passer de ce composant sans tout refaire à la main. On parlera de GNU/SystemD/Linux
[^] # Re: GNU/SystemD/Linux
Posté par cedric . Évalué à 10.
Les jolis briquent qu'on peut facilement remplacer. C'est cool, ca fait des jolis graphique pour les powerpoints. Apres dans la realite, je ne connais aucun logiciel qui remplace un autre. Il y a toujours quelques choses qu'on gagne, quelques choses qu'on perd. Depuis quand tu peux remplacer qt par gtk ou par les efl sans changement ? Et bind par dnsmasq ? Ou bash par csh ?
Systemd apporte une coherence inter distribution qui n'existe pas sous Linux. Cela permet a un projet upstream de fournir un .unit qui fonctionnera de maniere optimale sur toutes les distributions. Plus de probleme de QA parce qu'un script est different ou parce que le shell est different ou on ne sait trop quel bizarrerie local. Et pour le meme prix, tu as tout un tas de fonction fort sympatique pour les devs qui l'utilisent.
Mais bon, il ne faut pas oublier ce qu'est le logiciel libre. C'est un logiciel qui peut etre librement modifie pour etre adapate a SES propres besoins. Si ca ne te plaie pas, le code est libre, tu peux toujours l'adapter a tes besoins. Mais peut etre qu'a ce moment la tu decouvriras pourquoi la plus part des projets upstream ont librement decide de suivre systemd…
[^] # Re: GNU/SystemD/Linux
Posté par Batchyx . Évalué à -2.
Non. Dans la pratique, on remplace jamais les logiciels qui marchent. Ceux là, on oublie presque qu'ils existent. Par contre on cherche à remplacer les logiciels qui marchent pas, qui sont de la merde, qui sont totalement inadaptés à ce qu'on veut faire, qui sont trop lent, trop gros, trop stupides, trop inutilisables ou trop limités.
Si il y a autant de gens qui cherchent à remplacer NetworkManager, systemd, udev ou dbus, il faudrai peut-être regarder pourquoi.
La question ce n'est pas savoir si tu peux sans changement, c'est comment tu peux, et avec quels changements.
Et puis, sérieusement, t'a vraiment besoin de Qt/GTK/EFL pour afficher un pov' texte sur une matrice LCD 200x40 ? T'a vraiment besoin de bind pour servir deux trois pecnos sur ton réseau local ? Ou d'un shell utilisable par un humain pour lancer deux trois scripts de démarrages sur une machine sans utilisateur ? Ou de lancer une session gnome pour afficher un écran de login ? Parce que dans tout les cas, ça va ptet te convenir à toi, mais chez d'autres, ça sera lent, chiant, inutilisable, ou les trois à la fois. Et ils devront changer ça.
C'est complètement stupide comme idée. Systemd n'apportera jamais de cohérence entre Linux, BSD et Windows de toute façon, et les logiciels ne vont pas s'arrêter d'être portable.
En fait, systemd ne va même pas apporter de cohérence dans les distributions Linux puisqu'il y aura des distributions Linux qui ne l'utiliseront pas et qui pourront même pas rester compatibles avec celles qui l'utiliseront tellement systemd n'est pas générique. Je vais pas encore ressortir le fameux XKCD, mais on est typiquement en plein dedans, Systemd n'est qu'un standard supplémentaire pour en unifier d'autres.
Si tu a envie d'unifier des distributions Linux (et d'autres OS), tu fait pas des grosses implémentations monolithiques de standard hyper-spécifiques, tu fait des standard comme POSIX, FHS, LSB ou autres qui sont suffisamment génériques pour être applicables sur toutes les distributions Linux et Unix-like et voir même le gros OS monolithique qu'est Windows. Pas un faux "standard Systemd" qui dépend de D-Bus et de plein d'API spécifiques à Linux, et que tu ne peux pas intégrer à un système existant sans devoir tout refaire.
Raté. Un logiciel libre, c'est un logiciel qu'on réutilise. T'en vois souvent des logiciels clairement inadaptés se faire modifier en profondeur pour coller à un autre besoin ? Moi pas. À la place, je vois des grosses réimplémentations plus ou moins génériques, parce que d'une part ça prend moins de temps, ça collera mieux au besoin et que ça sera plus facile à maintenir qu'un fork d'un logiciel clairement pas fait pour et ou upstream ne voit même pas l'utilité du besoin.
[^] # Re: GNU/SystemD/Linux
Posté par claudex . Évalué à 9.
S'il y a autant de gens qui ont remplacé ce qu'il y avait avant par NetworkManager, systemd, udev ou dbus, il faudrait peut-être regarder pouquoi.
C'est quoi le(s) standard(s) en dehors de systemd (qui marche) des scripts init, du changement de hostname persistent, du changement de timezone… ?
« 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: GNU/SystemD/Linux
Posté par GG (site web personnel) . Évalué à 5.
NetworkManager, tu le vires et tu reprends le contrôle de ton réseau.
C'est généralement la première chose que je fais quand un machine a un problème de connexion réseau, je regarde s'il y a NetworkManager et je le vire (proprement).
Donc, non, la comparaison avec NetworkManager ne tiens pas.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: GNU/SystemD/Linux
Posté par Renault (site web personnel) . Évalué à 8.
Si tu as un problème réseau avec NetworkManager et que ta seule solution est de le virer montre plutôt que tu ne sais pas l'utiliser correctement. NetworkManager est très puissant.
[^] # Re: GNU/SystemD/Linux
Posté par Batchyx . Évalué à 5.
Ah bah, t'a ptet raison, je sais peut-être pas l'utiliser correctement. NetworkManager doit être tellement puissant que je suis pas obligé de remonter des patches à son code moche pour lui rajouter des fonctionnalités.
Je vais pas en dire plus, je risquerai d'être odieux. Ah je le suis déjà ? Mince alors.
[^] # Re: GNU/SystemD/Linux
Posté par Petit_Scarabee . Évalué à 10.
Network-manager puissant ? Il ne faut pas exagérer non plus. Un gestionnaire de réseau qui ne gère pas les interfaces bridgés, c'est pas ce que j'appelle de la puissance. Non je ne travaille pas sur un serveur mais sur un portable avec des machines virtuelles qui me servent de maquettes et de support de démo.
[^] # Re: GNU/SystemD/Linux
Posté par nud . Évalué à 3.
Cela fait longtemps que je n'ai plus eu de problème avec network manager en combinaison avec un bridge pour les machines virtuelles. Sous Debian avec libvirt ça marche juste au poil, et NM n'essaie pas de chipoter avec les interfaces qu'il ne contrôle pas. Il s'abstient même explicitement de toucher aux interfaces qui sont définies dans /etc/network/interfaces (genre eth0 dans la config post-install par défaut de Debian).
[^] # Re: GNU/SystemD/Linux
Posté par calandoa . Évalué à 6.
Je confirme la puissance de NetworkManager et de systemd réunis. sur ma machine (Fedora 19), ils partent en vrille et me génèrent un /var/log/messages de plusieurs giga en qq heures. En qq jours, mon disque dur s'est retrouvé saturé, et j'avais beau faire du ménage, la place gagnée était automatiquement utilisée. J'ai depuis débarqué NetworkManager, après avoir passé des heures à écrire et tester des scripts systemd pour faire un pauvre dhclient de merde au boot.
Peut être que systemd et son pote ont pleins de super avantages et que 2014 sera l'année du desktop sous Linux grâce à eux, en attendant c'est une véritable usine à gaz incompréhensible responsable du grand fail que j'ai rencontré sous Linux en 15 ans.
[^] # Re: GNU/SystemD/Linux
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
SysV RC.
echo "pouet" > /etc/hostname, un fichier utilisé par un script d'init fait pour.export TZ=Europe/Parispour un changement spécifique à l'utilisateur. Pour un changement du fuseau horaire global,cp /usr/share/zoneinfo/Europe/Paris /etc/localtime.[^] # Re: GNU/SystemD/Linux
Posté par claudex . Évalué à 9.
Un standard qui est différent par distribution, c'est un standard ?
Ça ne change pas l'hostname, ça le change après le prochain redémarrage. Ce n'est pas très user friendly.
Ça demande aussi un redémarrage pour être appliquer. Si ta vision de Linux, c'est un truc à la Windows où il faut redémarrer dès qu'on change un paramètre, c'est bien mais je préfèrerais un truc mieux foutu.
« 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: GNU/SystemD/Linux
Posté par totof2000 . Évalué à 3.
Faut être un peu couillon pour changer son hostname toutes les 5 minutes aussi.
Sur un serveur on s'en fiche, et c'est même mieux qu'on ne puisse pas faire plein de changement à la volée : ça évite que n'importe qui fasse n'importe quoi sans prévenir personne. Quand tu fais des astreintes, c'est pas très agréable de se rendre compte qu'un truc ne marche plus parce que le hostname (ou autre) a été changé à la volée sans que personne ne soit prévenu. En cas de reboot, ça se voit plus facilement : faut demander un arrêt de service, ça risque pas de passer inapperçu.
hostname c'est pas mal non plus. Et pour être sur d'être cohérent avec ta config, un truc du genre hostname $(cat /etc/hostname) marche bien. Et surtout, ça n'a pas à être user friendly sur un serveur, mais admin friendly. Et les trucs user-friendly (qui bien souvent veut dire neuneu-friendly) , ça a tendance à ne pas trop plaire aux admins.
[^] # Re: GNU/SystemD/Linux
Posté par flan (site web personnel) . Évalué à 8.
C'est encore pire : le gars d'astreinte qui va rebooter le serveur ne va pas comprendre pourquoi ces paramètres auxquels il n'a pas touché ont changé…
[^] # Re: GNU/SystemD/Linux
Posté par Tonton Benoit . Évalué à 3. Dernière modification le 02 décembre 2013 à 15:17.
LOL, à pars Debian qui utilise encore cette m sous Linux ? Un système d'init même pas capable de suive le statut des processus qu'il a lancé…
Je suis méchant mais demandez à n'importe qui dans la rue ce que je déteste sur Debian il répondra "le système d'init" et ce que j'aime ? /etc/network/interfaces
[^] # Re: GNU/SystemD/Linux
Posté par mael . Évalué à 10.
J'ai demandé à un type dans le métro, il m'a répondu "ta gueule". :(
[^] # Re: GNU/SystemD/Linux
Posté par claudex . Évalué à 10.
C'est normal, il avait dit « dans la rue ».
« 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: GNU/SystemD/Linux
Posté par zebra3 . Évalué à 10.
Ben vas-y, montres nous comment tu fais marcher Apache sur une RHEL avec un script Debian. Rien que le nom et les chemins sont différents (httpd pour RHEL, apache2 pour Debian)…
Ça c'est pour Debian. Ça ne marchera pas sous RHEL, où le nom est défini dans /etc/sysconfig/network.
Bref, tu viens de prouver que non, rien n'est unifié.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: GNU/SystemD/Linux
Posté par Renault (site web personnel) . Évalué à 2.
Quoi ? Debian n'est pas the universal operating system ? Ils nous ont donc menti depuis tout ce temps ?
[^] # Re: GNU/SystemD/Linux
Posté par Zenitram (site web personnel) . Évalué à 10.
Wow… C'est vraiment nier la réalité, la transformer pour être en accord avec ses fantasmes.
Quasi-tout le monde (on parle de ce qui doiven tse taper la maintenance hein, pas les trolleur qui foutent rien) veut mettre systemd sur Linux, et les seuls qui ne veulent pas sont ceux qui n'aiment pas le changement et veulent garder le "bohneur" de la maintenance pourrie de ce qui existe avant.
Tu as raison sur un point mais en changeant juste un peu : Si il y a autant de gens qui cherchent à remplacer l'existant par systemd, il faudrai peut-être regarder pourquoi.
Si tout le monde ou presque regarde systemd, c'est peut-être parce qu'il répond au besoin?
Et systemd est en train de rempalcer tous les logiciels qui marchent, c'est ça? Tu donnes toi-même les arguments pour systemd et contre l'existant (ou plutôt ce qui existait)…
Personne ne met un flingue sur la tête des gens. Par contre, de moins en moins de monde a envie de se faire chier pour toi. Personne ne devra changer d'outil, juste se taper la maintenance (et c'est normal : si tu veux reter aec de la merde quand quelque chose de mieux existe, assume, gère la merde toi-même, les autres sont passé à autre chose et n'en ont plus besoin)
Il faut croire, la vue du déploiement de systemd, que non, systemd va en tuer des système d'init (où ils seront tellement peu utilisé qu'on ne se fera plus chier à ce que tout soit compatible avec les vieux standards), donc non, on n'est pas en plein dedans. Et puis, bon, la, sortir ça pour un logiciel comme ça, va jusqu'au bout et gueule qu'il y a trop de distros Linux, c'est chiant.
Sérieux, tu sais lire ce que sont les 4 libertés?
Parce qu'un logiciel proprio, pas du tout libre, rentre dans ta définition de logiciel libre.
Tu as sans doute loupé ce qui est important dans le libre (aide : relire ce à quoi tu répond "non").
Triste pour le libre de le cantonner à être comme le proprio.
Pas mal.
[^] # Re: GNU/SystemD/Linux
Posté par Kaane . Évalué à 10.
et les seuls qui ne veulent pas sont ceux qui n'aiment pas le changement et veulent garder le "bohneur" de la maintenance pourrie de ce qui existe avant.
Euh…. Même si il y a énormément de trolls contre systemd, il y a des raisons parfaitement valides d'être contre. Le fait de ne pas vouloir autant de dépendances dans un système d'init est un point tout à fait valide. L'init c'est la première chose que va faire le système, si ca merde à ce moment là vous ne pouvez rien faire pour corriger le tir. Vouloir le garder aussi maigre que possible n'est pas fondamentalement idiot.
Ensuite à l'heure actuelle il existe un certains nombres de matériels que l'on ne peut (toujours) pas initialiser proprement avec systemd. Typiquement les matériels multi-étage. Par exemple si vous devez initialiser une architecture crossbar sur laquelle est posée un émulateur réseau matériel (grosse station sun typiquement) systemd ne verra pas les cartes réseaux au moment de l'initialisation du réseau, et quand il les verra enfin pleins de services se seront déjà vautrés parce qu'il aura voulu anticiper l'ouverture des ports sur des cartes qu'il ne connait que plus tard. Idem pour les pinpad, si vous avez besoin de taper un code sur un clavier externe (ie pas le clavier de la machine) pour débloquer votre disque dur, à l'heure actuelle vous ne disposez d'aucun moyen de booter avec systemd à l'heure actuelle.
Autre problème, systemd n'est pas turing complet et décide tout seul dans quel scope il se lance (essayez d'altérer les cgroups de lancement de systemd pour rire - surtout si c'est pour rajouter des restrictions en plus du taging). Mur assuré. Si vous avez déjà vos politiques cgroups et selinux, vous pouvez prier qu'elles soient compatibles avec systemd, parceque l'alternative est probablement de redéfinir des politiques à partir de 0… Certains logiciels (dont l'excellent HAProxy) ne peuvent tout simplement être lancés par systemd. En cas de reload systemd va interpréter l'arrêt du logiciel comme une panne et va tenter de le relancer avec les paramètres qu'il a en mémoire et dans le scope qu'il juge bon. Moralité vous êtes bon pour écrire des wrappers à la pelle ou à ne plus jamais utiliser de restart (sur un proxy c'est très emmerdant).
Mais le truc qui m'emmerde le plus personnellement ce sont les templates d'une pourritude rare. Avec sysVinit ou bsdinit il est très facile de faire un script qui va prendre en paramètre une flopée de commandes et/ou de variables et me démarrer un service en fonction de ces variables. Par exemple pour créer un réseau virtuel avec un dhcp sur un segment IP donnée dynamiquement ca me prend une demi ligne de code. Je n'ai pas encore trouvé comment faire ça avec systemd. Il faut créer un service à la volée, l'enregistrer puis l'initialiser , savoir dès le début si on compte le relancer ou pas (sinon il faut faire un script pour le désinscrire au cas ou). ca devient d'une complexité démentielle de créer dynamiquement trois VM et de les mettre en réseau.
Systemd a des idées géniales et de très bons cotés, mais dans le travail que je fais en ce moment il n'est pas adapté. Et par pas adapté je ne vaux par dire "j'ai pas envie de tout réécrire et d'apprendre systemd" je veux dire "Systemd m'empêche sciemment et volontairement de mettre en place les outils dont j'ai absolument besoin pour travailler".
Mon point de vue est le suivant : systemd rend la vie de 95% des gens plus facile dans 95% des cas, c'était aussi le cas d'internet explorer 5.0
[^] # Re: GNU/SystemD/Linux
Posté par Zenitram (site web personnel) . Évalué à -3.
Il va y avoir un marché à la Firefox pour quand RedHat et SuSE (les deux seules distros "pro" qui ramènet de la thune) vont passer à systemd alors, pas de soucis, le fric sera la de tous ceux qui souffrent avec systemd et qui sont délaissés par les deux "pro", ça va déchirer en retour sur investissement, il suffira de maintenir des vieux trucs, trop facile. Si tous les reproches ne sont pas juste des détails temporaires (systemd étant encore en développement, c'est normal qu'il manque des trucs, ça ne veut absolument pas dire que le coeur du projet est mauvais).
PS : personne n'a dit que systemd répond à tous les besoin maintenant. Il va en direction. Et rien ne me dit vraiment que le problème des exemples donnés ne vient pas d'un problème de l'admin qui fait des trucs bizarre ou d'un logiciel bizarre (combien de logiciels à la HAProxy qui en plus va refuser de s'adapter?). On verra quand systemd sera déployé par RedHat…
[^] # Re: GNU/SystemD/Linux
Posté par Kaane . Évalué à 7.
personne n'a dit que systemd répond à tous les besoin maintenant.
et les seuls qui ne veulent pas sont ceux qui n'aiment pas le changement et veulent garder le "bohneur" de la maintenance pourrie de ce qui existe avant.
Là, il va falloir choisir un des deux. Soit les personnes qui ne veulent pas de systemd sont des connards passéistes réactionnaires aigris et mal informés, soit il reste encore de vraies bonnes raisons de s'inquiéter de l'impact de systemd sur l'administration de certains systèmes dans certaines situations particulières.
Tout ce que je demande c'est que la possibilité numéro ne soit pas ridiculisée systématiquement.
Pour caricaturer, il y a deux possibilités :
- soit systemd devient turing complet et on va se retrouver dans deux, trois, quatre ans dans le même bordel de maintenance des scripts d'init.
- soit systemd ne devient pas turing complet et il y aura des admins qui ne pourront plus faire leur système comme ils ont l'habitude et qui devront recréer, tester et migrer vers une nouvelle architecture logicielle (nouvelles logiques d'init, nouvelles policies, potentiellement nouveaux logiciels).
combien de logiciels à la HAProxy qui en plus va refuser de s'adapter?
Typiquement un cas à la con pour systemd : mettre HAProxy derrière un wrapper entraine une perte de perfs, sortir HAProxy de son mode "single process, event driven" entraine une perte de perfs, bidouiller avec un pseudo-wrappo-manager à la nginx entrainne une perte de perf.
Grosso-modo si HAProxy "s'adapte" à systemd, il devient un autre logiciel.
[^] # Re: GNU/SystemD/Linux
Posté par totof2000 . Évalué à -4.
Laisse tomber : tu parles à quelqu'un qui a des oeuillères et qui n'a jamais eu à gérer des serveurs qui paraissent être des cas "rares" dans leur monde du poste de travail ou du serveur de fichier, mais qui est beaucoup plus courant que l'on ne le croit ailleurs.
[^] # Re: GNU/SystemD/Linux
Posté par Zenitram (site web personnel) . Évalué à 2.
J'ai bien rit, merci.
Clair, chez Red Hat qui est à fond dessus, ils n'ont jamais eu à gérer des serveurs bizarres avec des demandes bizarres, ils font trop du "standard" sans beaucoup de machines et de configs à supporter… Red Hat, ce sont des petits joueurs face à Kaane et totof2000 qui sont des dieux des trucs compliqués…
J'ai encore bien rit, encore merci.
PS : tu attaques perso faute d'arguments vraiment contre et en ayant de très grandes oeillères, je répond perso, c'est nul mais je joue.
[^] # Re: GNU/SystemD/Linux
Posté par totof2000 . Évalué à 1.
Redhat et Linux, dans la plupart des cas, c'est du PC X86, des VM sous VMWare. Les autres trucs plus costauds, c'est AIX, Solaris, HP-UX et zOS avec son monde particulier.
Tu peux rire tant que tu veux, Red!hart dans le monde des serveurs hauts de gamme, c'est rien du tout.
Non, mais RedHat ce sont des petits joueurs face à IBM par exemple. Tu peux rire tant que tu veux et garder tes oeuillères, ça ne changera rien à la réalité.
PS : tu attaques perso faute d'arguments vraiment contre et en ayant de très grandes oeillères, je répond perso, c'est nul mais je joue.
Les arguments contre t'ont été donnés avec un exemple précis, je n'ai rien à y ajouter. Ce sont des arguments de personnes ayant des problématiques d'admn à régler au quotidien, pas des argments de marketteux comme chez RedHat. Et en général, chez RedHat, ils ne sont pas là pour faire de la gestion au quotidien.
Ah tiens, puisque tu me parle du Dieu Redhat : ils ont mis au point un système de déploiement qui s'appelle RedHat Sattellite: ce truc marche très bien pour faire du déploiement d'OS et de la gestion de configuration simple, mais c'est une plaie lorsque tu veux gérer des configurations complexes : ça n'empêche pas RedHat de le vendre pour ça, alors que des outils comme Puppet ou Chef sont beaucoup mieux fichu pour ça. Et je ne suis pas un dieu, je suis juste un utilisateur de ces outils au quotidien.
[^] # Re: GNU/SystemD/Linux
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 02 décembre 2013 à 12:45.
Mouais, donc en gros la cible de Linux, cool on parle de Linux.
Finalement ça va bien dans la cible!
Plus costaud?
http://www.top500.org/statistics/list/
Unix (non Linux donc) : 2.2% (tendance : baissière)…
(OK, le top500 est un mode particulier, pas généralisable, mais bon, tu as commencé à parler de "monde particulier"… Et puis, IBM en fait du Linux aussi)
[^] # Re: GNU/SystemD/Linux
Posté par totof2000 . Évalué à 2.
Non, la cible Linux c'est aussi les trucs un peu plus costauds, sans entrer dans le top 500. Ca commençait à bien partir. On commençait à avoir des choses intéressantes. RedHAt Cluster est assez bien fichu, et tourne pas trop mal. Il lui manque quelques fonctionnalités pour remplacer un HACMP ou un HP Serviceguard (a moins que depuis elles soient arrivés). Et je dis du bien de RedHAt Cluster, alors mêe que son fichier de conf est en XML, alors qu'en général je n'aime pas trop ça (l'avantage de ce fichier est qu'il est plutôt bien écrit, par contre il est parfois difficile de s'y retrouver dedans).
Je me suis mal exprimé sur le monde particulier. Je parle du monde que je cotoie au quotidien, que l'on retrouve dans les banques, les télécoms, l'industrie, etc … : j'aurais du parler d'un monde différent du desktop et des serveurs "bas de gamme", le monde entre ça et le top 500 (note qu'en général, les OS tournant sur ces environnements sont des OS adaptés spécifiquement, que ce soit du Linux, Windows, AIX ou autre).
[^] # Re: GNU/SystemD/Linux
Posté par Zenitram (site web personnel) . Évalué à 1.
Donc Linux est adapté au très bas de gamme et aussi au très haut de gamme, mais comme par magie il n'est pas adapté au milieu de gamme, le truc entre les deux.
J'avoue reste circonspect devant une telle affirmation.
[^] # Re: GNU/SystemD/Linux
Posté par totof2000 . Évalué à 2.
Tu parles de quoi ? Du noyau ou de la distribution ? comme je pense que tu parles de la distrib, tu devrais relire ce que j'ai écrit : les serveurs du top500 sont des serveurs qui tournent avec des versions adaptées spécifiquement des distributions d'OS, quel que soit l'OS sous-jacent. Tu n'installes pas une Debian ou une RedHat/centOS standard pour tirer profit du matos.
[^] # Re: GNU/SystemD/Linux
Posté par Zenitram (site web personnel) . Évalué à -4. Dernière modification le 02 décembre 2013 à 13:30.
Dans le noyau aussi ils cassent souvent tout, c'est horrible etc… Aucune différence sur les principes (le monde évolue, le code aussi); systemd n'est juste dans la discussion pour être le souffre-douleur, mais tout Linux (le noyau) bouge de la même manière avec les mêmes impacts même si tu ne le vois pas (par exemple, grsecurity doit toujours s'adapter) et donc ne tape pas dessus.
[^] # Re: GNU/SystemD/Linux
Posté par lasher . Évalué à 3.
Red Hat tourne beaucoup sur les machines Blue Gene. Cependant, c'est une version ultra-light. De plus, si RHEL "light" est utilisé sur l'un des processeurs POWER/PowerPC, ils utilisent aussi très souvent KITTEN (développé dans les labos de Sandia), ou NanOS (développé au Barcelone Supercomputing Center), un « light-weight kernel » qui reprend partiellement l'API POSIX mais avec un modèle de threading et de gestion des ressources très différent en règle générale de ce que Linux offre.
[^] # Re: GNU/SystemD/Linux
Posté par Maclag . Évalué à 6.
Si les trucs "plus costauds" ne sont pas sous Linux, je ne vois pas en quoi ils seront emmerdés par systemd…
Pour les trucs "simples" que fait RedHat, faut croire que ça marche!
[^] # Re: GNU/SystemD/Linux
Posté par Joris Dedieu (site web personnel) . Évalué à 10.
Haproxy s'est adapté puisqu'un wrapper à été commité. On peut le lancer avec l'option -Ds qui permet de lancer un wrapper qui ne fait rien d'autre qu'un wait() afin de donner à systemd un PID stable a monitorer.
http://git.1wt.eu/web?p=haproxy.git&a=search&h=HEAD&st=commit&s=systemd
[^] # Re: GNU/SystemD/Linux
Posté par totof2000 . Évalué à 0.
Systemd sur un poste de bureau, je n'ai rien contre, bien au contraire. Systemd, c'est sur les serveurs que je n'en veux pas, parce que les problématiques serveurs et poste de bureau ne sont absolument pas les mêmes. Et le genre de problème qui a été reonté par la personne à qui tu réponds, c'est ce que l'on rencontre couramment dans le monde des "gros" serveurs. Maintenant ce que je vois, c'est qu'à cause de ce genre de conneries, c'est une tentative de percer sur le bureau. ca ne marchera pas. Et surtout, Linux perdra le marché des serveurs au profit des OS proprios tels qu'AIX ou Solaris, voire Windows.
[^] # Re: GNU/SystemD/Linux
Posté par oinkoink_daotter . Évalué à 7.
T'es au courant que Solaris a un équivalent de systemd (SMF) depuis des années ?
[^] # Re: GNU/SystemD/Linux
Posté par totof2000 . Évalué à -1.
Je suis parfaitement au courant, c'est l'une des raisons pour lesquelles je ne fais plus de Solaris. Mais vu que Solaris est prévu pour tourner sur du matos spécifique, il est fort probable que les problématiques de desktop auxquelles tente de répondre SystemD n'ont pas été prises en compte. Sinon, il me semble que le système de démarrage de Solaris et de SystemD ne sont pas si proches que ça : le système de démarrage de Solaris - me semble-t-il - ne s'accapare pas la gestion des logs et tous les autres trucs que fait systemd. Il faudrait que je vérifie ça.
[^] # Re: GNU/SystemD/Linux
Posté par Joris Dedieu (site web personnel) . Évalué à 6.
Non SMF sert uniquement à gérer les services. init continue d'exister. Il lance et supervise svc.configd et svc.startd. Il peut également lancer des processus définies dans /etc/inittab bien que cette façon de faire soit dépréciée.
Les logs continent d'être gérés par syslogd et les tty par ttymon (qui existe depuis solaris 2 je crois) comme précédemment.
[^] # Re: GNU/SystemD/Linux
Posté par Zenitram (site web personnel) . Évalué à 2.
Ou alors, il en gagnera car systemd, entre autres choix techniques, a des atouts, y compris sur les serveurs.
[^] # Re: GNU/SystemD/Linux
Posté par Barnabé . Évalué à -3.
Eh ben dis donc, mon Zenitram, tu progresses pas beaucoup en argumentation…
[^] # Re: GNU/SystemD/Linux
Posté par Misc (site web personnel) . Évalué à 8.
Tu bullshites ( comme d'hab sur certains sujets, donc je vais pas passer du temps à te répondre ). Sur une distro RHEL 6, pour avoir un programme lancé par init, tu va utiliser ça par exemple:
Sur une fedora 20, avec systemd, tu va utiliser:
La réécriture est en effet si douloureuse qu'on pourrais croire qu'il y a rien à faire à part recompiler la policy. Mais peut être que tu veux dire qu'il faut rajouter des autorisations quand on rajoute des fonctions ( car peut être que "compatible avec systemd", tu veux dire "compatible avec l'activation par socket" ce qui est totalement différent, et qui reviens à dire "selinux requiert de tout refaire de 0 si jamais on rajoute une feature sur un soft", ce qui est n'importe quoi ).
Oups, tu peut remplir un bug pour Fedora, car visiblement, la fedora 20 que j'ai a l'air de réussir à le lancer, et visiblement, ç'est un bug que ça marche.
Ensuite peut être que tu veux dire "haproxy n'utilise pas le démarrage par socket ou à la demande", ce qui est différent de "ne marche pas avec systemd". Mais bon, comme tout le reste de ta prose est assez souvent de la même acabit, je vais laisser quelqu'un d'autre te répondre ( ou ne pas passer de temps dessus, car ça ne vaut pas le temps passé à l'exercice ).
[^] # Re: GNU/SystemD/Linux
Posté par Kaane . Évalué à 3.
Tu bullshites ( comme d'hab sur certains sujets, donc je vais pas passer du temps à te répondre ). … Mais peut être que tu veux dire qu'il faut rajouter des autorisations quand on rajoute des fonctions
Non, je parle des cgroups et de selinux.. Par exemple pour les cgroups : si tu veux que deux services partagent le même cgroup, ou si tu veux que ton cgroup de tagging serve aussi à créer des limites, ou si tu veux avoir plusieurs cgroups sur un service ou des dizaines d'autres choses. En fait quand les cgroups ont été créés, certaines personnes ont eu l'idée (idiote je le reconnais aujourd'hui, mais à l'époque c'était difficile à voir) que ça pouvait servir à autre chose qu'à permettre à un système d'init qui serait écrit plusieurs années plus tard. Un des trucs fantatisque (pour un admin) était les hiérarchies, créer un cgroup "database" qui a la priorité partout, et un cgroup "frontend" qui n'a le droit d'utiliser qu'un seul CPU, à peine un peu de bande passante et de mémoire. Bref les trucs fondamentaux vont dans le cgroup "database" et les autres trucs vont dans le cgroup "frontend" - donc même si un crétin avec les droits roots lance une commande bouffeuse de ressources, la base de données aura toujours quoi qu'il arrive 80% des ressources réservées pour elle. C'est cool c'est génial c'est beau.
SAUF QUE - systemd va venir se servir du tagging des cgroups pour faire sa sauce, et la c'est le drame. Par exemple si j'ai l'habitude de faire des triplets apache/mysql/php en fastCGI et de les mettre dans le même cgroup pour limiter (par exemple) la consommation CPU dudit cgroups. Typique je lance 10 triplets AMP dans 10 cgroups AMP0, AMP1 … AMP9 qui déscendent tous de AMP_MASTER qui limite la consomation CPU à 25% MAX. Je vais pas rentrer dans les détails, mais pour faire un truc pareil avec systemd tu vas morfler. Une fois dans un cgroup un process ne peux pas en sortir, une fois un cgroup activé aucun process ne peut rentrer dedans. Et tu ne peux même plus utiliser le tagging pour suivre le lancement de tes process parce que systemd utilise le sien propre (et qu'un sous système ne peut se trouver à deux endroits d'une même hiérarchie bien sur).
Voilà typiquement un exemple d'utilisation de cgroups que systemd empêche de faire fonctionner. Et typiquement pour t'en sortir il faut repenser tes policies.
Oups, tu peut remplir un bug pour Fedora, car visiblement, la fedora 20 que j'ai a l'air de réussir à le lancer, et visiblement, ç'est un bug que ça marche.
Dans mon post j'explique clairement ce que je veux dire :
Fedora a écrit un wrapper qui a son tour lance HAProxy - sinon c'est la guerre au moment des reloads.
[^] # Re: GNU/SystemD/Linux
Posté par groumly . Évalué à -10.
La premiere question qui me vient a l'esprit c'est "tu fais vraiment tourner mysql et apache sur la meme box?"
T'es serieux ou tu trolles juste?
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: GNU/SystemD/Linux
Posté par Misc (site web personnel) . Évalué à 6.
Non, la tu parles de cgroups tout court, à aucun moment tu ne parles de selinux dans ta réponse. Quand aux histoires de hiérarchies des cgroups, c'est une chose que le dev des cgroups veut revoir pour justement éviter l'explosion de complexité, cf par exemple le dernier linuxmag ou il est interviewé. Systemd utilise le concept de slices pour faire une abstraction sur tout ça.
Je vais coller le fichier unit qu'on voit le fameux wrapper :
Il n'y a pas de wrapper pour lancer haproxy, ça lance direct le binaire :
Je ne sais pas quel distribution tu utilises pour faire du systemd avec un wrapper haproxy, mais ça doit pas être Fedora à vue de nez. Y a pas de mention du wrapper dans le changelog du paquet, pas de patch.
[^] # Re: GNU/SystemD/Linux
Posté par Kaane . Évalué à 2.
Ca s'appelle donner un exemple. Ce qui est indiqué en plus par Par exemple pour les cgroups :
Pour se-linux les exemples seraient beaucoup plus longs et compliqués à expliquer (non pas fondamentalement, mais parcequ'il faudrait que je raconte ma vie sinon il y a encore des gens "qui savent mieux" qui viendraient m'expliquer comment faire autrement sans se-linux)
Maintenant grosso-modo l'idée générale est que si tu veux protéger ton service contre un restart intempestif même par un user même root (dans le mauvais domaine), ben systemd va péter un câble. Charge à toi donc de concilier les droits et les différents domaines d'une façon qui a) ne casse pas ta sécurité et b) ne casse pas systemd/ta distrib.
C'est lourd.
Relis la ligne reload…
ExecReload=/bin/bash -c
[^] # Re: GNU/SystemD/Linux
Posté par Misc (site web personnel) . Évalué à 10.
Donc récapitulons, l'incompatibilité entre haproxy et systemd, c'est le fait de devoir rajouter 1 ligne de bash dans l'unité systemd, chose qui a bien du prendre 5 minutes, vu que la ligne vient du script d'init haproxy avec une rapide adaptation pour l'accès à $MAINPID. Si une ligne de bash est un souci, j'ose me demander ce que les 108 autres lignes du script d'init sont…
J'imagine dire que "attention, des logiciels comme haproxy et plein d'autres que je ne cite pas peuvent requérir un oneliner bash pour fonctionner", ça casse vachement moins la baraque.
[^] # Re: GNU/SystemD/Linux
Posté par Kaane . Évalué à 0.
J'imagine dire que "attention, des logiciels comme haproxy et plein d'autres que je ne cite pas peuvent requérir un oneliner bash pour fonctionner", ça casse vachement moins la baraque.
Bof tu sais dire "Attention, sur un logiciel comme HAProxy, quand on le lance avec systemd, même en mode fork (ce qui est déjà pas top) on est quand même obligé de faire un wrapper pour le reload", ca me gêne moins que de voir mes arguments réduit à peau de chagrin par les propres infos que j'ai donnée et que je n'ai pas su lire.
[^] # Re: GNU/SystemD/Linux
Posté par Batchyx . Évalué à 4.
C'est plutôt toi qui lis des choses que je ne dis pas.
Je n'ai jamais dis que la majorité voulais virer systemd, j'ai dis qu'ils y a des gens qui cherchent à le virer.
Personnellement, je connais aucun système de boot assez générique, généraliste, simple et facile pour contenter tout le monde. Et je crois que ça n'existera jamais. Toute tentative d'unifier ça va forcement se terminer par un standard supplémentaire.
Si le système de boot est maintenu par la distribution, le boot de chaque système est maintenu par l'administrateur. Si l'administrateur peux pas gérer et agencer son boot comme il veut parce que le système de boot est trop borné ou trop imprévisible, c'est lui qui devra trouver une autre solution, pas le mainteneur de la distribution.
Il répondra pas à tout les besoins. Surtout sur les systèmes ou lancer udev invoque l'OutOfMemory Killer du noyau dans les secondes qui suivent.
Ben non, personne n'est obligé de réparer son système pour qu'il marche. C'est tellement plus marrant d'acheter du matériel et d'installer des systèmes dont tu ne peux pas te servir pour ce que tu veut en faire.
Personne ne te met un flingue sur la tête pour que tu livre des choses qui marchent à un client, pourtant tu le fait quand même, non ? (enfin j'espère)
Tu prend le problème à l'envers. Ceux qui découvriront que systemd ne correspond pas à leur besoin devront changer d'outil. Faudrait quand même avoir un système qui marche à la fin, même s'il faut le maintenir soit-même. Parfois c'est la meilleure solution. Et parfois c'est la seule.
Avant, si je devais faire un démon à peu près portable, il suffisait généralement que je file un script rc.d pour les Linux et Unix-like, et peut-être de quoi avoir un service Windows et/ou un job launchd pour MacOSX.
Maintenant, je doit faire tout ça, et aussi un unit systemd pour les distros qui utilise ce truc. Le script d'init ne va pas disparaître, vu que BSD est pas près de passer à systemd.
Un standard de plus.
Pourquoi ? Si toutes ces distributions respectent un standard de fait que je peux utiliser (au hasard, POSIX, FHS, ou l'API du noyau Linux), j'ai aucun problème avec ça. La seule chose chiante c'est les bugs que chaque distribution se prend. Mais heureusement qu'il y en a plusieurs. Si il y en avais qu'une seule, j'aurai aucun moyen d'échapper à ses bugs.
Je vois pas le rapport avec la choucroute. Note les trois premiers mots de ma réponse. "Dans la pratique".
[^] # Re: GNU/SystemD/Linux
Posté par Astaoth . Évalué à 1.
Ca inclu Gentoo, Slackware, et leurs forks respectifs ?
Tant qu'on est à débattre/troller sur les fonctionnalités de systemd, ca marche comment pour les logs ? C'est toujours stocké en binaire, et pouvant être exporté en xml ? (vraie question, j'ai une distro qui utilise openrc).
Emacs le fait depuis 30 ans.
[^] # Re: GNU/SystemD/Linux
Posté par Maclag . Évalué à 7.
Non, c'est toujours stocké en binaire avec une bête option pour avoir du texte brut comme avant en plus, et au même endroit qu'avant (sur ma Debian au moins).
Bref, si tu n'utilises pas journalctl, tu ne verras pas la différence.
[^] # Re: GNU/SystemD/Linux
Posté par Astaoth . Évalué à 2.
Hum, à quoi sont censés servir les logs binaires en fait ?
Emacs le fait depuis 30 ans.
[^] # Re: GNU/SystemD/Linux
Posté par xcomcmdr . Évalué à 2.
Tout est expliqué ici
Pour résumer :
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: GNU/SystemD/Linux
Posté par Moonz . Évalué à 6.
Le texte ne demande pas plus de code, de dépendances ou d’abstractions que le binaire.
Le texte le fait, en mieux (en binaire tu dois gérer le cas où ta donnée structurée est coupée en plein milieu, est parasitée par un secteur défectueux sur le disque… Bonne chance si ton outil te fait un segfault parce que le champ « taille de l’enregistement » a été corrompu)
Le texte le fait, en mieux (je peux lire mail.log généré sous mon serveur Linux sous MacOS X, Windows ou FreeBSD ou une vieille distribution/LiveCD qui n’a pas journalctl, ce n’est pas le cas avec journald). Problème très concret rencontré récemment : le mode rescue d’OVH n’avait pas journalctl, si je n’avais pas les bons vieux logs texte à côté j’étais bien avancé pour analyser le problème…
Tu peux difficilement faire plus rapide qu’ajouter une ligne dans un fichier texte
D’accord sur l’avantage du binaire sur ce point.
Pas d’accord sur le fait que ce soit une raison suffisante.
Le reste des points abordés est indépendant du format de stockage. C’est une très belle argumentation pour expliquer les avantages de journald (et encore, mais je n’ai pas envie de troller sur la logique bizarre de ce document qui dit en gros « si l’on suppose que journald est universel, alors journald est meilleur que syslog parce que l’universalité est une propriété désirable pour un système de log »…), pas de l’utilisation d’un format binaire.
[^] # Re: GNU/SystemD/Linux
Posté par Zenitram (site web personnel) . Évalué à 4.
Merci, j'ai bien rit.
c'est vrai que formater un timestamp (généralement un entier 8 octets) en une date "humaine" de 40 caractères, puis écrire 5x plus de données sur le disque que nécessaire, pareil pour les autres champs, c'est ce qu'il y a de plus performant et difficile de faire plus rapide…
Tu as aussi oublié la partie "browsing", où la c'est le sport pour détecter le format (les langues etc… au bohneur la chance), convertir en timestamp pour enfin pouvoir comparer, c'est aussi difficile à faire plus rapide.
Tu plaisantes la, rassure-moi.
Avec toutes les autres (dont le bordel du texte pour un non humain), ça le fait.
Et peut-être pour toi tu as rien à faire de perdre de la place, mais qui sait d'autres (qui payent car ont vraiment besoin) ont peut-être ce besoin… Qui ne t'enlève rien (Tu peux continuer à garder le texte si ça te chante).
Avec ce genre d'argument, on arrête toute évolution, on gèle tout. Non merci, je te laisse ce monde figé, d'autres souhaitent avancer.
[^] # Re: GNU/SystemD/Linux
Posté par Moonz . Évalué à 5.
Tu devrais prendre des cours :
L’argument « on VEUT que des logs soient lisible de partout en toute circonstance », c’est un argument sortit par l’auteur de ce document hein, mais je suppose que lui aussi est un méchant réactionnaire rétrograde qui refuse tout changement.
Le problème de ce document c’est qu’il présuppose l’universalité de journald et qu’il se permet de déduire « donc c’est lisible partout en toute circonstance ». Le problème évident étant que journald n’est pas universel à l’heure actuelle (j’ai donné un exemple concret) et ne le sera probablement jamais (Windows, autres Unix qui refuseront d’intégrer du LGPL). Alors que le texte plat, c’est déjà universel (et encore même pas, il y a encore des systèmes en ECBDIC dans la nature, mais ça s’approche déjà infiniment plus de « universel » que journald)
J’ai rien contre le fait d’avancer, j’adhère à 90% aux positions de principe de ce document, mais quand je lis « les logs doivent être lisibles en toute circonstance et de partout », permet moi de pointer l’incohérence du choix d’un format binaire avec ce principe…
[^] # Re: GNU/SystemD/Linux
Posté par Zenitram (site web personnel) . Évalué à -5.
Tu as déjà essayé de lire une date en arabe?
A partir du moment où tu ne lis même pas ce qui est écrit et fait comme si ça n'avait pas été écrit… Tu risque de convaincre que toi-même avec de tels arguments.
La première des politesses est de ne pas ignorer ce que les gens écrive, la deuxième est de ne pas les prendre pour des cons.
[^] # Re: GNU/SystemD/Linux
Posté par Moonz . Évalué à 7.
Et qui ici a dit que tu devais impérativement stocker les dates dans le format de la locale ? Qui ici a refusé tout principe d’uniformisation, standardisation et rationalisation des logs ? Personne. Mais comme c’est ce que tu veux entendre (parce que ça conforte tes préjugés « tous des réactionnaires réfractaires au changement »), ben c’est ce que tu lis.
J’arrête les frais avec toi, je savais que j’aurais même pas dû essayer d’argumenter. Honnêtement, il y a quelque mois encore ton côté « avocat du diable » était intéressant parce que pertinent, et argumenté et honnête, mais depuis quelques temps tu ne fais que sombrer dans l’invective (et je dis pas ça parce que je ne suis pas d’accord avec toi sur ce point, c’est quelque chose que j’ai remarqué bien avant, et même sur des sujets sur lesquels je suis 100% d’accord avec toi, comme par exemple le travail le dimanche, sujet sur lequel tu as été absolument odieux avec tes contradicteurs).
Oui, c’est de l’ad hominem, tu peux en faire de même en réponse si ça te défoule, mais il fallait que ça sorte.
[^] # Re: GNU/SystemD/Linux
Posté par Maclag . Évalué à 9.
Moi ce que je ne comprends pas, c'est que journald permet d'avoir les logs à la fois en binaire et en texte exactement comme avant.
Alors pourquoi est-ce tellement un problème d'avoir les 2? Les regex, la lecture par un humain, tout ça reste possible, très exactement comme avant même, vu que journald peut aller remettre les logs au bon endroit dans /var/log.
Et quand bien même le format serait binaire, on n'a pas besoin de tout systemd pour lire un journal sur BSD. Si le besoin s'en fait sentir, libre à tous de faire un lecteur de journal au format journald (c'est pas comme si tous les formats pour tout étaient déjà standardisés et universels…).
[^] # Re: GNU/SystemD/Linux
Posté par Astaoth . Évalué à -3.
Mon dossier de log sur mon serveur fait 160Ko. Peux tu me donner un cas où 160Ko est un espace de stockage non négligeable ?
Pour la langue : par défaut en anglais. Je ne savais même pas qu'on pouvait avoir des logs localisés pour Apache, OpenSSH, Postfix, et cie, j'ai toujours cru que par convention on ne faisait que des logs en anglais.
Les outils Unix sont conçus spécifiquement pour traiter du texte ; ca reste le format universel pour Unix. Sinon, il y a un truc qui a 40 ans environ qui s'appelle "expressions régulières", très efficace pour parser du texte en O(n) quand c'est bien fait. Le gros intérêt est que ca existe ailleurs que sous Linux.
C'est très bien d'avancer, mais vaut mieux que ce soit en avant et non dans un mur. Je peux te citer des exemples de gens qui ont voulu faire et avancer, mais trop hâtivement, et se retrouver avec une magnifique différence entre leur propre doc et leur implémentation réelle.
Emacs le fait depuis 30 ans.
[^] # Re: GNU/SystemD/Linux
Posté par xcomcmdr . Évalué à 2. Dernière modification le 03 décembre 2013 à 21:22.
Et c'est très fragile. Ta regex devient inutile dès que le format des messages changent.
Peut-être que tu peux écrire des regex très intelligentes. Mais dès que le format des messages va changer, t'auras 50% de chances pour que ta regex ne fonctionne plus.
Perso, je préfère avoir affaire à une API stable ou une base de données qu'à du texte. Pis, du texte en langue humaine, le genre de langages très peu standardisé (où personne n'arrive à se mettre d'accord sur une chose aussi bête que le format des dates !).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: GNU/SystemD/Linux
Posté par Astaoth . Évalué à 2.
Je suis tout à fait d'accord avec toi sur la stabilité de la chose. Mais n'importe quel format possible répond à tes critères, du moment que les logs sont générés par journald.
Emacs le fait depuis 30 ans.
[^] # Re: GNU/SystemD/Linux
Posté par gouttegd . Évalué à 5.
Et qu’est-ce que systemd-journald va changer à cela au juste ?
Systemd-journald n’impose absolument rien quand au format des messages. Un programme souhaitant enregistrer une entrée dans le journal peut envoyer un message structuré basé sur des champs bien définis, mais le même programme peut aussi utiliser des champs qu’il définit lui-même et surtout il peut parfaitement se contenter de n’envoyer que de banales chaînes de caractères dans lequel il formatte les informations à sa guise. journald n’impose même pas la locale ou l’encodage des chaînes de caractères en question (UTF-8 est recommandé mais la documentation dit clairement que rien n’est fait pour l’imposer).
Tu auras une API stable pour accéder aux messages, mais pas pour exploiter leur contenu. Si un programme change le format de ses messages (que ceux-ci soit structurés ou non), tu devras toujours t’y adapter. systemd-journald ne résoudra pas automagiquement ce problème qui est totalement hors de sa portée, c’est entièrement dépendant des développeurs des programmes qui écriront dans le journal. Comme avec syslog en fait.
[^] # Re: GNU/SystemD/Linux
Posté par Anonyme . Évalué à 4.
Ca change que le programme peut logguer des données de facon structurée. Avec syslog il ne le peut pas. Et meme si le programme ne le fait pas, journald log de base certaines infos de facon structurée, comme le PID et l'UID du process, l'ID de boot, l'unit systemd, les infos SELinux, etc …
Si les données sont logguées de facon structurée, il est relativement simple de ne pas casser la compatibilité, l'ajout d'un nouveau champ ne va pas poser de problèmes. Si tu loggues tes données en vrac sur une ligne de texte, l'ajout d'un nouveau champ peut facilement casser tes regexps.
[^] # Re: GNU/SystemD/Linux
Posté par gouttegd . Évalué à 4. Dernière modification le 05 décembre 2013 à 23:56.
Et combien vont le faire ? Sachant que seul systemd-journald offre cette possibilité et qu’il n’est pas seul en jeu. Tu crois que les développeurs de démons vont laisser tomber syslog(3), largement disponible, et se mettre à utiliser l’API propre à systemd-journald ? Moi je n’y crois pas. Oh, certains le feront, certainement, mais je doute fort qu’ils soient nombreux.¹
D’ailleurs, d’après Lennart Poettering, la meilleure façon de logger, pour les démons « new style » (c’est comme ça qu’il appelle les démons conçus dès le départ pour profiter de systemd), c’est d’utiliser… le bon vieux printf(3), systemd se chargeant d’envoyer la sortie standard du démon vers journald.
Sauf que typiquement ce ne sont pas ces informations que l’on veut aller grepper dans les logs, mais bien les informations propres au programme, celles contenues dans le message qu’il a envoyé.
Pour illustrer mon propos, mettons que je veuille récupérer les adresses des petits malins qui tentent de bruteforcer mon serveur SSH. Actuellement, avec des journaux au format texte gérés par syslog, je ferais quelque chose du genre :
avec une belle regex fragile qui peut ne plus marcher à la prochaine mise à jour de sshd si les développeurs de celui-ci ont jugé bon de changer le format de ce message.
Avec des journaux au format binaire gérés par systemd-journald, je ferais (attention, révolution) :
… avec une belle regex fragile qui peut ne plus marcher à la prochaine mise à jour de sshd si les développeurs de celui-ci ont jugé bon de changer le format de ce message. Zut alors, ni systemd-journald ni le fait de stocker les journaux au format binaire n’ont empêché ça.
Le seul bénéfice visible de journald, ici, c’est de faire l’économie de la première regex, celle qui sert à filtrer les messages issus de sshd — c’est-à-dire, la plus simple et surtout celle qui n’est pas vraiment susceptible de changer.
Je considérerai cet avantage lorsque je verrai les développeurs de sshd opter pour l’API de journald en lieu et place de syslog(3). En attendant, c’est purement théorique.
¹ Quand je vois le nombre de programmes qui enregistrent encore leurs données directement à la racine de $HOME au lieu d’utiliser les répertoires proposés par la « XDG Base Directory Specification »… il ne suffit pas de proposer quelque chose de pratique pour que ce soit utilisé.
[^] # Re: GNU/SystemD/Linux
Posté par Anonyme . Évalué à 2.
Il n'y a pas besoin de laisser tomber syslog, le support de l'API journal peut etre ajoutée dans des #ifdef.
Quelques uns c'est deja mieux que aucun. Et meme si peu de programmes le font pour l'instant, peu importe, c'est deja bien de pouvoir en profiter pour ses propres programmes.
Non, ca peut permettre par exemple de ne grepper que les logs du dernier boot, ou du precedent, ou uniquement ceux depuis une certaine date.
Pour la recherche par IP, c'est une bonne idée de patch à proposer aux developpeurs de OpenSSH. En rajoutant aussi le nom d'utilisateur.
[^] # Re: GNU/SystemD/Linux
Posté par gouttegd . Évalué à 1.
Quand je disais « laisser tomber syslog pour journald », je sous-entendais naturellement « sur les plate-formes où systemd est disponible ». Et ça ne change rien à mon propos : qui va le faire ? Qui va prendre la peine de préparer une entrée de log structurée quand systemd est disponible, et une ligne de texte partout ailleurs, alors qu’il peut tout simplement continuer à utiliser une ligne de texte partout comme actuellement ?
Point accordé. Ça doit être bien pratique dans certains cas. Mais je ne trouve toujours pas ça transcendant (c’est-à-dire que je ne suis pas convaincu que ça justifie une telle refonte du système de log).
Enfin bref, comme je n’ai pas spécialement l’intention d’intervenir davantage dans ce débat, je vais résumer ma position actuelle sur systemd :
– détracteurs de systemd, ne vous tracassez pas trop, vous verrez qu’en définitive, systemd ne changera pas grand’chose ;
– adorateurs de systemd, ne vous emballez pas trop, vous verrez qu’en définitive, systemd ne changera pas grand’chose.
Bon vendredi.
[^] # Re: GNU/SystemD/Linux
Posté par cedric . Évalué à 3.
La plus part des daemons codes proprement vont avoir une point unique ou sera code toute leur infrastructure de log. C'est actuellement 5 lignes de code a faire pour passer de syslog a journald dans une infrastructure existante. Pour le coup, l'integration systemd complete, c'est pas loin d'etre juste une 30 aines de ligne codable par un developpeur debutant dans le projet.
Donc si tu utilises des daemons bien code, ils seront rapidement adapte pour tirer benefice de systemd. Si ils ne le sont pas, tu pourras le faire toi meme (logiciel libre, tu as les sources, tout ca). Ce sera l'occasion de te rendre compte si le code des daemons que tu utilisent est bien, ou pas, foutu. Globalement une tache plutot interressante pour decouvrir son systeme.
[^] # Re: GNU/SystemD/Linux
Posté par Anonyme . Évalué à 1.
Le packageur sur une distribution basée sur systemd va simplement activer la bonne option de compilation.
[^] # Re: GNU/SystemD/Linux
Posté par Zenitram (site web personnel) . Évalué à 0. Dernière modification le 03 décembre 2013 à 21:24.
Ok, j'ai encore bien rit, merci.
Me causer de trucs qui pète lors d'une bête mise à jour car la regex n'a pas prévu le léger changement… me parler du truc bâtard que tu fais parce que tu n'as pas le choix et qu'à chaque update de base (même pas un changement de version) tu croises les doigts pour ne pas manquer une regression, c'est ce qu'il me fallait. C'est bien le gros exemple de la merde que sont les logs texte (du moins ceux de la vraie vie, qui n'ont aucune spécification et où chacun fait un peu comme il veut de toutes façon c'est pas fait pour être lu par une machine. Dommage, on voudrait qu'une machine les lise…).
Manque de pot, ici ça a l'air de marcher, vu la vitesse à laquelle le projet a été adopté pour des ditro professionnelles* (qui font attention donc)…
Qui peut démontrer que ça va dans un mur? C'est plutôt le contraire qui se voit…
Faudrait arrêter l'excuse "je suis pour avancer, mais il faut pas anvacenr tu as vu le voisin il en est mort". Ca veut dire "ne pas avancer".
D'autres avancent, tout le monde est libre de dire "non, je ne suis pas d'accord", c'est imposé à personne.
Si vous y croyez vraiment, assumez et gérez.
Pourquoi vous ne laisser pas les gens "se planter" pendant que vous montrez que c'était la mauvaise voie? Moi je conclu que vous n'y croyait pas du tout à ce que vous dites…
[^] # Re: GNU/SystemD/Linux
Posté par Astaoth . Évalué à 0.
Je t'en prie :)
Sinon, on peut également définir des formats standards de texte, ce n'est aps réservé qu'au binaire.
Tu veux qu'on discute des choix de Apple ou de Microsoft sur leurs OS ?
De l'adoption rapide de docx comme format d'échange de documents textes par des entreprises professionnelles du domaine ? Et par le reste du monde aussi ?
Je dois avouer que j'aurais été plutôt surpris si Red Hat n'avait pas adopté systemd.
C'est très exactement ce que je fais.
C'est également ce que je fais. J'ai changé de distribution lors de l'obligation de son utilisation sur celle que j'utilisais avant.
Emacs le fait depuis 30 ans.
[^] # Re: GNU/SystemD/Linux
Posté par madhatter (site web personnel) . Évalué à 2.
Et moi, ça fait plusieurs fois que ça me pique les yeux : il n'y a pas de "t" au participe passé de rire. ;)
En ce qui concerne le débat, j'ai l'impression que bien que systemd soit libre et qu'il ne soit imposé à personne, le fait qu'il soit étroitement lié à d'autres projets importants (par exemple Gnome) et qu'il touche un peu à tout (journaux, consoles…), va rendre plus délicate la possibilité de ne pas le choisir. Tu ne crois pas ?
There is no spoon...
[^] # Re: GNU/SystemD/Linux
Posté par Zenitram (site web personnel) . Évalué à 4.
oups…
Je ne crois pas, non :
- Personne n'oblige à utiliser quoi que ce soit. Tu es libre de passer à Ubuntu ou FreeBSD si ça te chante, et en plus vu l'horreur qu'est systemd qui détruit tout, les distros ayant fait le "mauvais" choix mourront et donc on en entendra même plus parler (ou l'inverse en fait)
- C'est libre! Si il y a des gens qui croient vraiment que Linux va s'effondrer (on croirait les anti-mariage homo qui prédisent la fin du monde) et que c'est horrible, les gens dans ce style peuvent forker et prouver qu'ils ont raison. D'après toi, si il y a plus de paroles que d'actes, c'est pour quelle raison? Encore une fois pourquoi les autres devraient être les esclaves de gens pensant que c'est pas bien d'utiliser systemd?
Ca a déjà été dit maintes fois, je pense que le plus important maintenant est d'arrêter de colporter de telles sous-entendus qui n'est que du FUD. Il faut aussi arrêter dans la vie de tous les jours, pas que systemd, ce "j'ai pas le choix". On a le choix, il faut seulement en assumer les conséquences (les autres n'étant pas nos esclaves).
Peut-être que le problème se situe ailleurs, bref pas chez les distros, de l'autre côté… rien de nouveau, on interdisait bien à un moment aux voiture de rouler plus qu'au pas par peur que le monde s'écroule à coup d'argument "vraiment scientifiques, attention horrible", et les voitures n'ont pas tué la marche à pied.
[^] # Re: GNU/SystemD/Linux
Posté par madhatter (site web personnel) . Évalué à -3.
OK. Effectivement, je peux changer de distribution. Mais, je travaille sous Debian depuis quelques années, et son fonctionnement, ses conventions, ne sont pas les mêmes que celles de Gentoo par exemple. Je devrais donc me réadapter. Pourquoi pas, mais ça demande du temps et une envie que je n'ai pas. Je suis à l'aise sous Debian et en accord avec ses conventions.
Donc, si Debian choisi d'intégrer systemd, à moins de changer de distribution, j'ai peur qu'il soit compliqué pour moi de choisir une alternative à systemd sous Debian, du fait du design de systemd.
Dans le principe je n'ai rien contre une évolution des choses. Repenser le système d'init, pourquoi pas. Les raisons que tu évoques sont légitimes. Ce qui m'embête c'est cette impression que ça se fasse au détriment des autres solutions.
Vu les liens qui semblent exister entre Gnome et systemd, quelle va être la masse de boulot pour choisir et faire fonctionner une alternative à systemd ?
En essayant d'être plus parlant, toujours sous Debian, si Gnome ne me plaît pas ou plus, je le désinstalle et le remplace par xfce ou kde par exemple. Ça n'a pas d'impact. Mais si systemd ne me convient pas, je ne pourrais probablement pas utiliser Gnome, et donc il faudra soit que je change de DE (ce que je ne souhaite pas forcément), voir que je change carrément de distribution.
Et si toutes les distributions font le choix de systemd, que me reste t'il ? Développer et maintenir ma propre distribution ? Utiliser Windows ou Mac OS ?
D'accord pour ne pas considérer les développeurs comme des esclaves, mais il faut aussi que tu entendes que c'est pas juste pisser de la ligne de code. Il y a des utilisateurs derrière, tu ne pas les dénigrer non plus.
Tu développes mediainfo, tu ne le fais pas que pour toi. Je m'en sers moi et je t'en remercie. Mais si demain tu décides de tout arrêter, ce sera certes ton choix et je suis d'accord sur le fait que tu n'as pas à y être enchaîné à vie, mais ce sera également hyper égoïste de ta part. On n'y pourra rien, mais on ne t'avait pas non plus forcé à entreprendre son développement.
Pour mediainfo, on pourrait probablement trouver ou maintenir une alternative, mais pour systemd, les implications sont beaucoup grandes.
Tu vois ce que je veux dire ?
There is no spoon...
[^] # Re: GNU/SystemD/Linux
Posté par Zenitram (site web personnel) . Évalué à 9. Dernière modification le 04 décembre 2013 à 10:32.
Ah ouais, quand même… je vais peut-être perdre un utilisateur, mais il faut que ça sorte : je ne te dois absolument rien. Il n'y aurait absolument rien d'égoïste de ma part à ce que j'arrête, vu qu'il n'y a aucun rapport avec l'égoïsme.
"L'égoïsme est un trait de caractère, l'attitude d'une personne dont les actions ou les idées sont uniquement orientées par ses propres intérêts, sans prendre en compte les nécessités d'autrui."
Est-ce que ne plus faire d'actions est une action?
Refuser l'esclavagisme, se rebeller contre son maitre, est-il égoïste d'après toi?
D'après toi, personne ne devrait démissionner, car 'est de l'égoïsme?
Tout ces gens qui réclament des augmentation e salaire, n'est-ce pas de l'égoisme?
Pour revenir à systemd, proposer mieux pour la majorité des gens (car c'est bien la raison pour laquelle systemd est déployé) quitte à froisser des râleurs est-il considéré comme de l'égoïsme? vraiment?
On voit bien le problème qu'il y a dans la relation développeur FLOSS et utilisateur. Tu abuses du mot "égoïsme".
J'ai peur de voir, oui. Je préfère m'arrêter la, c'est trop gros.
Tant pis si je perd un utilisateur, mais d'autres sont plus reconnaissant et ne me traitent pas d'égoïste parce que je ne vais pas dans leur sens mais pense à tous mes utilisateurs, de manière globale, plutôt (mais j'en ai déjà eux qui m'ont traité de tous les noms car j'ai refusé d'aller dans leur sens… Ce genre de délire d'utilisateur qui veut tout n'est pas propre à systemd).
[^] # Re: GNU/SystemD/Linux
Posté par madhatter (site web personnel) . Évalué à -4.
Ouh là ! Doucement.
Je n'ai pas dit que tu étais égoïste, j'ai dit que ce serait égoïste de ta part d'arrêter du jour au lendemain le développement de mediainfo sans penser à tous à qui il rend bien service. Ça ne ferait pas de toi une mauvaise personne pour autant, ce serait ton choix et comme je l'ai dit, tu serais tout à fait libre de le faire car en effet, tu ne me dois rien.
Par ailleurs, pourquoi voudrais-tu perdre un utilisateur ? Tu penses vraiment que je vais m'offusquer de ta réponse au point de refuser d'utiliser un logiciel que tu développes ? On peut quand même discuter intelligemment, non ? Et on a parfaitement le droit de ne pas être d'accord. Sans déconner Jérôme, détends-toi. :)
Pour rester sur systemd, proposer mieux pour la majorité des gens, je suis pour. Je te rejoins sur le fait que l'innovation est une bonne chose.
Ce que j'essaye d'expliquer c'est que je trouve dommage que ce soit au détriment d'autres choses. Je suis d'accord pour que systemd innove, mais pas d'accord sur le fait qu'il me soit imposé pour utiliser Gnome par exemple. Pas d'accord non plus pour qu'il empêche toute alternative. De la même manière que chacun est libre de l'utiliser ou non, je veux rester libre d'utiliser l'init actuel de Debian.
Or j'ai le sentiment (peut-être à tort), que le fait que systemd soit si étroitement lié à tant de choses va m'empêcher de choisir autre chose (même si cette autre chose reste maintenue)
There is no spoon...
[^] # Re: GNU/SystemD/Linux
Posté par Zenitram (site web personnel) . Évalué à 6. Dernière modification le 04 décembre 2013 à 11:37.
Il y en a, du moins qui me le disent quand je leur dit que nous, je ne vais pas supporter le fichier buggué car c'est le fichier qui est buggé et pas mon logiciel.
je sais que je prend un risque quand je réagi. Ca reste un risque, pas de certitude :).
Je réagi en fonction de mes libertés potentielle. Et je n'accepte pas qu'on me parle d'égoïsme (mot très négatif, Wikipedia dit "Le terme est presque toujours utilisé de façon péjorative.") parce que j'utilise un droit.
Ma réaction reste la même : tu parles d'égoïsme un peu trop facilement, quand une personne ne fait pas (présent ou futur) un truc pour toi.
Tu n'as pas répondu à mes questions avec des exemples, qu'on sache comment tu vois l'égoïsme.
Mais en quoi est-ce la faute de systemd? Le coupable est dans ce cas Gnome.
C'est un truc que je trouve complètement ridicule aussi, ça n'a aune bonne justification de dépendre de l'init comme ça, c'est ridicule.
Mais ça n'a absolument rien à voir avec le sujet.
Il n'empèche rien. Libre à toi d'utiliser ce que tu veux, juste qu'il faut pas demander aux autres qu'ils bossent pour toi à te le préparer gratos.
Qu'est-ce qui interdit de faire un paquet (et le maintenir) en plus? Tu es libre, tout le monde et libre. y compris de refuser dans le dépot de Debian d'ailleurs.
La liberté des uns commence où celles des autres s'arrête. Tu parlait de communauté, mais si la communauté refuse, c'est la communauté. Tu ne peux pas dire que la communauté n'existe pas quand elle fiat juste un truc qui ne te plait pas.
Encore une fois, tu as toujours le choix. Sur tout. En plus, c'est libre, le travail est donc faible (seulement au pire un fork si tu n'arrives pas à convaincre la communauté, pour prouver que c'est mieux).
Tu es libre. Les autres aussi (la communauté comprise).
Ici, on parle qu'une poignée de râleurs veulent imposer leur point de vue à la communauté. Qu'on vienne pas me parler ensuite de respect de la communauté, les premiers à ne pas la respecter sont ceux qui crachent sur systemd et le choix de la communauté.
Comment peut-on parler de respect de la communauté quand on refuse les choix qu'elle fait?
On a l'impression d'avoir des réaction face à la justice qui quand elle tranche, va toujours avoir le "perdant" dire que la justice est pourrie (non pa qu'elle a fait un truc de mal, jsute qu'elle a pas fait comme attendu par la personne).
[^] # Re: GNU/SystemD/Linux
Posté par Anonyme . Évalué à 8.
Et dire que tout un tas de gens utilisent des bases de données structurées du genre MySQL alors qu'il leur suffirait de mettre ca en vrac dans un fichier texte et faire des grep dessus !
[^] # Re: GNU/SystemD/Linux
Posté par Anthony Jaguenaud . Évalué à 2.
Je suppose que si les log n’était pas en binaire dans les années 80-début 90, alors qu’un format binaire aurait été plus compact en ces temps reculés de l’informatique où le moindre octet avait son importance, que pour des raisons de performance word 5, works (en version DOS)… recopiait la structure en RAM dans un fichier sans conversion.
Les ingénieurs de l’époque étaient certainement plus bête que Lennart ? Je ne suis hélas pas aussi intelligent que toi, mais tu as certainement une théorie, que j’espère tu es près à m’instruire.
[^] # Re: GNU/SystemD/Linux
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 3.
Sans aller jusqu'a "instruire", je me rends compte que les entreprises, dans la "grande compétition internationale", cherchent de plus en plus le zéro faute, le zéro plantage, les mise à jour sans interruption de service, …
Et pour y arriver, on trace de plus en plus de chose, éléments susceptible de défaillir ou intéressant à analyser, scruté en temps réel pour agir dans l'instant. Mais globalement la quantité de data récolté/analysé explose [constatation perso]. Dans un petit SI, on compte rapidement en dizaine de Go/jours.
Toujours mon expérience, le format binaire ne me dérange pas, c'est un format interne, tout comme le format interne de mysql. Personne n'utilise mysql par son format de fichier binaire, mais plutôt par son API (SQL) et ses outils. C'est juste pareil avec systemd.
De toute façon, si on veut faire un travail sérieux dans un S.I. avec les logs (au delà des script à 2 balles qui font des grep dans des cron), on va se retrouver à centraliser ailleurs les logs dans d'autres bases servant à l'analyse, elle-même binaire, comme elasticsearch ou mongodb.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: GNU/SystemD/Linux
Posté par gouttegd . Évalué à 7.
Justement, systemd-journald ajoute pas mal « d’autres bricoles », comme :
– PID, UID et GID du processus émetteur ;
– le chemin du fichier exécutable ;
– la ligne de commande complète avec laquelle il a été lancé ;
– le cgroup dans lequel il se trouve ;
– le unit systemd dont il dépend ;
– un identifiant unique de la machine émettrice ;
– etc.
Cf. systemd.journal-fields(7) pour la liste complète (dans la section « Trusted journal fields »).
Du coup, voici à qui peut ressembler une entrée journald complète (telle que renvoyée par
journalctl -o export:Vu le nombre de champs ajoutés à stocker (ici, seul les champs MESSAGE et PRIORITY viennent du programme émetteur, tout le reste est ajouté soit par syslog, soit par journald), le choix d’un format binaire devient peut-être plus compréhensible… (Et puis, ça aurait pu être pire : si systemd avait été inventé dix ans plus tôt on aurait probablement eu droit à du XML…)
En tout cas, toujours au vu de la quantité d’informations à obtenir et à écrire, débattre du temps mis pour écrire un timestamp selon que l’on stocke en texte ou en binaire me semble assez peu pertinent, ce n’est certainement pas là à mon avis que systemd-journald passe le plus de temps.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1. Dernière modification le 05 décembre 2013 à 19:34.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: GNU/SystemD/Linux
Posté par gouttegd . Évalué à 5.
D’une part, le volume d’informations pour une entrée est tel que ça ne me paraitrait pas très pratique de tout stocker sur une ligne. Je note au passage qu’au moins deux de ces champs peuvent contenir des espaces (MESSAGE et CMDLINE), ce qui introduit la nécessité de trouver un séparateur dont on soit sûr qu’il ne figurera jamais dans le contenu d’un champ (ou de permettre des échappements).
On pourrait certes stocker une entrée sur plusieurs lignes, mais cela rendrait le journal sensiblement plus difficile à exploiter avec les outils Unix classiques qui sont typiquement conçus pour travailler sur des lignes (comment récupérer deux champs différents d’une même entrée à coups de grep|cut|sed|awk|etc. s’ils sont sur deux lignes différentes ? c’est possible, certes, mais certainement pas pratique).
D’autre part, avec systemd-journald la composition d’une entrée de journal n’est pas constante (par exemple, toutes les entrées n’auront pas de champ _SYSTEMD_UNIT, seules celles provenant d’un processus faisant partie d’une unité systemd). Et ce d’autant plus que systemd-journald veut offrir aux programmes la possibilité de créer leurs propres champs en plus des champs définis par défaut (même si je doute personnellement que cette fonctionnalité sera beaucoup utilisée). Encore une fois, gérer ça me paraît malaisé dans un format texte à la syslog (qui est facile à utiliser notamment parce que tous les champs sont à des positions connues d’avance sur une ligne).
Après, je n’ai pas dit que le format binaire était le meilleur choix (franchement, je n’ai pas d’opinion tranchée sur la question) : je dis juste que compte tenu des ambitions de systemd-journald (qui veut un journal plus riche), ça se défend.
Si. Ce passage s’adressait plus à Zenitram, à qui tu répondais.
[^] # Re: GNU/SystemD/Linux
Posté par xcomcmdr . Évalué à 3. Dernière modification le 05 décembre 2013 à 21:58.
le journal binaire de systemd-journald peut comporter des données purement binaires (core dump, ATA SMART blobs, firmware dumps, SCSI sense data, …)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: GNU/SystemD/Linux
Posté par Moonz . Évalué à 0.
Et alors ? MIME, format textuel, est totalement capable d’intégrer des attachment purement binaires (images, archives compressées, exécutables compilés…).
[^] # Re: GNU/SystemD/Linux
Posté par Zenitram (site web personnel) . Évalué à 2.
C'est vrai. Mais avec un encodage (adieu la simplicité du texte) et 33% de taille en plus. Que du bohneur (tu as du disque en trop, pas forcément les autres, quoique des fois on se demande vu que les mail ont toujours ce truc de 33% en plus certes).
[^] # Re: GNU/SystemD/Linux
Posté par xcomcmdr . Évalué à 2.
A propos de l'utilisation d'un format binaire :
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: GNU/SystemD/Linux
Posté par Moonz . Évalué à 2. Dernière modification le 03 décembre 2013 à 20:15.
Non sequitur.
S/MIME, DKIM, OpenID, OAuth : tous des protocoles purement textuels qui utilisent pourtant de la signature cryptographique.
[^] # Re: GNU/SystemD/Linux
Posté par xcomcmdr . Évalué à 2.
L'utilisation d'un format binaire permet aussi de standardiser les logs (par exemple au niveau des dates). Fini les regex qui changent en même temps que les programmes tiers changent leurs messages de logs.
L'anglais (ou n'importe quelle langue humaine, d'ailleurs), c'est de la merde à parser.
Je suis sûr qu'on peut trouver d'autres avantages à un format binaire dans le lien que j'ai donné, mais ce lien ne parle pas spécifiquement de ça, et démêler tout ça serait plus d'efforts que j'en ai envie pour un n-ième troll au sujet de "binaire vs textuel".
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: GNU/SystemD/Linux
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 03 décembre 2013 à 19:17.
Surtout quand tu te tapes un serveur dans une langue que tu ne connais pas parce que l'admin local a oublié que sa locale pour le confort a de l'impact sur le fichier de log, et où changer la locale pour ta session ne change pas la locale du fichier texte (du moins, c'est pas implémenté dans les serveurs que j'ai vu… Peut-être que Moonz a des logiciels que je n'ai pas) alors que les logs binaires l'affichage utilise la locale de ta session.
Alors certes les boites internationales (le monde bouge, change, évolue, plus besoin d'avoir 100 000 personnes pour être une boite internationale) imposent souvent "en-US.utf8" comme locale pour ne pas avoir de surprise, quel plaisir de se limiter techniquement…
[^] # Re: GNU/SystemD/Linux
Posté par Moonz . Évalué à 4.
Parce que les formats textes ne peuvent pas être standardisés ? HTTP, XML/HTML, vCard, SMTP, MIME, ce n’est pas standardisé ? JSON c’est de la merde à parser ?
[^] # Re: GNU/SystemD/Linux
Posté par Astaoth . Évalué à 2.
Ce n'est pas nécessaire. On peut standardiser les logs dans un format texte, on y arrive bien pour d'autres choses (au hasard je html ; ca reste du texte, et la syntaxe est plutôt précise).
Question de format, et de techno employé. Si le texte est bien formaté, selon des règles lexicales et syntaxiques constantes et précises, et que tu utilises un outil adéquat, il n'y a pas énormément de difficulté à parser du texte.
Je sais que ca fait beaucoup de condition, sauf que pour celles qui concernent la génération de texte, journald le fait déjà au format binaire, et pourrait très bien le faire de façon aussi générique en texte.
Et bon, honnêtement, si je n'ai pas d'OS avec journalctl sous le coude, je trouve que le texte est quand même énormément plus facile à traiter que du binaire.
Emacs le fait depuis 30 ans.
[^] # Re: GNU/SystemD/Linux
Posté par Zenitram (site web personnel) . Évalué à -2. Dernière modification le 03 décembre 2013 à 21:29.
Je rigole toujours, super!
Avec des si, on met Paris en bouteille.
Sauf si tu n'as pas de traducteur ASCII --> affichage pour humain (tu parles bein d'absence de l'outil, j'utilise le même argument que toi qui aurait empéché l'avenement d'ASCII par exemple… Terrible comme argument)
Et quitte à se répéter, rien n'empèche de mettre une copie texte juste à côté (parait que ça bouffe rien!).
Et rien n'empèche de faire un lecteur de journaux journald comme on a des lecteurs de fichier ASCII spéciale Linux sous Windows (parce que tu as déjà ouvert un fichier log Unix sous Windows Notepad? Tout sur une ligne. Oui, voila, c'est ton super format texte, tout sur une ligne, très pratique… ou alors il faut avoir un outil "Unix" qui n'existait pas avant! Mais la on retombe sur ton argument "ça n'existe pas")
[^] # Re: GNU/SystemD/Linux
Posté par Astaoth . Évalué à 0.
Développe.
Ca c'est de l'argumentation en béton. Dans le même genre, je pourrais dit qu'avec des "si" et des "sinon" on a fait des OS.
Cite moi un OS qui n'en est pas équipé par défaut, à son installation.
Oui très, parce qu'il ne m'empêche pas de le traiter avec l'outil que je veux. Alors que ton binaire, je dois passer par un outil Linux-only.
Lex, gcc, grep, sed, find, et autre, n'existent pas que sous Unix. Bien tenté.
Par contre journalctl n'existe que sous Linux et non sous Mac OS, FreeBSD, et les non-Unix.
Emacs le fait depuis 30 ans.
[^] # Re: GNU/SystemD/Linux
Posté par xcomcmdr . Évalué à 0. Dernière modification le 03 décembre 2013 à 21:37.
Bonne chance pour standardiser les messages de logs de tous les logiciels existants.
Et puis :
Tu arrives à avoir un OS avec journald et ses logs binaires, mais sans journalctl ? Où, quand, comment, pourquoi ?
Et puis bon, c'est pas comme si journald n'était pas compatible avec syslog (il te manquera juste les méta-données, les blobs binaires au sein du journal ("ATA SMART health data, SCSI sense data, coredumps or firmware dumps"), l'access control & chiffrement du journal - comment savoir si le journal a été modifié ou non sans ça ? -, et la structuration du journal).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: GNU/SystemD/Linux
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 03 décembre 2013 à 21:45.
La, tu merdes, l'argument a déjà été donné et c'est le seul de pas trop mauvais pour 1 minute de réflexion avant de savoir comment s'en sortir : mode rescue d'un serveur à distance (la distro n'est pas toujours la même, pas toujours à jour).
Argument qui vaut pour toute évolution, et se casse en une option (tu gardes le format binaire pour tes gros log, et si ton rescue ne connait pas systemd, tu perd du CPU et un peu de charge disque à faire une copie en mode "à l'ancienne" que tu effaces 48 heures après et basta, c'est un faux problème mais il ne fut pas leur donner le plaisir de dire que ça n'arrive pas d'avoir une machine sans journald mais un log journald, en attendant que leur rescue soit à jour)
Mais sinon, oui, le reste est difficile à faire passer… On ne leur enlève rien (faut juste activer une option), on ne fait que rajouter, mais ils se plaignent.
[^] # Re: GNU/SystemD/Linux
Posté par Astaoth . Évalué à 2.
La sortie de journald n'a pas de format standard ?
Depuis que je ne lis pas forcément mes logs que sous Linux, surtout quand le sus-cité Linux ne boot plus.
Emacs le fait depuis 30 ans.
[^] # Re: GNU/SystemD/Linux
Posté par Moonz . Évalué à 3.
Tout ce qui est formaté automatiquement par journald dans un format binaire peut être formaté dans un format texte "standardisé". Je ne comprend pas l’argument.
La structuration se fait très bien en texte, cf JSON.
Les blobs peuvent être mis dans un fichier à part s’ils sont gros (coredump par exemple) ou peuvent être sérialisés en base64.
L’indexation peut (et c’est même une très bonne idée, c’est ce que font la plupart des base de données à ma connaissance) se faire dans un fichier à part des données.
Pour l’access control, encore une fois je ne vois pas le rapport avec le débat texte/binaire
Système non bootable, je veux voir les logs, j’ai un dual-boot MacOS X ou Windows (desktop). Même situation, j’ai une option netboot sur FreeBSD (serveur). Comment je lis les logs binaires pour savoir pourquoi ça boot pas ?
C’est en pratique ce que je fais, mais s’il faut avoir les logs en double pour avoir la fonctionnalité « être lisible en toute circonstance », je trouve que c’est loin d’être optimal… (et ça pénalise à peu près tous les autres critères discutés : vitesse (écrire deux fois sur le disque dans des fichiers séparés, pas glop), fiabilité dans une situation d’espace disque plein (le problème est doublé), taille prise sur le disque).
[^] # Re: GNU/SystemD/Linux
Posté par Anonyme . Évalué à 3.
Ca tombe bien, journalctl permet justement d'exporter les logs en json.
[^] # Re: GNU/SystemD/Linux
Posté par Moonz . Évalué à 0.
La situation dans laquelle tu veux directement les logs dans un format textuel c’est justement quand journalctl est indisponible.
[^] # Re: GNU/SystemD/Linux
Posté par Zenitram (site web personnel) . Évalué à 4.
Libre à toi d'exporter tout le temps en JSON pourton cas (gestion du passé ou de l'incompatibilité, tranquille systemd te permet tout).
C'est quoi le problème? Que tu te rendes compte que ton argument tient pas et tu cherches à te racrocher aux branches?
[^] # Re: GNU/SystemD/Linux
Posté par Anonyme . Évalué à -1.
Et dans quel cas as tu besoin de consulter ces logs alors que journalctl est indisponible ?
La machine sur laquelle sont tes logs dispose forcement de journalctl. Si le problème est que la machine ne boot pas, ben tu prends un livecd ou une clef USB de la distro utilisée, qui doit normalement inclure journalctl.
[^] # Re: GNU/SystemD/Linux
Posté par Moonz . Évalué à -2.
Lire toute la conversation, ça aide.
http://linuxfr.org/users/atem18/journaux/systemd-va-gagner-une-console-systeme-un-bootsplash-et-un-login-screen#comment-1504670
[^] # Re: GNU/SystemD/Linux
Posté par Anonyme . Évalué à 5.
Et le jour ou OVH oublie de mettre gzip sur leur mode rescue tu vas aller dire qu'il ne faut jamais compresser les logs ?
Si OVH fournit des distributions utilisant systemd-journal sans les outils pour le lire dans le mode rescue, c'est un probleme du mode rescue OVH. C'est rien d'insurmontable à corriger, faut juste leur signaler.
systemd-journal étant assez recent, c'est pas très étonnant qu'il puisse y avoir ce genre de problème, mais y a pas de raison que ca reste comme ca. Et si ca te gene vraiment, ben tu actives l'export vers syslog (ou tu ne le désactive pas, puisqu'il est encore souvent activé par default).
[^] # Re: GNU/SystemD/Linux
Posté par Astaoth . Évalué à 2.
Et pour remplir tout ces points, est-il nécessaire d'avoir un binaire en lieu et place d'un texte standard qui serait encore plus portable, encore plus facilement manipulable par des outils éprouvés et reconnus pour leurs grandes vitesse de fonctionnement (en O(n), et code machine optimisé pendant bientôt 40 ans) ?
Malgré la doc, je ne comprends toujours pas l'intérêt d'avoir un binaire en lieu et place d'un texte, à part pour le stockage, mais je crois que plus grand monde a des systèmes équipés de mémoires de stockages pour lesquelles 160Ko n'est pas négligeable (taille de mon dossier de log). Quelqu'un pour éclairer ma lanterne ?
Emacs le fait depuis 30 ans.
[^] # Re: GNU/SystemD/Linux
Posté par Zenitram (site web personnel) . Évalué à 3.
Faut croire qu'en 40 ans, pas foule a réussi à standardiser du texte (déjà que personne n'arrive à se mettre d'accord sur comment on écrit un retour à la ligne entre OS…)
Je retourne la question dans l'autre sens : quel interêt d'un stockage en texte "standard" (à définir)?
Donc au final, j'en conclue que ça ne te dérange pas de sélectionner l'option permettant de sortir en texte, ça bouffe rien. Finalement, en quoi le fait qu'il y a un stockage binaire (encore plus petit) à côté de ta sortie préférée te dérange?
Un truc que je ne capte pas : vous avez votre sortie texte, tous vos avantages d'une sortie texte sont la, donc quelle est la réélle critique?
Sinon, pour information, tu es sensé stocker tes logs pendant 1 an, et un jour ça passera à 2 ans. tout le monde n'a pas que 2 visiteurs par jour sur son site web et a des loggs à gérer.
Je jette un oeil vite fait sur mon petit site web, access_log d'httpd fait 100 Mo (non compressé ok, ça donne 3 Mo compressé, mais peut-on considérer du compressé comme du texte? Non, un octet quii saute et hop tout est perdu, pile une critique de journald, donc parlons de 100 Mo). Merci le texte (déjà un rapport de 1/30 juste en compressant de manière générique sans optimisation "pour logs"), sur 1 an ça donne 30 Go, et tout ça pour un petit site… Je n'ose pas imagine un site moyen ni gros.
Je tape un peu à côté, mais c'est juste pour dire que la où toi tu n'as pas de problème de place, d'autres en ont. J'ai vu plusieurs projets (dont un dont j'étais chef de projet, c'est moi qui ai pris la gueulate d'avoir fait planter un serveur à cause de lenteur non gérées quand le log a fait x100 d'un coup) se dire "pas grave, on a du CPU, du disque et du réseau" et ensuite exploser en vol à cause des perfs dès que ça montait en charge car succès, et le boss il a pas aprécié que ça se plante le jour où ça a du succès (ou simplement un gros problème qui fait faire de gros logs) avec les clients…
Bref, désolé, mais la taille, la perf, c'est critique pour certains, et le but d'un projet tel que celui dont en parle n'est pas de simples serveurs.
[^] # Re: GNU/SystemD/Linux
Posté par Astaoth . Évalué à 4.
Faut croire que si, (x)HTML est stocké en texte et non en binaire, pourtant son format est plutôt standard.
La lisibilité par un humain, la possibilité le le lire et le traiter avec autre chose que journalctl.
Selon entre autre toi, parce que ca bouffe de la place. Autrement, parce que ca fait des fichiers inutiles, et si tu veux de l'argument technique, certains FS, toujours utilisés, sont limités à ce niveau là.
Si tu as un cas d'utilisation d'un sysème qui n'a pas 160Ko pour les logs, n'hésite surtout pas à le donner, comme demandé plus haut.
Logs que tu n'utilises pas tout les jours et que tu archives. Tu peux donc les compresser en xz.
Contexte différent. Ce sont des logs archivés que tu ne gardes que pour respecter la loi, et non pour les utiliser toi même, pour maintenir ton système, avec des yeux ou avec des outils tels que Fail2Ban ou Ossec.
D'ailleurs à ce propos, Fail2Ban et Ossec gèrent comment ces logs binaires ? Tes 3 Mo, c'est en tar.xz ? Et ils donnent quoi en binaire ?
La façon dont systemd est poussé dans la majorité des distributions, et donc de l'imposer. Parce que oui, quand une distribution abandonne le support d'un logiciel au détriment d'un autre, et qu'elle retire l'ancien logiciel du système de l'utilisateur via une mise à jour, elle force ce dernier à changer de logiciel.
Merci pour ton retour d'utilisation, et les chiffres "à la louche" pour le stockage, ca donne une meilleure vu d'ensemble.
Emacs le fait depuis 30 ans.
[^] # Re: GNU/SystemD/Linux
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 03 décembre 2013 à 22:06.
Donc c'est du binaire (avec toutes les attaques sur les binaire : faut le logiciel, si un octet saute tout saute… Ca a été donné ici, tu n'as pas réagi, rien ne te choque dans le bianire en fait).
Merci, tu viens d'argumenter pour avoir du binaire, tu n'aimes pas le texte.
(non, parce que bon sur le rescue, xz est pas supporté… C'était vrai à une époque)
Foutaises : tu es libre de prnedre une autre distro, de forker… Merci de ne pas sortir les argument d'hier, les réponses sont les mêmes : ce dotn vous vous plaingez, c'est que vous n'avez pas d'esclaves.
Monde pourri quand on n'a pas d'esclaves…
OK, c'est bon, belle démonstration d'incohérence complète sur le binaire + le problème est que les autres ne sont pas vos esclaves, ça n'a rien à voir avec systemd.
tu veux dire que tu as aucune idée de ce qu'est du volume de log mais dit que c'est "pas gros"? hum… Et dire que j'ai pris juste un petit site qu'est le mien, j'ai pas osé voir les logs de grosses machines auquelles se destine systemd…
[^] # Re: GNU/SystemD/Linux
Posté par Astaoth . Évalué à 1.
La lecture et l'étude de texte se fait dès la 6ème. Je te mets la suite que tu as visiblement oublié de lire.
"Contexte différent. Ce sont des logs archivés que tu ne gardes que pour respecter la loi, et non pour les utiliser toi même, pour maintenir ton système, avec des yeux ou avec des outils tels que Fail2Ban ou Ossec.
D'ailleurs à ce propos, Fail2Ban et Ossec gèrent comment ces logs binaires ? Tes 3 Mo, c'est en tar.xz ? Et ils donnent quoi en binaire ?"
Merci de répondre aux questions au passage, c'en sont de vraies, par pour faire joli.
Oui, donc je suis contrains de ne plus utiliser l'ancienne. Merci d'abonder dans mon sens, mais lis en entier un texte avant de passer à la suite.
Non. Ce dont je me plains, dans ce cas là, est la suppression pure et simple d'un logiciel des dépôts d'une distribution, alors qu'il y a eu une demande à ce qu'il y reste.
Non. Comme dit plus haut, la compréhension de texte s'étudie en 6ème. Je t'invite à tout relire en entier avant de parvenir à une conclusion aussi erronée. Je n'y peux rien si tu ne peux pas essayer de comprendre le point de vu de quelqu'un d'autre.
Non, tu tires là, encore une fois devrais-je dire, une conclusion erronée. J'en ai une idée de ce que j'ai eu l'occasion d'en voir, avec mon serveur. D'ailleurs je trouve intéressant que tes logs prennent autant de place, et j'aimerais bien volontiers avoir le détail des services qui logs quelques choses qui tournent sur ton serveur.
Emacs le fait depuis 30 ans.
[^] # Re: GNU/SystemD/Linux
Posté par Astaoth . Évalué à -1.
Hum je vais illustrer un peu ton propos pour te montrer l'idiotie de ce genre de raisonnement.
J'échange ta femme avec la mienne. Si tu n'es pas content, tu es libre de changer de maison, ou de forker la tienne pour essayer d'y remettre ta femme.
Dois-je continuer l'analogie en parlant des esclaves ?
Emacs le fait depuis 30 ans.
[^] # Re: GNU/SystemD/Linux
Posté par Maclag . Évalué à 8.
L'analogie est pertinente.
Dans la vraie vie, c'est ta femme qui décide de se barrer chez le voisin, et chance: celle du voisin te trouve à son goût.
Les développeurs, en particulier les bénévoles, ont encore le droit de choisir ce sur quoi ils travaillent. S'ils sont payés, c'est peut-être la boite qui décide.
Les intégrateurs, en particulier les bénévoles, ont le droit de prendre des décisions sur l'intégration, vu que c'est eux qui vont faire le boulot. S'ils sont payés, c'est peut-être la boite qui décide.
Les utilisateurs ont le droit d'utiliser, de faire part de leur opinion, mais à la fin, celui qui tranche, c'est celui qui code, qu'il soit bénévole ou qu'il soit payé.
Si l'utilisateur est payé, ça ne change absolument rien.
Réclamer sans cesse le maintien d'une solution que les développeurs et intégrateurs ne veulent plus maintenir, c'est censé donner quel résultat? Qu'ils le fassent à contre-cœur pour te faire plaisir à toi et aux autres anti-systemd?
C'est des branleurs au marketing chez RedHat, il y a un marché gigantesque pour une distro exempte de systemd qui sera aussi rentable que celle avec systemd et ils ne l'ont pas vu?
Ils ne savent pas encore que le support technique va s'écrouler suite à la migration vers systemd?
[^] # Re: GNU/SystemD/Linux
Posté par Astaoth . Évalué à -1.
On m'a vendu Linux comme un système communautaire, où les utilisateurs peuvent donner leurs avis, et où les devs, en fonction des retours, prennent leurs décisions. J'ai donc encore le droit de donner mon avis je crois.
Pour information, pour Archlinux, le nombre de personne réclamant la cohabitation systemd sysVinit n'était pas de l'ordre de la dizaine, mais bien supérieur.
Alors certes les bénévoles ne veulent plus maintenir sysVinit, mais est-ce une raison suffisante pour forcer son remplacement via une mise à jour ? Et pour le sortir des dépôts comme un mal propre, alors qu'il fonctionne ?
Ce dernier point soulève également un débat un peu plus général que l'univers de systemd : est-ce que, parce qu'un logiciel n'a plus de mise à jour, il doit être considéré comme non maintenu, et est-ce parce qu'un logiciel est non maintenu qu'il doit forcément être éjecté des dépôts (je ne dis pas non plus de le garder dans le dépôt core) ?
Systemd ne vient pas de chez eux ? On m'aurait menti ? Parce qu'autrement, ca serait comme dire que comme Microsoft vend et fourni un support de ISS, il est forcément meilleur techniquement et beaucoup plus fiable que Apache.
Emacs le fait depuis 30 ans.
[^] # Re: GNU/SystemD/Linux
Posté par groumly . Évalué à 3.
Decider de ne plus maintenir sysv me parait une raison suffisante pour ne plus maintenir sysv init. Parce que oui, maintenir un paquet dans les depots, ca revient a le maintenir, donc s'ils ont decide de ne plus le maintenir.
Si ca te derange qu'arch l'ait vire un beau matin (si c'est bien ce dont tu parles), fallait pas choisir une distro rolling ou aucune garantie n'est faite sur la stabilite des paquets ;-)
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: GNU/SystemD/Linux
Posté par Zenitram (site web personnel) . Évalué à 2.
Oui…
Oui…
Oui.
Mais ici, ce n'est pas ce qui est demandé. Ici, la phrase change : et où les devs doivent obéir.
Et la, c'est non.
Rien de nouveau, syystemd n'est qu'un parmi d'autres avec le même type de personnes qui ne comprennent pas la différence entre choix communautaire et "mon choix".
Ici, la communauté décide de prendre systemd, le fait que le choix ne soit pas le tien personnel ne change pas que c'est communautaire.
dure la vie communautaire où le choix communautaire n'est pas toujours ton choix personnel…
Bizarrement, ta phrase n'a absolument rien à voir avec ce qui est demandé par les gens qui râlent (ils veulent pas que les dév fassent un choix en fonction des retour, mais de leurs retours sans prendre en compte les retours des autres).
Ou comment travestir la réalité (et ce n'est pas spécifique à systemd, pas spécifique à Linux, dans le monde politique on a exactement le même type de réaction où les gens se prennent pour les "99%" en ayant pas foule derrière eux en réalité).
[^] # Re: GNU/SystemD/Linux
Posté par Astaoth . Évalué à -3.
Ce n'est pas uniquement mon choix personnel justement. Cesse de prétendre que je suis le seul et unique à ne pas vouloir de systemd, c'est une conclusion fausse.
Non. Ils veulent un choix qui satisfassent, ** entre autre ** leurs retours, tel qu'une cohabitation. Je doute fortement que les pro sysVinit refusent que les retours des pro systemd soit pris en compte.
Oui en effet. Dire que tout le monde veut une chose quand justement une minorité non négligeable n'en veut pas, c'est travestir la réalité.
Emacs le fait depuis 30 ans.
[^] # Re: GNU/SystemD/Linux
Posté par claudex . Évalué à 5.
Ça vient d'un employé qui l'a commencé sans que ce soit un projet de Red Hat, et il y a des développeurs hors Red Hat qui bossent dessus. Du coup, vu le nombre d'employés qui bossent sur Linux (et les positions qu'ils ont), c'est aussi un projet Red Hat ?
« 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: GNU/SystemD/Linux
Posté par Astaoth . Évalué à -2.
Il l'a fait sur son temps libre ou durant ses heures de travail ?
Emacs le fait depuis 30 ans.
[^] # Re: GNU/SystemD/Linux
Posté par Spyhawk . Évalué à 9. Dernière modification le 04 décembre 2013 à 14:10.
Blah blah blah. Le nombre de personnes réclamant la cohabitation était tellement grand qu'aucune de celles-ci n'a mis la main à la pâte pour maintenir sysinit (et tous les scripts qui vont avec) dans l'AUR. Bah, oui, parce que le paquet a été déplacé des dépôts binaires officiels vers le dépôt utilisateurs AUR. Parce qu'il n'y avait plus de support de la part des développeurs officiels, et que les utilisateurs intéressés étaient invités à le maintenir eux-même (et je vois mal comment on peut reprocher ceci).
Alors les anti-systemd, faudra sortir du pathétisme de haut niveau et apprendre que râler != bosser, et que seule cette dernière action donne du résultat. Etre son propre esclave et faire le boulot soi-même, c'est tout de suite moins drôle, pas vrai?
[^] # Re: GNU/SystemD/Linux
Posté par Astaoth . Évalué à -2.
Si tu ne veux pas lire, ne lis pas, je ne te force pas.
La façon dont sysVinit a été remplacé directement dans le systeme des utilisateurs est assez intéressante, parce que justement, Sabayon a également opté pour systemed, mais n'a pas forcé la désinstallation de l'ancien init. Au final je peux continuer à faire mes mises à jours sans avoir systemd en guise d'init.
Surtout quand on est uniquement utilisateur d'un OS. Donc pour résumer ton point de vu, quand on veut utiliser un système, on ne peut pas être seulement utilisateur mais aussi être mainteneur ?
Au fait, le ndd de ta page perso semble avoir expiré.
Emacs le fait depuis 30 ans.
[^] # Re: GNU/SystemD/Linux
Posté par Spyhawk . Évalué à 3. Dernière modification le 05 décembre 2013 à 18:08.
Tu veux dire que tu peux dire des bêtises sur un site public sans que quiconque n'ai un droit de réponse?
La cas Sabayon est peut être intéressant, mais si tu es en désaccord avec la façon de faire d'Arch (garantir la qualité des paquets officiels notamment) c'est que tu as trés mal choisi ta distribution. Arch, c'est pas seulement la distribution "hype" du moment, c'est avant tout une ligne directrice claire avec des utilisateurs cibles bien définis (relis "The Arch Way").
Non, quand tu es simple utilisateur tu utilises simplement ce qui est fourni par la distribution. Si tu veux t'amuser à sortir des sentiers battu, tu assumes, et encore plus quand tu es sous Arch.
Arf, dommage. Pas ma page perso, mais un site en contraste avec linuxfr bien rigolo.
[^] # Re: GNU/SystemD/Linux
Posté par Maclag . Évalué à 6.
Zenitram a répondu au reste et je suis d'accord avec lui.
Juste ça:
MS est une boite qui fait du proprio et vend exclusivement des solutions internes (ou rachète des boites, ce qui fait que la solution devient interne).
RedHat édite une distribution Linux, ça veut dire que même s'ils ont de (nombreux) développements internes, ils font surtout de l'intégration de multiples composants.
J'aurais du mal à croire que le choix de ces composants se fait sans aucune idée de l'impact pour leurs clients, ou alors on doit attribuer leur succès jusqu'ici à la chance, ça me parait un peu gros.
Donc l'idée que c'est un projet RedHat porté par un dev RedHat et donc forcément RedHat va le passer en force partout même si tout le monde sait que c'est pas bon, j'ai un peu de mal à le mettre en corrélation avec le succès commercial de RedHat.
[^] # Re: GNU/SystemD/Linux
Posté par oinkoink_daotter . Évalué à 3.
Fail2ban a maintenant une interface journald. je n'ai pas regardé pour Ossec.
https://aur.archlinux.org/packages/fail2ban-systemd-journal-git/?setlang=fr
https://github.com/fail2ban/fail2ban/pull/82
[^] # Re: GNU/SystemD/Linux
Posté par claudex . Évalué à 8.
Je ne sais pas comment tu fais mais le dossier log de mon serveur fait 350Mo (et encore, il y a des trucs compressés) et je dois avoir un visiteur par jour sur mes sites.
« 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: GNU/SystemD/Linux
Posté par Misc (site web personnel) . Évalué à 10.
bah, systemd est lui même censé remplacé sysvinit, et contrairement à systemd, sysvinit a été remplacé par : openrc, upstart, launchd, smf, parmi tant d'autres.
Au contraire, j'attends de voir qui remplace udev ou dbus.
Par exemple, qui utilise eudev, en dehors de gentoo ?
Et en fait, au vue de l'activité des derniers mois, ou on voitsoit des commits qui sont globalement une synchro du travail de l'original, ou rien à part de la doc, ou sont tout les gens qui veulent remplacer udev ?
Ou sont tout les gens qui poussent à faire des distros basé sur mdev ? Ou sont les gens qui ont cherché à garder devfsd en vie ? Tout ces howtos pour avoir une distro avec un /dev statique et tout les avantages si innombrale qu'on comprends pas comment on peut s'en passer ?
[^] # Re: GNU/SystemD/Linux
Posté par Astaoth . Évalué à 5.
Et c'est une spécificité des OS Unix, qui permet à l'utilisateur d'adapter son système en fonction de ses besoins, et de ses préférences.
C'est ce qui permet d'avoir de la diversité dans un éco-système, pour pouvoir avoir un OS personnalisable selon ses préférences.
Tout ces shells ont un dénominateur commun : "sh". Je ne dis pas qu'un script écrit avec les spécificités de bash va marcher avec csh, mais qu'on peut faire des scripts génériques pour toutes les distributions.
Un service sysVinit est déjà compatible avec OpenRC, l'init de Slackware, l'init BSD, et sûrement d'autres. Le système d'init était déjà cohérent entre les distributions. De même que la gestion des logs d'ailleurs (je dis bien entre les distributions).
Tu penses honnêtement que quelqu'un qui a un besoin auquel ne répond pas systemd va avoir le temps de se pencher sur son code pour l'adapter, au risque de casser d'autres choses dedans ? Tu ne penses pas qu'il est plus simple de remplacer un logiciel qui ne répond pas à un besoin par un autre, déjà existant, qui y répond ?
Emacs le fait depuis 30 ans.
[^] # Re: GNU/SystemD/Linux
Posté par feth . Évalué à 10.
J'espère que debian passera à systemd, et sinon, j'utiliserai probablement autre chose que debian, et j'en serai triste.
Je comprends que Canonical préfèrerait que debian ne passe pas à systemd, voire, pourquoi pas, utilise Mir : l'isolationisme forcené ça coûte cher, et ils voudraient bien partager les coûts.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 7.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: GNU/SystemD/Linux
Posté par cosmocat . Évalué à 5.
Tiens, en parlant de choix, il y a une date butoir à laquelle Debian a prévu de faire son choix?
Ou là encore, ils ont le choix…
[^] # Re: GNU/SystemD/Linux
Posté par Misc (site web personnel) . Évalué à 6.
C'est une bonne question, du coup, j'ai relu :
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708
Grosso modo, je pense que la discussion et les arguments ont été exposés en détails et les gens considèrent la position comme étant final ( ie, les pages sont complètes ).
Celle de systemd est déclaré final :
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#538
Celle de upstart :
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#548
Celle du support multiple :
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#553
et celle de openrc :
bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#558
Donc depuis fin novembre, je pense que c'est bon, et la phase suivante peut commencer ( malgré la tentative de Ian jackson de relancer le débat en parlant de sécurité ).
[^] # Re: GNU/SystemD/Linux
Posté par feth . Évalué à 9.
J'utilise systemd sous debian, mais pas complètement -init est encore marqué « essentiel » ; Debian, pour l'instant, est dans une phase de transition et de décision.
En tant qu'utilisateur, j'utilise très souvent le boot et la mise en veille.
En tant que développeur/admin, la gestion des dépendances et des services qui tournent ou pas est une de mes problématiques, et systemd a une bonne manière d'y répondre.
Perso je vois systemd comme une extension de Linux en userspace, et à la limite je me demande s'il n'aurait pas été plus facile de faire passer cette pilule dans /usr/src/linux/userspace/systemd.
Il semble que l'intégration avec systemd soit d'une complexité moindre qu'avec sysvinit qui oblige à fournir des scripts compliqués pour chaque démon (avec des
while true, dessleep()etc), et je serais en faveur d'ériger une statue à sysvinit pour tous les services qu'il a rendus jusqu'à maintenant.Lennart a fâché les gens en disant que Debian/Freebsd était un OS jouet, ce n'était pas constructif ; n'empêche, je crains que plus Debian gèrera de noyaux différents de la même façon, plus le dénominateur commun sera petit, et moins on pourra avancer dans chacune de ces directions. MS pourrait opensourcer Windows RT, maintenant qu'ils l'ont abandonné, histoire de vraiment scléroser Debian. Et si la direction ne me convient pas, peut-être me prendrai-je une licence Redhat :-)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3. Dernière modification le 01 décembre 2013 à 14:55.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: GNU/SystemD/Linux
Posté par cosmocat . Évalué à 4.
[^] # Re: GNU/SystemD/Linux
Posté par Misc (site web personnel) . Évalué à 1.
Mhhh intéressant :
suivi de
Pour les gens qui n'ont pas lu le lien, je le colle :
"Essential is defined as the minimal set of functionality that must be available and usable on the system at all times, even when packages are in the "Unpacked" state. "
IE, essential est utilisé pour les trucs qu'on ne peut pas retirer, et qu'on estime donc faire parti de la base sur laquelle on peut s'appuyer. Donc ça impose le support des scripts d'init aux DDs. Le choix oui, mais pas pour les DDs, sauf si par choix on veut dire "faire tout ce que les utilisateurs veulent".
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: GNU/SystemD/Linux
Posté par claudex . Évalué à 7.
systemd est compatible avec les script init existant, ce n'est donc pas un 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
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: GNU/SystemD/Linux
Posté par Zenitram (site web personnel) . Évalué à -1.
Mais PERSONNE, vraiment PERSONNE, ne t'oblige d'apprendre ce nouveau système.
Tu affirmes donc haut et fort que tu fais la maintenance (puisque le fait que les autres ne veulent plus la faire ne te concerne pas), donc rien ne change pour toi quand les autres changent.
Il est imposé à PERSONNE.
Que des personnes ne souhaite plus faire les trucs chiants et te les laisse != Imposer (ce ne sont pas tes esclaves, ils sont libres de ne plus faire ce qui te plaisait).
L'idée est de virer cet existant trop chiant à gérer et qui ne répond plus au besoin des gens qui développent.
Non, ce n'est pas raisonnable.
On peut aussi dire que le caractère essential de systemd est raisonnable vu que ça simplifie une tonen de trucs pour les mainteneurs, et que rien n'empèche personne d'installer sysinit s'il le veut (et que des gens se font chier à le maintenir).
Ce qui me va en pleine figure quand je lis ce genre de prose, c'est que les utilisateurs d'un truc gratuit (le libre n'est pas le sujet la) considèrent que les mainteneurs sont leur esclaves, et qu'ils devraient continuer à faire un truc juste parce que cest utilisateurs ne veulent pas apprendre un tout petit truc de différent… Parce que la, personne n'empèche personne, on dit juste "plus avec nous car on a un truc mieux pour nous, vous êtes libre de maintenir si vous avez envie" et les gens considèrent bizarrement qu'on leur impose un truc. Faudra un jour m'expliquer ce qui est imposé.
[^] # Re: GNU/SystemD/Linux
Posté par fravashyo . Évalué à 10.
je ne vois pas pourquoi tu entres dans le débat vu que tu n'utilises pas de bureau linux, comme tu aimes à le rappeler.
Là ta position, c'est juste de l'entrisme vis à vis de tes idées génériques (en gros tu te fais chier à faire plusieurs paquets de ton logiciel sous les diverses distributions linux, de cela tu considères que le boulot de maintenance est ingrat et tu prends partie pour systemd alors que je suis sûr que tu ne l'utilises pas et tu n'as pas à en subir les effets).
Il y a plein de gens qui sont contre systemd et les autres délires de Lennart Poettering, et beaucoup d'entre eux sont des admin système ou des développeurs.
http://www.linuxadvocates.com/2013/05/systemd-accident-waiting-to-happen.html
http://lists.debian.org/debian-devel/2012/11/msg00617.html
http://monolight.cc/2011/05/the-systemd-fallacy/
http://seife.kernalert.de/blog/2013/05/31/the-systemd-journal-is-a-broken-piece-of-crap/
http://phoronix.com/forums/showthread.php?73574-OpenSUSE-Not-Everyone-Likes-SystemD&s=a54953c55c66e646efc1093deabc1b55
Ça ne sert à rien de ressortir le vieil argument « c'est libre, tu peux forker ». Je pense qu'on a encore heureusement le droit de dire que c'est de la merde et qu'on ne voit pas d'un bon oeil le fait de voir de moins en moins d'alternative à cette merde.
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: GNU/SystemD/Linux
Posté par Zenitram (site web personnel) . Évalué à -1.
Oh c'est vrai, excuse-moi, il faut "en être" à 100% (rien d'autre sur aucune machine) pour avoir le droit de parale.
Conneries.
Sans compter que tu sais effectivement ce qu'est mon OS principal, mais n'a aucune idée de ce que j'utilise au quotidien (bien que je le dise assez souvent en fait). Principal != tous.
Et ça serait mal?
En quel honneur n'aurais-je pas le droit d'estimer que les mainteneurs ont autre chose à foutre que de gérer un vieux truc otut pourri qui bouffe des ressources alors qu'ils ont autre chose à faire à coté? Désolé, mais indirectement ça m'impacte, que ça te plaise ou pas.
combien d'entre eux sont des developpeur de systèmes d'init? combie nd'entre eux se tapent la maintenance? le reste, on s'en fout.
Qu'on ne me sorte pas alors qu'on force quiconque. Ca sert à rien aussi. Ma réponse est uniquement uen réaction à un pseudo-argument "contre" qui ne sert à rien, pour reprendre ta description.
Tu as le droit, tu remarqueras que j'ai interdit à personne quoi que ce soit. J'ai heuresement tout autant le droit de réagir en disant que tu (et aures) racontes n'importe quoi avec des arguments qui tiennent pas 10 secondes de lecture (Il y a eu suffisament de monde pour démonter les pseudo-arguments des gens qui accusent systemd de tout alors que c'est faux, et qui utilisent encore les arguments malgré le fait qu'on leur a démontré, et "on" n'étant pas moi, que c'est faux, ce qui démontre que l'argument n'est pas pour être objectif mais juste une excuse).
Bref, pour paraphraser, on a encore heureusement le droit d'avoir un avis et réagir sans devoir remplir une liste de critères subjective (parce que le nombre de gens qui sont simples utilisateurs du système d'init et ne vuelent pas voir les merdes de l'autre côté, ils devraient aussi être éliminés… facile de faire des filtres subjectifs)
Au final, tu peux contre-argumenter plutôt que de tirer sur la personne gratos sans plus d'arguments que ça (j'ai mis "quasi" pour bien noter qu'il y en a… mettre des liens au pif comme ça ne change rien au débat)?
[^] # Re: GNU/SystemD/Linux
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 01 décembre 2013 à 18:35.
J'en ai lu qu'un (au pif), c'est celui-la. Je n'ose pas lire les autres tellement ce lien est démonstratif de l'énormaité :
- faudra un jour arrêter avec le fantasme du tout texte qui est trop bien trop génial et bugue jamais le binaire ça pue. Le gars a de la place (mineur mais quand même, à force de mineur ça fait beaucoup), du CPU (idem) et du temps (les fichiers texte étant super chiant à scripter vu que leur format n'est pas précis et change suivant la distro, trop fun à gérer) en trop, tant mieux pour lui, d'autres souhaitent optimiser.
- Il "oublies" étonnament qu'il peut tout mettre en texte à côté si il veut du truc "comme avant" pour se faire plaisir ou "au cas où".
- Le pauvre petit a été confronté à un bug. Ben oui, ça existe, même avec des programmes qui écrivent du texte (et qui font du coup du texte 100% illisible autant que journald). ca se corrige, et on passe à autre chose, point.
Bref, très démonstratif de l'anti qui va chercher le moindre petit détail et l'agrandir pour justifier sa haine non objective, merci.
Je recopie le dernier commentaire de la page :
"I just fixed your bug, now you need to find something else to bitch and flame about ;P"
[^] # Re: GNU/SystemD/Linux
Posté par Misc (site web personnel) . Évalué à 8.
Tu aurais aussi pu cliquer sur le premier, qui pointe sur le 3eme. ( et vers d'autres articles de qualités comme "apt vs yum, what is the best one", et sans doute d'autres )
Le 3eme date de 2011, donc ça reste un document qui parle des premières versions de systemd, et qui n'abordent pas les features rajoutés par la suite ( genre les fonctions de sécurités de coupure du réseau, systemd-nspawn, etc).
Donc les arguments techniques ( car on va éviter ceux sur "propagande de RH avec tout son argent" en pointant la doc de systemd sur freedesktop , ç'est assez peu convaincant ) sont les suivants suivi de mon rebuttal :
L'argument est assez mal construit. Soit il veut dire qu'il y a déjà des outils come monit/runit, et auquel cas, je dirais que /bin/init le fait aussi, soit il veut dire que la feature est déjà utilisé avant, et auquel cas je dirait qu'il s'agit juste de coder ce qui est utilisé.
"collecting information on daemon crashes". C'est vrai, init ne le fait pas, et dans la philosophie d'avant, c'est fait par le kernel sous la forme de la création d'un coredump quelque part sur le FS. Ce que systemd fait, c'est d'enregistrer le coredump dans journald, et de sauver divers infos. Et ça n'implique pas de ne pas faire les choses à coté si quelqu'un le veux aussi, tout comme systemd n'implique pas de retirer les appels à chroot et/ou setuid bien que le faisant également ( appels parfois mal fait par les daemons, quand le logiciel ne fait pas de chdir avant ou d'initgroups, mais bon, on le saurait si la réécriture du code sans arrêt implique de faire des erreurs de temps en temps )
keeping control with cgroups. L'argument est faible, car pour lui, on a pas besoin d'utiliser les cgroups car on peut juste utiliser les cgroups. Je suppose qu'il veut dire "y a pas besoin d'utiliser les cgroups dans le binaire d'init car on peut juste demander à tout les scripts de le faire directement". Mais la, curieusement, il ne dit pas "good luck making the author conform to a single standard", alors que visiblement, c'est ce qui arriverais.
delayed on demand. La, l'auteur dit que ça sert à rien ( car la ram sur sa workstation est suffisante et/ou la swap sert à ça ), et si jamais ça venait à servir, on peut déjà le faire via xinetd ( car soyons sérieux, inetd est un peu merdique à utiliser, et je mentirais si je faisait la comparaison en le prenant comme base ). Le fait que par exemple xinetd ne supporte pas les sockets unix, le fait que ça supporte pas les scripts d'init classiques, c'est des détails d'implémentation. Détail que personne n'a codé depuis que xinetd existe mais sans doute parce que ça sert à rien ( le fait que cups s'en serve, que X11 sur mac s'en serve et que j'ai une dizaine d'autres trucs sur mon laptop montre peut être que ça sert pas à rien ). L'auteur loupe aussi que ç'est pas juste "économiser de la ram", mais surtout assurer la parallélisation par design.
"dependency based service management". La, le mec semble vivre dans un monde à part, car "on range les choses dans un ordre arbitraire", ça n'a rien à voir avec la gestion de dépendance. Par exemple, la gestion de dépendance, ça implique que la transaction échoue si une dep échoue. Chose que sysvinit ne fait pas. Mais je peux reconnaitre que je voit fort peu d'usage en local ( à part "postfix a besoin que ldap soit up sinon il rejette les mails" et ce genre de choses ). Et bien sur, le mec n'a pas lu la doc de systemd, car l'option --ignore-dependencies existe. Donc la partie sur "l'admin doit pouvoir faire ce qu'il veut" est factuellement incorrect.
la partie sur autofs est light sur les détails. Je ne pige pas exactement ce qu'il veut dire, car je voit moi que les unités sont pour la plupart lancé après local-fs.target, donc le souci ne semble pas vraiment se poser dans mon cas d'usage. Mais bon, je ne m'y connais pas en autofs, à part que autofs sur linux fait jurer mon coloc à intervalles régulier. Je vais donc laisser le bénéfice du doute.
listening on hardware change. Que je sache, ç'est fait via udev. Et donc ça rentre dans "c'est déjà fait ailleurs". Donc c'est un peu creux comme argument, surtout parce qu'il est pas détaillé des masses. Au passage, upstart va bien plus loin que systemd et gère les choses de façons bien plus poussé, comme le montre un des développeurs :
http://ifdeflinux.blogspot.fr/2013/04/upstart-user-sessions-in-ubuntu-raring.html ( c'est vers la fin ).
enfin, l'argument qui tue : "dbus, c'est orienté desktop, car c'est dans le nom". Il y a aucun example de ce qu'il propose de mieux comme les sunrpc de nfs, java rmi, ou faire ça en xml-rpc par dessus le réseau, en soap ? Je suis pas sur que ça soit mieux, tout le monde rale sur soap, sunrpc est inutilisé ( et semble un peu compliqué à utiliser ). Mais encore une fois, sans argument, j'aurais tendance à dire que c'est un détail. Après tout, d'autres composants ( nm, upstart, bluez, wpa_supplicant pour ne citer qu'eux) passent aussi par dbus donc ça a une certaine logique de se baser sur ce que les autres font.
Donc au final, les arguments sont très discutables. Certains sont incorrects ( le 5 ), d'autres sont assez peu explicites ( le 6, le 8, le 1 ), d'autres sont pas très clairs car ça demande à réutiliser des choses existantes ce qui est le cas ( le 3, le 7 ). Il reste donc le 2 et le 4, à savoir la gestion des crashs, qui n'obligent à rien ( et qui reste une feature pour journald, donc hors du pid 1 ) et la partie sur le démarrage à la demande.
[^] # Re: GNU/SystemD/Linux
Posté par Maclag . Évalué à 10.
Je n'ai pas de SSD. Mais disons que la différence au temps de boot n'est pas mon principal souci (cas particulier?).
L'utilisateur ne voit pas de différence notable? Tant mieux, c'est que ce n'est pas l'apocalypse annoncée. Perso je ne vois aucune différence notable sauf quand je découvre les logs avec journalctl (note que je les ai encore dans /var/log comme avant aussi…).
Par contre, même si je me suis inquiété (et m'inquiète toujours) au sujet du fossé qu'on creuse avec les BSD, je ne peux que constater que les mainteneurs de scripts sysV semblent se réjouir en masse de l'arrivée de systemd. Tout le temps qu'ils ne passent pas sur ces fameux scripts peut être passé ailleurs, tout bénéf pour moi aussi!
Alors systemd n'est plus une alternative parmi d'autres mais la solution alpha? Et bien voilà, ce sera la nouvelle solution alpha qui remplacera l'autre.
Faut voir. La maintenance autrement plus facile par les développeurs de la distribution, ce n'est pas ton problème? Je dirais que si, un peu quand même.
Admettons-le, les scripts shell pour lancer les différents services, ce n'est pas ce qu'on a vu de plus propre dans le monde Unix: les mêmes scripts à quelques détails près sans aucune factorisation de code!
Je serai limite de mauvaise foi, mais toutes les briques communes des distros t'ont été "imposées", non? Si tu avais découvert le monde Linux en 2014 (ou disons quelques années plus tard, le temps que la transition se termine), tu aurais appris à te servir de systemd dans la foulée du bash et des commandes GNU, non?
Quand tu as débuté, tu as demandé quelles étaient les alternatives à sysV ou on te l'a imposé?
[^] # Re: GNU/SystemD/Linux
Posté par Renault (site web personnel) . Évalué à 10.
Je pense que c'est un faux problème.
SysV n'est pas commun avec *BSD, c'est un truc que GNU/Linux utilise de son côté donc finalement ça n'empire pas la situation existante de ce point de vue.
Ajoutons que le but de *BSD et de GNU/Linux est d'être compatibles mais pas identiques. Si on veut que chaque système ait son intérêt, il faut des utilitaires par endroit unique et pas seulement un noyau différent. Linux est un noyau très puissant avec de nombreuses fonctionnalités que systemd exploite mais pas SysV, il serait dommage de se priver de certaines fonctionnalités possibles au nom de la sacro-sainte compatibilité.
Je trouve très dubitatif que l'init soit commun aux *BSD et GNU/Linux car c'est un composant par essence proche du noyau, très bas niveau et assez « anecdotique », il est plus pertinent par contre que les composants de couches supérieurs soient compatibles car c'est là où réside l'utilisation de la machine et non dans les quelques secondes de démarrage.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3. Dernière modification le 01 décembre 2013 à 22:42.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: GNU/SystemD/Linux
Posté par navaati . Évalué à 3.
Combien de fois faudra le répéter ? Systemd fournit un sur-ensemble de sysvinit puisque si t'as besoin de faire des choses plus compliquées que ce que te permet le langage (pas Turing-complet, mais c'est le but !) des unit-files, tu demande à ton unit de lancer un script shell et tu y fais ce que tu veux et c'est tout pareil qu'avant.
Par contre, tous les autres qui ont des besoins simples (enfin, les units permettent déjà beaucoup de choses) ont pas besoin d'écrire un programme, toujours le même en plus, pour simplement lancer un autre programme.
[^] # Re: GNU/SystemD/Linux
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Vu la facilité à le faire, il doit être possible d'étendre systemd avec Lua :)
"La première sécurité est la liberté"
[^] # Re: GNU/SystemD/Linux
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
au moins, il y a aurais un vrai langage utilisable à la place des scripts shell :)
"La première sécurité est la liberté"
[^] # Re: GNU/SystemD/Linux
Posté par rewind (Mastodon) . Évalué à 1.
Moi j'ai toujours dit que le prochain truc que Lennart va péter, c'est les shells, c'est l'étape suivante logique. Mais comme sh, sainul, il va réinventer la roue carrée avec un nouveau truc qui servira pour systemd (et puis après, ça servira de shell dans Gnome Terminal pour pas que les users ils aient à apprendre bash, vous vous rendez compte de la taille de man bash ?). Allez, je vous donne le nom : shd :P
[^] # Re: GNU/SystemD/Linux
Posté par claudex . Évalué à 4.
J'aimerais bien un nouveau shell, un truc qui reprendrais certaines idées de powershell mais qui resterait utilisable. Malheureusement, je ne crois pas que ce soit possible sans réécrire toutes les applications et redéfinir les standards Unix. Du coup, demain, ça risque d'être un peu court.
« 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: GNU/SystemD/Linux
Posté par rewind (Mastodon) . Évalué à 5.
C'est précisément pour cette raison que je fais confiance à Lennart pour le faire !
[^] # Re: GNU/SystemD/Linux
Posté par Sylvain Blandel . Évalué à 5.
D'ailleurs, sur sa machine de travail, Lennart a réinventé la commande
ls, et il l'utilise quotidiennement.[^] # Re: GNU/SystemD/Linux
Posté par totof2000 . Évalué à 1.
Va voir les scripts rc de NetBSD et on en reparle. Sinon il y a de la factorisation de code dans les scripts des distribs Linux.
[^] # Re: GNU/SystemD/Linux
Posté par Kaane . Évalué à 1.
Le système d'init/boot, en temps que d'utilisateur et développeur, je n'ai que très rarement un contact direct avec.
Si tu as envie que ça reste comme ça, je te déconseille formellement systemd.
[^] # Re: GNU/SystemD/Linux
Posté par YBoy360 (site web personnel) . Évalué à -2.
Je passerai à debian le jour où ils utiliseront pleinement systemd.
[^] # Re: GNU/SystemD/Linux
Posté par totof2000 . Évalué à 2.
Le système d'init et de boot, en tant qu'admin de serveurs, j'y suis confronté tous les jours. Et quand ça ne démarre pas, ce n'est pas toi, le développeur, qui se débrouille pour que la machine reparte. En tant que développeur, tu n'y vois que dalle. Par contre, quand il y a quelque chose qui ne part pas, c'est mon job de chercher à comprendre pourquoi, et je préfère dans ce cas un truc un peu moins "neuneu-friendly (sur un serveur - je précise) mais qui garde une certaine souplesse et une grande simplicité de design. Le système d'init a ses défauts qu' on aurait pu tenter de corriger plutôt que de vouloir tout réécrire from scratch.
[^] # Re: GNU/SystemD/Linux
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
apt-get install systemd[^] # Re: GNU/SystemD/Linux
Posté par saltimbanque (site web personnel) . Évalué à 3.
du pdv de l'utilisateur, je n'ai pas plus de contact qu'avant. L'utilisateur n'a pas de besoin de man systemctl. Même les simples trucs ci dessous je les découvre aujourd'hui.
http://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet
après je ne développe pas de démon (vim existe déjà).
[^] # Re: GNU/SystemD/Linux
Posté par feth . Évalué à 2.
Et aussi modification de la ligne de commande de linux pour le choisir comme init.
# résistance au changement
Posté par AgentSteel (site web personnel) . Évalué à 6.
Pour ceux qui ne veulent pas de systemd, y'a toujours la Slackware et les *BSD :)
[^] # Re: résistance au changement
Posté par Anthony Jaguenaud . Évalué à 5.
Ce n’est pas de la résistance au changement, de la défiance à la rigueur.
Les « Linuxiens » sont fier de leur écosystème varié de logiciel, si l’un n’est pas adapté, ils en utilisent un autre, nous avons ainsi un paquet d’applications, de gestionnaire de fenêtre, de gestionnaire de bureau… aujourd’hui des gens bien pensants veulent m’expliquer que pour mon bien, je devrais utiliser Wayland et que comme ça, ça simplifiera tout, puisque c’est lui qui gèrera mes fenêtres et que je n’aurais plus à m’inquiéter. Pareil pour SystemD, on m’explique que ça va uniformiser et que se sera mieux.
Merci de penser pour moi, mais je sais faire ça seul. Moi je vois d’un mauvais œil cette uniformisation. Tu peux me taxer de « vieux con réfractaire au changement », ça ne changera rien au fait que je trouve ça mauvais pour l’avenir.
Linux s’est un peu comme l’Évolution, la loi du darwinisme… heureusement, se brave homme n’a jamais essayé d’obtenir une seule espèce de fleur « pour les contrôler tous… ».
Demain, on nous dira que c’est mal d’utiliser plusieurs lecteur pdf, que c’est mal d’utiliser plusieurs éditeurs de texte ?
[^] # Re: résistance au changement
Posté par Renault (site web personnel) . Évalué à 4.
Non, c'est juste que les distributions perdent beaucoup de temps et d'énergie pour rien à gérer SysV et les développeurs de Xorg veulent simplifier l'architecture d'un logiciel dont les méandres génèrent des bogues insolubles et des évolutions difficiles.
Le code de X.org et de l'init classique sont disponibles, tu es libre de poursuivre le boulot mais c'est un travail fastidieux dont plus grand monde ne cherche à produire au profit d'autres plus attractifs. des espèces apparaissent et d'autres meurent avec l'évolution, et tant que systemd et Wayland n'auront pas des concurrents potables, ils seront dominants oui.
Uniformiser a du bien aussi, il y a des tâches que les distributions font chacun dans leur coin pour rien pour un gain nul alors qu'en centralisant un peu on pourrait gagner du temps (beaucoup de distributions manquent de bras) mais aussi en possibilité et qualité. cela ne signifie pas qu'il faut totu mettre en commun mais ce qui est pertinent et les scripts init entrent dans ce cadre (le script à la Debian ou à la Fedora c'est du pareil au même, mais chacun a son bogue et personne n'a mieux ce qui double l'effort…). Systemd et Wayland sont des réponses à ces problèmes mais d'autres peuvent les supplanter si le cœur en dit à leurs détracteurs.
[^] # Re: résistance au changement
Posté par xcomcmdr . Évalué à 5.
Tu mets les briques systèmes et les applications/DE (qui vivent dans les couches supérieurs) au même niveau, alors que ça n'a rien à voir.
systemd et wayland sont des briques systèmes donc y'a intérêt à les uniformiser. Déjà pour uniformiser les API, ensuite pour éviter de se mettre pas mal de monde à dos (ceux qui écrivent des pilotes graphiques pour wayland, ceux qui écrivent des services/daemons pour systemd)
D'ailleurs :
On a plusieurs API pour le son dans le noyau ? Non, il n'y a que ALSA (et à la limite une couche de compatibilité avec OSS).
On a plusieurs kernels ? Non, il n'y a que Linux.
On a plusieurs système de TTY ? Non, il n'y a que l'implémentation fournie par le noyau.
On a plusieurs implémentations d'OpenGL, juste histoire d'avoir le choix et de multiplier les bugs ? Non, y'a pas grand chose à part mesa.
On a plusieurs implémentations d'initrd ? bah non.
On a plusieurs manières de rendre une application accessible à l'utilisateur moyen dans son DE ? Bah non y'a pas grand chose à part les fichiers .desktop
etc…
Et l'uniformité au niveau du système de base, c'est bien pour les développeurs, et par conséquent les utilisateurs. Ça leur évite de fuir Linux. On a déjà trop de systèmes d'init (openrc, upstart, systemd, sysv, tout ça pour quoi ?), trop d'APIs pour la même chose (ALSA vs OSSv3 vs OSSv4, par exemple. Heureusement il y a des wrappers comme OpenAL ou la SDL ou PulseAudio-le-wrapper-universel, mais ça rajoute forcément de la latence).
D'ailleurs la réponse est là : plein de distributions y passent à systemd ou y sont déjà passés (Archlinux, Fedora, RHEL, …), et Wayland est désigné comme étant le successeur de Xorg par beaucoup de distributions (à part Ubuntu, même si c'était le cas il y a pas si longtemps), avec une phase de transition (serveur XWayland).
systemd et wayland vont-ils faire disparaître les dizaines de lecteurs PDFs, et imposer evince par exemple ?
Non, parce que ça n'a aucun rapport avec la choucroute.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: résistance au changement
Posté par Maclag . Évalué à 6.
Sérieusement, pas quelle brique plus adaptée à certains besoins tu remplaces xorg chez toi aujourd'hui?
Est-ce que tu as testé tous les systèmes d'init de ta distro avant d'en choisir un suivant les avantages et inconvénients, ou est-ce que tu utilises celui fourni par défaut?
Je crois que changer mon lecteur PDF aura bien plus d'impact sur mon quotidien que la migration de ma distro vers systemd…
[^] # Re: résistance au changement
Posté par dinomasque . Évalué à 5.
XFree86
Accelerated-X
Vesafb
Mir
Wayland
mon cul sur la commode
…
BeOS le faisait il y a 20 ans !
[^] # Re: résistance au changement
Posté par Zenitram (site web personnel) . Évalué à 4. Dernière modification le 02 décembre 2013 à 07:11.
100% faux, à force c'est du mensonge…
Le gens expliquent que pour leur bien ils font ce qui leur convient pour avoir ce qu'il y a de meilleur de leur point de vue. Libre à toi (c'est libre) de faire ou sponsoriser une autre distro qui va se faire chier avec les vieilleries si tu penses que ta vision est meilleure.
Pourquoi on penserai à toi? Les autres ne sont pas tes esclaves.
au final, je constate juste une chose : des gens pour se plaindre, mais pas foule pour se bouger le cul. J'adore l'argument "oui mais Slack". Génial : 0.00001% de part de marché de Linux ne veut pas de systemd, quel argument percutant! Tous vos "arguments" tendent à montrer que systemd répond à un besoin, et que le problème est juste que vous ne trouvez pas d'esclaves qui font un boulot pour vous (eux n'en n'ont plus besoin, pourquoi le feraient-ils?)
Vous êtes très nombreux (ok, pour de faux, en pratique je sais qu'il y a toujours plus de monde pour se plaindre que pour dire qu'ils sont contents) à vous plaindre, je trouve étonnant qu'aucune distro majeure (non, Ubuntu ne compte pas, eux c'est juste qu'ils aiment tout refaire et se plaindre ensuite que personne ne les suit) ne se dise pas que systemd est pourri.
Et un truc que je ne comprend pas : Ubuntu est la pour vous sauvez, vous avez le choix, où est le problème?
Le problème est-il qu'une distro qui fait le choix de ne pas avoir systemd fait aussi d'autres mauvais choix techniques qui vous dérangent?
[^] # Re: résistance au changement
Posté par Patrick Lamaizière (site web personnel) . Évalué à 6.
Ce serait pas la première fois qu'on voit les gens changer d'avis. Par exemple Hal : ah ouais trop de la balle on va faire une abstraction pour le matériel. Quelques années plus tard : Hal ça pue on va faire udev…
Je dis ça…
les pixels au peuple !
[^] # Re: résistance au changement
Posté par totof2000 . Évalué à 3.
C'est justement ce que je reproche au monde Linux : vouloir toujours tout changer et tout révolutionner, puis se rendre compte que ce n'était pas la bonne solution ensuite puis rechanger pur un autre truc qui marche moins bien, et HAL est un exemple flagrant. Les scripts rc de NetBSD sont un exemple de propreté et de factorisation de code qui montre que des scripts, ce n'est pas si pourri que ça.
[^] # Re: résistance au changement
Posté par Zenitram (site web personnel) . Évalué à 5.
Donc en gros tu dis que tout ce que Linux a fait depuis des lustres c'est pas bien… Et bizarrement, c'est à ce moment-la que Linux a explosé en part de marché. Et après, tu vas nous dire qu'à cause de systemd, Linux sur les serveurs va chuter? ha ha ha… Tu t'enfonces tout seul…
Ce que tu reproches en fait, c'est que le monde bouge plus vite que toi et que ce qui a du succès est quelque chose que tu n'aimes pas.
[^] # Re: résistance au changement
Posté par totof2000 . Évalué à 1.
Enlève tes oeuillères : je ne parle pas de tout. Ou alors je me suis mal exprimé, ce qui est possible.
Tout simplement parce que entre une station ultra5 + Solaris à 25000 F et un PC + Linux à 10000F le choix est vite fait. Ce n'est pas parce que Linux faisait mieux que les autres, au contraire dans certains cas, il faisait moins bien, mais les DSI s'en sont accomodés pour de petits serveurs qui autrefois étaient gérés par des machines Unix bas de gamme mais qui coutaient quand même très cher. Linux sur les grosses infras critiques, c'est relativement récent.
Il restera cantonné aux petits serveurs et aux petites VM, et perdra les parts qu'il est en train de gagner sur les trucs un peu plus musclés. Ou alors ce sera une distrib adaptée, comme on en voit sur certains clusters spécifiques, pour lesquels il faudra payer cher une prestation d'adaptation/maintenance. Et les systèmes que je cotoie tous les jours qui aujourd'hui tournent sous AIX/Solaris resteront sous AIX/Solaris parce que le cout d'adaptation/maintenance du Linux ne sera pas rentable.
[^] # Re: résistance au changement
Posté par cedric . Évalué à 6.
C'est quoi ca F comme unite ? :-D
[^] # Re: résistance au changement
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 03 décembre 2013 à 07:02.
Une résistance au changement?
(désolé…)
N'empèche, je serai curieux de voir une station ultra5 datant d'avant le 1er Janvier 2001 encore en prod' et maintenue par son fournisseur (pareil pour un Linux d'avant 2001), 2001 étant l'année de disparition du F (il y a quasi 13 ans…).
[^] # Re: résistance au changement
Posté par madhatter (site web personnel) . Évalué à 6.
2001, c'est aussi l’apparition d'un certain Windows XP. Quasi 13 ans certes, mais encore pas mal en prod (malheureusement).
Ça ne nous rajeuni pas. :)
There is no spoon...
[^] # Re: résistance au changement
Posté par Zenitram (site web personnel) . Évalué à 3.
A noter que certes Solaris ne suit pas (le Solaris de 2001 = v8 étant officielement mort début 2012), mais HP-UX tient encore le high-score (la version de 2001 = v11i tenant jusqu'à encore fin 2015, soit quasiment 2 ans de plus que WinXP si Microsfot ne cède pas à la demande insistance de maintenir WinXP plus longtemps), après HP-UX v11i est sans doute moins en prod que WinXP :) (et surtout, c'est un OS "client", type qui n'a pas l'habitude d'être supporté aussi longtemps, les grande durée étant pour les serveurs).
Oh oui, la veillesse nous rattrape…
[^] # Re: résistance au changement
Posté par Maclag . Évalué à 8.
Si je ne m'abuse, à l'époque, le choix ne s'est pas fait sur FreeBSD, NetBSD, OpenBSD.
Le choix a été Linux.
En dehors de la licence, les caractéristiques sont d'un côté le développement est très dynamique, ce qui veut dire qu'on rajoute et on balance des trucs assez vite.
Du côté des BSD, l'approche est plus conservatrice (sans connotation péjorative aucune). On n'aime pas casser et on n'aime pas les révolutions.
Ma conclusion c'est que je ne crois pas une seule seconde que systemd puisse être déclaré "cause de pertes de parts de marché". Ça sonne comme une excuse à la con par un manager qui rate ses objectifs, ça.
[^] # Re: résistance au changement
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 02 décembre 2013 à 12:30.
Ce serait pas la première fois qu'on voit les gens résister au changement, et après quelques années plus personnes n'en parle, les gens ayant oublié et ceux qui étaient contre se gardant bien de rappeler qu'ils étaient contre. Par exemple… Euh… le droit de vote des femmes? (oui, je prend un gros exemple de la France arriérée qui a été en retard sur ce sujet, tout comme elle est en retard sur la mariage homo qui ressemble aussi au mariage blanc/noir pas bien, j'ai la flemme pour le software car justement on oublie et puis j'aime troller)
Je dis ça…
[^] # Re: résistance au changement
Posté par totof2000 . Évalué à 3.
Aucun rapport : restons dans la technique STP. Je ne suis pas résistant au changement, mais je n'aime pas le changement pour le changement. Il y a des changements assez réussi (on peut par exemple parler des changements sur l'ordonnanceur du noyau par exemple), /proc et /sys sont de bonnes idées (je ne dis pas que c'est parfait, notamment je trouve que les arborescences sont parfois complexes à retenr dans /sys et une commande faisant la modif au bon endroit serait parfois utile). Quitte à changer le système d'init, j'aurais préféré que ce ne soit pas aussi brutal, et qu'on s'attaque aux vrais problèmes. Là je vois urtout un gars qui a envie de faire parler de lui (et ça marche) et qui est parti dans son délire en voulant tout réécrire les fondamentaiux de Linux. En soit ça ne me gène pas, mais qu'il annonce la couleur de suite plutôt que de mentir comme il l'a fait, et qu'il appelle son OS Systemd/Linux et le présente comme une alternative à GNU/Linux. Parce que c'est bien vers ça que l'on va.
Je trouve l'attitude de Google beaucoup plus clean sur ce point, et Androïd une alternative intéressante à un GNU/Linux
[^] # Re: résistance au changement
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 02 décembre 2013 à 13:09.
Justement, il le fait, jsute que ça ne te plait pas de s'attaquer au problèmes, tu aurais préféré que rien ne change (donc les prolbèmes restent…)
C'est fou comme du monde suit son délire… Ou alors c'est pas une délire. Un délire, c'est plutôt des gens qui crachent dessus mais que pas foule ne suit finalement, non?
Hein? Moi qui croyais que systemd avait besoin de Linux (c'est d'ailleurs un reproche) et que Gnome (GNU Network Object Model Environment) était un projet GNU (alors qu'on critique gnome pour trop dépendre de systemd non?)…
Foutaises : c'est juste un élément parmis plein d'autres, et ça reste GNU et Linux… Seulement ça ne te plait pas que Linux (les distros) et GNU aillent dans cette direction. Tu veux juste "renommer" car la direction ne te plait pas, mais dommage pour toi, tu n'as aucun pouvoir de décision dessus vu que tu ne participes pas aux décisions. Que du crachat. Et sans que ça te fasse "tilt"? J'y peux rien, je ne fais que lire et déduire., et j'en reste impressionné.
# Juste une question
Posté par calandoa . Évalué à 4.
Je profite de l'empoignade sur systemd pour poser une vraie question technique :
Je veux lancer un programme au boot de ma machine, que ce programme renvoi un résultat que je place dans une variable d'environnement, et que cette variable soit accessible par la suite par tout le système.
Il y a un moyen de faire ça proprement ?
[^] # Re: Juste une question
Posté par Misc (site web personnel) . Évalué à 2.
Non.
Les variables d'environnement sont hérités par les processus fils, pas par les processus parents. Tout au plus, tu peux bidouillé en écrivant /etc/profile ou en faisant des trucs avec pam.
(ou tu peux faire un module moche dans le kernel pour écraser l'env des softs existants)
[^] # Re: Juste une question
Posté par calandoa . Évalué à 4.
De ce que je comprend, systemd est justement un seul processus qui traite les fichiers de configuration tout seul, à la différence de l'initialisation type System V ou BSD qui lancent des scripts dans des processus différents et qui ne peuvent pas remonter les variables vers init.
J'espérais donc découvrir la commande magique QuiResoudExactementMonProbleme= qui allait éviter une magouille en plusieurs temps.
Pas encore essayé, mais je pense maintenant à une première unit qui génère un fichier de conf dans /etc/sysconfig, puis à modifier display-manager.service avec EnvironmentFile= qui pointe vers le fichier en question.
[^] # Re: Juste une question
Posté par Misc (site web personnel) . Évalué à 3.
Je pense qu'il serait plus efficace de dire ce que tu veux obtenir comme résultat plutôt que comment tu veux implémenter ce que tu penses être une solution.
[^] # Re: Juste une question
Posté par calandoa . Évalué à 2. Dernière modification le 02 décembre 2013 à 20:19.
Heuuu…
Avec une précision : par « tout le système » j'entends les programmes que je vais démarrer depuis une session utilisateur.
[^] # Re: Juste une question
Posté par Misc (site web personnel) . Évalué à 1.
j'ai lu le truc vu que j'ai répondu.
Mais pourquoi utiliser une variable d'environnement et pas autre chose comme maniére de transmettre l'information, et entre quoi et quoi. Pourquoi au boot et pas à chaque fois, pour détecter quoi, etc, etc.
[^] # Re: Juste une question
Posté par Anthony Jaguenaud . Évalué à 1.
Une solution serait de mettre la variable d’environnement dans le fichier inittab… hélas, init n’a pas de syntaxe pour ça à ma connaissance.
Syntaxe de inittab
[^] # Re: Juste une question
Posté par gouttegd . Évalué à 3. Dernière modification le 02 décembre 2013 à 15:14.
Sous Slackware (mais ça doit être adaptable facilement sous une autre distribution), je ferais ça d’abord en ajoutant le code suivant dans
/etc/rc.d/rc.local:Le script
/etc/rc.d/rc.localest exécuté à la fin de la séquence de démarrage (sous Slackware, il est vide par défaut — il est précisément conçu pour que l’administrateur puisse y rassembler ses bidouillages) ; ici, il exécute le programme demandé et stocke le résultat (sous une forme sourçable par un shell, c’est-à-direnom=valeur) dans un fichier quelque part dans/var.Ensuite, dans
/etc/profile, ou dans un fichier quelconque dans/etc/profile.d(ces fichiers étant sourcés lors de tout démarrage de session), on vérifie la présence du fichier/var/state/resultats, on le source, et on exporte la variable dans l’environnement :(La variable n’est pas accessible depuis tout le système — en particulier, tous les processus démarrés dans les scripts d’init en ignoreront toujours l’existence —, mais elle sera accessible à tous les programmes démarrés depuis une session utilisateur.)
La présence de systemd (ou d’un autre système d’init non-classique) ne devrait pas changer grand’chose, dès lors qu’on peut insérer un bout de script shell quelque part à une étape du démarrage. Avec systemd, j’imagine qu’il faudra créer une unit uniquement chargée d’exécuter un script dédié.
[^] # Re: Juste une question
Posté par claudex . Évalué à 5.
Pas mal de distribution on une unit systemd qui lance rc.local, donc, ce que tu décris fonctionne aussi sur systemd (c'est peut-être même un comportement par défaut de systemd mais je ne suis pas sûr).
« 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: Juste une question
Posté par gouttegd . Évalué à 3.
Vérification faite (directement depuis l’archive source de systemd-208), c’est le cas : c’est l’unité « rc-local.service », qui exécute par défaut
/etc/rc.local(modifiable par--with-rc-local-script-path-startlors de la configuration de systemd).[^] # Re: Juste une question
Posté par lcld . Évalué à 5.
Depuis la version 207:
Et depuis la version 205:
Par contre, si la valeur de ta variable peut changer à chaque démarrage, le plus simple est apparemment d'écrire une unité qui se lance suffisamment tôt et qui utilise la commande
set-environmentdesystemctl.[^] # Re: Juste une question
Posté par calandoa . Évalué à 3.
Très utile, merci !
J'ai rajouté un service en début de boot qui me fait un petit :
ExecStart=/bin/sh -c 'systemctl set-environment MY_VAR=$(my_prog)'Et ça marche assez bien… sauf que
kded4n'a pas la variable en question (alors quekdml'a) donc elle n'est plus transmise à aucun programme… Bon, si même KDE s'y met, là, ça va devenir vraiment ardu.[^] # Re: Juste une question
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 3.
http://userbase.kde.org/Session_Environment_Variables
# Un vrai problème ?
Posté par Joris Dedieu (site web personnel) . Évalué à 10.
Au delà du troll l'auteur du patch semble pointer un vrai problème qui est la présence d'une interface utilisateur complète dans le noyau Linux. C'est l'option CONFIG_VT (activée par défaut sous RedHat et Debian et sur toutes les distributions que je connais).
Cela sert au noyau à afficher divers messages, à deboguer mais aussi et surtout à ouvrir plusieurs terminaux sur la même machine (ctrl-alt-F1 …).
L'auteur point du doigt que l'affichage des messages peut se faire de façon beaucoup plus simple avec par exemple fblog et que le débogage du noyau se fait habituellement par port série. Il pointe en outre que cette console dans le noyau pose divers problèmes notamment en terme d'occupation mémoire et de sécurité.
systemd se propose donc d'offrir un système de console alternatif permettant de désactiver le support des terminaux virtuels du noyau.
Ce qui est donc en cause ici est avant tout le support des VT dans linux et l'assertion selon laquelle il devraient être gérés en espace utilisateur.
A noter que Kmscon < http://www.freedesktop.org/wiki/Software/kmscon/> fonctionne déjà sans la couche VT du noyau.
[^] # Re: Un vrai problème ?
Posté par mdlh . Évalué à 10.
Le support des VT dans Linux est un sacre bordel.
Par exemple, je peux ecrire une appli console qui utilise drm pour gerer un affichage graphique. Par defaut, on ne peut plus changer de VT. Pour fonctionner, l'appli doit
demander a etre notifie d'une demande de changement de console pour que l'appli console arrete de jouer avec la carte graphics. Et encore la, faut la jouer sympa. Pire, tu peux
changer de console virtuelle tant que tu changes vers une console text. Pas possible de retourner sous X. Pour retourner sous X, tu dois d'abord lancer ton appli en tant que root pour pouvoir appler drmDropMaster(…) et drmSetMaster(…). Pour resumer:
- En tant qu'utilisateur simple, il est plus facile de prendre le controle de la carte et bloquer les autres VTs que d'avoir une appli qui s'integre bien dans l'environment.
- Pour s'integrer correctement, il faut etre root.
C'est un peu le monde a l'envers. Et c'est ce que le gentil monsieur essaye de corriger avec son travail.
[^] # Re: Un vrai problème ?
Posté par Joris Dedieu (site web personnel) . Évalué à 4.
Donc pour toi les VT sont clairement mal foutus ? C'est une vrai question, j'y connais rien.
Ça semble pas aberrant de gérer cela en espace utilisateur. Le noyau à priori n'as pas à fournir grand choses de plus que des tty. On a ceci dit du mal à imaginer comment gérer correctement les situations d'urgence. Typiquement l'usage que je vois des VT en mode noyau, c'est le lancement d'un debogueur suite à un panic.
[^] # Re: Un vrai problème ?
Posté par mdlh . Évalué à 3.
L'implementation actuelle des VT dans le kernel est pour moi effectivement mal foutu aujourd'hui. A l'epoque ou ca a ete implemente, cela avait du sens. Par contre je ne dis pas que d'un point de vue theorique on ne pourrait pas gerer les VT dans le kernel. Mais cela reposerai sur pas mal de pre-requis que l'on est pas pret d'avoir avant un moment et le passage par une solution dans l'espace utilisateur semble obligatoire pour l'instant.
Le premier qui me vient a l'esprit c'est d'avoir une API graphique interne dans le kernel pour que celui-ci puisse controller le changement de context graphique. Faisable si l'on considere seulement les drivers open-source. Mais vu combien de temps il a fallu pour avoir KMS supporte par ces derniers, et que les drivers proprio ne le supportent toujours pas, je pense que l'on peut attendre un moment.
De plus dans le contexte de la gestion multi-seat qui est gere dans l'espace utilisateur il me semble (j'y connais pas grand chose donc peut-etre je m'avance un peu), il faut une bonne coordination entre les deux. Donc autant avoir tout ca au meme endroit, dans l'espace utilisateur. Et le jour ou tout le monde est content et que l'on se rend compte que finalement, pour certaines raisons apparentes a ce moment la, ca serait mieux d'avoir cela dans le kernel, quelqu'un s'y collera surement.
# Singularité
Posté par Perthmâd (site web personnel) . Évalué à 5.
Mais la vraie question, c'est de savoir quand on va atteindre la singularité : le jour où systemd aura plus de features que Gnome, et réciproquement.
[^] # Re: Singularité
Posté par Spyhawk . Évalué à 8.
Ah, c'est pas déjà le cas?
# Session management
Posté par GaMa (site web personnel) . Évalué à 10.
Au passage je vous conseil grandement cette série d'articles de David Herrmann expliquant la gestion des sessions (ainsi que les problèmes soulevés par les nouveaux usages) sous linux.
http://dvdhrm.wordpress.com/2013/08/24/session-management-on-linux/
http://dvdhrm.wordpress.com/2013/08/24/how-vt-switching-works/
http://dvdhrm.wordpress.com/2013/08/25/sane-session-switching/
Très rapidement, il explique :
Je ne sais pas quel rapport ça a avec les derniers changements cités dans le journal. Mais ça met quand même bien en évidence les limites du système actuel et pourquoi il y a des mecs qui bossent pour pondre du systemd et cie au lieu de garder les trucs "qui marchent déjà" .
Matthieu Gautier|irc:starmad
[^] # Re: Session management
Posté par needs . Évalué à 0.
Après la lecture de ces articles, je suis encore plus persuadé que systemd (enfin ici systemd-logind) est une surcouche, et que tout le travail devrait être fait à un niveau plus fondamental : dans le noyau. Le système entier des sessions semble être un bordel monstre et plus du tout adapté aux besoins d’aujourd’hui. Et mettre une surcouche sur un système qui ne convient plus est vraiment, vraiment une mauvaise chose.
Vu l'état du truc actuellement, j'espère qu'on finira bien un jour ou l'autre par reprendre le système des sessions de zéro.
[^] # Re: Session management
Posté par Maclag . Évalué à 10.
Oui mais si quelqu'un écrit sessiond, on est reparti pour un tour de Trolls.
"Quoi? Un mec veut enlever un pan entier du noyau!? Quoi sessiond a plus de 2 binaires et fait un chouia plus que CONSOLE_VT?! Mais c'est une usine à gaz!"
[^] # Re: Session management
Posté par GaMa (site web personnel) . Évalué à 8. Dernière modification le 03 décembre 2013 à 10:21.
Justement, c'est ce qui est en train d'être fait.
Le but c'est clairement de virer les VT. C'est même le titre du mail cité dans le journal : "Bugfixes for CONFIG_VT=n". Les nouvelles fonctionnalités sont là pour virer les VT.
Que David Herrmann explique sur son blog que son système de gestion reste compatible avec les VT (voir les améliore) c'est compréhensible (voir nécessaire) mais le but in fine c'est de virer les VT.
Et systemd étant un daemon qui gère le système, il a toute légitimité pour gérer les sessions.
Je m'avance peut-être mais j'ai vraiment l'impression que c'est un changement qu'on voit un peu à tous les niveaux.
Quand je regarde ces changements j'ai justement l'impression qu'on est complètement en train de remettre à plat la gestion des sessions (notamment graphiques), des droits niveau accès matériel et autres…
Bizarrement il y a plein de gens qui râlent parce que systemd et wayland, ça fait pas la même chose qu'avant…
Matthieu Gautier|irc:starmad
[^] # Re: Session management
Posté par mdlh . Évalué à 2.
Juste pour preciser: Virer la gestion des consoles virtuelles du kernel. Pas pour virer purement et simplement le principe des consoles virtuelles.
# Next troll
Posté par cedric . Évalué à 3.
Bon, et bien, il a remis ca, un nouveau truc dans systemd, systemd-su ! J'attend avec impatience le prochain journal et sa fournee de troll de compete. On va encore rire.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.